Abstract
Informix Dynamic Server (IDS) can be configured to save the contents of shared memory (as well as readable evidence in an “assert file” and stack trace) either when a critical error occurs or a trap is in place for specific error numbers. This can help IBM diagnose a problem by running “onstat” commands off-line to examine the state at time of error.
However, if dumps happen repeatedly before the DBA can intervene, the file system nominated to store them may well fill. Saving a memory dump is also slow, intensive, and exclusive, so excessive repeats will further impede the instance, assuming it has stayed running, and if not will hinder any restart attempts until the dump has finished.
Managed Shared memory dumps is the latest configuration parameter settings in IDS 14.10.FC4 that enable limiting the number and/or frequency of such dumps. These enhancements are described in the updated documentation pages for DUMPSHMEM and DUMPCNT in the IBM Knowledge Center, but are missing from What’s New in IDS 14.10 so may not be as well known.
Content
The latest template configuration file “onconfig.std” contains these comments, with those in blue being new:
|
# DUMPSHMEM - Controls shared memory dumps. Acceptable values # are: # 0 Disabled # 1 Dump all shared memory # 2 Exclude the buffer pool from the dump # 5 Managed shared memory dumps, dumping all shared memory # 6 Managed shared memory dumps, excluding the buffer pool
# DUMPCNT - An integer representing the maximum number of shared memory # dumps or core files for a single thread, or, for managed # shared memory dumps, the extended format: # thrdlimit=<#>,instlimit=<#>,insttime=<#>,interval=<#> # where all parameters are optional and have these meanings: # - thrdlimit = max number of shared memory dumps per thread # - instlimit = max number of shared memory dumps for the # instance in the time period defined by # insttime. The default value value of 0 # implies no limit. # - insttime = time period in seconds for the limit of shared # memory dumps defined by instlimit. The default # is 0 which means no time limit and instlimit # then becomes a maximum count until the instance # is restarted. # - interval = minimum interval in seconds between the # completion of one shared memory dump before # another is permitted. The default is 300 seconds. |
- “onstat -g cfg full DUMPSHMEM” command output is incomplete.
- “onstat -g cfg full DUMPCNT” shows all of the above details.
In previous versions, recommended settings in the $ONCONFIG file (if not disabled) were:
In 14.10.FC4, we might want to allow only one shared memory dump in any 12-hour period:
You can force dumps on given error numbers with “onstat -I” which is used in this demonstration:
- Run 1 – unmanaged dumps, recommended legacy settings, new session saves one dump.
- Run 2 – managed dumps, dump saved as beyond interval of 5 minutes.
- Run 3 – managed dumps, no dump as within interval of 12 hours.
Alternatively, you can limit the number of dumps in a given time:
- Running 3 tests in quick succession only saved the first 2 dumps with those settings.
- Note that “insttime=0” would only have the count reset by restarting the instance.
The trap for error -206 was cancelled after testing with:
Conclusion
With IDS 14.10.FC4, the number of shared memory dumps can be managed to prevent a flood during repeated non-fatal error conditions, avoiding unnecessary server load, session blocking, and file system filling.
Disclaimer
Suggestions above are provided “as is” without warranty of any kind, either express or implied, including without limitation any implied warranties of condition, uninterrupted use, merchantability, fitness for a particular purpose, or non-infringement.
Contact us
If you have any questions or would like to find out more, simply contact us.
