On Thu, Apr 10, 2008 at 01:02:34PM -0700, Alexander Kolbasov wrote:
>
> It may be useful to observe prstat -mL which will report micro-state
> accounting data for each thread.
>
prstat -mL takes a *lot* of time with 16k threads. Nevertheless, I have some
further data: reruning the dtrace gave
On Fri, Apr 11, 2008 at 12:16:21PM +0200, [EMAIL PROTECTED] wrote:
> Hi,
> I think you already said this, but are you using pthread_cond_signal, or
> pthread_cond_broadcast to wake up threads?
>
I use pthread_cond_signal since there's ever only at most a single thread
to be woken up.
Hi,
I think you already said this, but are you using pthread_cond_signal, or
pthread_cond_broadcast to wake up threads?
max
Zeljko Vrba wrote:
> On Thu, Apr 10, 2008 at 01:02:34PM -0700, Alexander Kolbasov wrote:
>
>> It may be useful to observe prstat -mL which will report micro-state
>> acc
Hi,
Our Java server occasionally stalls because all the threads are waiting
for something. Though we know that the sockets are all established and the
other end does not respond making the threads to wait indefinitely we would
like to get more statistics. Java threads are all mapped to Sol
I think that Mike is on the right track with some type of cache effect
going on. The increased sleep time may simply be due to increased
lock hold times because your critical regions take longer to complete,
and may also be due to increased time needed to acquire and release
locks because the lock
Zeljko Vrba wrote:
> On Thu, Apr 10, 2008 at 01:02:34PM -0700, Alexander Kolbasov wrote:
>
>> It may be useful to observe prstat -mL which will report micro-state
>> accounting data for each thread.
>>
>>
> prstat -mL takes a *lot* of time with 16k threads. Nevertheless, I have some
> fu
