Messages are stored in a database. The distribution of users on disks, the size of their mailbox, and disk requirements affect the store performance. These are described in the following subsections:
stored performs a variety of important tasks such as deadlock and transaction operations of the message database, enforcing aging policies, and expunging and erasing messages stored on disk. If stored stops running, the messaging server will eventually run into problems. If stored doesn’t start when start-msg is run, no other processes will start. For more information about stored see stored in Sun Java System Messaging Server 6.3 Administration Reference.
There are no outward symptoms.
Check that the stored process is running. stored creates and updates a pid file in msg-svr-base/data/proc called store. The pid file shows an init state when recovering and a ready state when ready. For example:
231: cat store 28250 ready |
The number on the first line is the process ID of stored.
232: ps -eaf | grep stored inetuser 28250 1 0 Jan 05 ? 8:44 /opt/SUNWmsgsr/lib/stored -d |
Check for log file build up in msg-svr-base/store/mboxlist. Note that not every log file build up is caused by direct stored problems. Log files may also build up if imapd dies or there is a database problem.
Check the timestamp on the following files in msg-svr-base/config:
stored.ckp - Touched when attempt at checkpointing is made. Should get time stamped every 1 minute stored.lcu - Touched at every db log cleanup. Should get time stamped every 5 minutes stored.per - Touched at every spawn of peruser db writeout. Should get time stamped every 60 minutes
Check for stored messages in the default log file msg-svr-base/log/default/default
Can be monitored with watcher and msprobe. See 4.5 Automatic Restart of Failed or Unresponsive Services and 27.8.9 Monitoring Using msprobe and watcher Functions.
The state of database-locks is held by different server processes. These database locks can affect the performance of the message store. In case of deadlocks, messages will not be getting inserted into the store at reasonable speeds and the ims-ms channel queue will grow larger as a result. There are legitimate reasons for a queue to back up, so it is useful to have a history of the queue length in order to diagnose problems.
Number of transactions are accumulating and not resolving.
Use the command imcheck -s (used to be counterutil -o db_lock)