UNIX Acquire for Process Accounting - the results

We set out to see if running UNIX Acquire for Process Accounting actually has a high or low overhead on the UNIX host system and as promised the results are below:

The results

On AIX there was no measurable difference between the average elapsed time of the script with or without accounting enabled.  For each of the 15 times the script was run, it took 58 seconds of elapsed time, and the command termination rate therefore remained constant at around 172 per second.

The following table shows some of the key system measurements taken at various points:

From 15:00 to 15:18 and from 15:48 onwards are the times when the tests were not being run.

From 15:20 to 15:25 is when the test one was being run with no accounting active.

From 15:28 to 15:36 is when the test two was run with Process Accounting active.

From 15:38 to 15:47 is when the test three was run with both Process Accounting and Advanced Accounting active.

Of note are the following observations:

·         Not surprisingly the CPU busy jumps from 5% before and after to 60+% during all three tests;  this work is being run on an AIX system in an LPAR, so these numbers are only a logical view of the CPU needed to run the work.  Looking at the Number of Physical Processors Consumed metric shows that the second and third tests do not show any material difference in CPU requirements from the first test

·         The number of characters written/second increases from about 2,500 during test one, without accounting running, to about 25,000 for tests two and three; this is of course a ten-fold increase, but only from 2.5 KB/second to 25 KB/second.  This extra rate of data writing would hardly be noticeable on all but the poorest performing disks

·         The physical disk I/O rate does not change noticeably throughout the whole testing period.  These numbers are therefore inconclusive in terms of showing an effect on the disk subsystem of any significant additional load from either Process Accounting and/or Advanced Accounting.  The average response times on the single disk on this system were as follows:

Millesconds	Item
17.9	Overall average
17.8	Before testing
21.6	No accounting
15.7	PACCT only
16.7	PACCT and AACT
18.3	After testing

The PACCT file was reset to null before the testing began.  At the end of the tests two and three (where accounting was running) the PACCT file had grown to 5.8 MB, so for each test it required something like 2.9 MB to store data about 50,000 terminating commands.  The Advanced Accounting file was 10 MB in size and at the end of the final test had utilized about 9MB or 90% of that space.

Given that at least 50,000 commands had terminated in each test, this does not seem an unreasonable amount of disk storage to occupy in order to obtain greater detail about the work running on a machine.

It is of course necessary to provide management of the PACCT file to avoid running out of space in a file system, and there are simple commands and techniques to allow this to occur.  In addition, Metron’s Acquire utility does not require much in the way of a backwards view of commands, simply needing to see data timed at the start of a command in order to pick it up, at each capture interval.

For example, with a 15 minute capture interval, Acquire will request from the accounting system the details of all commands that have completed in the previous 15 minutes.  If the PACCT file has been “rotated”, e.g. from pacct to pacct.1, and a new pacct file started, Acquire accesses the previous file through a link in the Metron.save.d directory.  Therefore, providing the “old pacct” file is still present, (i.e. not deleted or zipped up), Acquire will pick up data for it.

This means that pacct files can be managed to avoid continual growth in the occupancy of disk space whilst not losing the detail of completed commands.

Other techniques such as placing the pacct file in its own file system can help to isolate problems should active management of the accounting data fail for some reason.

Conclusion

In conclusion the general belief that process accounting places a 10-15% overhead on a UNIX system cannot be seen to be true in the sense that there is no observable CPU overhead.  Neither is there a particular overhead associated with the writing of the accounting data.

The overhead of process accounting appears to be very low.

 

Nick Varley

Principal Consultant