Date: Thu, 1 Dec 2005 11:51:47 +0100 From: =?ISO-8859-1?Q?Eirik_=D8verby?= <ltning@anduin.net> To: Michael Vince <mv@roq.com> Subject: Re: Reduced java/tomcat performance 6-beta3 -> 6-stable ? Message-ID: <6E0EE473-BBA9-415A-9BF4-7FCC31E16F3C@anduin.net> Resent-Message-ID: <B9F578AF-1F6E-49C5-B7DF-B8EC410B9322@anduin.net>
next in thread | raw e-mail | index | archive | help
On Dec 1, 2005, at 04:12 , Michael Vince wrote: > Some apps that use of frequent queries of the system time for =20 > example MySQL are well known in FreeBSD to be slower then Linux =20 > because its more expensive to call compared to Linux, maybe Tomcat =20= > is also another such app this can also be double the case depending =20= > on on your jsp and servlet code. True, but on equal hardware it should perform equally. > If you are on good hardware, are using 6 and keep your systems time =20= > updated via ntp you might want to try changing from =20 > kern.timecounter.hardware: ACPI-fast to TSC(-100) and doing a =20 > benchmark this has already proven to increase performance of MySQL =20 > by a significantly amount. I will try this, though it will not solve my original problem (and =20 the subject is somewhat misleading now, as this seems to be =20 independent of kernel revisions). > Also some new experimental low-precision time code has been added =20 > to current source tree to see how much performance increases can be =20= > gained, weirdly enough some people have argued against it for I =20 > guess a wide range of reasons such as they just have crap hardware =20 > and don't care about performance, don't like the extra maintenance =20 > of code or just like Red Hat fanatics having an easy way to bad =20 > mouth FreeBSD performance. I think most people would agree though =20 > that it has to be done, or have to choose to believe FreeBSD isn't =20 > about performance among other goals. I will not join this discussion ;) > With 6 you can also use the new thr threading library, try your =20 > libmap.conf to libthr for testing, for example > [/usr/local/jdk1.4.2/] > libpthread.so.2 libthr.so.2 > libpthread.so libthr.so > > I been doing some 'ab' testing libthr with Apache2 compiled for =20 > worker MPM and have some really interesting differences on server =20 > load, loads of about 40 for pthread and around 5 thr under certain =20 > tests with ab with the exact same test. Too bad this causes jdk1.5.0-amd64 to crash... Application startup times were significantly reduced, but only the =20 times it actually managed to start without failing. Latest at the 2nd =20= or 3rd transaction Java coredumps. :( And as current load testing is done without Apache in between, this =20 is moot.. /Eirik > > Mike > > > Eirik =D8verby wrote: > >> Update: The diff below was made after making sure both systems =20 >> are running the exact same kernel. Behavior is the same. Building =20= >> new kernels (6-STABLE) now to get out of the BETA stage. >> >> /Eirik >> >> On Nov 28, 2005, at 22:53 , Eirik =D8verby wrote: >> >>> Firmware versions are equal. BIOS settings are equal. >>> However, a diff of the dmesgs show (apart from MAC address =20 >>> differences): >>> >>> 30c30 >>> < Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 >>> --- >>> > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 >>> >>> What on earth is that all about? The "slow" box has the ACPI-=20 >>> fast timecounter... >>> >>> /Eirik >>> >>> On Nov 28, 2005, at 22:14 , Kris Kennaway wrote: >>> >>>> On Mon, Nov 28, 2005 at 09:54:30PM +0100, Eirik ?verby wrote: >>>> >>>>> Hi, >>>>> >>>>> I think I have found the culprit. There must be some sort of >>>>> difference between the machines after all (BIOS revision?), =20 >>>>> because >>>>> while on one machine the interrupt rate for the bge card stays =20 >>>>> very >>>>> low (2 to be exact) during maximum load, the other machine goes >>>>> beyond 1000 and keeps rising constantly. This might also =20 >>>>> explain why >>>>> performance slowly degrades over time on that machine, and =20 >>>>> response >>>>> times vary wildly, while the "fast" machine responds nicely within >>>>> 1-2 seconds no matter the load and testing time. >>>>> >>>>> I will have to investigate this more closely. Is there a way =20 >>>>> to force >>>>> the NIC to polling mode (I'm assuming that is the difference, =20 >>>>> an IRQ >>>>> rate of 2 is too low for a heavily loaded server if the NIC is >>>>> interrupt-driven)? >>>>> >>>>> Anything else I could look at? >>>> >>>> >>>> BIOS update. >>>> >>>> Kris >>> >>> >> > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6E0EE473-BBA9-415A-9BF4-7FCC31E16F3C>