This paper start from what were left behind in the previous one.
It’s purpose is to further tests the capabilities and performance of oracle against different linux I/O scheduler.
The workload of choice is transactional. Horahammer is going to simulate a TPC-C workload while the scheduler will be switched dynamically.
The main difference compared to the first test is that the redologs have been relocated on another disk with a different I/O scheduler setting.
Since deadline has been the one with less wait event on the redolog it has been the scheduler of choice for the device of the redo logs.
The device sdc (a RAID 1) is going to host the redo logs and is set to deadline with default parameters.
The device sdb, hosting the datafile, will have its scheduler modified without interrupting the TPC-C workload.
Of course, hardware and DB remained the same.
No parameters of oracle and SUSE where modified.
Results:
For any scheduler you can see an AWR report following the below links:
noopanticipatorydeadlinecfq
| transaction per second | log file sync % | user calls | physical reads | physical writes | |
| noop | 151.74 | 8.6 | 705.11 | 310.14 | 214.27 |
| anticipatory | 126.32 | 6.9 | 586.14 | 260.42 | 179.45 |
| deadline | 154.94 | 8.9 | 717.67 | 317.77 | 216.99 |
| cfq | 51.33 | 0.5 | 238.90 | 107.69 | 82.31 |
Again the winner is deadline and again noop is close to it.
The worst performance seems to be given by cfq (the default scheduler *sigh*).
I tried to retest the deadline scheduler after tuning some of the available parameters but I couldn’t measure any significant variation.
Probably the workload rely mainly on merging while a marginal part can be improved by the I/O sorting algorithm.
A second test has been performed.
The different scheduler are tested with and without direct I/O and asynchronous I/O.
Results setting filesystemio_options=none:
| transaction per second | log file sync % | user calls | physical reads | physical writes | |
| noop | 152.36 | 8.6 | 705.49 | 308.85 | 213.97 |
| anticipatory | 125.63 | 7.1 | 580.85 | 255.18 | 179.27 |
| deadline | 150.80 | 8.7 | 698.20 | 310.96 | 212.79 |
| cfq | 56.81 | 0.7 | 264.32 | 117.92 | 87.84 |
The winner this time is noop while the worst scheduler for this workload remains cfq (the test has been repeated several times to be sure of the performance drop).
The absence of asynch I/O doesn’t seem to make a great deal of difference in the number of transaction per second (only deadline performance are worse).
What now if the direct I/O is enabled?
The I/O merging should be disabled as well as the filesystem caching.
Below the results of the test with filesystemio_options=setall.
| transaction per second | log file sync % | user calls | physical reads | physical writes | |
| noop | 138.76 | 7.5 | 645.24 | 288.37 | 193.82 |
| anticipatory | 123.20 | 6.8 | 580.85 | 253.20 | 178.53 |
| deadline | 139.58 | 7.8 | 648.43 | 291.79 | 199.89 |
| cfq | 51.22 | / | 237.86 | 108.19 | 81.52 |
Performance surely dropped but still it seems the scheduler got its importance.
As always cfq shows the worst behaviour.
To be noticed: deadline and noop schedulers, which showed the best performance during the previous test, had the highest performance drop.
Probably this is due to the impossibility of the I/O merging (as showed by iostat and the kernel statistics) induced by direct I/O.