NYCPHP Meetup

NYPHP.org

[nycphp-talk] SuSE linux & unused swap space

Andrew Yochum andrew at plexpod.com
Mon Jan 24 14:57:31 EST 2005


On Mon, Jan 24, 2005 at 12:19:33PM -0700, Nunez, Eddy wrote:
> 
> Greets all you fellow php'ers...
> 
> 	If sys admins can answer this one it'd be great.  For last couple of
> weeks
> my development linux box has not been using it's swap space at all, EVER.
> It's always
> at "0K used"...I mean ALWAYS; even when new processes are spawned.

0K used is good :-)  That means someone spent enough $$ on RAM that
you're not swapping to slow disks.

> 	Recently I was trying to write some PHP for CLI cron task and it
> consistantly
> caused a Seg fault.   My guess it's because PHP CLI script is denied the
> memory it needs.

Mmm.. probably not, IMO.  Seg faults are from memory pointers going
beyond the bounds of the application's allocated memory space.  This is
usually due to buggy pointer arithmetic code, not the inability to
allocate memory.  In my experience, if memory isn't available, you get
an "out of memory" or "unable to allocate memory" error or something
along those lines, not a segfault.

> 	I tried doing web searches for anything helpful, found nothing
> useful .. so I thought
> I'd give the list a try.
> 
> Here's a snapshot of top:
> ----------------------------------------------------------------------------
> -
>   4:35pm  up 3 days, 19:27,  1 user,  load average: 0.00, 0.00, 0.00
> 49 processes: 48 sleeping, 1 running, 0 zombie, 0 stopped
> CPU states:  0.3% user,  0.0% system,  0.0% nice, 99.6% idle
> Mem:   392668K av,  389284K used,    3384K free,       0K shrd,  275740K
> buff
> Swap:  136544K av,       0K used,  136544K free                   20832K
> cached

Well, this tells us that you have something like 384MB of RAM, a little
bit is free and 275MB of it is allocated for buffers.  Oh, and no swap
used ;-). This is quite a typical snapshot profile of a healthy system
with a lot of RAM free.  The kernel typically sucks up all it can for
its buffers/cache.  This is made a bit more clear by the output of the
"vmstat" command.  The RAM allocated there will be given to newly
spawned processes or processes requesting more RAM on-the-fly.  No need
to worry I believe - you see to have plenty free.

I'd say your problem lies elsewhere.  Does it happen consistently in a
particular script?  Are you able to track it down to a particular line
or function?  Is this code using a non-standard PHP extension? Are you
using a hand-built PHP binary, pre-packaged RPM/deb/etc binary?

Hope that helps...
Andrew



More information about the talk mailing list