in reply to Checking system cpu load when forking?

Checking CPU load for a process (and all other system counters) from Perl is done with Win32::Perflib . Some examples are available around the monastery (perflib is not particulary easy) .

Forking should be done with Win32::Job . This even gives you a status() method that has access to the accumulated time of the process, in kernel and user mode, which you could use to assess your processus CPU consommation (like buy doing a delta between polling times).

  • Comment on Re: Checking system cpu load when forking?

Replies are listed 'Best First'.
Re^2: Checking system cpu load when forking?
by mattr (Curate) on Nov 09, 2005 at 13:31 UTC
    Thank you very much. I'm not too familiar with the objects that come back from Win32::Perflib but it seems to be a solution for NT and later windows systems. Also Win32::Job looks quite useful in eliminating zombies from plugins.

    Of course the drawbacks are they only work on windows, and not win98 which might need it the most. And I'm not sure if wxperl running from a pp archive will be able to spawn using the perl command like the example given. I'm still looking for a cross-platform heuristic but these modules will be a very useful tool. By the way, can perflib return the overall cpu load of the whole system, or only the process you specify? And it mentions different "levels". Would that let me find overall impact of all subprocesses by checking the load caused by the parent process? Thanks a bunch.

    Just for the sake of argument, is there a problem with using Forkmanager and perlfork as discussed above on windows? Also, the Job module says it is good because it will kill grandchild zombies. Doesn't perl work that way on unix? (and is the failure of perl to do that on windows a windows-specific related to not being able to fork correctly? Thanks again.

[reply]

      Win32::Process::Info is mush easier to use than Win32::PerfLib and can return (almost?) all the same information in a form that is much better structured. However, it will only work on win95/98(SE) if they have had the WMI upgrade added.

      That said, I'd have to wonder about the efficacy of writing new code to support a platform that is 8 years old and for which the manufacturer dropped support over 2 years ago.

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

      Actually what you will get for calling Win32::Perflib is a massive structure made of hash of hash of hash ... up to 7 levels. This structure contains everything that the performance monitor service of Win32 is able to collect, and that includes global cpu load (per CPU on a SMP system, but there maybe also a grandtotal) . Your problem will be to find where it is !

      I found that the perflib struct was almost impossible to understand so i had to test thing many times in order to get the info i wanted from it . Dave Roth has some example scripts on his "roth consulting" site, he wrote the "Win32 perl programing" New Riders book (which i don't recommand by the way, it's close to useless )

      I don't think you can assess the cpu impact of a job (that is a pool of process) through perflib, and you will still have to add the load of the different forked process.

      About forking without Win32::Jobs, the only thing i can say is: even IPC::Open3 didn't work very well for me and that's standard in the active state distribution ! You can't even pass filehandles to the forked process. My feeling is that if you want to run under windows you had better use the windows way ...

[reply]

In Section Seekers of Perl Wisdom