fat apache/mod_ssl/mod_php: big memory size on solaris
hi, Trying to build a small apache with mod_ssl and mod_php on sparc64-solaris2.9 (512 Mo RAM), i found the following strange result and i don't understand why ? The first build: openssl-0.9.8d: (with default option) apache-1.3.37-20070208: with_mod_ssl = yes with_mod_php = yes and with_mod_php*option = no After successfully build and install, show process size give the following result (prstat -s size) apache = 72M Size (not RSS) The second build with_mod_ssl = no, and after install and running, give the following result: apache = 5M Size. The difference is not so big under linux. How can we explain this difference on sparc64-solaris2.9 ? And perhaps how can i get apache thinner ;) ? any idea are welcome __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: [CVS] OpenPKG: openpkg-src/libgda/ libgda.patch
On Mon, Feb 12, 2007, Ralf S. Engelschall wrote: OpenPKG CVS Repository http://cvs.openpkg.org/ Server: cvs.openpkg.org Name: Ralf S. Engelschall Root: /v/openpkg/cvs Email: [EMAIL PROTECTED] Module: openpkg-src Date: 12-Feb-2007 19:18:27 Branch: HEAD Handle: 2007021218182600 Modified files: openpkg-src/libgda libgda.patch Log: I can no longer remember for what the -static were required or on what platform, but resurrenct them in all previous placed just to make sure we do not break anything until I'm sure we don't need them In this case shouldn't there be a build time dependency to gcc? -static might not be portable, please correct me if I'm wrong. -cs __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: fat apache/mod_ssl/mod_php: big memory size on solaris
On Mon, Feb 12, 2007, PLI wrote: Trying to build a small apache with mod_ssl and mod_php on sparc64-solaris2.9 (512 Mo RAM), i found the following strange result and i don't understand why ? The first build: openssl-0.9.8d: (with default option) apache-1.3.37-20070208: with_mod_ssl = yes with_mod_php = yes and with_mod_php*option = no After successfully build and install, show process size give the following result (prstat -s size) apache = 72M Size (not RSS) The second build with_mod_ssl = no, and after install and running, give the following result: apache = 5M Size. The difference is not so big under linux. How can we explain this difference on sparc64-solaris2.9 ? And perhaps how can i get apache thinner ;) ? Well, you said not RSS above, but only the RSS is what really counts here! The _virtual_ process size you can more or less completely ignore. Here the different Unix flavors always differ dramatically because of the way shared memory areas are counted, etc. So, as long as the RSS of your processes is about 10MB, everything is just fine. BTW, as a comparison: experience shows that a full-sized Apache usually grows up to 50MB in RSS after some processing time. For a small Apache I expect about 10MB RSS. The only thing you should keep in mind when comparing RSS values is that your system should be not already swapping as this fudges your comparison, of course. ;-) Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: [CVS] OpenPKG: openpkg-src/libgda/ libgda.patch
On Mon, Feb 12, 2007, Christoph Schug wrote: On Mon, Feb 12, 2007, Ralf S. Engelschall wrote: OpenPKG CVS Repository http://cvs.openpkg.org/ Server: cvs.openpkg.org Name: Ralf S. Engelschall Root: /v/openpkg/cvs Email: [EMAIL PROTECTED] Module: openpkg-src Date: 12-Feb-2007 19:18:27 Branch: HEAD Handle: 2007021218182600 Modified files: openpkg-src/libgda libgda.patch Log: I can no longer remember for what the -static were required or on what platform, but resurrenct them in all previous placed just to make sure we do not break anything until I'm sure we don't need them In this case shouldn't there be a build time dependency to gcc? -static might not be portable, please correct me if I'm wrong. No, gcc is not required. _THIS_ -static is from libtool(1), not the -static from gcc(1). Yes, I know, rather confusing... Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
