On Fri, Mar 01, 2013 at 07:18:28PM -0700, Bob Proulx wrote: [...] > Why the defunct zombies? It doesn't wait(2) for its children? > Apparently not!
If you want to know why your statement are wrong, you don't even need to look at the source - just read /usr/share/doc/bandwidthd/README.Debian This is a FAQ. > > Here is a snap from htop. to show what the userland memory and swap looks > like. > > Mem[||||||||||||||||||||||||1901/2017MB] > Swp[||||||||||| 1116/3811MB] > > PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command > > 12296 root 21 1 767M 534M 2512 S 0.0 26.5 3h08:03 > /usr/sbin/bandwidthd > 12297 root 21 1 836M 451M 2524 S 0.0 22.4 6h25:54 > /usr/sbin/bandwidthd > 25970 root 25 5 516M 429M 2980 R 70.0 21.3 1:03.89 > /usr/sbin/bandwidthd > 12295 root 21 1 513M 415M 2516 S 0.0 20.6 2h33:06 > /usr/sbin/bandwidthd > 12299 root 21 1 593M 252M 2520 S 0.0 12.5 13h22:35 > /usr/sbin/bandwidthd > I don't find this information very useful..... A valgrind log would probably be much more useful. > It is really hogging memory! It isn't thrashing. The active set must > be small. But the total memory is huge. I must stop it because it is > no longer graphing and is thowring "bandwidthd: Forking grapher child > failed!" errors. (And worse is that when I restart it all of the > history is lost and it starts again fresh. Making this quite fragile. > But that would be a separate bug report.) Have a look at the recover_cdf config option, if you want to read in your logged CDF files on restart. > > I don't know if I will get time in the near future to debug it or > not. But it looks grim. > > Bob -- Andreas Henriksson
signature.asc
Description: Digital signature
