in reply to Re: Parallel::ForkManager (high cpu and a lot of memory)
in thread Parallel::ForkManager (high cpu and a lot of memory)

There is no way that you should using 100% cpu with 10 threads performing IO
But it's not just IO, LWP::UserAgent loads and parses several Perl modules on demand.

For instance, running the OP script (with a fixed set of URLs) under strace on my machine shows that every process reads...

bytes Compress::Raw::Zlib Compress::Zlib Fcntl File::Glob File::GlobMapper File::Spec File::Spec::Unix HTML::Entities HTML::HeadParser HTML::Parser IO IO::Compress::Adapter::Deflate IO::Compress::Base IO::Compress::Base::Common IO::Compress::Gzip IO::Compress::Gzip::Constants IO::Compress::RawDeflate IO::Compress::Zlib::Extra IO::File IO::Handle IO::Seekable IO::Select IO::Socket IO::Socket::INET IO::Socket::UNIX IO::Uncompress::Adapter::Inflate IO::Uncompress::Base IO::Uncompress::Gunzip IO::Uncompress::RawInflate List::Util LWP::Protocol::http Net::HTTP Net::HTTP::Methods Scalar::Util SelectSaver Socket Symbol URI::_generic URI::http URI::_query URI::_server utf8

Replies are listed 'Best First'.
Re^3: Parallel::ForkManager (high cpu and a lot of memory)
by BrowserUk (Patriarch) on Oct 08, 2008 at 12:34 UTC

    Given that forks are threads on win32, and I see those same file access on my machine with my threaded code, there has to be something else going on that is consuming cpu, because the threaded version uses far less.


    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.
      Thx for all the help so far!

      But I still have a question in my mind.
      If I would code thesame in c++ for example. Would the process use less memory and cpu?

        It depends. If you used MFC or STL probably not. If you use ATL maybe. If you eshew the use of template libraries altogether and write directly to the API (Win32 or POSIX) probably.

        But the other side of that equation is instead of 15 or 20 lines of code you'll end up writing 100s. And they will be much harder to get right, and much, much harder to debug when they go wrong.

        You could also substantially reduce the memory consumption of the Perl program by avoiding LWP and writing your own socket code. For what you are doing it wouldn't be very complex, but it would be much harder to get right.

        Or you can strike a compromise and use LWP::Simple and a pool of threads. This version uses ~20MB and < 3% cpu for 10 threads on my system:

        #! perl -slw use strict; use threads; use LWP::Simple; use threads::shared; use Thread::Queue; $|++; our $THREADS ||= 10; my $sem :shared; my $Q = new Thread::Queue; sub worker { while( my $url = $Q->dequeue ) { chomp( $url ); { lock $sem; print "fetching $url" } my $content = get "http://$url/"; lock $sem; print "$url : ", $content && $content =~ /ok/ ? 'ack' : 'nack' + } } $Q->enqueue( <> ); $Q->enqueue( (undef) x $THREADS ); my @threads = map threads->create( \&worker ), 1 .. $THREADS; $_->join for @threads __END__ C:\test>715836 urls.txt fetching www.bbc.co.uk fetching news.bbc.co.uk fetching www.ibm.com fetching www.yahoo.com fetching www.microsoft.com fetching www.google.com fetching www.google.co.uk fetching www.google.co.au fetching www.cnn.com fetching www.msnbc.com www.google.co.au : nack fetching www.perl.org www.google.co.uk : ack fetching www.nasa.com www.yahoo.com : nack fetching www.ask.com www.google.com : ack fetching www.itv.com www.perl.org : nack www.nasa.com : nack www.ask.com : nack www.msnbc.com : ack www.itv.com : nack www.ibm.com : ack www.microsoft.com : ack news.bbc.co.uk : ack www.cnn.com : ack www.bbc.co.uk : ack

        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.