On Tue, Nov 23, 2010 at 10:57 AM, Matthew Kitchin (public/usenet)
<mkitchin.pub...@gmail.com> wrote:
> On 11/23/2010 9:38 AM, Douglas Hubler wrote:
>> On Tue, Nov 23, 2010 at 10:28 AM, Matthew Kitchin (public/usenet)
>> <mkitchin.pub...@gmail.com>  wrote:
>>> I'm running sipXconfig (4.2.1-018971 2010-08-17T02:20:18
>>> build20) 64 bit ISO build.
>>> I rebooted last night to resolve a java/CPU issue.
>>> There have been several threads started related to the high memory usage in
>>> Sipx 4.2.1 .
>>> I was looking at the performance graphs for the server since the reboot. I
>>> noticed something interesting. Take a look at the attached screenshot. I
>>> normally hate screenshots, but I couldn't find a better way to show it in
>>> this case. My backups run at midnight. It is very obvious in the CPU,
>>> memory, and IO graphs when it runs. The interesting thing to me is, the
>>> memory utilization doesn't drop at all after the backup is done. CPU and IO
>>> both drop back down to normal, but memory never does. The current TOP output
>>> is below.
>>> Does anyone else see this behavior? Should it be expected?
>> Expected, no, but fairly conclusive where the problem may lie!    This
>> is certainly useful information.  If you find (one of the many I'm
>> sure) bugs reported on this, I'll escalate that to look into for 4.2.1
>> in early december.
> I cannot find an open bug with the text java and memory in it. I'm not a
> master of searching through jira, so I could be doing something wrong. I
> will keep poking around.

ok, then you can create a new one please

re:XX-8282
I think that is a different issue because it consumes CPU as well.
I'll close that one. So create a new one.

re:Tony's comment about java not freeing up memory
Tony is right about most things and mostly likely right about this as
well so I googled and found this post
  http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6498735
We may have to consider specifying these parameters because of the few
specific large jobs the config server occasionally does, we need to
compensate for that like CDR reports, replication, backups




> _______________________________________________
> sipx-users mailing list
> sipx-users@list.sipfoundry.org
> List Archive: http://list.sipfoundry.org/archive/sipx-users/
>
_______________________________________________
sipx-users mailing list
sipx-users@list.sipfoundry.org
List Archive: http://list.sipfoundry.org/archive/sipx-users/

Reply via email to