On Thu, 2017-11-02 at 08:57 +0000, Marian Rainer-Harbach wrote: > Hi William, > > I'm sorry it took me so long to get back to you! I get what you're > saying and it seems like a possible explanation for some scenarios. > > However, I'm still not sure it applies to my case, where 389 DS > behaves completely normal for a few minutes and then an instantaneous > jump to full CPU usage occurs. > > I created three pstack traces: > 1: https://pastebin.com/iBCbmpuk was taken while the load test was > already running and 389 DS still behaved normally. > > 2: https://pastebin.com/aVbCxjeT is one minute later. The same load > test is still running, but now 389 DS uses all CPUs and is very slow. > > 3: https://pastebin.com/Bsv0uefY is after stopping the load test, 389 > DS is now idle. > > It would be great if you could take a look at those traces! > > Hey there, Thread wise, I can see that the time in pbkdf2 is likely your issue. You are not consuming all workers though, as you can see many threads are in pthread_cond_wait/connection_threadmain. However, I still think the initial assessment was correct. Have you tried out the latest version with the pbkdf2 timing changes applied? 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
