Hi!
If your "top" isn't brand new (tey changed the UI), this is what you could try: Press "1" to show statistics for each logical CPU, press "f j <RETURN>" to display the CPU each process runs on, press "H" to display threads, press "i" to leave out idle processes in display, press " s 0.5 <RETURN>" to refresh the display twice per second (you may increase the rate to any paranoid value you like). The watch what's going on. Have an eys on the wait and system parts of CPU also...
Regards, Ulrich
Brian Reichert reichert@numachi.com schrieb am 12.08.2014 um 21:22 in
Nachricht 20140812192257.GA54292@numachi.com:
On Tue, Aug 12, 2014 at 02:04:20PM -0400, Brian Reichert wrote:
On Tue, Aug 12, 2014 at 11:12:51AM -0700, Howard Chu wrote:
While that search is running you should see slapd at 100% CPU. If not, then
something in your system is throttling your connection.
And it is not at 100%. 'top' shows slapd on this host is only at ~50%.
I'll review the 'threads' setting.
Progress!
The 'ldap' user has no system limits set on it:
# setuidgid ldap sh -c ulimit -a unlimited
I have 2 CPUs with 4 cores each:
# grep "^physical id" /proc/cpuinfo | sort -u | wc -l 2 # grep "^cpu cores" /proc/cpuinfo | sort -u cpu cores : 4
This page recommends:
http://www.openldap.org/doc/admin24/tuning.html#%7B%7Bslapd%7D%7D%288%29%20T...
This value should generally be a function of the number of "real" cores on the system, for example on a server with 2 CPUs with one core each, set this to 8, or 4 threads per real core.
Assuming 'real core' == CPU, in my case, I think this should be 8 (4 * 2 physical CPUs). Is that correct?
It was set to 32 (I have no idea why), and 'top' showed ~50%.
When I changed threads to '8', my query times dropped to ~22 seconds, which is _much_ better than the 175 I was seeing.
'top' still shows slapd only using %50, so I hazard that it keeps to one CPU. Is that a valid assumption?
Could this mdb database perform better? It's outperforming my bdb backend by %25, which isn't too shabby, but I'm curious if this sort of performance increase is typical...
-- Brian Reichert reichert@numachi.com BSD admin/developer at large