Yeah that is what I am thinking to. My guess is some large array allocated
in the php code maybe or a sql query taking to long to finish eating up
all the ram. That is kind of interesting to know. I would think the
backstore would maybe be moved back to the paging system after the memory
is free to use again at the very least. My understanding is once return
address of memory used in swap is accessed a page fault occurs and then it
would be taken out of swap space. I guess maybe what is happening is that
that memory got into swap and is never used again so that is why i keep
seeing those numbers in the swap space, or like you said the system just
has decided to leave it there once it has gone in.
I'll have to do some more research but I guess this is comming down to
more of catching the offending apache process then watching vmstat for
page in and page outs happening.....I would say it's fairly obvious that
that is happening before it hits swap.
Anyone have recommendations on catching what php code it is accessing at
that certian time or how to track it down.
On Thu, 30 Aug 2001, mark tinguely wrote:
> Date: Thu, 30 Aug 2001 09:18:42 -0500 (CDT)
> From: mark tinguely <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED], [EMAIL PROTECTED]
> Subject: Re: memory + apache
>
> Once a page gets backed into swap backstore, it will remain until the
> application exits. The page may be brought back to physical memory
> and be used from physical memory. It was decided back in the early
> days that it was not worth the effort to remove the page from backstore
> until the program exitted.
>
> Is your memory/CPU peaks periodic enough to watch with top(1) or
> other diagnostic tool. Something is eating your memory (like a run-away
> CGI).
>
> --mark tinguely.
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message