tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "anorakgirl" <tom...@anorakgirl.co.uk>
Subject Re: concurrent user threading problem
Date Thu, 13 Nov 2003 12:53:32 GMT
redhat.. version:

rpm -q redhat-release
redhat-release-8.0-8

is that the right way to find the OS version??
tamsin

> Hello
>
>> very strange that the problem occurred though, i don't know what part
>> of the system didn't like the hyperthreading.
>
> What operating system are you running?
>
> Regards
>
> Harry Mantheakis
> London, UK
>
>
>> phew. problem resolved!
>>
>> for info, we switched the kernel on the new server to use a single
>> processor (no hyperthreading) and it is now fine.
>>
>> very strange that the problem occured though, i don't know what part
>> of the system didn't like the hyperthreading.
>> tamsin
>>
>>
>>
>>
>>> hi all,
>>> orry for the long mail; i'm at my witts end here, and just wanted to
>>> check that i'm not losing my marbles!
>>>
>>> we have been running a commercial app on tomcat for the last two
>>> years. we've had intermittent out of memory problems processing large
>>> pages meaning we've had to reboot occasionally (the app produces xml,
>>> transforms it using xslt to output html), but in general the
>>> performance has been good and the app has been stable. as the
>>> business has been growing, we recently upgraded to a new funky dell
>>> server, multiprocessor with
>>> hyperthreading, but this seems to have exacerbated the problem
>>> dramatically:
>>> we now have a situation where if a single user requests a page, it is
>>> lightening fast, but once there are two requests at the same time,
>>> both are about 100 times slower; i would expect twice slower at most.
>>> once returning to only one request at a time, the speed recovers
>>> immediately. in top you can see that java has 100% of the CPU time,
>>> and one of the 4 effective CPU's is maxed out.
>>>
>>> so i'm desperately trying to track down the cause of this problem;
>>> i'm guessing it must be some kind of race condition. we have reviewed
>>> all our code, ensured that methods accessing shared objects are
>>> synchronized, been through all the config, removed most of the
>>> logging etc etc, and upgraded to tomcat 4.1.29 and all to no avail;
>>> we don't seem to be able to narrow down where the problem could be.
>>>
>>> what i wanted to check was: the app has one servlet only, through
>>> which all requests are processed. all requests go through the doGet
>>> method. to try and check if our code was to blame, we synchronised
>>> this method. my understanding is that this would mean if two requests
>>> were received at approximately the same time, one would have to wait
>>> until after the first had been processed, meaning the two requests
>>> could not access any of our code at the same time, and therefore the
>>> second would be say twice as slow as the first. however, this is not
>>> the case, still they are both about 100 times slower. this makes me
>>> think that it cannot be an error in our code? but then tomcat seems
>>> to serve concurrent users on other people's apps with no problem, so
>>> i can't believe tomcat is to blame.
>>>
>>> is my assumption about synchronizing the doGet method correct?  is
>>> there anything special i should know about using tomcat on a
>>> multiprocessor server? any suggestions at all greatfully received!
>>>
>>> thanks,
>>> tamsin
>>>
>>> ps:
>>> tomcat: 4.1.29
>>> java: 1.4.2
>>> postgresql: 7.3.4
>>> saxon
>>> xerces
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org For
>> additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>>
>>
>
>
> --------------------------------------------------------------------- To
> unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org For
> additional commands, e-mail: tomcat-user-help@jakarta.apache.org




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


Mime
View raw message