Re: CFS scheduler OLTP perforamnce

["Gilles.Carry" <Gilles.Carry@ext.bull.net>]

Peter Zijlstra a écrit :
> On Fri, 2008-12-12 at 13:12 +0100, Peter Zijlstra wrote:
>> On Thu, 2008-12-11 at 16:25 -0700, Ma, Chinang wrote:
>>> We are evaluating the CFS OLTP performance with 2.6.28-c7 kernel. In
>>> this workload once a database foreground process commit a transaction
>>> it will signal the log writer process to write to the log file.
>>> Foreground processes will wait until log writer finish writing and
>>> wake them up. With hundreds of foreground process running in the
>>> system, it is important that the log writer get to run as soon as data
>>> is available. 
>>>
>>> Here are the experiments we have done with 2.6.28-rc7.
>>> 1. Increase log writer priority "renice -20 <log writer pid>" while
>>> keeping all other processes running in default CFS priority. We get a
>>> baseline performance with log latency (scheduling + i/o) at 7 ms.
>> Is this better or the same than nice-0 ?
>>
>>> 2. To reduce log latency, we set log writer to SCHED_RR with higher
>>> priority. We tried "chrt -p 49  <log writer pid>" and got 0.7% boost
>>> in performance with log latency reduced to 6.4 ms.
> 
> BTW, 6.4ms schedule latency sounds insanely long for a RR task, are you
> running a PREEMPT=n kernel or something?
> 
> How would you characterize the log tasks behaviour?
> 
>  - does it run long/short (any quantization)
>  - does it sleep long/short - how does it compare to its runtime?
>  - does it wake others?
>    - if so, always the one who woke it, or multiple others?
> 

To this, I would add these questions:
- do you have the source code of the DBMS? Are you sure that the 
timestamp you get corresponds to the very beginning of the wakeup time?
- if many foregroud tasks write data onto a buffer which is later read 
by the log writer, there may be locks (mutexes?) involved and the log 
writer is supposed to wait for lower prio tasks to release the lock.

Gilles.