Max cache messages Option

The  option is available only as a global Job Controller option,.

The Job Controller keeps information about messages in an in-memory structure (the "queue cache database"). This is essentially a cached-in-memory index to the message files currently on disk. In the event that a large backlog of messages builds up on disk, the Job Controller may need to limit the size of this in-memory structure so as not to allow memory usage to grow excessively. If the number of messages in the backlog exceeds the Job Controller&#x27;s currently computed maximum messages value (see below -- the Job Controller uses the specified     value as a starting point, but during operation may  adjust that value up or down according to circumstances), then information about subsequent messages is not kept in the in-memory queue cache database. Mail messages are not lost because they are always written to disk, (and the disk queue area will get scanned by the Job Controller eventually, and remaining messages will then be detected and processed) but such messages are not considered for delivery until the number of messages known by the Job Controller drops to half this number. At this point, the Job Controller scans the queue directory mimicking an    command. The initial default for  is 100,000. But the Job Controller, while running, may adjust this size either up or down, depending on circumstances.

To manually adjust the effective   size "on the fly" (without having to restart the Job Controller to get a change to the   option to take effect), you may use the   utility: Note that exceeding the current maximum messages value means that subsequent messages can be expected to be processed "out-of-order". is not truly a performance-related option -- increasing it will not improve message throughput nor will decreasing it (unless decreased to an absurdly low number) have much effect on message processing speed. Rather, its purpose is to place a limit on the Job Controller&#x27;s memory usage, and its operational effect is to limit on how many messages the Job Controller will attempt to schedule in "first in, first out" order. The Job Controller&#x27;s scheduling is normally roughly "first in, first out", as modified by message processing priority,  response speed of destination being delivered to, and effects of "bunching up" messages to the "same" host onto  the same process and even process thread. But once the current maximum messages value is exceeded, the Job Controller is only attempting "first in, first out"  scheduling on the messages it has in its in-memory queue cache database; the remaining messages don&#x27;t get a shot at being processed until later (once the Job Controller initiated channel jobs have managed to deliver a lot of the original backlog of message). And scanned messages picked up via a disk scan (whether manually executed  or the Job Controller&#x27;s automatic rescans such as due to dropping sufficiently below the current maximum messages value), are all considered to be of lower processing priority than newly submitted, normal priority messages.
 * 1) imsimta cache -change global -max_messages=value

In legacy configuration mode,  was a deprecated  synonym for  ; that old   name is not a synonym in Unified Configuration, where it refers instead to a different option for the Message Store.

The default value is: 100000

See also:
 * Job Controller options
 * cache -change utility
 * cache -sync utility
 * Job Controller operation under stress