On 08/21/2013 09:53 AM, David Boreham wrote:
Another thing you might try :
While the server is under stress, run the "pstack" command a few times
and save the output.
gdb will give much more detail
http://port389.org/wiki/FAQ#Debugging_Hangs
If you post the thread stacks here, someone fami
On 08/21/2013 05:29 PM, David Boreham wrote:
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
On 08/21/2013 09:29 AM, David Boreham wrote:
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
On 08/21/2013 09: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
On 08/20/2013 08:39 PM, Jeffrey Dunham wrote:
We have a customer that has been multi-threading behind multiple
servers and writing to our Master server. These writes come in the
form of heavy spikes (1k over 5 second intervals) very much burst
traffic and all the writes are adding new items t
On 08/20/2013 10:39 PM, Jeffrey Dunham wrote:
We have a customer that has been multi-threading behind multiple
servers and writing to our Master server. These writes come in the
form of heavy spikes (1k over 5 second intervals) very much burst
traffic and all the writes are adding new items
