Andreas Henriksson wrote: > On Tue, Apr 13, 2010 at 11:13:11AM +0200, root wrote: > [...] > > As you can see, at any time, the daemon uses more than 75% of my two CPUs > > and 80% of the memory > > I can't let it run anymore > > If you're able to figure out what bandwidthd is up to or what triggers this > please share it.
I have been running bandwidthd on several machines without problem. And then just now I ran into a case where the machine was starting to page to swap. Here is a data point for the report. This is on an up to date Squeeze system. I was initially alerted to the problem because logwatch told me this was seen in the logfiles: Feb 19 20:20:00 cerberus bandwidthd: Forking grapher child failed! Feb 19 21:20:05 cerberus bandwidthd: Forking grapher child failed! Looking at it I see this: PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command 7278 root 25 5 774M 533M 2976 S 0.0 26.4 1:04.66 /usr/sbin/bandwidthd That bandwidthd process was growing and consuming much memory. That machine only has 1G of ram and half of it was consumed by that one process. It was starting to thrash. I ran 'service bandwidthd stop' and the system returned to normal. I then started the bandwidthd back up again with 'service bandwidthd start'. Subsequently it seems to have lost its history. All of the stats have been reset to zero. Although the htdocs directory is filled with png files there are only the main html index files. # ls /var/lib/bandwidthd/htdocs | grep -v png Subnet-1-0.0.0.0.html Subnet-2-0.0.0.0.html Subnet-3-0.0.0.0.html Subnet-4-0.0.0.0.html index.html index2.html index3.html index4.html legend.gif logo.gif > I've been running bandwidthd for several years on heavily utilized > connections without ever seeing much resource usage. > The only place I've seen it do weird things is that it can take very > long time to parse CDF files when you have alot of traffic logged. And these files became quite large at the same time. # ll /var/lib/bandwidthd/ total 308728 drwxr-xr-x 2 root root 565248 Feb 19 22:55 htdocs -rw-r--r-- 1 root root 154623712 Feb 19 23:11 log.1.0.cdf -rw-r--r-- 1 root root 101708838 Feb 19 22:59 log.2.0.cdf -rw-r--r-- 1 root root 47830871 Feb 19 22:20 log.3.0.cdf -rw-r--r-- 1 root root 11064720 Feb 19 17:05 log.4.0.cdf I am assuming that the newest is 1, an older is 2, and then 3, and so forth as they are rolled down? In which case it grew hugely in a very short time. I am running with "subnet 0.0.0.0/0" which I know is strongly recommended against. But it is the useful configuration for me. :-) I acknowledge that it might be related to this problem however. It might be getting swamped by a network wave of some sort. I am not expecting anything at this point. Just making a report in the idea that information is good since I saw what appeared to be this same problem on my machine too. Thank you for maintaining bandwidthd. Bob -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
