Hi,
> 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?
It was one of the things I was thinking about. But grizzly already has
workaround for Linux selector spins.
Can you pls. check what
"System.getProperty("os.name")" returns on customer's platform?
Thanks.
WBR,
Alexey.
>
>
> 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.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>
