Internal size MTA options

From Messaging Server Technical Reference Wiki
Jump to: navigation, search

The MTA has a number of options that control internal MTA table sizes. These options do not normally need to be adjusted manually. Although they provide "starting points" (and maximums) for the sizes of various internal memory tables, the MTA will resize its internal tables as necessary when running. In particular, use of the imsimta cnbuild command will cause resizing to accomodate the current configuration size (and then all subsequently started processes will use the compiled configuration sizes). If a compiled configuration has not been created, then each process when it initially starts will need to do the resizing itself. Thus the penalty for not having "good" values set for these options is merely a little initial overhead---either overhead only for the imsimta cnbuild command when a compiled configuration is used, or overhead for each starting process when a compiled configuration is not used. In other words, the relevance of these options is limited mostly to "fine-tuning" memory usage, and providing a modest performance benefit for the imsimta cnbuild command (or for all starting processes if a compiled configuration is not in use).

For those who do wish to ensure that these options are set to values matching the MTA's real memory needs, using the imsimta cnbuild utility, that is, using a command such as the UNIX command

# imsimta cnbuild -noimage_file -maximum -option_file

is usually the best approach (letting the MTA tell you what values it needs, rather than trying to guess values and manually set them yourself). The above command will output MTA options (stored in the MTA option file in an legacy configuration) with sizes adequate for the current configuration, plus some growth room. (Note that the above shown command does not actually compile the configuration using these sizes; that would require an additional imsimta cnbuild command. Rather, the above command determines appropriate sizing, and outputs corresponding MTA option values; such values could then be used in any subsequent MTA process invocation and in particular, in a subsequent imsimta cnbuild command.)

Since the MTA will resize its internal table sizes as needed, errors about exceeding table sizes are normally seen only if the MTA's more-or-less "hard" limits on resizing are reached. (The limits are established by the maximum.dat file and/or "hard" limits in the code.) And since the MTA's "hard" limits are very generous, exceeding the limits is usually an indication of either a configuration error of a type that has confused the MTA about the intended meaning of certain configuration inputs (for instance, an extraneous blank line in the rewrite rules, causing the MTA to attempt to interpret all remaining material as channel definitions), or configuration choices involving poor use of MTA facilities that would be better handled in an alternate manner (such as attempting to hard code many thousands of mapping table entries, rather than using a few general entries that do general database callouts for the specific fields). In particular, reaching the limits specified in the normal maximum.dat file is usually an indication of poor configuration choices; you should contact Oracle if you believe you wish to exceed those limits, as you may be better served by alternate configuration tactics.

Note: Historically, the default values, maximum size achievable through automatic resizing, and "hard" limits for these options have been prone to change (particularly increase) during and especially between releases, to a rather greater extent than for most other options. So although a diligent attempt has been made to provide correct numbers as of press time, the on-going quest to improve performance and scalability may mean that these documented values become out-of-date.

See also: