FAQ
Looking at the server's processes, I see three of script/myapp_fastcgi.pl, which I suppose
co-inside with the Apache configuration option where I said to start 3 fastcgi processes
to handle this app.

WebMin tells me "size", which can't be the actual load of server RAM needed since it
doesn't add up with the total usage.

Some basics here... is Apache/fastcgi/Catalyst smart enough to load the app and get it
running to the point where it is ready to start handling requests, and THEN fork it? The
Perl runtime and all the loaded modules can certainly be shared! Do I need more advanced
configuration or app tuning to maximize this ability?

How can I tell, through WebMin or command-line tools via ssh, how much memory is really
being used by my apps?

Thanks for any pointers!
--John

Search Discussions

  • Jorge Gonzalez at Apr 11, 2011 at 1:54 pm
    You can be assured that it's being done that way. Certainly all modern
    operating systems do Copy-On-Write on memory pages, which means that
    several processes with a common set of code will share much of it. This
    is not being done by Apache/fastcgi/Catalyst, but by the very operating
    system itself.

    Linux even has a recently added capability called KSM (kernel same-page
    merging) which does this even with completely unrelated processes, based
    on the bare memory contents (which is pretty much more difficult than
    the original case, by the way).

    Regarding your question, since lots of processes have lots of shared
    memory chunks, it's difficult to "blame" some process or another for
    using a memory region. You can use "top" to spot the memory usage of
    processes, looking at the VIRT, RSS and SHR columns. I'd use the RSS
    column, but certainly the sum of this column will be much greater than
    your physical RAM in a loaded server (due to shared pages).

    Regards
    J.

    El 11/04/11 15:07, John M. Dlugosz escribi?:
    Looking at the server's processes, I see three of
    script/myapp_fastcgi.pl, which I suppose co-inside with the Apache
    configuration option where I said to start 3 fastcgi processes to
    handle this app.

    WebMin tells me "size", which can't be the actual load of server RAM
    needed since it doesn't add up with the total usage.

    Some basics here... is Apache/fastcgi/Catalyst smart enough to load
    the app and get it running to the point where it is ready to start
    handling requests, and THEN fork it? The Perl runtime and all the
    loaded modules can certainly be shared! Do I need more advanced
    configuration or app tuning to maximize this ability?

    How can I tell, through WebMin or command-line tools via ssh, how much
    memory is really being used by my apps?

    Thanks for any pointers!
    --John


    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive:
    http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/
  • John M. Dlugosz at Apr 12, 2011 at 10:58 am

    On 4/11/2011 8:54 AM, Jorge Gonzalez jorge.gonzalez-at-daikon.es |Catalyst/Allow to home| wrote:
    You can be assured that it's being done that way. Certainly all modern operating systems
    do Copy-On-Write on memory pages, which means that several processes with a common set
    of code will share much of it. This is not being done by Apache/fastcgi/Catalyst, but
    by the very operating system itself.
    I don't think so. If two different Perl processes are started up, and each loads modules
    and loads data, they will be writing all that to separate pages.

    Rather, it needs to load all the stuff and _then_ fork, so that the stuff is identical and
    shared.

    Thanks for the pointer to the "top" command; I'll read up on it.
  • Jorge Gonzalez at Apr 12, 2011 at 12:51 pm

    El 12/04/11 12:58, John M. Dlugosz escribi?:
    On 4/11/2011 8:54 AM, Jorge Gonzalez jorge.gonzalez-at-daikon.es
    Catalyst/Allow to home| wrote:
    You can be assured that it's being done that way. Certainly all
    modern operating systems do Copy-On-Write on memory pages, which
    means that several processes with a common set of code will share
    much of it. This is not being done by Apache/fastcgi/Catalyst, but
    by the very operating system itself.
    I don't think so. If two different Perl processes are started up, and
    each loads modules and loads data, they will be writing all that to
    separate pages.

    Rather, it needs to load all the stuff and _then_ fork, so that the
    stuff is identical and shared.
    You are right in this case: the pages would be shared just after the
    fork, but would probably start to get copied individually for each
    process again as soon as the process starts doing something useful. For
    perl, which works as some kind of JIT compiler, the script executable
    code is just data and probably gets rewritten very often, so each
    process would end with its own set of pages.

    I'd bet for a KSM capable machine and OS. You can activate and
    deactivate it, so benchmarking it with your app would be trivial.

    Regards
    J.
  • John M. Dlugosz at Apr 12, 2011 at 3:17 pm

    You are right in this case: the pages would be shared just after the fork, but would
    probably start to get copied individually for each process again as soon as the process
    starts doing something useful. For perl, which works as some kind of JIT compiler, the
    script executable code is just data and probably gets rewritten very often, so each
    process would end with its own set of pages.

    I'd bet for a KSM capable machine and OS. You can activate and deactivate it, so
    benchmarking it with your app would be trivial.
    I would suppose that loading all the modules needed would generate the internal perl
    representation, and that won't change during execution. It doesn't get rewritten unless
    it's unloaded, which doesn't happen to named package contents.

    It's plausible that multiple fire-ups of the same program would wind up with identical
    pages, if no memory allocation ever depends on timing or anything other than static
    configuration.

    In Windows, the executable code of a process is "backed" by the exe file and shares
    physical pages with every process that loaded it. Paging out just forgets it, and paging
    it reads it from the exe file again. Would you know if Linux, with its fork/exec model,
    does likewise?

    Of course, I know that doesn't help the Perl code, which is data as far as the Kernel is
    concerned.

    FWIW, VMWare does its own KSM at a higher level, across virtual machines. So if that is
    possible it does reduce the real load on the host hardware. But it doesn't change how I'm
    billed!
  • Jorge Gonzalez at Apr 13, 2011 at 7:25 am

    El 12/04/11 17:17, John M. Dlugosz escribi?:
    I would suppose that loading all the modules needed would generate the
    internal perl representation, and that won't change during execution.
    It doesn't get rewritten unless it's unloaded, which doesn't happen to
    named package contents.
    Code in Perl is dinamic: you can eval a string with perl code at runtime
    and it will generate new code (data, for the kernel).
    It's plausible that multiple fire-ups of the same program would wind
    up with identical pages, if no memory allocation ever depends on
    timing or anything other than static configuration.
    Could be, but lots of perl modules defer their load until some function
    belonging to them is actually called at runtime. Catalyst does this. So
    it's not like "load everything, set everything up and then fork". Tons
    of new modules will be loaded after that.
    In Windows, the executable code of a process is "backed" by the exe
    file and shares physical pages with every process that loaded it.
    Paging out just forgets it, and paging it reads it from the exe file
    again. Would you know if Linux, with its fork/exec model, does likewise?
    Of course it does.
    Of course, I know that doesn't help the Perl code, which is data as
    far as the Kernel is concerned.
    That's my point, actually.
    FWIW, VMWare does its own KSM at a higher level, across virtual
    machines. So if that is possible it does reduce the real load on the
    host hardware. But it doesn't change how I'm billed!
    I assumed that the machine was yours. If someone is billing you for such
    a sloppy concept like "memory usage", well, you are stuck with whatever
    criteria s/he wants to impose on you, since there's no easy way to
    measure it on a shared system.

    If your provider could bill you for a complete virtual machine with,
    say, 2GB of emulated RAM, that would be pretty more sensible.

    Isn't this getting a bit offtopic for the Catalyst list? Maybe we should
    continue this chat personally...

    Regards
    J.
  • Tomas Doran at Apr 29, 2011 at 2:07 pm

    On 13 Apr 2011, at 08:25, Jorge Gonzalez wrote:
    It's plausible that multiple fire-ups of the same program would
    wind up with identical pages, if no memory allocation ever depends
    on timing or anything other than static configuration.
    Could be, but lots of perl modules defer their load until some
    function belonging to them is actually called at runtime. Catalyst
    does this.
    No it does not. This is entirely incorrect.

    Some perl modules do only get loaded at Runtime, but this is _not
    true_ for a Catalyst application (but may be true for modules you
    application then uses).

    Cheers
    t0m
  • Tomas Doran at Apr 29, 2011 at 2:11 pm

    On 12 Apr 2011, at 13:51, Jorge Gonzalez wrote:

    Rather, it needs to load all the stuff and _then_ fork, so that the
    stuff is identical and shared.
    You are right in this case: the pages would be shared just after the
    fork, but would probably start to get copied individually for each
    process again as soon as the process starts doing something useful.
    For perl, which works as some kind of JIT compiler, the script
    executable code is just data and probably gets rewritten very often,
    so each process would end with its own set of pages.
    Not quite.

    What happens is that the perl code is all compiled, and will stay
    static for the duration of the program.

    Ergo loading a load of stuff, then forking, _will_ give you some
    memory sharing.

    However, the difficulty is that you don't get to in any way assign
    which parts of the memory get perl code (which doesn't change), and
    which get variables (which do change). And the operating system's
    granularity of 4k on memory pages, means that if you change any 1 byte
    within each 4k page, then that page will get unshared.

    Ergo even though most of a memory page may contain static code, it'll
    be unlucky enough to become unshared if a few bytes are allocated to
    variables...

    So memory sharing starts out high if you pre-load everything, but
    falls off over time..

    Cheers
    t0m
  • Tomas Doran at Apr 12, 2011 at 12:09 pm

    On 11 Apr 2011, at 14:07, John M. Dlugosz wrote:

    Looking at the server's processes, I see three of script/
    myapp_fastcgi.pl, which I suppose co-inside with the Apache
    configuration option where I said to start 3 fastcgi processes to
    handle this app.

    WebMin tells me "size", which can't be the actual load of server RAM
    needed since it doesn't add up with the total usage.

    Some basics here... is Apache/fastcgi/Catalyst smart enough to load
    the app and get it running to the point where it is ready to start
    handling requests, and THEN fork it? The Perl runtime and all the
    loaded modules can certainly be shared! Do I need more advanced
    configuration or app tuning to maximize this ability?
    If you're using dynamic fast cgi, then no, there is no way to do this,
    as apache dynamically starts / removes workers.

    if you're using external mode fast cgi, then yes, this 'just works'.

    Cheers
    t0m

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcatalyst @
categoriescatalyst, perl
postedApr 11, '11 at 1:07p
activeApr 29, '11 at 2:11p
posts9
users3
websitecatalystframework.org
irc#catalyst

People

Translate

site design / logo © 2022 Grokbase