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 33.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 33.4.2 and Section 33.4.3 provide further discussion of the implementation of counters.
220.127.116.11 Example of Counters Interpretation
Example 33-3 shows a sample excerpt of counters data, as might be
seen using the PMDF COUNTERS/SHOW (OpenVMS) or
-show (UNIX and NT) utility.
|Example 33-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)
mail.log*file) to the directory channel by any other channel.
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.
mail.log*file) from the channel directory to any other channel.
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 33.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.