v5.1.4393 Memory Hog

[BJReplay]

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?

 

[BJReplay]

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.

 

[BJReplay]

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?