On 08/20/2013 10:39 PM, Jeffrey Dunham
wrote:
We have a customer that has been multi-threading
behind multiple servers and writing to our Master
server. These writes come in the form of heavy spikes
(1k over 5 second intervals) very much burst traffic and
all the writes are adding new items to the same ou.
While we have plans to throttle them I had a few
questions:
a) If they're writing to the same ou / updating the same
indexes are they blocked on one items success before
another succeeds?
Writing to the same the subtree is not an issue. Trying to update
the same entry at the same time might slow it down a bit. The
access log "etime" result(microsecond
logging) will tell you more during these bulk updates.
So in this case multi threading behind multiple boxes
does not give them any performance impact. I would guess
this is the case, but I want to be sure. Because
replication seems to be fine which goes through a single
thread iirc.
b) are there any performance tweaks that can help? I
thought maybe looking at nsslapd-threadnumber.
This setting usually doesn't need to be adjusted, as the performance
impact is not related to the number of threads, but what is being
updated in the db. Look at the "cn=monitor" output for the
backend(e.g. cn=monitor,cn=example,cn=ldbm
database,cn=plugins,cn=config). You really want the cacheHitRatios
to be as close 99% as possible. Then adjust the cache sizes if
needed.
Regards,
Mark
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
Mark Reynolds
389 Development Team
Red Hat, Inc
mreynolds@xxxxxxxxxx
|
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
