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

[Ludwig Krispenz]

On 08/21/2013 05:29 PM, David Boreham wrote:
> On 8/21/2013 9:14 AM, Jeffrey Dunham wrote:
>> The reason I asked about nsslapd-threadnumber is because during the 
>> time of the spike, all transactions slow. Meaning that binds, adds, 
>> searches, ect. all start increasing in their etime until it hits the 
>> point where we've processed the majority of writes and then etimes 
>> fall back to 0.The customer in this case is doing 1k Adds to a 
>> subtree, an object with 10 attributes, three of which are indexed. 
>
> This is actually quite strange : the server is designed to allow 
> concurrent read operations while writes are in-flight. Initially I 
> thought you were asking about multiple concurrent writes interfering 
> with each other, which is plausible under some scenarios. However, 
> writes blocking reads is more surprising. This could happen of course 
> if there is contention for the underlying storage hardware : if the 
> search references entries that are not in-cache already, or index 
> pages that are not in the page pool, then it might wait on I/O already 
> queued by writes.
we don't have dedicated threads for read or write operations, in theory 
writes should not block reads, but if the write threads queue up for the 
backend lock there might be no threads available to do the reads
>
> One thing to note is that today you will see much (much!) better 
> performance with SSD storage (use some kind of reliable "enterprise" 
> SSD, not a random cheapo-drive intended for a laptop). One SSD will 
> give you an order of magnitude more write performance than even 
> multiple physical spindles. If it is the case that you're seeing I/O 
> contention, then deploying an SSD drive should entirely solve the 
> problem. Check the output from "iostat -x 1" while the spike is 
> underway -- if the util% is high, or the queue length builds up, then 
> you probably have an I/O bottleneck.
>
>
>
>
>
> -- 
> 389 users mailing list
> 389-users at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users