Getting system info using perl

[saurabh hirani]

Hey all,

I am writing a daemon in perl which will check for load average, free
disk space on a particular partition and free memory and send it as an
updation query to another daemon.

I am supposed to check for these params at least twice in a minute. I
was looking at perl modules which would give me this info - but after
looking under their hood - most of them fire system command to launch
a shell. Some of them do it via /proc which I would rather do myself.
My queries are

1. What is faster - reading /proc/loadavg or uptime? I would say /proc/
loadavg.

2. Are there any perl modules which are using XS to get these queries
done faster without opening a shell?

3. Load average I can get through /proc/loadavg, free memory through /
proc/meminfo. But how to obtain free disk space through proc? I am
talking about 2.6.x kernels on RHEL4. I want to use /proc as much as I
can because I would be reading from a file and not launching a shell.

Are there any other suggestions that you guys think would be useful in
writing such daemons which do frequent updates? Thanks for going
through my post.


regards,
Saurabh.

 

[Peter Scott]

I am writing a daemon in perl which will check for load average, free
disk space on a particular partition and free memory and send it as an
updation query to another daemon.

I am supposed to check for these params at least twice in a minute. I
was looking at perl modules which would give me this info - but after
looking under their hood - most of them fire system command to launch a
shell. Some of them do it via /proc which I would rather do myself. My
queries are

1. What is faster - reading /proc/loadavg or uptime? I would say /proc/
loadavg.

2. Are there any perl modules which are using XS to get these queries
done faster without opening a shell?

The module Sys::Cpuload claims to do what you want:

http://search.cpan.org/~clintdw/Sys-CpuLoad-0.03/CpuLoad.pm

I haven't tried it myself. Inspection shows it only uses XS on BSDish
systems, and inspects /prov/loadavg on Linux. Seems like a good starting
place though.

Twice a minute isn't exactly onerous for running a short child process
IMHO. Twice a second and I'd worry.

 

[Peter Makholm]

3. Load average I can get through /proc/loadavg, free memory through /
proc/meminfo. But how to obtain free disk space through proc? I am
talking about 2.6.x kernels on RHEL4. I want to use /proc as much as I
can because I would be reading from a file and not launching a shell.

Using Linux::SysInfo should be even faster than reading and parsing
two files in /proc. This module is a simple wrapper around the
Linux-specific sysinfo()-system call.

Free disk space can be detected by Filesys:f which is a wrapper
around the statfs() or statvfs() systemcalls. Again a wee bit faster
than opening a file and parsing the values.

Filesys:f should be portable on POSIX systems, but Linux::SysInfo is
linux-only. But reading anything directly from /proc/ would also be
very linux-specific.

//Makholm

 

[saurabh hirani]

The module Sys::Cpuload claims to do what you want:

http://search.cpan.org/~clintdw/Sys-CpuLoad-0.03/CpuLoad.pm

I haven't tried it myself.  Inspection shows it only uses XS on BSDish
systems, and inspects /prov/loadavg on Linux.  Seems like a good starting
place though.

Thanks. I started with that only. After looking at the code, I saw
that I could do that without including the module. So I wrote my own
code to do thatt.

Twice a minute isn't exactly onerous for running a short child process
IMHO.  Twice a second and I'd worry.

That is what I was thinking about. But I actually don't know the
frequency. It can also be once in 5 seconds.

 

[saurabh hirani]

Using Linux::SysInfo should be even faster than reading and parsing
two files in /proc. This module is a simple wrapper around the
Linux-specific sysinfo()-system call.

Free disk space can be detected by Filesys:f which is a wrapper
around the statfs() or statvfs() systemcalls. Again a wee bit faster
than opening a file and parsing the values.

Filesys:f should be portable on POSIX systems, but Linux::SysInfo is
linux-only. But reading anything directly from /proc/ would also be
very linux-specific.

Thanks Peter. That was really useful. I will be using these modules -
for their speed, ease of use and options provided which might be
useful in the future. My daemon is not going to bomb update queries to
the other daemon as frequently as once a second, but these modules
really do pump up the speed from okay to burn-the-road. Just to
compare system call and Filesys:f, I wrote a small perl program
which calls getting free disk using system call to df and using the
module. I profiled them by running them around 1000 times and this was
the output of dprofpp:

Forking df and getting the time:

Total Elapsed Time = 42.04899 Seconds
User+System Time = 5.668994 Seconds
Inclusive Times
%Time ExclSec CumulS #Calls sec/call Csec/c Name
96.7 5.485 5.485 1000 0.0055 0.0055 main::get_freequeue


Using df from the module
Total Elapsed Time = 0.618107 Seconds
User+System Time = 0.768107 Seconds
Inclusive Times
%Time ExclSec CumulS #Calls sec/call Csec/c Name
92.1 0.013 0.708 1000 0.0000 0.0007 main::get_freequeue
90.4 0.013 0.695 1000 0.0000 0.0007 Filesys:f::df
88.7 0.682 0.682 1000 0.0007 0.0007 Filesys:f::_df

The difference is staggering.

Thanks again guys for your viewpoints. They really helped.

regards,
Saurabh

 

[Uri Guttman]

sh> Forking df and getting the time:

sh> Total Elapsed Time = 42.04899 Seconds
sh> User+System Time = 5.668994 Seconds
sh> Inclusive Times
sh> %Time ExclSec CumulS #Calls sec/call Csec/c Name
sh> 96.7 5.485 5.485 1000 0.0055 0.0055 main::get_freequeue


sh> Using df from the module
sh> Total Elapsed Time = 0.618107 Seconds
sh> User+System Time = 0.768107 Seconds
sh> Inclusive Times
sh> %Time ExclSec CumulS #Calls sec/call Csec/c Name
sh> 92.1 0.013 0.708 1000 0.0000 0.0007 main::get_freequeue
sh> 90.4 0.013 0.695 1000 0.0000 0.0007 Filesys:f::df
sh> 88.7 0.682 0.682 1000 0.0007 0.0007 Filesys:f::_df

sh> The difference is staggering.

this is not news. a single system call with some perl wrapping will
always blow away ANY fork. fork is a very slow system call and it uses
tons of resources (ram AND cpu). we always say to newbies to stop
calling backticks and such when modules or perl builtins can do it for
you. we see newbies doing `date ...` vs strftime so often.

uri

 

[saurabh hirani]

--
Uri Guttman  ------  (e-mail address removed)  --------  http://www.sysarch.com--
-----  Perl Code Review , Architecture, Development, Training, Support ------
--------- Free Perl Training ---http://perlhunter.com/college.html---------
---------  Gourmet Hot Cocoa Mix  ----  http://bestfriendscocoa.com---------

Checked out the link to your website. Felt good to you see you being
so passionate about the language. 3 years ago I had worked on my first
perl project which required me to read a file backwards and your
File::ReadBackwards was a savior on that front.