I might face the same problem like you did. I am just wondering if you are still trying to find a way to make your webapp run on the new hardware with hyperthreading turned on? If yes, what if the compiler used to compile your code wasnt optimised for a hyperthreaded environment ? I might be wrong, but maybe compiling tomcat or / and compiling your webapp with a compiler that does optimizations for a hyperthreaded environment might solve the issue. If you are doing some tests in this regards and have results do let me know.
Thanks.
On Thursday, November 13, 2003, at 05:21 AM, tamsin wrote:
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: [EMAIL PROTECTED] For
additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
