v5.1.4393 Memory Hog

Discussion in '3CX Phone System - General' started by BJReplay, Apr 12, 2008.

Thread Status:
Not open for further replies.
  1. BJReplay

    BJReplay New Member

    Joined:
    Oct 31, 2007
    Messages:
    133
    Likes Received:
    0
    I've just upgraded to 5.1.4393 (ok, uninstalled, backed up, re-installed), and noticed it is using heaps of memory - much more than 5.1.4128.

    I was running on a Win2K3R2SP2 VM with 256MB of memory allocated, and it tended to run with a commit charge of around 230MB.

    Now it is running (with nothing else but 3CX with a commit charge of around 360MB - so it's over-committed by around 100MB).

    The 3CX Processes are using:
    • Apache (2 instances 48MB and 12MB) 60MB
    • Media Server peaked at 38MB, but dropped down to 2MB
    • Fax Server 29MB
    • IVR peaked at 12MB, but dropped down to 5MB
    • Phone System 3MB

    And (I almost forgot), half-a-dozen instances of postgres at around 5MB each.

    All in all, a peak of 190MB, and steady state of around 120MB!

    I'm lucky in that I can just increase the memory allocated to the VM, but this is a huge increase.

    Any reason why? Can anything be done to drop the memory footprint - in particular the Fax Server and Apache?

    Has a config change been made to Apache that causes it to allocate vast quantities of RAM?

    I know that 256MB is not much for a machine now - but when you're trying to run lots of VMs, allocating 2GB to all of them "just in case" isn't an option - you need to allocate a sufficient amount to each so that they don't page, without wasting memory. 3CX used to play nice in 256MB, but now cant. What gives?
     
  2. BJReplay

    BJReplay New Member

    Joined:
    Oct 31, 2007
    Messages:
    133
    Likes Received:
    0
    And, as has been mentioned here before, restoring history records takes forever. Around three hours so far, at 100% CPU, for about 6 months history.

    When you can't just upgrade, and are forced to uninstall and re-install, then restore, you must fix the loading if history records - you can't expect customers to throw away call history to upgrade, nor to have a multi-hour outage while the history is restored.
     
  3. BJReplay

    BJReplay New Member

    Joined:
    Oct 31, 2007
    Messages:
    133
    Likes Received:
    0
    Watching taskmanager while restoring history - there are nine or ten instances of postgres running - but each only runs for a few CPU seconds at most - so there might be two instances running at close to 100% CPU between them, but they appear, run for a few seconds, clock up a few CPU seconds, then disappear.

    Is the restore starting up a new instance of postgres for every history record restored?
     
Thread Status:
Not open for further replies.