Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 24 Aug 2005 13:27:36 -0500
From:      Jonathan Noack <noackjr@alumni.rice.edu>
To:        JG <jarek@adeon.lublin.pl>
Cc:        freebsd-performance@freebsd.org
Subject:   Re: slow tar performance on fbsd5
Message-ID:  <430CBC18.6040902@alumni.rice.edu>
In-Reply-To: <1168719770.20050824183357@adeon.lublin.pl>
References:  <1168719770.20050824183357@adeon.lublin.pl>

next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigAAFC06154F4DB0DF41AB9E66
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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@alumni.rice.edu | OpenPGP: 0x991D8195

--------------enigAAFC06154F4DB0DF41AB9E66
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (FreeBSD)

iD8DBQFDDLwdUFz01pkdgZURAm35AJ9cLy4yFsZVOddNKWhx+P8xa+L35wCglRkt
VcQCEMX22H2TqJbzfm9oTBk=
=Zdqt
-----END PGP SIGNATURE-----

--------------enigAAFC06154F4DB0DF41AB9E66--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?430CBC18.6040902>