Andreas Henriksson wrote: > 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.
Ah... I see. An interesting program design. Unconventional. I
would do it differently. But not unreasonable. The child process
accounting balances. Now that I understand it I am okay with it.
> > 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 was only provided to show the indications seen by a user (me!)
about the behavior of the program. The processes are consuming a lot
of memory. It isn't thrashing. The working set size seems smaller
than the total set size. This would be the same symptoms as a memory
leak but impossible to tell at this point. I will need to debug it
more.
If I get to the point of debugging in more detail I will then invoke
valgrynd and try to figure out where the memory is being used. Until
then all I can report is that it is using a lot of memory.
> > (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.
The manual for bandwidthd.conf says:
recover_cdf <bool>
Recover from logfiles after restart. Default false. Warning:
This can take very long time if the logfiles are big.
Enabling this and having bandwidthd start on system start
might be a bad idea. It will delay your possibilities to log
in locally since it's not done in the background.
I have the package default unchanged. The value I have in the
/etc/bandwidthd/bandwidthd.conf file is:
$ grep recover_cdf /etc/bandwidthd/bandwidthd.conf
#recover_cdf false
recover_cdf true
Therefore it should resume after a restart. It does not.
I think part of the problem for me might be that the site (a k-12
school) might have a very high level of activity and might simply be
too big for the capabilities of bandwidthd. I have the same
configuration running on two other sites with much less activity and
it works fine there.
Bob
signature.asc
Description: Digital signature
