demo server performance

[Jacques Le Roux]

From: "Jacques Le Roux" <[hidden email]>

> From: "Adam Heath" <[hidden email]>
>> On 12/10/2010 04:05 AM, Jacques Le Roux wrote:
>>> Hi devs,
>>>
>>> FYI, this morning the trunk demo was stale again. It was running but not
>>> accessible. I then stopped and restarted, same issue. I tried an "svn
>>> st" no issues there. I reloaded all manually (I have a script for that)
>>> and it was then OK.
>>
>> When these issues occur, send QUIT to the java process; it'll give you
>> a stack dump, and a memory usage summary.  Then, use jmap to get a
>> binary heap dump.  Those 2 things will allow for debugging this.  Also
>> keep track of which particular svn version the system is running.
>
> I will try that
>
> Jacques

I have tried to use both (on 3 new trunk threads running amok)
kill -QUIT PID
kill -3 PID

but got no stack traces, nothing at all :/

Jacques
PS: I have also tried on the main PID

[Adam Heath-2]

On 12/10/2010 03:46 PM, Jacques Le Roux wrote:

> From: "Jacques Le Roux" <[hidden email]>
>> From: "Adam Heath" <[hidden email]>
>>> On 12/10/2010 04:05 AM, Jacques Le Roux wrote:
>>>> Hi devs,
>>>>
>>>> FYI, this morning the trunk demo was stale again. It was running but
>>>> not
>>>> accessible. I then stopped and restarted, same issue. I tried an "svn
>>>> st" no issues there. I reloaded all manually (I have a script for that)
>>>> and it was then OK.
>>>
>>> When these issues occur, send QUIT to the java process; it'll give
>>> you a stack dump, and a memory usage summary. Then, use jmap to get a
>>> binary heap dump. Those 2 things will allow for debugging this. Also
>>> keep track of which particular svn version the system is running.
>>
>> I will try that
>>
>> Jacques
>
>
> I have tried to use both (on 3 new trunk threads running amok)
> kill -QUIT PID
> kill -3 PID

It goes to STDERR, where-ever that is.  lsof -p PID will show you
where that is attached, but it might be a pipe.

[Jacques Le Roux]

From: "Adam Heath" <[hidden email]>

> On 12/10/2010 03:46 PM, Jacques Le Roux wrote:
>> From: "Jacques Le Roux" <[hidden email]>
>>> From: "Adam Heath" <[hidden email]>
>>>> On 12/10/2010 04:05 AM, Jacques Le Roux wrote:
>>>>> Hi devs,
>>>>>
>>>>> FYI, this morning the trunk demo was stale again. It was running but
>>>>> not
>>>>> accessible. I then stopped and restarted, same issue. I tried an "svn
>>>>> st" no issues there. I reloaded all manually (I have a script for that)
>>>>> and it was then OK.
>>>>
>>>> When these issues occur, send QUIT to the java process; it'll give
>>>> you a stack dump, and a memory usage summary. Then, use jmap to get a
>>>> binary heap dump. Those 2 things will allow for debugging this. Also
>>>> keep track of which particular svn version the system is running.
>>>
>>> I will try that
>>>
>>> Jacques
>>
>>
>> I have tried to use both (on 3 new trunk threads running amok)
>> kill -QUIT PID
>> kill -3 PID
>
> It goes to STDERR, where-ever that is.  lsof -p PID will show you where that is attached, but it might be a pipe.

I was not able to do it in a reasonnable time. I did not find the STDERR for the sub-processes (blocked java threads reported by
top). Nor for the main process, but  for it I had a very very long list of files... Cetainly a pipe somewhere? Then how to find it?
Asking infra? One thing I'm sure is the problem will are-appear soon anyway...

Thanks

Jacques

[Jacques Le Roux]

Please see https://issues.apache.org/jira/browse/OFBIZ-4043

Jacques

From: "Jacques Le Roux" <[hidden email]>

