Quoting Mark Sapiro <msapiro@value.net>:
Xueshan Feng wrote:
Quoting Mark Sapiro <msapiro@value.net>:
All four of them?
Only 3:
mailman:/var/lib/mailman/qfiles# ps -ef | grep Inco list 21394 21383 0 18:45 ? 00:00:17 /usr/bin/python /var/lib/mailman/bin/qrunner --runner=IncomingRunner:0:4 -s list 21395 21383 0 18:45 ? 00:00:13 /usr/bin/python /var/lib/mailman/bin/qrunner --runner=IncomingRunner:1:4 -s list 21396 21383 0 18:45 ? 00:00:15 /usr/bin/python /var/lib/mailman/bin/qrunner --runner=IncomingRunner:2:4 -s
A these 3 remaining ones would not do the work?
You are processing the 'in' queue in 4 slices with 4 IncomingRunner instances.
You do this by redefining or modifying the QRUNNERS list in mm_cfg.py. The entry in the list for IncomingRunner is
('IncomingRunner', 4),
That's exactly I have in our mm_cfg.py.
meaning that there will be four IncomingRunner instances processing slices 0:4, 1:4, 2:4 and 3:4 (the 3:4 runner is missing above).
Slicing works by dividing the queue entry hash space into slices (2^n in general, 4 in this case. Each slice has its own runner. A portion of each queue entry's name (the part between '+' and '.pck') is a 20 byte hash of a pickle of the message + the list name + the time of enqueueing expressed as 40 hex digits. In this case, the first quarter of the hash space is processed by the 0:4 runner, the second quarter by the 1:4 runner, etc. If one of the four runners isn't running, its portion of the hash space will not be processed.
Wow, that's interesting. I was wondering how the long file name was generated in the queue. For effective monitoring, I should check total qrunner instances to match up what's configured in mm_cfg.
Thanks for the explanation!
Xueshan