If there's no true backlog (eg, rs_ticket goes through right away) then (off the top of my head) I can think of a couple reasons for a delay in freeing up the queue's segments:
- DSI save interval has been set (config name = 'save_interval')
- DSI has been configured to allow non-blocking commits (config name = 'dsi_non_blocking_commit'); behind the scenes this implements an implicit save interval for the connection's recently processed segments
I'd want to get a detailed look at the queue's used segment count. Try running the following in the RSSD:
=======================
-- NOTE: For segments allocated to routes you'll need to join to
-- rs_sites (instead of rs_databases)
select db.dsname,
db.dbname,
s.q_type,
-- all segments that have been allocated to a queue
sum(case when s.used_flag >= 1 then 1 else 0 end) as alloc_count,
-- used but not-yet applied segments have used_flag = 1
sum(case when s.used_flag = 1 then 1 else 0 end) as used_count,
-- applied but awaiting cleanup segments have used_flag > 1
-- actual number represents when segment can be deallocated
sum(case when s.used_flag > 1 then 1 else 0 end) as saved_count
from rs_segments s,
rs_databases db
where s.used_flag >= 1
and s.q_number = db.dbid
group by db.dsname, db.dbname, s.q_type
order by 4 desc
go
=======================
If used_count is (relatively) large then you have transactions that haven't been applied to the RDB yet.
If saved_count is (relatively) large then your connection has been configured to save the transactions (on those segments) for some period of time.
Message was edited by: Mark A Parsons; added alloc_count to query