> From: "Adam Heath" <[hidden email]>
>> On 12/10/2010 03:46 PM, Jacques Le Roux wrote:
>>> From: "Jacques Le Roux" <[hidden email]>
>>>> From: "Adam Heath" <[hidden email]>
>>>>> On 12/10/2010 04:05 AM, Jacques Le Roux wrote:
>>>>>> Hi devs,
>>>>>>
>>>>>> FYI, this morning the trunk demo was stale again. It was running but
>>>>>> not
>>>>>> accessible. I then stopped and restarted, same issue. I tried an "svn
>>>>>> st" no issues there. I reloaded all manually (I have a script for that)
>>>>>> and it was then OK.
>>>>>
>>>>> When these issues occur, send QUIT to the java process; it'll give
>>>>> you a stack dump, and a memory usage summary. Then, use jmap to get a
>>>>> binary heap dump. Those 2 things will allow for debugging this. Also
>>>>> keep track of which particular svn version the system is running.
>>>>
>>>> I will try that
>>>>
>>>> Jacques
>>>
>>>
>>> I have tried to use both (on 3 new trunk threads running amok)
>>> kill -QUIT PID
>>> kill -3 PID
>>
>> It goes to STDERR, where-ever that is.  lsof -p PID will show you where that is attached, but it might be a pipe.
>
> I was not able to do it in a reasonnable time. I did not find the STDERR for the sub-processes (blocked java threads reported by
> top). Nor for the main process, but  for it I had a very very long list of files... Cetainly a pipe somewhere? Then how to find
> it? Asking infra? One thing I'm sure is the problem will are-appear soon anyway...
>
> Thanks
>
> Jacques
>

[BJ Freeman]

thanks for your work.
you patch still looks like a memory management problems.
added full comment in Jira.

=========================
BJ Freeman
Strategic Power Office with Supplier Automation  <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
Specialtymarket.com  <http://www.specialtymarket.com/>
Systems Integrator-- Glad to Assist

Chat  Y! messenger: bjfr33man


Jacques Le Roux sent the following on 12/17/2010 4:32 AM:

> Please see https://issues.apache.org/jira/browse/OFBIZ-4043
>
> Jacques
>
> From: "Jacques Le Roux" <[hidden email]>
>> From: "Adam Heath" <[hidden email]>
>>> On 12/10/2010 03:46 PM, Jacques Le Roux wrote:
>>>> From: "Jacques Le Roux" <[hidden email]>
>>>>> From: "Adam Heath" <[hidden email]>
>>>>>> On 12/10/2010 04:05 AM, Jacques Le Roux wrote:
>>>>>>> Hi devs,
>>>>>>>
>>>>>>> FYI, this morning the trunk demo was stale again. It was running but
>>>>>>> not
>>>>>>> accessible. I then stopped and restarted, same issue. I tried an
>>>>>>> "svn
>>>>>>> st" no issues there. I reloaded all manually (I have a script for
>>>>>>> that)
>>>>>>> and it was then OK.
>>>>>>
>>>>>> When these issues occur, send QUIT to the java process; it'll give
>>>>>> you a stack dump, and a memory usage summary. Then, use jmap to get a
>>>>>> binary heap dump. Those 2 things will allow for debugging this. Also
>>>>>> keep track of which particular svn version the system is running.
>>>>>
>>>>> I will try that
>>>>>
>>>>> Jacques
>>>>
>>>>
>>>> I have tried to use both (on 3 new trunk threads running amok)
>>>> kill -QUIT PID
>>>> kill -3 PID
>>>
>>> It goes to STDERR, where-ever that is. lsof -p PID will show you
>>> where that is attached, but it might be a pipe.
>>
>> I was not able to do it in a reasonnable time. I did not find the
>> STDERR for the sub-processes (blocked java threads reported by top).
>> Nor for the main process, but for it I had a very very long list of
>> files... Cetainly a pipe somewhere? Then how to find it? Asking infra?
>> One thing I'm sure is the problem will are-appear soon anyway...
>>
>> Thanks
>>
>> Jacques
>>
>
>
>