On 08/21/2013 09:29 AM, 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.
Two other cases:
1) There are so many write threads that there are not enough threads
available for search requests.
2) The write lock on a database page acquired for a write operation will
block search requests that attempt to acquire a read lock on the
database page.
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.
+1
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
