Progressively throughout the week if we start it on Monday, the gui and server itself will become increasingly slower by the day until it becomes unusable. The only way to “solve” this issue is by doing a
“fwconsole restart” once a week.
Server info:
FreePBX 15.0.17.55
Current Asterisk Version: 16.20.0
It’s not a system resources issue, we’re running Dual X5660 (HyperThreat disabled) 72Go, SAS Drive Raid 10, 2 x 10Gbs SFP+ LACP. It can take upwards of 1 minute to load the “extensions” page, and all it has to do is load from the TMP directory. And once the extensions page loads, it can take another minute just to get into that extension.
I never suggested you were under resourced, sarwill give you hourly snapshots of increasing resource usage over the last week, it will show you what resource is being used more and more after a restart. I’m guessing memory but it might be disk io
we’ve tried running the server virtualized, had the original issues then we moved it to a physical box and the issues kept persisting, and we are still experiencing them.
Is that sysstat output shown from when the system is slow?
Basically you need to do more investigation into what is using the resources. i.e. asterisk, mysql, etc.
The systat package can help, I tend to use ‘atop’ (which can store the data over time and shows cpu, processes, network and disk IO in a top-style format) and nagios/check_mk monitoring of CPU and disk IO.
Also, what is being used in FreePBX - for example, I believe I’ve heard that Zulu can cause performance issues.
There is no significant CPU usage (%idle ~= 100) and no significant use of fast I/O (%iowait ~= 0 - which I think means disk). That suggests, to me, that is suffering from network problems, or from, maybe, an external database server.
I’m not sure if %iowait includes page I/O, and you didn’t provide disk statistics. Assuming you are not in the same room, to actually hear if the disk is being thrashed, vmstat should be useful.
Is the memory or disk space an issue? We had a similar issue having to do with a slowly increasing memory leak. After a period of time, the memory would be completely consumed, everything would slow, audio would drop. Are you a 24/7 operation? If not maybe you can set a cron to fwconsole reset the box once a night during off hours, as a mitigation until you get the issue solved.
Delays from low memory will show as disk thrashing, which ought to be obvious from sar or vmstat or by simply listening to the disk for large numbers of head arm movement.
For what it is worth, I have noticed that our PBX starts to slow when there are more and more recorded calls piling up. After cleaning them up, the PBX pep returns. Just a thought.
Perhaps poor choice of words on my part.
When the count and size of manually recorded calls in the /var/spool/asterisk/monitor/… folders grows, the PBX tended to get sluggish. Since keeping older recordings purged, reducing the size and count, the issue appears alleviated.
Could be coincidental to something else.