Tuning system call activity

Case study: semaphore activity on a database server

In this study, a site has installed a relational database on a multiprocessor system. The database gives the choice of using System V semaphores or the sleeper driver (sometimes called the post-wait driver) to synchronize processes. The object is to investigate which of these options will maximize the number of transactions that can be processed per second and the response time for the user.

System configuration

The system's configuration is as follows:

Multiprocessor -- 2 Pentium 60MHz processors.
EISA bus.
96MB of RAM.
96MB of swap space.
14GB of hard disk (two arrays of seven 1GB SCSI-2 disks).
One Bus Mastering DMA Ethernet network card with a 16KB buffer and 32-bit wide data path.

The database server does not act as host machine to any users directly; instead there are five host machines connected to the LAN which serve an average of 100 users each.

Defining a performance goal

The performance goal in this study is to compare the performance of the database when using System V semaphores and when using the sleeper driver.

NOTE: To configure the sleeper driver into the kernel, change the second field of the line in the file /etc/conf/sdevice.d/sleeper to read ``Y''. Then relink and reboot the kernel.

Collecting data

To monitor the performance, an in-house benchmark is used for an hour with the system configured to use System V semaphores, and then with it using the sleeper driver. The benchmark measures the minimum, maximum, and average transaction times and the total throughput in transactions per second.

The result of running the benchmark is that the best performance is achieved using the sleeper driver.

Formulating a hypothesis

When the database is using System V semaphores, the system may be spending too much time in kernel mode executing semaphore calls. The benchmark run using the sleeper driver gives better results because it is an enhancement specifically aimed at improving the performance of relational databases. It allows an RDBMS to synchronize built-in processes without the high overhead of switching between user mode and system mode associated with System V semaphores.

Getting more specifics

To test the hypothesis, mpsar -u is used to display the time that the system spent in system mode while each benchmark was being run. For the benchmark using the sleeper driver, typical results were:

   13:55:00    %usr    %sys    %wio   %idle
   ...
   14:20:00      75      20       2       3
   14:25:00      72      23       1       4
   14:30:00      69      24       5       2
   14:35:00      77      19       4       0
   ...

The averaged performance of all the CPUs was excellent with low percentages spent in system mode, idle waiting for I/O, or idle.

For the run using semaphores, the results were:

   16:08:00    %usr    %sys    %wio   %idle
   ...
   16:48:00      55      38       6       0
   16:43:00      59      32       7       2
   16:58:00      61      34       4       1
   16:53:00      58      38       2       2
   ...

The system spends more time in system mode and waiting for I/O when System V semaphores are used. The benchmark results indicate that transaction throughput and response time are approximately 10% better when the sleeper driver is used.

Making adjustments to the system

The database is configured to use the sleeper driver as this provides the best performance for the benchmark. The system should be monitored in everyday use to evaluate its performance under real loading.

Vendors of the database management systems are continually improving their products to use more sophisticated database technologies. If you upgrade the database management system to a version that supports POSIX.1b semaphores, you may need to evaluate if these should be used instead of the sleeper driver.