Date: Mon, 5 Mar 2001 18:04:49 -0800 (PST) From: Dan Phoenix <dphoenix@bravenet.com> To: Matt Dillon <dillon@earth.backplane.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: systat -vmstat or iostat IO help Message-ID: <Pine.BSO.4.21.0103051804050.6833-100000@gandalf.bravenet.com> In-Reply-To: <Pine.BSO.4.21.0103051732370.6833-100000@gandalf.bravenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I guess that machien was a bad example as it is doing well right now. I will have to wait till peak time again to monitor it. On Mon, 5 Mar 2001, Dan Phoenix wrote: > Date: Mon, 5 Mar 2001 17:51:22 -0800 (PST) > From: Dan Phoenix <dphoenix@bravenet.com> > To: Matt Dillon <dillon@earth.backplane.com> > Cc: freebsd-hackers@FreeBSD.ORG > Subject: Re: systat -vmstat or iostat IO help > > > > [Mon Mar 5 11:04:01 2001] [error] (54)Connection reset by > peer: getsockname > [Mon Mar 5 11:04:01 2001] [error] (54)Connection reset by > peer: getsockname > > i see that from apache error log > > i have seen that is past from a)either maxclients being set to low or > b) freebsd maxusers set to low.... > > neither is the case on this machine. > > > > from /var/log/messages i see > > > Mar 4 23:00:47 drago postfix/flush[73473]: fatal: accept > connection: Software caused connection abort > Mar 4 23:17:27 drago postfix/flush[74329]: fatal: accept > connection: Software caused connection abort > Mar 4 23:34:07 drago postfix/flush[75360]: fatal: accept > connection: Software caused connection abort > Mar 4 23:34:48 drago /kernel: pid 65438 (httpd), uid 506: exited on > signal 10 > > > ok httpd exiting of signal 10.....that is a bad one. > > > only 2 things really running on webservers are apache and postfix. > all postfix does on webservers is just dish mail off to mail servers, > so apache is my concern. Max clients is not set to low. > > > [root@drago dphoenix]# top |grep -i mem > Mem: 128M Active, 169M Inact, 77M Wired, 22M Cache, 61M Buf, 106M Free > > Active: > number of pages active > > Inact: number of pages inactive > > Wired: number of pages wired down, including cached file > data pages > Cache: number of pages used for VM-level disk caching > > Buf: number of pages used for BIO-level disk caching > > Free: number of pages free > > Total: total available swap usage > > > I am trying to figure out corelation between Inactive and Free then. > Inact would be unused ram right? > Free would be what how much of Active is being used? So what you are > saying is if there is to much free then alot of active pages are being > killed for some reason...as seen in error logs etc? ....just trying to get > a quick overview of what a good accessment that was...never thought of > that. > > > On Mon, 5 Mar 2001, Matt Dillon wrote: > > > 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 > > > > > > :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?Pine.BSO.4.21.0103051804050.6833-100000>