slow tar performance on fbsd5

[Jonathan Noack]

On 08/24/05 11:33, JG wrote:
> I had to unpack a lot of tar archives and I occasional noticed terrible
> bad performance on freebsd5.
> 
> This is my test file:
> 
> 854251520 24 Sie 12:13 mysql-m.tgz
> 
> There are some real MySQL tables in it, it has been done with tar
> -cvf. This archive contains about 146.000 small files. 
> 
> ---------------------------------------
> Unpacking it on FreeBSD5 gives me such results:
> 
> # time tar -xf mysql-m.tgz
> 2.130u 20.187s 7:02.69 5.2%     41+382k 13097+8205io 0pf+0w
> ...so 7 minutes of real time.
> 
> This is today's FreeBSD 5.4-STABLE but I also tried 5.4-release.
> 
> That server is brand new Dell PE2850 with Seagate ST373207L SCSI
> drive, no raid. Parition is default UFS2 mounted with noatime, softupdates on.

Will noatime make a difference when unpacking a tar archive (assuming an 
otherwise idle system, at least)?  My understanding of atime is that it 
might slow down the disk for later accesses due to atime writes, but 
when creating files it shouldn't have any effect.  Is that not correct?

> This is Dual Xeon 2.8, 2GB ram.
> 
> My sysctls:
> vfs.ufs.dirhash_maxmem=16777216 (much better than default 2MB)
> machdep.hyperthreading_allowed=1 (better dd results)

Your other settings appear ok, but I'd turn off hyperthreading.  Almost 
every FreeBSD/HT test has shown that it reduces performance because the 
scheduler is not HT-aware.  When the system is relatively idle (single 
dd running, for example), it might not pessimize things, but it will 
most likely slow you down under load.

> kern.maxfiles=65536
> kern.maxfilesperproc=65536
> vfs.read_max=16
> 
> <snip>
> 
> ----------------------------------------
> This is result from Gentoo Linux on 2.6.x hardened kernel:
> # time tar -xf mysql-m.tgz
> 
> real    1m3.944s
> user    0m1.702s
> sys     0m15.794s
> 
> Only ~one minute! Six times faster than on a FreeBSD. I'm not a linux
> fan, and I don't want to tell you how good linux is, but I would to
> find out what causes such bad results on my favourite FreeBSD...

This sounds like you're running into the old "lemming syncer" problem. 
There is currently some work on disk schedulers (even a Summer of Code 
project), but it will most likely not make it into 5.x.

-- 
Jonathan Noack | noackjr at alumni.rice.edu | OpenPGP: 0x991D8195
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-performance/attachments/20050824/cef782ac/signature.bin