Date: Mon, 5 Mar 2001 17:24:58 -0800 (PST) From: Matt Dillon <dillon@earth.backplane.com> To: Dan Phoenix <dphoenix@bravenet.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: systat -vmstat or iostat IO help Message-ID: <200103060124.f261OwH48293@earth.backplane.com> References: <Pine.BSO.4.21.0103051702020.6833-100000@gandalf.bravenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:Well we use php mostly. I noticed from moving from php3 to php4
:memory consumption on webservers was just incredible and had to
:increase ram from 256 megs to 500megs on each of webservers.
:Memory is fine now.
:
:[root@lotho dphoenix]# ps aux|grep httpd|wc -l
: 65
:[root@lotho dphoenix]# top |grep -i mem
:Mem: 193M Active, 138M Inact, 89M Wired, 33M Cache, 61M Buf, 46M Free
:[root@lotho dphoenix]# uptime
: 5:06PM up 2 days, 23:51, 1 user, load averages: 3.29, 1.94, 1.70
:[root@lotho dphoenix]#
:
:load is down now cause peak is off but systat -vm 1 showed about 3-4
:seconds of 100% then 1 sec of 0 then 3-4 sec of 100% again...etc.
:Another factor is mysql with persistant database connections.
:Waiting on a request back from the mysql server could cause some IO
You shouldn't have 46MB free. You should have maybe 10MB free. 46MB free
would seem to indicate that some progrma is eating a large chunk of
memory and then exiting, blowing a big piece of the disk cache away
in the process.
I would monitor the machine's memory and disk I/O closely to try to
figure out which process or processes are responsible.
:as well i could imagine...another factor. Only thing I have never been
:able to figure out is how to kill persistant connections when a mysql
:server goes down. Let's say i drop a mysql server....all the webservers
:will use up all ram and swap till machine just drops using up all it's
:resources.....effect on freebsd is unable to free vm free_pages and
Dunno, but it sounds like a problem you need solve. At the very least
set Apache's connection limit so Apache stops working before the machine
would otherwise die.
:But I am going offtopic....memory is not an issue. So real question
:is how to calculate then if the drive is doing more than say 166 seeks on
:disk per sec. Any great tool out there :)
Memory is always an issue when you have a saturated drive unless the
saturation is being caused by a lots of write I/O.
For a script, probably the easiest thing to do is to pipe (the
continuous) 'iostat ad0 10' output to a script and have the script pull
out the tps field and do something with it.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200103060124.f261OwH48293>