Messages in this thread | | | Date | Tue, 05 Mar 2013 14:42:49 -0500 | From | Waiman Long <> | Subject | Re: [PATCH v2 0/4] ipc: reduce ipc lock contention |
| |
On 03/05/2013 12:10 PM, Rik van Riel wrote: > On 03/05/2013 04:35 AM, Davidlohr Bueso wrote: > >> 2) While on an Oracle swingbench DSS (data mining) workload the >> improvements are not as exciting as with Rik's benchmark, we can see >> some positive numbers. For an 8 socket machine the following are the >> percentages of %sys time incurred in the ipc lock: >> >> Baseline (3.9-rc1): >> 100 swingbench users: 8,74% >> 400 swingbench users: 21,86% >> 800 swingbench users: 84,35% >> >> With this patchset: >> 100 swingbench users: 8,11% >> 400 swingbench users: 19,93% >> 800 swingbench users: 77,69% > > Does the swingbench DSS workload use multiple semaphores, or > just one? > > Your patches look like a great start to make the semaphores > more scalable. If the swingbench DSS workload uses multiple > semaphores, I have ideas for follow-up patches to make things > scale better. > > What does ipcs output look like while running swingbench DSS? >
For Oracle, the semaphores are set up when the instance is started irrespective of the workload. For a 8-socket 80 cores test system, the output of ipcs look like:
------ Semaphore Arrays -------- key semid owner perms nsems 0x00000000 0 root 600 1 0x00000000 65537 root 600 1 0xcd9652f0 4718594 oracle 640 226 0xcd9652f1 4751363 oracle 640 226 0xcd9652f2 4784132 oracle 640 226 0xcd9652f3 4816901 oracle 640 226 0xcd9652f4 4849670 oracle 640 226
The recommended kernel.sem value from Oracle is "250 32000 100 128". I have tried to reduce the maximum semaphores per array (1st value) while increasing the max number of arrays. That tends to reduce the ipc_lock contention in kernel, but it is against Oracle's recommendation.
-Longman
| |