|
|
Re: return_job and the difference between imsimta view database | directory: msg#00057mail.ims.general
Inline... Peter Coates wrote: The reported behaviour of the qm command at restart is strange. At start There was a bug found recently with job_controller not sending all files to the return job. So return had to be run multiple times for all appropriate messages to get processed. 6572478 Only subset of messages provided by the job controller to return job fixed in 120228-22/126479-03 (et al) for 6.3 (more below...) The defaults for all my channels include: I am not sure what you mean by "nonexistent". Yes, having many files in the MTA queue directories can be a performance drag due to file system directory inefficiencies. Hence the subdir channel keyword. So if you normally have so many messages in a channel queue, you would want to increase subdirs on that channel. Also, having so many files will cause job_controller more work when you restart it or when it performs its check of the channel queues every 4 hours. (one other thought on "performance" impact, see below, after we define some more terms...) Other than that, those files have no direct bearing on job_controller or SMTP client performance. As for which qm summary is telling the truth, they both are. The directory view tells you about the files in the channel queue directories. The database view tells you about the messages job_controller knows about. (A third variable can come into this: .HELD messages would *never* be known by the job_controller.) Some ways a valid file could be in the channel queue directory and job_controller not know about, might be: - you recently moved it there - you just restarted job_controller - it was being processed by a channel master program that crashed - it has wrong ownership/permission - really isn't valid (ie job_controller has some problem handling it) job_controller initially learns about a new message in the channel queue when the message is enqueued. The enqueuing process notifies job_controller. As long as the number of messages job_controller knows about in all channel queues has not exceeded MAX_MESSAGES (default 100,000), job_controller adds the message to its internal database. So directory view and database view should be consistent. When you restart job_controller, it starts with an empty internal database and begins scanning the channel queue directories. This can take some time. So it is normal to expect directory view and database view to be different until job_controller finishes that scan. The design of that scan has been has been improved in 6.3. From the 6.3 release notes: (166) The Job controller directory sweep is now more sophisticated. Instead of reading all the files in the queue directory in the order in which they are found, it reads several channel queue directories at once. This makes for much more reasonable behaviour on startup, restart, and after max_messages has been exceeded. The number of directories to be read at once is controlled by the job controller option Rebuild_Parallel_Channel. This can take any value between 1 and 100. The default is 12. If a message is being worked on by a channel master program and the program crashes, job_controller has no way to know that happened. So it thinks the message is still reserved by that process. So it will not be until the next every 4 hour scan that it notices the message is still there and re-adds it to the database view. Before I turned on job_controller debugging... If you are frequently restarting job_controller, then stop doing that. If job_controller needs to be restarted frequently, let's focus on that problem. Look in job_controller log file for any clues. Otherwise, look at a few of the older files that are not in the database view. When were they tried last? Anything different about their ownership or permissions? etc... If they are .HELD messages, then that is one thing. But I doubt that is the case because you are not seeing them with qm sum -held, just qm sum. Having so many files (if your MAX_MESSAGES is set to (or default) 100,000) also means that if job_controller did learn about all of them, it would probably stop listening about new messages entering the queues. So job_controller could be stuck only working on existing messages in the queue. ie, you restart it; it starts finding the 74,000 messages that are already in the queue; it processes them as it finds them; it also adds and likely processes any new messages entering the queue; if the total in the database view touches MAX_MESSAGES, then job_controller stops listening about new ones entering the queue; when the total drops below (I think it is 75% of MAX_MESSAGES), then it starts listening again, but it also has to deal with all those messages that entered the directory view but not the database view, while it wasn't listening. And if the old messages are not deliverable for some reason, this continually becomes a tighter squeeze. So if you are restarting job_controller occasionally and many of those 74k messages should have been returned, that may be the problem. Do you already have a case open about this? ( I recognize those channel names ) Kelly Donald Richardson |
|
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| Previous by Date: | Re: Load problem with ims 5.2: 00057, Rich Bishop |
|---|---|
| Next by Date: | Re: custom 55x error message for specific email addresses: 00057, Kristin Hubner |
| Previous by Thread: | RE: return_job and the difference between imsimta view database | directoryi: 00057, Peter Coates |
| Next by Thread: | outlook connector and email aliases: 00057, tomvo-hTDmKBYT6Sw |
| Indexes: | [Date] [Thread] [Top] [All Lists] |
| News | FAQ | advertise |