Date: Wed, 9 Feb 2005 02:40:47 -0800 From: "Loren M. Lang" <lorenl@alzatex.com> To: "Marc G. Fournier" <scrappy@hub.org> Cc: freebsd-questions@freebsd.org Subject: Re: vinum in 4.x poor performer? Message-ID: <20050209104047.GN8619@alzatex.com> In-Reply-To: <20050209022929.D94338@ganymede.hub.org> References: <20050208231208.B94338@ganymede.hub.org> <20050209002232.B94338@ganymede.hub.org> <20050209011528.X94338@ganymede.hub.org> <20050209022929.D94338@ganymede.hub.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Feb 09, 2005 at 02:32:30AM -0400, Marc G. Fournier wrote:
>
> Is there a command that I can run that provide me the syscall/sec value,
> that I could use in a script? I know vmstat reports it, but is there an
> easier way the having to parse the output? a perl module maybe, that
> already does it?
vmstat shouldn't be too hard to parse, try the following:
vmstat|tail -1|awk '{print $15;}'
To print out the 15th field of vmstat. Now if you want vmstat to keep
running every five seconds or something, it's a little more complicated:
vmstat 5|grep -v 'procs\|avm'|awk '{print $15;}'
>
> Thanks ...
>
> On Wed, 9 Feb 2005, Marc G. Fournier wrote:
>
> >On Tue, 8 Feb 2005, Dan Nelson wrote:
> >
> >>Details on the array's performance, I think. Software RAID5 will
> >>definitely have poor write performance (logging disks solve that
> >>problem but vinum doesn't do that), but should have excellent read
> >>rates. From this output, however:
> >>
> >>>systat -v output help:
> >>> 4 users Load 4.64 5.58 5.77
> >>
> >>>Proc:r p d s w Csw Trp Sys Int Sof Flt
> >>> 24 9282 949 8414***** 678 349 8198
> >>
> >>>54.6%Sys 0.2%Intr 45.2%User 0.0%Nice 0.0%Idl
> >>
> >>>Disks da0 da1 da2 da3 da4 pass0 pass1
> >>>KB/t 5.32 9.50 12.52 16.00 9.00 0.00 0.00
> >>>tps 23 2 4 3 1 0 0
> >>>MB/s 0.12 0.01 0.05 0.04 0.01 0.00 0.00
> >>>% busy 3 1 1 1 0 0 0
> >>
> >>, it looks like your disks aren't being touched at all. You are doing
> >>over 99999 syscalls/second, though, which is mighty high. The 50% Sys
> >>doesn't look good either. You may have a runaway process doing some
> >>syscall over and over. If this is not an MPSAFE syscall (see
> >>/sys/kern/syscalls.master ), it will also prevent other processes from
> >>making non-MPSAFE syscalls, and in 4.x that's most of them.
> >
> >Wow, that actually pointed me in the right direction, I think ... I just
> >killed an http process that was using alot of CPU, and syscalls drop'd
> >down to a numeric value again ... I'm still curious as to why this only
> >seem sto affect my Dual-Xeon box though :(
> >
> >Thanks ...
> >
> >----
> >Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
> >Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
> >_______________________________________________
> >freebsd-questions@freebsd.org mailing list
> >http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> >To unsubscribe, send any mail to
> >"freebsd-questions-unsubscribe@freebsd.org"
> >
>
> ----
> Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
> Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
> _______________________________________________
> freebsd-questions@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org"
--
I sense much NT in you.
NT leads to Bluescreen.
Bluescreen leads to downtime.
Downtime leads to suffering.
NT is the path to the darkside.
Powerful Unix is.
Public Key: ftp://ftp.tallye.com/pub/lorenl_pubkey.asc
Fingerprint: B3B9 D669 69C9 09EC 1BCD 835A FAF3 7A46 E4A3 280C
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050209104047.GN8619>