Re: 2xPIIIx450 results & NFS results (was More benchmarking stuff...)

On Friday, 17 September 1999 at 11:17:48 -0700, Matthew Dillon wrote: > : Might I then request that you help rewrite it so that it performs > :a much more comprehensive testing of OS/filesystem throughput? > :Myself, I'd really love to see something that lets you seriously > :stress your syste

Re: More benchmarking stuff...

Actually, the IIRC, NetApps have NVRAM cache, powering the thing down and back up doesn't change anything. - ( Adam Strohl ) - - UNIX Operations/Systems http://www.digitalspark.net - - adams (at) digitalspark.net

Re: 2xPIIIx450 results & NFS results (was More benchmarking stuff...)

: Note that with a mail server, this is precisely the sort of thing :that happens with /var/spool/mqueue. In particular, with sendmail, a :qf/df pair of files get created, the message is received, the sender :is told "250 Ok", then sendmail goes to deliver the message in the :background

2xPIIIx450 results & NFS results (was More benchmarking stuff...)

Ok, these are on duel P3 450 boxes running -CURRENT, with the NFS performance enhancements. Local disk is an 18G seacrate on an LVD/W scsi bus. UFS tests: on 1G duel P3-450 machine, 1x18G seagate SCSI-LW bus NFS tests: 1G duel P3-450 client, 512M duel P3-450 server, 100Base

Re: More benchmarking stuff...

:According to kirk FSYNC() does the right thing and 'sync()' doesn't. : Lets see... well, it will sync the file state, but it will not necessarily sync the related directory entry (as far as I can tell). So if you take a case such as sendmail creating a queue file, fsync will suc

Re: More benchmarking stuff...

:Also FreeBSD only caches a limited number of directory blocks. This :was discussed on -hackers in April. Search for the subject "Directories :not VMIO cached at all!". Matt Dillon posted a patch to to better :cache directories (at the possible expense of wasted RAM and which breaks :NFS) in M

Re: More benchmarking stuff...

:> files sitting in unflushed disk caches and you reboot, those files are :> lost. Softupdated just guarantees that the disk will be in a stable :> state after a crash, not that all data written before the crash will be :> available. :> : :Soft updates guarantees that when an fsync() is done, it

Re: 2xPIIIx450 results & NFS results (was More benchmarking stuff...)

At 1:02 PM -0700 1999/9/17, Matthew Dillon wrote: > Sendmail does not get into trouble with queue files it is able to retire > quickly. Where sendmail gets into trouble is with queue files it ISN'T > able to retire quickly. This is why you *see* 10,000+ files in mqueue > at time

Re: 2xPIIIx450 results & NFS results (was More benchmarking stuff...)

At 11:56 AM -0700 1999/9/17, Matthew Dillon wrote: > In real-life... for example, with a mail or web server, the namecache > tends to be somewhat more effective then 50%. The web servers at BEST > generally had a 95%+ name cache hit rate. The name cache misses are > what are cau

Re: 2xPIIIx450 results & NFS results (was More benchmarking stuff...)

