[Catalyst] server memory usage

[Jorge Gonzalez]

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.