[arch-general] most efficient way to get linux kernel statistics
pelzflorian at pelzflorian.de
Mon Mar 7 20:15:06 UTC 2016
On 03/07/2016 04:36 PM, Jonathan Horacio Villatoro Córdoba wrote:
> On Sun, Mar 06, 2016 at 05:13:37PM +0100, Florian Pelz wrote:
>> On 03/06/2016 04:47 PM, Jonathan Horacio Villatoro Córdoba wrote:
>>> On Sun, Mar 06, 2016 at 03:23:33PM +0100, Andre Schmidt wrote:
>>>> hello archers,
>>>> thought i ask here first, before i try some kernel mailing list.
>>>> i'm writing (for fun) a tiny daemon that sends linux usage (cpu, mem, net, etc.) statistics as efficiently as possible to another machine, repeatedly, to get "live" data.
>>>> at the moment i'm simply sending /proc files, but they sometimes have too much data. so was wondering if there is a more efficient way to get (only parts of) the data thats available in /proc?
>>>> for example, /proc/meminfo has all this info:
>>>> if /proc is the only way to get this info, i wonder if creating a kernel module for this would be more efficient, or even possible?
>>> Hello Andre,
>>> According to what you need, you may want to use the 'free' command
>>> instead, as its output is much simpler than the output of the
>>> /proc/meminfo file
>> The free command gets its information from /proc/meminfo.
>> Performance-wise, it doesn't really matter if a few additional lines
>> need to be parsed.
> Thank you Florian. Actually, I already knew it's the same, I just
> thought that he could use the free command instead of parsing it
> himself. You're right. Performance-wise, it's pretty much the same.
Sorry, I didn't express myself properly. I didn't mean to criticize
free. What I meant to say was that the time it takes to parse
/proc/meminfo or free is negligible. It doesn't need to be any more
efficient. free parses /proc/meminfo. libgtop parses /proc/meminfo.
Querying the information probably takes much more time than parsing it.
Your suggestion to use free may indeed be useful if the original poster
wants parsing to be slightly simpler and does not mind the additional
dependency. My impression was that they considered parsing to be too
More information about the arch-general