|
Re^3: portable way to get system load average
by BrowserUk (Patriarch) on Jun 25, 2010 at 17:35 UTC
|
i am disappointed there is no pure perl solution in the core :/
The reason is quite simple.
If there was any demand for it, it would either be in core, or someone would have made it available as a module amongst the 18000? modules on CPAN. But there is no demand, so it isn't. Indeed, the fact that it isn't there shows there is no demand for it.
So what use would you make of it, were it available?
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
|
|
so no availability == no demand, eh? causality, anyone?
i need this functionality for throttling purposes. daemons written in perl that sleep in the background based on load. the daemons doing maintanence shouldn't starve the ones making money. i know load is not perfect for this, but it's usable.
saying "you dont need this really" just because perl cannot provide it without extra strap-ons is apologetics at its worst.
| [reply] |
|
|
i need this functionality for throttling purposes. daemons written in perl that sleep in the background based on load. the daemons doing maintanence shouldn't starve the ones making money. i know load is not perfect for this, but it's usable.
The point is, that won't work! By the time your code has obtained an instantaneous cpu load reading, it has changed. And by the time you're code has decided what to do about the out-of-date reading it has, it has changed again.
Have you heard of Hysteresis?
You will either drive your systems into chaotically unstable boom-bust cycles where everything sleeps and then they all wake up together and you get a huge burst of activity; which they all detect and therefore go back to sleep.
Or, you smooth the reading by averaging them together over a few seconds. Then your code is reacting to an approximation of the real situation as it was a few seconds ago. Net result is that anything from 10% to 30% of your cpu is spent accessing, calculating, and deciding whether to sleep or work; and wasting context switches by sleeping when you could be doing useful work.
And whatever calculations you come up with for your breakpoints through trial & error, every time a new process is added, or a new device; or one of either is removed; or you move to a faster cpu; or more cores; or get a faster disk; or the cpu drops the clock rate because one or more cores are overheating; all your calculations go right up the swanny.
Load balancing/throttling processes based upon instantaneous cpu loading doesn't work. It never has, and never will!
Besides which, every modern OS has a very simple, and extremely effective way of ensuring that "money making processes" are favoured over "maintenance processes". The keyword here is PRIORITY.
Look up "nice" if you're on a *nix system; or type help start at a command line prompt if you're on Windows. It can also be done programmically.
saying "you dont need this really" just because perl cannot provide it without extra strap-ons is apologetics at its worst.
I'm certainly not apologising. Perl can provide it quite easily, but other than writing replacements for top/TaskManager, it doesn't have a use. Hence no demand.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply]
[d/l] |
|
|
|
|
|
|
|
|
|
|
|
|
'saying "you dont need this really" just because perl cannot provide it without extra strap-ons is apologetics at its worst.'
You quote "you dont need this really" as though it's something that BrowserUk has said, which they didn't.
Also this is the first time I've heard modules described as "strap-ons".
| [reply] |
|
|
|
|
|
|
|
| [reply] |
|
|
Re^3: portable way to get system load average
by sierpinski (Chaplain) on Jun 25, 2010 at 17:29 UTC
|
every other script langauge has a call for this.. perl being the system tool it is, how is this even possible? i am disappointed there is no pure perl solution in the core :/
I didn't say there wasn't one (I don't have the information to accurately answer that question), but I was merely asking why you have such a restriction. If there is some technical reason, perhaps it can be mitigated another way.
If you don't have a shell, how is your program running? If you don't know what commands are available on the host, how can you assume that any program/shell/script/whatever is available? There is no cure-all for every environment or platform.
One thing that perl does that I think is a great thing, is that it doesn't re-invent the wheel all of the time. If there is a command that exists on all version of a particular platform (like ls, cp, etc), it doesn't try to create it's own version. You have to make some assumptions to expect any script to work on any particular system. (is perl installed, is it the correct version, do I have access to /bin, is my script executable, or whatever) You can check for these assumptions, but if you want a script to execute on _any_ environment regardless of what you have access to, what exists on the box, or anything, then I'd imagine it would be rather difficult and/or tedious. | [reply] |
|
|
i dont find it unreasonable to write full perl programs that make no assumptions about what systems they run on whatsoever... actually, that's one of its real strengths and the reason many commercial applications and many inhouse tools were written in it. it can bridge systems flawlessly because it has its own library of functions.
there are multiple CPAN modules for uptime/load, i had a look at some of them. there are a couple of reasons why i would prefer not to use them:
- they have no corresponding packages in most operating systems (only the most used/famous ones have) and would create overhead in system admininstration.
- they use exactly the same unportable techniques like using sysctl and /proc and so on
| [reply] |
Re^3: portable way to get system load average
by JavaFan (Canon) on Jul 07, 2010 at 12:39 UTC
|
considering that there is a simple libc call getloadavg()
... then it should be easy to write a few lines of XS and get said information. If you then release said module on CPAN, others can benefit from it as well.
But is getloadavg() available everywhere? Your request is for a portable way. This suggests it doesn't.
| [reply] |
|
|
It is hard to believe that anyone (never mind many anyones), missed the obvious GetSystemTimes() function. Hard to believe that they actually looked--which is the "usual problem".
It would take minimal work to translate the return values of that function into the appropriate values for getloadavg(). Of course, the results would be equally meaningless--what it the point in knowing what happened 60 seconds ago when 128 billion (* 2 or 4 or 6 or 8 or 12 or 16 or 48) things will have happened in the interim?
In human terms, that's like receiving an urgent news flash(*) that the Egyptians had just finished building the Great Pyramid.
Assumes that your news flashes are delivered within one second of the actual event occurring.
Ie. If 1 clock cycle represents 1 second in "human time", then on a 2 GHz single core cpu, a 1 minute load average equates to information pertinent ~4000 years ago!
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |