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.
-- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
