On Mon, 2017-10-02 at 09:56 +0000, Marian Rainer-Harbach wrote: > Hi William, > thanks for the explanation and links to the code! > > However, I'm not sure if this is really related to the problem I'm seeing. As I tried to explain above, the first few minutes of a load test run fine, but then (after a variable time) there is a sudden jump from <25% CPU to almost 800% CPU. > > If I understood the calculation of the number of rounds in the code correctly, wouldn't the behavior of 389 DS be consistent across the whole load test? I.e., wouldn't the high CPU usage happen right from the start of a test run? This was my thinking also, but you said the problem *only* occurred with pbkdf2, which means this must be the source of the issue. The way the rounds calculate on startup was likely to mean that you would have 10,000 rounds (the minimum), which would exceed the 40ms work fact that we would aim for. As a result, each bind starts to take say ... 100ms lets say. As clients start to join it's initially "quick" but as you add more clients connecting, not only do you not have enough cpu to service all the clients, these times elongate and you have more clients queued, so you saturate the CPU completely. If you suspect the issue is elsewhere, during the highload, I'm going to ask you to take a pstack of the process and send it to me to analyse to see where the server is processing, Hope that helps, -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
