[7.075] Clicking on various reports causes very high IO WAIT [CONFIRMED]

Just wanted to add more.

After my last reboot, I have not touched the reporting.

Here is some info from top:

top - 13:23:27 up  1:48,  1 user,  load average: 0.04, 0.15, 0.12
Tasks: 105 total,   1 running, 104 sleeping,   0 stopped,   0 zombie
Cpu(s):  1.3%us,  0.7%sy,  0.0%ni, 98.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:    515200k total,   482480k used,    32720k free,     5004k buffers
Swap:  1052248k total,       68k used,  1052180k free,   127572k cached

My average load is 0.04, 0.15, 0.12. If I click into the reporting, the load average goes up above 5.0, and the %wa goes into the high 90s.

Further info.

After clicking on the Network Usage to look at my last week of bandwidth graphs (which defaults to the Accounting), my %wa is now back up to 90+ %.

The load average is also climbing. The only way I will be able to get out of this is by a reboot.

top - 14:01:17 up  2:26,  1 user,  load average: 4.51, 2.28, 1.06
Tasks: 116 total,   3 running, 112 sleeping,   0 stopped,   1 zombie
Cpu(s):  1.3%us,  1.3%sy,  0.7%ni,  0.0%id, 96.4%wa,  0.3%hi,  0.0%si,  0.0%st
Mem:    515200k total,   501320k used,    13880k free,     1460k buffers
Swap:  1052248k total,    86648k used,   965600k free,   140312k cached

Is there something in the network accounting presentation in Webadmin that would be causing such high IO?

Issuing the command to restart configdeamon seems to have fixed the problem without a reboot.
 /etc/rc.d/confdaemon restart

I can understand having some IO wait, but it only appears when going into the Network Activity reporting, and lasts even if browsing away from the page. Looking at my cpu history, it was running 100%  for over 12 hours last night, since I first tried the network accounting after install until my first reboot this morning.


I would gladly give access to my box for someone at Astaro to take a look and see what I am seeing.

Hi ReD-MaN, 

thanks for the information.

We can reprouce this here. 
This happens especially if you have a larger accounting or accounting_archive DB. 

You can check the size of these two files under

ls -l /var/log/reporting/adbs/

it seems that the code acessing these larger files is very inefficient. 
we are currently working on a more efficient way to 
a) get faster access time to reporting
b) lower the resource usage when reports are generated.

thanks
Gert

Hi Gert,

If my files are large, I would hate to see someone with more traffic than me.

Here are my file sizes:

vpngw:/root # ls -l /var/log/reporting/adbs/
total 470596
-rw-r--r-- 1 root root  27984896 Nov  9 14:43 accounting.dbl
-rw-r--r-- 1 root root 282787840 Nov  8 02:36 accounting_archive.dbl
-rw-r--r-- 1 root root  27984896 Nov  9 02:30 accounting_rotate.dbl
-rw-r--r-- 1 root root     31744 Nov  9 13:42 auth.dbl
-rw-r--r-- 1 root root    130048 Nov  9 12:00 imp2p.dbl
-rw-r--r-- 1 root root    160768 Nov  9 12:00 ips.dbl
-rw-r--r-- 1 root root      2048 Nov  9 12:00 ipscount.dbl
-rw-r--r-- 1 root root    577536 Nov  9 14:20 mailsec.dbl
-rw-r--r-- 1 root root  34185216 Nov  9 14:40 pfilter.dbl
-rw-r--r-- 1 root root 107520000 Nov  9 14:40 websec.dbl
vpngw:/root #

Just wanted to add, this does not appear to happen with the websecurity report, even though it's database seems to be not very small either.

Possibly the Network Accounting should not be the default tab to show up when someone wants to view the Network usage reports?

An update on this one. With 7.080, the IO Wait doesn't seem to last as long, however it still jumps up very high.

top - 00:46:04 up 11:25,  1 user,  load average: 3.95, 1.81, 0.85
Tasks: 116 total,   4 running, 112 sleeping,   0 stopped,   0 zombie
Cpu(s): 18.2%us,  1.7%sy,  0.3%ni,  0.0%id, 79.1%wa,  0.7%hi,  0.0%si,  0.0%st
Mem:    515200k total,   510300k used,     4900k free,      452k buffers
Swap:  1052248k total,    37788k used,  1014460k free,    70552k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
30893 root      18   0 13660 8188 2288 R 16.0  1.6   0:00.48 audld.plx
29826 root      18   0 62676  30m 3600 R  1.7  6.1   0:39.62 confd.plx
 3056 root      17   0 13340 8444 2496 S  1.0  1.6   4:18.00 selfmonng.plx
 3280 mysql     16   0  122m  13m 4796 S  0.3  2.6   3:00.13 mysqld
30728 root      16   0  2172 1128  828 R  0.3  0.2   0:00.45 top
30831 root      34  19 15472  13m 2392 R  0.3  2.7   0:00.98 gen_inline_repo
    1 root      16   0   720  176  132 S  0.0  0.0   0:00.79 init
    2 root      34  19     0    0    0 S  0.0  0.0   0:02.39 ksoftirqd/0
    3 root      10  -5     0    0    0 S  0.0  0.0   0:00.00 events/0
    4 root      11  -5     0    0    0 S  0.0  0.0   0:00.02 khelper
    5 root      10  -5     0    0    0 S  0.0  0.0   0:00.00 kthread
    7 root      10  -5     0    0    0 S  0.0  0.0   0:00.00 kblockd/0
    8 root      20  -5     0    0    0 S  0.0  0.0   0:00.00 kacpid
   61 root      15  -5     0    0    0 S  0.0  0.0   0:00.00 khubd
   93 root      15   0     0    0    0 S  0.0  0.0   0:00.31 pdflush
   94 root      15   0     0    0    0 S  0.0  0.0   0:00.63 pdflush
   96 root      11  -5     0    0    0 S  0.0  0.0   0:00.00 aio/0

Confirmed, we're working on making it faster ...