Re: slow tar performance on fbsd5
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 > > real1m3.944s > user0m1.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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-performance > To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Samba Performance problem
On Mon, Oct 02, 2006 at 12:42:41PM -0400, Nick Evans wrote: > On Mon, 02 Oct 2006 10:30:23 -0400 > Mike Jakubik <[EMAIL PROTECTED]> wrote: > > > Nick Evans wrote: > > > Mike Jakubik <[EMAIL PROTECTED]> wrote: > > > > > >> Quite possibly, just as MySQL has been written with Linux primarily in > > >> mind. > > > > > > It should be possible to profile smbd and see where the bottleneck is, no? > > > Has anyone tried it? > > > > > > > > > It should be, but i don't believe anyone has tried yet. > > > > Does anyone know how to get gprof to set the gmon.out file with a pid number > in the filename? It's kind of hard to get output of the pid that controls a > file transfer without it. Everything I've found via Google is not working so > far. I'd start with plain ktrace and look in the trace to check for 'suspicious things'. It might be something trivial like calling gettimeofday() way too often as it was with mysql ___ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Help with improving mysql performance on 6.2PRE
On Wed, Oct 04, 2006 at 08:52:51PM -0400, Jerry Bell wrote: > I have a Dell PE2950 with 2 dual core 3.73Ghz processors and 4G of ram. > I've looked through some of the lists here and have seen super-smack > results in the 42k qps range on a 2 dual core opteron system. I'm able to > get up to about 34k with the wide at the back of my server whilest rubbing > the side of it. > > Here's what I've done: > built both mysql 5.0 and 5.1 from ports with build_static and > optimazations on. > changed the clock to TSC > > added the following to my /etc/libmap.conf file: > [mysqld] > libc_r.so.5 libthr.so.2 > libc_r.so.6 libthr.so.2 > libthr.so.2 libthr.so.2 > libpthread.so.1 libthr.so.2 > libpthread.so.2 libthr.so.2 > > And this is about the best result I get: > 2950# super-smack -d mysql select-key-mysql.smack 10 1 > Query Barrel Report for client smacker1 > connect: max=200ms min=0ms avg= 20ms from 10 clients > Query_type num_queries max_timemin_timeq_per_s > select_index20 0 0 34440.88 > > > Are there any other optimizations I need to do to mysql or freebsd? I'm > still not 100% convinced that I've done everything I need to use libthr > instead of libpthread. on UP people recomend to use TSC instead of acpi timer ___ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: DNS Performance Numbers
On Tue, Oct 24, 2006 at 09:59:57PM -0500, [EMAIL PROTECTED] wrote: > I am running some performance tests on named to see how it performs > with different configurations on FreeBSD and figured I would share the > first results. The first tests are for serving up static data. > > System: > Supermicro PDSMi Motherboard > 1G Memory > Intel Pentium D CPU 3.40GHz > Intel Gigibit NIC > Bind 9.2.3 > > OS UP UP+PMP MP+PMP+TP MP+TT MP+TP+P > MP+TT+P > --- > FreeBSD 4.1128455 28370 28976 X X X X X > FreeBSD 6.1 29074 34260 34635 35730 17846 38780 19776 > 44188 > FreeBSD Stable 30190 34707 33294 36651 18893 39374 19449 > 44169 > FreeBSD Current 30707 34029 32300 33689 15535 40554 13886 > 42071 > Ubuntu 6.06 X X X X X 37294 X X I see regression between -current and -stable. are you sure you tested without any debuging stuff? some performance speedups went in in 7-current also - do you use the same config everywhere? -current GENERIC doesnt have COMPAT_43 for example which miht affect performance (additional locking) etc. roman ___ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: em forwarding performance (was Proposed 6.2 em RELEASE patch
On Fri, Nov 24, 2006 at 03:27:40PM -0500, Mike Tancsa wrote: > At 03:28 AM 11/24/2006, Massimo Lusetti wrote: > >On Thu, 2006-11-23 at 11:52 -0500, Mike Tancsa wrote: > > > >> I might give OpenBSD a quick try as a reference. > > > >That would be very interesting. > > OpenBSD 4.0 i386 panics on boot. > > I also posted some results with PMC compiled into the kernel > > ipfw compiled into the kernel, with 1 rule > > http://www.tancsa.com/pmc/ I see generic_bzero/bcopy used quite often. why dont you define cpu I586_CPU in your kernel config? also... bde@ just commited some bzero-related optimizations to routing code.. might be work trying.. just an idea roman ___ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: em forwarding performance (was Proposed 6.2 em RELEASE patch
On Fri, Nov 24, 2006 at 04:18:03PM -0500, Mike Tancsa wrote: > At 04:03 PM 11/24/2006, Divacky Roman wrote: > >On Fri, Nov 24, 2006 at 03:27:40PM -0500, Mike Tancsa wrote: > >> At 03:28 AM 11/24/2006, Massimo Lusetti wrote: > >> >On Thu, 2006-11-23 at 11:52 -0500, Mike Tancsa wrote: > >> > > >> >> I might give OpenBSD a quick try as a reference. > >> > > >> >That would be very interesting. > >> > >> OpenBSD 4.0 i386 panics on boot. > >> > >> I also posted some results with PMC compiled into the kernel > >> > >> ipfw compiled into the kernel, with 1 rule > >> > >> http://www.tancsa.com/pmc/ > > > >I see generic_bzero/bcopy used quite often. why dont you define > >cpu I586_CPU > >in your kernel config? > > Hi, > > I had > > cpu I486_CPU > cpu I586_CPU > cpu I686_CPU hm.. now I am confused. the rule is that having I586_CPU improves performance because optimized bzero/bcopy is included (its not included if you only have I686_CPU). I dont understand why the generic version is used. ___ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: em forwarding performance (was Proposed 6.2 em RELEASE patch
On Sat, Nov 25, 2006 at 05:22:16AM -0600, Matthew D. Fuller wrote: > On Sat, Nov 25, 2006 at 09:36:05AM +0100 I heard the voice of > Divacky Roman, and lo! it spake thus: > > > > hm.. now I am confused. the rule is that having I586_CPU improves > > performance because optimized bzero/bcopy is included (its not > > included if you only have I686_CPU). > > Haven't we been by this before? It's not included even if you have > I586_CPU either. > > See src/sys/i386/isa/npx.c, line 432: > > #ifdef I586_CPU_XXX < > ^^^ > > This has been disabled since r1.95, in 2001 (in 5-CURRENT days). > There may be SOMETHING about including I586_CPU that speeds things up, > but it ain't that. the log says: People are still having problems with i586_* on UP machines and SMP machines, so just hack it to disable them for now until it can be fixed. noone has been able to step up and fix that? for more then 5 years? huh.. I guess thats quite low hanging fruit worth shoting down.. ___ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: (S)ATA performance in FBSD 6.2/7.0
On Fri, Mar 02, 2007 at 10:43:34AM +0100, Wojciech Puchar wrote: > >another while the box didn't do anything else than copying. I watched the > >copy process via 'systat -vmstat 1' and realized, that the value of 'KB/t' > >never go byond 128 (128kb buffer limit?). But more frustrating, I never got > > what's wrong? FreeBSD uses 128k limit by default. > > edit /usr/src/sys/sys/param.h > > and change > > #define MAXPHYS (128 * 1024) /* max raw I/O transfer size */ > > > to say > > #define MAXPHYS (1024 * 1024) /* max raw I/O transfer size */ did anyone measure impact on various benchmark of this change? is 128k the optimal size for "nowadays computers" ? if we can squeeze more performance out of a typical box by just raising one define it would be great... roman ___ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "[EMAIL PROTECTED]"
