On 2010.10.21 16:38, Bowie Bailey wrote: > On 10/20/2010 6:06 PM, Sam Varshavchik wrote: >> Bowie Bailey writes: >> >>> >>> What is the behavior if the queue size never goes above queuelo? How >>> often does Courier check queuelo and attempt to refill the memory queue? >> >> If the queue size never reaches queuelo, everything is tracked in >> memory. I think. >> >>> Since I have plenty of resources to spare on this machine, should I >>> decrease queuefill? >> >> I don't think this would make any difference. As I understand it, you >> had a massive number of messages that got dumped into your queue. >> That's it. Anything that was added to the queue afterwards takes a >> back seat. Older messages take priority, and won't be dealt with until >> the older messages are done. Now, if the older messages' delivery >> attempts failed and were rescheduled, they should get rescheduled >> after the newer messages, so the newer messages should eventually be >> gotten around to, before the messages to be retried. > > The problem was that there were 5000 total recipients. So the initial > delivery attempts took forever. I saw some inconsistent behavior with > new messages. Sometimes the new messages would come in and be > delivered. Other times the new messages would get held in the queue. > >> But as far as I understood you, you just had a bunch of messages >> dumped that took up all your bandwidth. That's all. > > Right. It took about 14 hours to process the initial delivery attempts. > > The only thing I can think of that would be useful for me in this > situation would be to have a dedicated process for delivering to my > internal server. Basically some way to tell Courier that there should > always be at least one delivery process available for a particular > server. This way, regardless of how busy the queue gets, incoming > messages would not get delayed.
I think that little bit modified scheduler would help you. As I understand now the scheduler chooses message with min(time_submitted). If it would choose message with min(time_submitted_or_network_used + megabytes_sent*penalty_per_meg) then those messages now congesting your network, would be delayed until messages without penalties are sent. How to count megabytes_sent? Ideally, per sender. But this may be difficult to implement. And this would need some mechanism how to write-off accumulated amount periodically. Therefore, calculating per message would be sufficient compromise: you have message with 100 recipients located on 10 different servers; you deliver to the group on the first server, and add message size to megabytes_sent; if there are new messages, those will be sent now; deliver to the second server--add again; and so on. In case of heavy backlog, just megabytes_sent*penalty_per_meg may be insufficient to let new messages first. It's possible to increase penalty manually and adjust, but taking into account time of last DATA or QUIT command instead of time_submitted would make that adjustment not necessary. And, I'm not against fair order for message sending. I just want to be fair per user, not per message. -- Aidas Kasparas IT administrator GM Consult Group, UAB +370 686 08473 http://www.gmc.lt ------------------------------------------------------------------------------ Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev _______________________________________________ courier-users mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
