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 <[EMAIL PROTECTED]>
> To: Matt Dillon <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> 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 <[EMAIL PROTECTED]>
> > To: Dan Phoenix <[EMAIL PROTECTED]>
> > Cc: [EMAIL PROTECTED]
> > 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
