[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: performance loss on real time linux

Pierangelo Masarati <ando@sys-net.it> writes:

> Dieter Kluenter wrote:
>> Hi,
>> I am at an early stage of deploying OpenLDAP running on Monstavista
>> Carrier Grade linux, with Linux-2.6 kernel but modified scheduler.
>> http://www.mvista.com
>> For this I compiled and installed OpenLDAP-2.3.27 on my TP T43
>> notebook and on a x86 Carrier Grade hardware, I'm not sure about the
>> processor manufacturer and type of this hardware.
>> On both machines identical DB_CONFIG files, slapd.conf and data have
>> been set up. I created only 10,000 entries as this would the expected
>> average database size be.
>> A ldapsearch on localhost with SuSE-9.3 Linux, after some warming
>> up the results were levelling at
>> Due to a real time scheduler I was expecting the results to be vice
>> versa.
>>   Can a RT scheduler or other modifications to the operating system
>> have
>> a negative influence on performance of OpenLDAP?
> You can't expect results to be any better than under non-RT os, since
> a RT-scheduler will always add overhead to non-RT processes since it
> will preempt much more than a normal OS.  I have no experience with
> Monta-Vista, however my institution (Politecnico di Milano) develops
> RTAI, the Real-Time Application Interface for Linux
> (http://www.rtai.org/); I'll check what happens when running OpenLDAP
> with that.
> In the meanwhile, can you tell something more about Monta Vista's
> handling of RT?  Does it include the PREEMPT_RT patch, which will
> likely become part of Linux in a year or so, or does it rather
> implement some custom support to handle preemption?

I don't know much about Montavista yet, as they are more than
restrictive about their information policy. But they claim to have
introduced a preemtive kernel in 1999 and their preemtive patch is now
a standard kernel option for 2.6 kernels.

> About your test: are your results an average over a realistic number
> of trials?  Is the database entirely in cache or does it require any
> access to disk?  Mallocs under a real-time scheduler might also
> represent a significant bottleneck; in this case, slapd should really
> handle memory internally, to minimize the amount of system calls.

My results are actually the last result of about 20 test runs, but
after a warm up time of 5 runs, they didn't vary much.
Both machines have 2GB ram and this are the settings for DB_CONFIG

set_lg_dir /opt/openldap/ldapDB 
set_cachesize 0 20000000 0 
set_lg_regionmax 262144 
set_lg_bsize 2097152 

I didn't notice hardly any disk access during the initial tests.


Dieter Klünter | Systemberatung
N 53°37'10.08"
E 10°08'02.82"