slow tar performance on fbsd5
Divacky Roman
xdivac02 at stud.fit.vutbr.cz
Thu Aug 25 09:30:03 GMT 2005
cannot this be related to low value of nswbufs (fixed in curennt and I think
releng_6)?
On Wed, Aug 24, 2005 at 06:33:57PM +0200, JG wrote:
> Hello,
>
> 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.
> 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)
> kern.maxfiles=65536
> kern.maxfilesperproc=65536
> vfs.read_max=16
>
> I've tried a few different kernels - I had results like 6-15 minutes
> of real time. 6 minutes was the best.
>
> I've also tried standard sysctls, and with/without make.conf cputype.
> I've tested bsdtar and gtar from ports (btw. gtar seems to be faster).
>
> I didn't noticed slowness of any other things on this server. I've quiet good DD results.
>
> Diskinfo shows:
> # diskinfo -tv /dev/da3s1d
> /dev/da3s1d
> 512 # sectorsize
> 73402366464 # mediasize in bytes (68G)
> 143363997 # mediasize in sectors
> 8923 # Cylinders according to firmware.
> 255 # Heads according to firmware.
> 63 # Sectors according to firmware.
>
> Seek times:
> Full stroke: 250 iter in 3.107691 sec = 12.431 msec
> Half stroke: 250 iter in 2.223141 sec = 8.893 msec
> Quarter stroke: 500 iter in 3.595413 sec = 7.191 msec
> Short forward: 400 iter in 1.832164 sec = 4.580 msec
> Short backward: 400 iter in 2.047162 sec = 5.118 msec
> Seq outer: 2048 iter in 0.315528 sec = 0.154 msec
> Seq inner: 2048 iter in 0.320899 sec = 0.157 msec
> Transfer rates:
> outside: 102400 kbytes in 1.341191 sec = 76350 kbytes/sec
> middle: 102400 kbytes in 1.536625 sec = 66640 kbytes/sec
> inside: 102400 kbytes in 2.731570 sec = 37488 kbytes/sec
>
>
> Soon I'll be able to post results from my other server powered by
> FreeBSD 4.11 with poor SCSI, maybe in the night.
>
> ----------------------------------------
> 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 one is noname server with Dual Xeon 2.8, 2GB ram. It has
> SATA Maxtor drive. Partition is ext3 -T news, -O dir_index, with
> atime! I've similar results with ReiserFS.
>
> ------------------------------------------
>
> Both systems was good optimized - as good as I can. All services (like
> mysql, apache) was terminated before my tests. Both FreeBSD's
> locate.updatedb and Gentoo's updatedb disabled.
>
>
> Thank you for any opinions or hints how to tune FreeBSD a bit.
>
> Best Regards,
> JG
>
> _______________________________________________
> freebsd-performance at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-performance
> To unsubscribe, send any mail to "freebsd-performance-unsubscribe at freebsd.org"
More information about the freebsd-performance
mailing list