PMDF System Manager's Guide

PMDF channel counters are intended for indicating the trend and health of your e-mail system. PMDF channel counters are not designed nor intended to provide an accurate accounting of message traffic; for precise accounting, instead see PMDF logging as discussed above in Section 31.1. The lack of accuracy in PMDF's channel counters in an inherent aspect of their design; it is not a bug. Specifically, PMDF's channel counters adhere to what Marshall Rose calls the fundamental axiom of management, which is that management must itself not interfere with proper system and network operation by consuming anything but the tiniest amount of resource.

Therefore PMDF's channel counters are implemented using the lightest weight mechanisms available, namely a shared memory section on each system (that is periodically synchronized to a disk database on OpenVMS). Channel counters do not try harder: if an attempt to map the section fails, no information is recorded; if one of the locks in the section cannot be obtained almost immediately, no information is recorded; when a system is shut down, the information contained in the in-memory section is lost forever. Section 31.4.2 and Section 31.4.3 provide further discussion of the implementation of counters.

31.4.1.1 Example of Counters Interpretation

Example 31-3 Sample of Counters Data

Channel Messages Recipients Blocks ------------------------ ---------- ---------- ---------- directory Received 6523 9042 69694 (1) Stored 4 4 149 (2) Delivered 6519 9038 69545 (6500 first time) (3) Submitted 6811 9019 71123 (4) Attempted 21 25 287 (5) Rejected 0 0 0 (6) Failed 0 0 0 (7) Queue time/count 100020/6519 = 15.34 (8) Queue first time/count 31525/6500 = 4.85 (9)

In this example:

1. The "Received" value represents a count of messages coming from any channel to the channel named directory; that is, messages enqueued ("E" records in the mail.log* file) to the directory channel by any other channel.
2. The "Stored" value represents a count of messages stored in the channel queue to be delivered. This will generally correspond to the number of entries currently stored for the channel in the PMDF queue cache database.
3. The "Delivered" value represents a count of messages which have been processed (dequeued) by the channel directory, i.e., "D" records in the mail.log* file. A dequeue operation may either correspond to a successful "delivery" (that is, an enqueue to another channel), or to a dequeue due to the message being returned to the sender. This will generally correspond to the number Received minus the number Stored. PMDF also keeps track of how many of the messages dequeued were dequeued upon first attempt; this number is shown in parentheses.
4. The "Submitted" value represents a count of messages which have been enqueued ("E" records in the mail.log* file) from the channel directory to any other channel.
5. The "Attempted" value represents a count of messages which have experienced temporary problems in dequeuing, i.e., "Q" or "Z" records in the mail.log* file.
6. The "Rejected" value represents a count of attempted enqueues to the channel which have been rejected, i.e., "J" records in the mail.log* file.
7. The "Failed" value represents a count of attempted dequeues which have failed, i.e., "R" records in the mail.log* file.
8. The "Queue time/count" represents the average time-spent-in-queue for the delivered messages. This includes both the messages delivered upon the first attempt---see ---and the messages that required additional delivery attempts (hence typically spent noticeable time waiting fallow in the queue).
9. The "Queue first time/count" represents the average time-spent-in-queue for the messages delivered upon the first attempt.

Note that in this example, the number of messages Submitted is greater than the number delivered. This is often the case, since each message the channel dequeues (delivers) will result in at least one new message enqueued (submitted) but possibly more than one. For example, if a message has two recipients reached via different channels, then two enqueues will be required. Or if a message bounces, a copy will go back to the sender and another copy may be sent to the postmaster. Usually that will be two submissions (unless both are reached through the same channel).

When interpreting counters values, keep in mind the discussion of Section 31.4.1: counters are neither intended nor expected to be to-the-message accurate. Rather, counters are intended to give a general idea of current message traffic trends, while causing as little impact as possible on actual operation; and counter information will be discarded rather than recorded whenever recording it would be burdensome for operation.