Hi,

Using gkrellmd on machine with many routes (e.g. a router) is impractical.

gkrellmd reads /proc/net/route in order to determine which interfaces are up,
but this file may contain hundreds of thousands of lines, making parsing quite
CPU-consuming.

Even after lowering update-hz to 1, gkrellmd still uses about 40% CPU all the
time and the machine load stays at 0.7.

I guess it would be better if gkrellmd could use some other source of
intormation for discovering active/inactive interfaces. 'ip link' utility seems
to use the linux netlink socket for example.

Another solution would be to add an option which disables the /proc/net/route
scan or makes it very rare (silimar to inet-interval).


Thanks for considering,
    dam

forwarded 678958 gkrellm@lists.netservicesgroup.com
thanks

Hello Damyan,
thanks for the report: I'm forwarding it upstream.

Dear Gkrellm upstream authors,
a fellow Debian Developer has reported this issue which I hereby
forward to your attention.

Regards,
Sandro

Can you provide a rough number of lines in that file when gkrellm starts
to eat a visible amount of CPU? I think I can already see from the code
where this is coming from, reading the file itself hopefully is not the
problem.

Unless /proc/net/route is one of those files that cause on-demand
overhead on the kernel side I'd say using a different way of listing the
routing won't help.

Yes, ideally I'd prefer if gkrellm could be informed about changes to
many of the variables it is monitoring. Maybe in the long run it could
make use of some desktop features like NetworkManager, udisks etc. and
only use the relatively costly polling code for systems where such
services are not reachable via dbus.

Regards,
Stefan Gehn