At 11:17 AM -0700 1999/9/17, Matthew Dillon wrote: > What we really need is something that generates a performance > curve based on several variables, including block size, locality of > reference (seek randomosity), amount of parallelism, locality of > parallelism (i.e. operating

Re: More benchmarking stuff...

On Fri, 17 Sep 1999, Matthew Dillon wrote: > :According to kirk FSYNC() does the right thing and 'sync()' doesn't. > : > > Lets see... well, it will sync the file state, but it will not > necessarily sync the related directory entry (as far as I can tell). > > So if you take a cas

Re: More benchmarking stuff...

On Fri, 17 Sep 1999, Matthew Dillon wrote: > :> files sitting in unflushed disk caches and you reboot, those files are > :> lost. Softupdated just guarantees that the disk will be in a stable > :> state after a crash, not that all data written before the crash will be > :> available. > :> > :

Re: More benchmarking stuff...

At 10:46 AM -0500 1999/9/17, Dan Nelson wrote: > Hmm. But when you're running a mail spool, you _want_ your files to > get committed to disk, don't you? True enough. RFC 1123 requires that you *not* lost mail messages for stupid reasons like fileservers crashing, etc You do want

Re: More benchmarking stuff...

>Date: Fri, 17 Sep 1999 10:46:08 -0500 >From: Dan Nelson <[EMAIL PROTECTED]> >Don't NetApps do logging, so if the system crashes, the files are >recovered from the log? It's my (ca. 4-year-ancient) recollection that the write requests are written to a split NVRAM buffer; when one half hits the h

Re: More benchmarking stuff...

On Fri, 17 Sep 1999, Dan Nelson wrote: > In the last episode (Sep 17), Brad Knowles said: > > At 8:05 AM -0700 1999/9/17, Thomas Dean wrote: > > > Are the files deleted before they are actually written to disk? > > > > Good question. I don't know the answer. I know that the > > process i

Re: More benchmarking stuff...

In the last episode (Sep 17), Brad Knowles said: > At 8:05 AM -0700 1999/9/17, Thomas Dean wrote: > > Are the files deleted before they are actually written to disk? > > Good question. I don't know the answer. I know that the > process is to create all the files first, then operate on the

Re: More benchmarking stuff...

> My results running postmark on a PII-450 with 196MB RAM and an IBM Deskstar > DJNA 352030 running -current as of a few weeks ago are: > 1000/5UFS+softupdates MFS NFS > > tr/s 218 1562100 > read kb/s 699.05

Re: More benchmarking stuff...

At 8:05 AM -0700 1999/9/17, Thomas Dean wrote: > These tests with softupdates do not appear to be a test of the disk > i/o system, but, a test of memory. > > Are the files deleted before they are actually written to disk? Good question. I don't know the answer. I know that the process

Re: More benchmarking stuff...

At 4:35 PM +0200 1999/9/17, Brad Knowles wrote: > I'm running the second tests now. The second series of tests was *highly* educational. For the first time ever with postmark, I saw errors like this: Error: cannot open '34878' for writing Error: cannot open '34879' for writing .

Re: More benchmarking stuff...

At 3:33 PM +0200 1999/9/17, Brad Knowles wrote: > For the third and final stage (20,000 files and 100,000 > operations), I get the following results: > > Transactions per second:38 > KBytes Read per second: 102.84 > KBytes Written pe

Re: More benchmarking stuff...

On Sep 17, 2:03pm, Brad Knowles wrote: } Subject: Re: More benchmarking stuff... } } Sadly, when I go to the second set of tests (20,000 files and } 50,000 transactions), my performance goes into the crapper. I know } that softupdates trades memory for speed, and I guess this PPro 200

Re: More benchmarking stuff...

At 2:03 PM +0200 1999/9/17, Brad Knowles wrote: > For this stage, I now get: > > Transactions per second:33 > KBytes Read per second: 79.66 > KBytes Written per second: 144.31 For the third and final stage (20,000 files

Re: More benchmarking stuff...

On Fri, Sep 17, 1999 at 11:24:41AM +0200, Brad Knowles wrote: > > Their best results on an F630 with 1000 files and 50,000 > transactions were 253 transactions per second, 799.91 KBytes/sec > read, and 817.89 KBytes/sec written. > > I just ran this same test on an old PPro 200Mhz s

Re: More benchmarking stuff...

At 11:24 AM +0200 1999/9/17, Brad Knowles wrote: > I just ran this same test on an old PPro 200Mhz system > with 128MB of RAM and softupdates on a Western Digital > Enterprise 4.5GB hard drive. I got 282 transactions per > second, 869.09 KBytes read per second, and 888.63 KBytes > written

More benchmarking stuff...

Folks, In addition to the vinum vs. DPT SmartRAID IV benchmarking that I had done, I've also started doing filesystem/OS-level benchmarking with a program called "postmark" that Network Appliance wrote to show off the performance of their NetApp Filers. See