Re: Re: Bug#678958: CPU hog on machine with many routes

On 18.08.12 16:37, Sandro Tosi wrote:
> forwarded 678958 [email protected]
> 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
>
> On Mon, Jun 25, 2012 at 1:06 PM, Damyan Ivanov <[email protected]> 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