The query output is showing the WLWEB_RS queue with 3,010 active (ie, in-use) segments.
==========================
db.dsname+'.'+db.dbname q_number q_type active saved
------------------------------ --------- ------ ------ -----
WLPROD_R2.ics 105 1 1 0
WLPROD_R2.ics_aux 106 1 1 0
WLPROD_RS_RSID.WLPROD_RS_RSID 101 1 1 0
WLWEB_RS 16777318 0 3010 0
==========================
It would appear that you have a route from your current repserver to a downstream repserver named WLWEB_RS. And the outbound queue associated with this route is currently using up 3,010 segments (~3GB).
Can't tell from what's been posted so far what the issue is so fwiw ...
1 - make sure the WLWEB_RS repesrver is up and running
2 - review both repserver errorlogs (current repserver; WLWEB_RS repserver) for any messages related to route/RSI issues
3 - make sure 'admin who_is_down' does not show any down threads in either repserver; for good measure, in the current repserver, suspend and then resume the route to WLWEB_RS just to make sure there's no issue with a hung thread
4 - if your RSSD resides in a ASE dataserver, review your ASE and repserver errorlogs for any occurrences of the ASE dataserver being bounced while the repserver was still up and running; generally speaking the repserver should always be shutdown if/when the ASE/RSSD goes down. [Just worked with a client on Monday ... ASE/RSSD crashed over the weekend while the repserver was up and running; since repserver needs to communicate with RSSD at all times, several repserver threads went into a hung state when the ASE/RSSD crashed; in this instance the outbound queue for a route from an upstream repserver was backed up because this repserver's RSI/route user thread was hung; client had to bounce repserver to clear up the hung threads.]