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.
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.