tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Schulz <sch...@videotron.ca>
Subject Re: Any synchronization issues with SMP?
Date Wed, 23 Jun 2004 22:37:17 GMT
Rainer,

Thanks for the tips.  I am about to take timing stats
internally in the ThreadPool and the Tcp workers.
Also, the described symptoms do not disappear, but seem to be of much
shorter duration when only 4 CPUs are used for the application.
I'll summarize what I find.

 Martin

Rainer Jung wrote:

> Hi,
>
> we know one application running on 9 systems with 4 US II CPUs each
> under Solaris 9. Peak request rates at 20 requests/second per system.
> Tomcat is 4.1.29, Java is 1.3.1_09. No symptoms like yours!
>
> You should send a signal "QUIT" to the jvm process during the
> unresponsiveness time. This is a general JVM mechanism (at least for sun
> JVMs). The signal writes a stack trace for each thread on STDOUT (so you
> should also start tomcat with redirection of STDOUT the output to some
> file). Beware: older JVM in rare cases stopped working after getting
> this signal (not expected with 1.3.1_09).
>
> In this stack dump you should be able to figure out, in which methods
> most of your threads stay and what the status is.
>
> Is there native code included (via JNI)? Any synchronization done in the
> application itself? Are you using Tomcat clustering? Which JVM?
>
> Sincerely
>
> Rainer Jung
>
> Martin Schulz wrote:
>
>> Can someone confirm that Tomcat works well on busy SMP systems (e.g. 
>> Sun V1280),
>> or whether there are problems in Tomcat.
>>
>> Here's what we have at our end:
>>
>> We are currently performance testing our application (Tomcat 4.1.30) 
>> on Solaris 9,
>> on a V1280 system w. 8 CPUs. (SDK 1.4.2_04).  Transaction rates are 
>> moderate, around 30/s.
>>
>> The application, after about 30-40 minutes, gets unresponsive for a 
>> little while (1-10 minutes),
>> gets back to work (for a varying period of time, but definitely under 
>> 30 min), and then the cycle
>> repeats.  At half the transaction rate, the smptoms are no longer 
>> easily observed,.
>>
>> The above symptoms disappear when we use a single CPU, or a single 
>> board of 4 CPUs.
>> That scenario seems to imply synchronization problems soemwhere in 
>> the Java code.
>> The problem could not be observed in development configurations 
>> either (Wintel, 1-CPU Sun
>> boxes.)
>>
>> The behavior is such that connections get accepted, but no response 
>> is sent (established connections
>> remain at a fixed level).   The number of connections in this state 
>> varies (20-70).
>>
>>  From the timers we keep we learn that the service gets stuck when 
>> reading the input.
>> Once unblocked the responses get sent out rapidly again.
>>
>> We have tuned the system for efficient, high-volume TCP-IP traffic.
>>
>> We tried the coyote connector and the HttpConnector, both with the 
>> same effect.
>>
>> Please respond if you can confirm or dismiss threading issues in Tomcat.
>> We would also be ineterested in testing approaches for such a scenario.
>>
>> .I have kept system statistics for both scenarios and can provide 
>> these on request.
>>
>> Thanks!
>>    Martin Schulz
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message