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 Message-ID: <Pine.BSO.4.21.0103051732370.6833-100000@gandalf.bravenet.com> In-Reply-To: <200103060124.f261OwH48293@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | 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.0103051732370.6833-100000>