Bob Proulx wrote: > 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.
And here is additional information.
root 12295 1 1 Feb19 pts/0 02:33:05 /usr/sbin/bandwidthd
root 12296 12295 1 Feb19 pts/0 03:08:01 /usr/sbin/bandwidthd
root 23520 12296 17 18:50 pts/0 00:01:24 [bandwidthd] <defunct>
root 12297 12295 2 Feb19 pts/0 06:25:53 /usr/sbin/bandwidthd
root 12299 12295 5 Feb19 pts/0 13:22:33 /usr/sbin/bandwidthd
root 5431 12299 0 11:37 pts/0 00:00:44 [bandwidthd] <defunct>
root 24042 12295 98 18:58 pts/0 00:00:28 /usr/sbin/bandwidthd
Why the defunct zombies? It doesn't wait(2) for its children?
Apparently not!
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
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.)
I don't know if I will get time in the near future to debug it or
not. But it looks grim.
Bob
signature.asc
Description: Digital signature
