On 7/23/2010 1:35 PM, Howard Chu wrote:
passwordSync: What are you thinking here? DLL that recognizes password
changes and creates apropriate hashes and syncs these into OpenLDAP, or
Yes. Bi-directionally, of course - it should also intercept LDAP
passwordModify requests and forward them to A
Gavin Henry wrote:
Thanks for all this Howard. It certainly makes it clear where OpenLDAP
lies in the LDAP world (looking down from the top and around at
everyone else ;-) ).
Hmm...not so sure about the 'everyone' part because
I added this feature (parallel import with correctly implemented
par
Howard Chu wrote:
It's pretty amazing to watch the processor status in top and see an
entire CPU consumed by interrupt processing. That kind of points to
some major walls down the road; while any 1GHz or faster processor
today can saturate 100Mbps ethernet, it takes much faster processors
to f
Howard Chu wrote:
But again, using O_DIRECT means every I/O is synchronous, so I guess
that might wreak havoc on any queuing optimizations in the fs.
And readahead, if it's working for the application.
In my tests I ran a battery of workloads, not just operations that
benefitted from a warm,
Howard Chu wrote:
I think the difference is so small because the caches were already at
a 99% hit rate; very few requests would actually need to do I/O.
Right, that was my concern. When I tried this (was done on both Linux
and NT),
I saw performance in the non-100% hit rate case fall signifi
With this patch, a slapd that occupies 6.8GB on a system with 8GB of
RAM can run continuously without swapping, delivering a sustained
11,500 authentications per second. Without the patch, swapping starts
when the process hits the 4.5GB mark (because over 3GB of buffer
cache is in use), and
> Why we can not search any info during the client is normally
running? But
> once I rebooted the client site, it worked well and could accept search
> requests? How to solve this problem:)
There are quite a few potential problems with your approach.
The first one that comes to mind is th
Howard Chu wrote:
What's also interesting is that for Hoard, Umem, and Tcmalloc, the
multi-threaded query times are consistently about 2x slower than the
single-threaded case. The 2x slowdown makes sense since it's only a
dual-core CPU and it's doing 4x as much work. This kinda says that the
Howard Chu wrote:
Kinda interesting - with hoard this shows us processing 23000 entries
per second in the single-threaded case, vs only 3521 per second with
glibc malloc.
It is possible that you are seeing the syndrome that I wrote about here:
http://www.bozemanpass.com/info/linux/malloc/Linu
Comments?
The last time I tried this many years ago the thing floundered on
the details of isolation. So you might watch out for that :
clients will want to see varying levels of isolation depending
on their goals. For example a client may want to see the
effects of their updates reflected
Oni (Paolo Meschi) wrote:
Thanks for the clarification.
I understood that this behaviour will violate the specifications,
however this should be useful to some people. So the possibility to
compare the userPassword hashed value with a cleartext value, for the
standards sake, should be implement
Kurt D. Zeilenga wrote:
The current behavior is not considered a bug and hence
it doesn't need "fixing". See RFC 2251/2252/2256.
I'm fairly sure that the behavior of the Netscape (and hence Sun)
server was unintended. The code that does the hashing of the comparison
value is deeply buried i
12 matches
Mail list logo
