Where/what is all the disk activity?

Firstly, I should say that this is not a complaint - it is more that I would like to understand something that appears unusual to me.

I am running FreePBX (13.0.124 from distro) in a virtualised ESXi 6.0 environment on a system using SSD. (Yes, I am aware of all the caveats etc about virtualised/SSD etc.) As part of most installations in this environment I do the normal modifications to reduce the write rate based on the underlying SSD storage. This includes:

  • moving /tmp to RAM
  • moving /var/log to RAM (with save/restore on shutdown/start etc.)
  • update the mount options to include: noatime,data=writeback,commit=60
  • run without swap

On the whole this normally works well and prior to running FreePBX in this environment the daily write rate was about 0.07GB for two VMs (a FreeBSD router, and a Linux server).

When I install FreePBX in this environment my daily write rate goes up be a factor of 10 to 0.70 GB. Now this is probably acceptable, however, I am wondering exactly what all this write traffic is?

Even on a physical disk based system the disks would be active almost 100% of the time. The ESXi performance information shows continues write rates of 15 KByte/Sec (avg) for the FreePBX VM.

My installation has 2 x VOIP Phone, 1 x ATA (FXO+FXS) Trunk, 1 x IAX2 Trunk, 1 x SIP Trunk to external provider (60sec registration rate).

Another interesting thing is that if I run a copy my FreePBX system connected to an ‘empty’ network (ie. disconnected from the world) then the write rate drops a little, but not that much.

So what I am trying to understand is where exactly this write traffic is occurring and what it is related to?

I should add that altering the commit rate on the ext4 file systems doesn’t appear to have much effect on the write traffic.

Thanks,
Tim

Not sure if there is something useful for you here:

Thank you for that.

I don’t have any swap configured, and have allocated 2.4G of RAM to the VM. Given the very small size of my installation I don’t think that Virtual Memory is an issue. When I look at the memory utilisation reported by ESXi it is less than 1G of the 2.4G allocated, so I don’t think that the disk activity is related to the CentOS virtual memory.

I thought I would try and work out which files were being modified and the only things I can find that have changing modification times are:

  • files in /dev
  • files in /var/log (now stored on a tmpfs, so no actual disk here)
  • /var/lib/mysql/asterisk/kvstore.*
  • /var/spool/cron/asterisk
  • /var/spool/postfix/public/pickup

A bit of a mystery to me exactly where all the disk write traffic is coming from. I can only guess that somewhere some bit of code is issuing a sync() every 60 seconds or less.

Dashboard updates it’s stats every 60 seconds to provide you with graphs. You can configure this or turn it off in advanced settings.

Thanks Andrew,

That makes sense. In my application I would be more than happy to turn the stats collection off, with a small number of extensions in a turnkey application I don’t need any stats.

Now the only problem is that I can’t see where to configure this on the Settings/Advanced Settings page.

I have turned on the ‘Display Readonly Settings’ and I can’t see any setting that appears to control this. I am sure that I must be missing something obvious, but I can’t see it.

So at the risk of asking a stupid question, which control on the Advanced Settings page allows me to control the statistics collection?

(Edit: as a quick test I put an exit(0) in near the top of /var/www/html/admin/modules/dashboard/scheduler.php and sure enough the disk writing dropped significantly. Also the graphs stopped updating - as expected.)

Thanks,
Tim

Hi, Tim.

You might want to yum install iotop, then iotop -P will show disk activity by process and you can locate the culprit. If freePBX debug log is turned on, and verbosity is high in the full log, you will get a lot of disk activity because freePBX is writing all the detail from every event, including checking all time constraints every minute.