man, 2003-01-06 kl. 21:40 skrev Derek Simkowiak:
> > I use Exim/ldap for all smtp under *very* stressful conditions.
>
> Numbers and hardware specs would be very nice. Remember that
> Exchange servers consider 500 users "very stressful" conditions... :)
Hi again. A bit late, but ...
I've nothing to do with Stanford University. Or Sun machines at all, at
the moment. Qanah's posting to the Openldap list is quoted below.
My own experience is based on a single overstressed machine where Exim
4.05 to Exim 4.12 and Openldap 2.1.2 to 2.1.8 parted company on high
loads. I have no specific figures that could help, but the breakpoint
was where there was 100% IDE disk activity (memory swapping,
Spamassassin) through the load and the machine itself more or less froze
up. the Whether it was due to Exim or Openldap, I don't know. My own
experience is, that this would not have happened with a reasonable SCSI
disk machine. The failure led to periodic myriad 550 rejects, for which
I did not become famous.
I'm deliberately refraining from giving the exact machine specs or
conditions, so don't ask. But I do use Spamassassin 2.50 for all mail
over 2 KB size, and Spamassassin is very greedy
However. As soon as Openldap 2.1.10 was installed with the same Exim,
same configuration, same Spamassassin, the 550 rejects stopped. There
have been *no* more 550 rejects under the same, foul, conditions. Heaven
be praised.
> > Exim/2.1.8 and previous would conk out under stress, Exim 4.1.12 and
> > Openldap 2.1.10 seems to be "self healing", [...]
>
> I'm using OpenLDAP 2.0.25, but have not stress tested it yet.
> Can you elaborate the definitions of "conk out",
"conking out" is the machine freezing up and Exim sending smtp 550 back
to mail servers, because it could not verify local users any more. "Can
not contact ldap server" was the symptom.
> "stress",
"Stress" is the machine freezing up through memory (swapping) and disk
overloading (read/write, bus design).
> and whether you
> saw this "conk out" with the OpenLDAP 2.0.x series?
Never, because I never tried 2.0.x. I use 2.1.x exclusively with
Berkeley BDB 4.x DB libraries, having initially tried a gdbm backend and
being frightened to death by a database with "holes" in it that kept on
growing.
For me the break point was Openldap 2.1.10 with BDB 4.1.24
People (also Openldap.org) state 2.0.x as being "stable". But the
Openldap designers and developers continually recommend upgrade to 2.1.x
because of shortcomings in 2.0.x. The only "stable" version of 2.0.x is
said to be 2.0.27, and development of the 2.0.x line is finished.
Heinz Ekker asked about large installations. He shouldn't as me, but ask
people like Qanah Mt-Gibson of Stanford University, address below, or
Howard Chu of Symas who know all about this:
Quanah Gibson-Mount <quanah@???>, Howard Chu
<hyc@???>
Lastly, those with real interest in Openldap really should subscribe to
the list: openldap-software@???. There's precious little Exim
presence there.
Best,
Tony
--
Fra: Quanah Gibson-Mount <quanah@???>
Til: openldap-software@???
Emne: Update on performance issues with Openldap 2.1.x and Solaris 8
Dato: Fri, 03 Jan 2003 11:53:43 -0800
Thought I'd send out an update on where Stanford is at since my last
mail:
We are now at 45 queries/second via GSSAPI binds sustained with 18 hosts
on a single CPU Netra T1. On a 3 CPU Netra 1405, we have gone up to 75
queries/second via GSSAPI binds, and it was apparent that this rate
could be pushed higher. If we were to use pooled connections, it was
found that we could get at least 120 queries/second.
We are currently running:
Openldap 2.1.10
Cyrus-SASL-2.1.10
Berkeley DB-4.1.24
Heimdal-0.5.1 (plus patches)
OpenSSL-0.9.6g
To achieve this massive performance increase (from about 4-6
queries/second), we hired Howard Chu as a consultant. He found the
performance problems I reported to be a combination of issues in
OpenLDAP, Cyrus-SASL, and Heimdal (and not, as was often suggested on
this list, problems with our setup). The changes he made to fix these
problems on the OpenLDAP side are in 2.1.10, and the same with
Cyrus-SASL. Howard submitted the fixes to Heimdal as well, but they
have as yet not released an updated version. Part of the performance
boost came in part with a new caching piece for Berkeley DB, so people
who are running the 2.1.x series with Berkeley DB as their backend, may
see an increase in performance if they move to 2.1.10 from older
versions.
<snip, original can be read on the list>
Regards,
Quanah Gibson-Mount
--
Quanah Gibson-Mount
Senior Systems Administrator
ITSS/TSS/Computing Systems
Stanford University
GnuPG Public Key:
http://www.stanford.edu/~quanah/pgp.html
--
Tony Earnshaw
When all's said and done ...
there's nothing left to say or do.
e-post: tonni@???
www: http://www.billy.demon.nl
