Re: maintaining shared memory size (was: Re: swampedwithconnection?)
top - 17:24:27 up 34 days, 9:01, 4 users, load average: 20.67, 12.84, 9.26 Tasks: 142 total, 7 running, 135 sleeping, 0 stopped, 0 zombie Cpu(s): 88.7% us, 7.6% sy, 0.0% ni, 0.0% id, 2.0% wa, 0.0% hi, 1.7% si Mem:906736k total, 359464k used, 547272k free, 6184k buffers Swap: 3036232k total, 111564k used, 2924668k free,17420k cached Which processes are swapping? Have you tried setting MaxClients to say 10 (or some other low number that'll ensure you don't run out of memory). I just did, and cleared the swap before doing another testing. The result: Nothing swapped, but the average response time goes down by 20 seconds. I guess Perrin was right, with 30 MaxClients, the processes are competing the CPU cycles. I think I have to write some of the code in C. I can't find any other places in the code to optimize (or probably I uncounciously don't want to make changes because I don't have any test suites)... --- Badai Aqrandista Cheepy (?) _ Low rate ANZ MasterCard. Apply now! http://clk.atdmt.com/MAU/go/msnnkanz003006mau/direct/01/ Must be over 18 years.
Re: survey
It's in backports.org's incoming directory, as of the 16th. Let's hope they push that out soon (I don't think they've released any backports for Sarge yet). They've also got an updated libapreq2. http://www.backports.org/incoming/ On Sunday 28 August 2005 06:48 am, Jeff wrote: > >> It is not even available on Testing and Unstable :( > > > > Sure it is. Unstable has 2.0.1. > > You're right - don't know how I missed that! since May! > > Unfortunately I am not in a position to upgrade our servers to unstable, > and it has i386 dependencies on libc6 >= 2.3.5-1, perl >= 5.8.7 etc etc > etc ad infinitum, nothing on backports.org, so for anyone running > anything Debian production, no mod_perl2 for the next few years. > > :((
Re: survey
It is not even available on Testing and Unstable :( Sure it is. Unstable has 2.0.1. You're right - don't know how I missed that! since May! Unfortunately I am not in a position to upgrade our servers to unstable, and it has i386 dependencies on libc6 >= 2.3.5-1, perl >= 5.8.7 etc etc etc ad infinitum, nothing on backports.org, so for anyone running anything Debian production, no mod_perl2 for the next few years. :((
Re: memory resident config hash
Ok, thank you. That example from perlref is what I was searching for, but it seems that it can't do what I want. (I didn't know that programs that use 'require' don't share the memory). I will try to use Config::Simple. I need to store a few hashrefs in the memory. Thank you very much. Teddy From: "Michael Peters" <[EMAIL PROTECTED]> > If these are just .ini files, then why don't you use something like > Config::Simple to create a object from which to read the data. You could > then create a wrapper class that would give access to this object as a > singleton. Load the class on server startup and initialize the object > there too. As long as you don't change the data it should be stay shared > by all of your apache children. > > Once you do a 'require' in a process the data is no longer shared > between processes. Another request that needs the same configuration > data that is handled by a different apache process will need to do the > same 'require' thus increasing it's unshared memory, etc. > > Sometimes this is necessary, but it should be avoided if possible. How > many of these language specific configs do you have? Do you know which > ones are more likely to be used? If you do then preload as many as > possible ahead of time.
