[389-users] Multi-Theading writes to the same 389 Master Server

[Mark Reynolds]

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 
<https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Configuration_and_Command-Line_Tool_Reference/logs-reference.html#Access_Log_Content-Access_Logging_Levels>) 
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
> /
> /
> -Jeff
>
>
> --
> 389 users mailing list
> 389-users at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users

-- 
Mark Reynolds
389 Development Team
Red Hat, Inc
mreynolds at redhat.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/389-users/attachments/20130821/d31875cf/attachment.html>