Thanks for the quick response Oleksiy!
We are experimenting with your suggestion. Also, I was wondering if we
might be experiencing the "Linux selector Spin" problem in HP-UX. We ran
the test program found here:
http://forums.sun.com/thread.jspa?forumID=535&threadID=5135128
And discovered that on some HP-UX systems (OS version V1) that the problem
exists, but on V2 systems it does not. The client having the issue is on
one of the affected V1 systems. Based on this and thread dumps gathered on
the system we believe that this issue is contributing to the CPU spikes.
Would implementing the Linux selector spin workaround cause any harm?
Oleksiy Stashok wrote:
>
> Hi Dennis,
>
> Can I ask you to try the latest Grizzly 1.9.19-SNAPSHOT built from
> sources? (Know it's a bit more complicated, but artifacts were not
> pushed to maven yet).
> To download latest Grizzly sources please use:
> svn checkout https://www.dev.java.net/svn/grizzly/trunk/code
>
> And then run your implementation with the following system property
> set to true:
> -Dcom.sun.grizzly.executePendingIOUsingSelectorThread=true
>
> or you can set it programmatically before starting up the framework:
> controller.setExecutePendingIOUsingSelectorThread(true);
>
> Let me know the result.
>
> Thanks.
>
> WBR,
> Alexey.
>
> On Dec 10, 2009, at 20:53 , ddooley wrote:
>
>>
>> Hello...
>>
>> First I would like to say how impressed I am with Grizzly. Great job!
>> However, on one of our client systems we are having a performance
>> issue that
>> occurs approximately every hour and can last up to ten minutes.
>> When this
>> happens Java takes 100% of the CPU and the garbage collect starts
>> thrashing.
>> Attached is the output from the HP JMeter statistics gathered on the
>> system
>> as well as stack dumps taken during the performance problem.
>>
>> I've seen a couple of posts where Grizzly seems to be stuck in
>> preClose0,
>> but I don't see how that was ever resolved. The stack traces
>> attached show
>> this is a likely scenario.
>>
>> We are using grizzly web server 1.9.18-e with one selector thread
>> and 30
>> maximum worker threads. The client's system is a two CPU system
>> with 14
>> gigs (we have Java configured to 1/2 gig initial and max). Bumping
>> the
>> initial/max to one gig did not make a difference.
>>
>> Java version 1.5.0.18
>> HP-UX OS version B.11.11
>>
>> Any help would be greatly appreciated.
>> Thanks!
>> --dennis
>> http://old.nabble.com/file/p26733514/consecutive_sigquit_121009.txt
>> consecutive_sigquit_121009.txt
>> http://old.nabble.com/file/p26733514/GC.jpeg
>> --
>> View this message in context:
>> http://old.nabble.com/Grizzly-Web-Server-on-HP-UX-PA-RISC-Performance-Issue-tp26733514p26733514.html
>> Sent from the Grizzly - Users mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>
>
>
--
View this message in context: http://old.nabble.com/Grizzly-Web-Server-on-HP-UX-PA-RISC-Performance-Issue-tp26733514p26821328.html
Sent from the Grizzly - Users mailing list archive at Nabble.com.
