Re: Apache::Session::File and free memory weirdness
Odd thing #1: As it gets into evening time, load on the machine drops off and there are fewer httpd children running, but I am not seeing free memory return to that 1.3GB level. At most it comes back up to 400MB or so. I don't think the httpd children are hanging on to memory, because they cycle through pretty quickly - MaxRequestsPerChild is set to 512 and none of the processes are ever more than a couple minutes old when I look in. Is there any reason to think the parent httpd process would hang on to anything? I have noticed that over time the new processes will spawn with less memory shared. I'm not sure exactly why this is, but it does seem to happen. A nightly complete restart of the server will reset things, but you may not have that option. Odd thing #2: (This part seems most bizarre to me.) At 5:15 AM, we run a Perl script that finds and deletes Apache::Session::File session and lock files that are older than 28 days. Usually there are about 50,000 old files that get deleted out of about 2,300,000 total. Almost immediately, free memory on the machine jumps back up to 1.3GB. What's up with that? Sounds like you're counting the buffers and cache in your used memory. Depending on what OS you're on, you may want to look at a tool other than top. The memory used for buffers and cache will be available to applications if they need it. - Perrin
Re: Apache::Session::File and free memory weirdness
Perrin Harkins wrote: Odd thing #1: As it gets into evening time, load on the machine drops off and there are fewer httpd children running, but I am not seeing free memory return to that 1.3GB level. At most it comes back up to 400MB or so. I don't think the httpd children are hanging on to memory, because they cycle through pretty quickly - MaxRequestsPerChild is set to 512 and none of the processes are ever more than a couple minutes old when I look in. Is there any reason to think the parent httpd process would hang on to anything? I have noticed that over time the new processes will spawn with less memory shared. I'm not sure exactly why this is, but it does seem to happen. A nightly complete restart of the server will reset things, but you may not have that option. I have noticed this also. I have a theory about its cause, but I haven't had the free time to hack with it yet. My theory is that when the VM subsystem swaps pages of the mod_perl parent process, those pages become forever unshared (even after they return to memory from swap). So I was going to test the mlockall() Linux system call to see if it made a difference. (Search the archives for mlockall). However, I am using the Linux platform - the VM behavior may be totally different on Solaris. If anyone else has some time to play with mlockall() on Linux, I'd like to know the results. It'll be a few more weeks till I get a chance. -Adi
