[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: performance loss on real time linux
Hello Ando,
Pierangelo Masarati <ando@sys-net.it> writes:
> Dieter Kluenter wrote:
>>>> Due to a real time scheduler I was expecting the results to be vice
> Dieter,
>
> I don't know how much this could be of any help, but today I tried to
> run a simple test using OpenLDAP 2.3.28 running on Linux 2.6.17 with
> RTAI, compared to the stock 2.3.6.15 kernel f the distribution used on
> that PC. I created a database with ~10000 users, fully indexed and
> fully cacheable (cachesize 10000). What I found (strange enough) is
> that the execution time of ldapsearch would differ a lot on the two
> systems, but sort of the reverse of what you experienced. I checked
> few cases:
>
> - entry not yet in cache vs. entry already in cache
> - system unloaded vs. system heavily loaded
>
> in the case of RTAI, I also considered some hard real-time load, which
> gets the highest priority and accurate scheduling.
>
> - searching for an entry not in cache, w/ RTAI, requires a little bit
> longer than w/o RTAI; this requires access to disk; but
> - searching for the same entry, after it's in cache, requires ~0.008s
> w/ RTAI, and ~0.080s w/o RTAI (ten times longer! It's a slightly
> different kernel, but running on exactly the same machine, so, without
> too much investigation, I have no clue about the exact reason)
>
> - under load (repeated disk and network access), the above entry in
> cache times are occasionally delayed, but not that much, on both
> systems. w/ RTAI the average goes to ~0.010s, with peaks to ~0.020s;
> w/o RTAI no significant extra delay is added to the ~0.080s. The
> latter case makes sense, since the system already appears
> significantly delayed.
>
> - under hard RT load (30% of one CPU, and 15% of the other CPU on a
> dual CPU system), performances drop significantly; occasionally, the
> response time for not-in-cache entry, which requires access to disk,
> may raise to ~0.500s, with an average above ~0.100s. The response
> time when the entry is in cache is not significantly worse than in the
> case with non-RT load, ~0.020s.
>
> This seems to indicate that with a (possibly) different hard RT
> scheduling there is no significant impact on basic OpenLDAP's slapd
> performances, so its design seems to have no impact on its execution
> in conjunction with RT schedulers. I have no clue, right now, about
> how the two RT systems compare.
>
> I would like to acknowledge the support of Paolo Mantegazza, the main
> developer of RTAI, in performing those tests with a devel snapshot
> (called "magma") of that system; it should not differ from recent
> releases (3.4) in terms of scheduling policies and related issues.
Thank you for your test and report and thanks to Paolo Mantegazza. I
think I have to dive a bit more into Montavista scheduler and have
a chat with their support.
-Dieter
--
Dieter Klünter | Systemberatung
http://www.dkluenter.de
N 53°37'10.08"
E 10°08'02.82"
GPG Key ID:8EF7B6C6