Pierangelo Masarati <[EMAIL PROTECTED]> 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. http://www.mvista.com/products/realtime.html > 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 -- Dieter Klünter | Systemberatung http://www.dkluenter.de N 53°37'10.08" E 10°08'02.82" GPG Key ID:8EF7B6C6
