We’re seeing now after the 4.12.0 update that our (redis backed) QueuedTracking is not working as expected.
Our instances are oom-ing out once they collect too many trackker hits. We see a half-million hits in the monitor command output, but then running process is a noop?
Please advise:
/var/www/html $ ./console queuedtracking:process -vvv
Starting to process request sets, this can take a while
This worker finished queue processing with 0req/s (0 requests in 0.00 seconds)
/var/www/html $ ./console queuedtracking:monitor
Queue is enabled
Request sets in the queue will be processed automatically after a tracking request
Up to 1 workers will be used
Processor will start once there are at least 25 request sets in the queue
637680 (637680) request sets left in queue. 1.57G used memory (1.57G peak). 1 workers active.
637687 (637687) request sets left in queue. 1.57G used memory (1.57G peak). 1 workers active. ^C
/var/www/html $ ./console queuedtracking:process -vvv
Starting to process request sets, this can take a while
This worker finished queue processing with 0req/s (0 requests in 0.00 seconds)
/var/www/html $ ./console queuedtracking:monitor
Queue is enabled
Request sets in the queue will be processed automatically after a tracking request
Up to 1 workers will be used
Processor will start once there are at least 25 request sets in the queue
637736 (637736) request sets left in queue. 1.57G used memory (1.57G peak). 1 workers active. ^C