On Mon, 2017-10-02 at 09:56 +0000, Marian Rainer-Harbach wrote:
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,
Red Hat, Australia/Brisbane