Dismiss Notice
We would like to remind you that we’re updating our login process for all 3CX forums whereby you will be able to login with the same credentials you use for the Partner or Customer Portal. Click here to read more.

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.