On 18.08.12 16:37, Sandro Tosi wrote:
forwarded 678958 gkre...@lists.netservicesgroup.com thanksHello 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 On Mon, Jun 25, 2012 at 1:06 PM, Damyan Ivanov <d...@debian.org> wrote:Package: gkrellmd Version: 2.3.4-1 Severity: normal Tags: upstream 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.
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.
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.
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.
Another solution would be to add an option which disables the /proc/net/route scan or makes it very rare (silimar to inet-interval).
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
smime.p7s
Description: S/MIME Cryptographic Signature
