From grarpamp at gmail.com Wed Sep 2 07:24:35 2009 From: grarpamp at gmail.com (grarpamp) Date: Wed Sep 2 11:12:16 2009 Subject: RELENG_7 heavy disk = system crawls [solved] Message-ID: I didn't actually solve it or do anything. I just upgraded to RELENG_8. Now it's behaving more like FreeBSD should. I can do sequential reads/writes and still use kbd/mouse/X11/buildworld and so on. Yes, the cpu is still completely underwater, and allowing for that, it seems interactivity is nearly back to normal. ZFS is taking up a power of 10 less cpu than before. Geli is at it's rightful place on top of the cpu/time list. And where copying GiB sized files would sink the system requiring the reset button, it just keeps on copying. If anyone's having issues with similar setup/loads, all I can say is upgrade asap. [OT] If you do installkernel installworld mergemaster reboot all in one uptime session, 'ln' will core in some places. Just replace it in the makefiles with cp -p and rerun whatever stage cored. once you reboot into 8, all is well. From tlott at gamesnet.de Wed Sep 9 08:58:02 2009 From: tlott at gamesnet.de (Tobias Lott) Date: Wed Sep 9 08:58:15 2009 Subject: System crawls after Upgrade 7.0->7.2 In-Reply-To: <20090908121945.43ba3976@sub.han.vpn.gamesnet.de> References: <20090908121945.43ba3976@sub.han.vpn.gamesnet.de> Message-ID: <20090909104807.633418ea@sub.han.vpn.gamesnet.de> On Tue, 8 Sep 2009 12:19:45 +0200 Tobias Lott wrote: > Hey Everyone, > > I upgraded a Dual Core Machine to 7.2-Stable (2 Days ago), all OS > related Stuff is located on an UFS Slice, Application is on a ZFS > Volume. > > After the Upgrade everything seemed fine, but a User noticed one PHP > Script which is basically loading a plain Textfile into Mysql times > out. PHP Timeout was set to 60 secs, that was more then enough just > one day before the upgrade. > > System-wise its like Mysql can't get get the data fast enough, process > is max at 10% cpu usage most of the time in sbwait state. > > Haven't changed any sysctl (kern.maxvnodes="200000", > vm.kmem_size="512M" vm.kmem_size_max="512M" vfs.zfs.arc_max="100M" > but had those before already) or kernel parameter at that time. But > according to the Wiki's ZFS Tuning Guide those aren't needed anymore > so I tried without but no change there either. > > I checked the following (and the current used values each): > maxproc > maxfiles > kern.ipc.somaxconn > kern.ipc.nmbclusters > > Getting no error messages dmesg, syslog wise. > > Tried moving Mysql to the UFS Slice but same thing happens happens > there. > > Some very basic testing like dd-ing: > # dd if=/dev/da0 of=/dev/null bs=1024 count=1048576 > 1048576+0 records in > 1048576+0 records out > 1073741824 bytes transferred in 157.698602 secs (6808823 bytes/sec) > > FreeBSD hostname 7.2-STABLE FreeBSD 7.2-STABLE #3 r196954: > Tue Sep 8 02:10:22 CEST 2009 > root@hostname:/usr/obj/usr/src/sys/SPIRIT amd64 > > Since I upgraded the Machines zpool to version 13 already I don't > really wanna go back to 7.0, but it seems the only way out atm. > > Hopefully someone can give me a Hint where maybe I forgot to check. > > > Somehow it feels like the last Versions, I'd say starting with 7.x > doesn't really feel that Rock-Stable as Versions Prior used to > be. Prolly cause I'm using an Experimental Feature like ZFS, so no > Offense nor Blame and this is not intended as a Flame or whatsoever! > So don't get me wrong, I always liked, used, recommended FreeBSD since > 4.0 and will continue to do so! > > Best Regards > I've tested some more it seems the Bottleneck is the HD, Raid Array is Optimal checked it. Running bonnie++ takes like forever, couldn't finish it since its a Productive Machine, cause it renders the Server useless, every try to access the server while bonnie is running times out. Weird thing is bonnie++ is using max 1-3% CPU. But according to gstat its only ~3mb/s (displayed as 100% busy) during first 3 Tests that is. savecore: reboot after panic: page fault But had no luck with the coredumb # kgdb kernel.debug /var/crash/vmcore.12 Cannot access memory at address 0x0 Or is there any other method I could try? Cause this is getting nasty unstable -- Tobias Lott From cliftonr at lava.net Wed Sep 9 17:02:15 2009 From: cliftonr at lava.net (Clifton Royston) Date: Wed Sep 9 17:38:29 2009 Subject: System crawls after Upgrade 7.0->7.2 In-Reply-To: <20090909104807.633418ea@sub.han.vpn.gamesnet.de> References: <20090908121945.43ba3976@sub.han.vpn.gamesnet.de> <20090909104807.633418ea@sub.han.vpn.gamesnet.de> Message-ID: <20090909170213.GA7925@lava.net> On Wed, Sep 09, 2009 at 10:48:07AM +0200, Tobias Lott wrote: > On Tue, 8 Sep 2009 12:19:45 +0200 > Tobias Lott wrote: > > Hey Everyone, > > > > I upgraded a Dual Core Machine to 7.2-Stable (2 Days ago), all OS > > related Stuff is located on an UFS Slice, Application is on a ZFS > > Volume. > > > > After the Upgrade everything seemed fine, but a User noticed one PHP > > Script which is basically loading a plain Textfile into Mysql times > > out. PHP Timeout was set to 60 secs, that was more then enough just > > one day before the upgrade. ... > > Since I upgraded the Machines zpool to version 13 already I don't > > really wanna go back to 7.0, but it seems the only way out atm. > > > > Hopefully someone can give me a Hint where maybe I forgot to check. > > > > Somehow it feels like the last Versions, I'd say starting with 7.x > > doesn't really feel that Rock-Stable as Versions Prior used to > > be. Prolly cause I'm using an Experimental Feature like ZFS, so no > > Offense nor Blame and this is not intended as a Flame or whatsoever! > > So don't get me wrong, I always liked, used, recommended FreeBSD since > > 4.0 and will continue to do so! > > > > Best Regards > > > > I've tested some more it seems the Bottleneck is the HD, Raid Array is > Optimal checked it. Probably you already checked this, but did you go through the dmesg output relating to ata and drive detection closely? In the past from time to time I've had machines suddenly start crawling after an upgrade, and it turned out it was because some change in the driver detection caused the ata to fall back to pio mode. The symptoms are pretty much like you describe - all HD IO takes forever. -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From tlott at gamesnet.de Wed Sep 9 20:00:11 2009 From: tlott at gamesnet.de (Tobias Lott) Date: Wed Sep 9 20:00:51 2009 Subject: System crawls after Upgrade 7.0->7.2 In-Reply-To: <20090909213022.34d64e47@sub.han.vpn.gamesnet.de> References: <20090908121945.43ba3976@sub.han.vpn.gamesnet.de> <20090909104807.633418ea@sub.han.vpn.gamesnet.de> <20090909170213.GA7925@lava.net> <20090909213022.34d64e47@sub.han.vpn.gamesnet.de> Message-ID: <20090909215959.6b5152f2@sub.han.vpn.gamesnet.de> On Wed, 9 Sep 2009 21:30:22 +0200 Tobias Lott wrote: > > > On Wed, 9 Sep 2009 07:02:13 -1000 > Clifton Royston wrote: > > > On Wed, Sep 09, 2009 at 10:48:07AM +0200, Tobias Lott wrote: > > > On Tue, 8 Sep 2009 12:19:45 +0200 > > > Tobias Lott wrote: > > > > Hey Everyone, > > > > > > > > I upgraded a Dual Core Machine to 7.2-Stable (2 Days ago), all > > > > OS related Stuff is located on an UFS Slice, Application is on > > > > a ZFS Volume. > > > > > > > > After the Upgrade everything seemed fine, but a User noticed one > > > > PHP Script which is basically loading a plain Textfile into > > > > Mysql times out. PHP Timeout was set to 60 secs, that was more > > > > then enough just one day before the upgrade. > > ... > > > > Since I upgraded the Machines zpool to version 13 already I > > > > don't really wanna go back to 7.0, but it seems the only way > > > > out atm. > > > > > > > > Hopefully someone can give me a Hint where maybe I forgot to > > > > check. > > > > > > > > Somehow it feels like the last Versions, I'd say starting with > > > > 7.x doesn't really feel that Rock-Stable as Versions Prior used > > > > to be. Prolly cause I'm using an Experimental Feature like ZFS, > > > > so no Offense nor Blame and this is not intended as a Flame or > > > > whatsoever! So don't get me wrong, I always liked, used, > > > > recommended FreeBSD since 4.0 and will continue to do so! > > > > > > > > Best Regards > > > > > > > > > > I've tested some more it seems the Bottleneck is the HD, Raid > > > Array is Optimal checked it. > > > > Probably you already checked this, but did you go through the > > dmesg output relating to ata and drive detection closely? > > > > In the past from time to time I've had machines suddenly start > > crawling after an upgrade, and it turned out it was because some > > change in the driver detection caused the ata to fall back to pio > > mode. The symptoms are pretty much like you describe - all HD IO > > takes forever. > > > > -- Clifton > > > > Thanks for that Hint, checked again to be sure, but thats not the > Case. > > mpt0:vol0(mpt0:0:0): Settings ( Hot-Plug-Spares High-Priority-ReSync ) > mpt0:vol0(mpt0:0:0): Using Spare Pool: 0 > mpt0:vol0(mpt0:0:0): 2 Members: > (mpt0:1:32:0): Primary Online > (mpt0:1:1:0): Secondary Online > mpt0:vol0(mpt0:0:0): RAID-1 - Optimal > mpt0:vol0(mpt0:0:0): Status ( Enabled ) > (mpt0:vol0:1): Physical (mpt0:0:1:0), Pass-thru (mpt0:1:0:0) > (mpt0:vol0:1): Online > (mpt0:vol0:0): Physical (mpt0:0:32:0), Pass-thru (mpt0:1:1:0) > (mpt0:vol0:0): Online > acd0: CDROM at ata0-master UDMA33 > acd1: CDROM at ata2-slave PIO3 > da0 at mpt0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-5 device > da0: 300.000MB/s transfers > da0: Command Queueing Enabled > SdMaP0:: A1P5 1C6P3U4 M#B1 (L3a1u0n5c4h6e4d3!2 > 512 byte sectors: 255H 63S/T 19330C) > > Oh well just did some more research and found: http://www.mail-archive.com/freebsd-performance@freebsd.org/msg02461.html Gonna try it out later and gonna give a Report. -- Tobias Lott From stefan.lambrev at moneybookers.com Fri Sep 11 21:21:39 2009 From: stefan.lambrev at moneybookers.com (Stefan Lambrev) Date: Fri Sep 11 21:21:45 2009 Subject: System crawls after Upgrade 7.0->7.2 In-Reply-To: <20090909215959.6b5152f2@sub.han.vpn.gamesnet.de> References: <20090908121945.43ba3976@sub.han.vpn.gamesnet.de> <20090909104807.633418ea@sub.han.vpn.gamesnet.de> <20090909170213.GA7925@lava.net> <20090909213022.34d64e47@sub.han.vpn.gamesnet.de> <20090909215959.6b5152f2@sub.han.vpn.gamesnet.de> Message-ID: Hi Tobias, This is the "pseudo" RAID controller that comes by default with most Dell, low cost HP servers and probably others? If you depend on I/O I would recommend you to change this raid with PERC6/i (looks like this is Dell server) which is little more expensive, but comes with 256MB battery backed cache. In my experience mpt devices are crap, and their performance is worse then software mirror. PERC6/i is something totally different :) It's again LSI product branded from Dell and it works with mfi driver. The only problem in the past with them was the management utility which was linux binary, but today there is official native tool in ports, and in 8.0 in base install there will be a tool to manage your controller. Well this wasn't that big problem compared to mpt which cannot be managed under FreeBSD at all? On Sep 9, 2009, at 10:59 PM, Tobias Lott wrote: > > > On Wed, 9 Sep 2009 21:30:22 +0200 > Tobias Lott wrote: > >> >> >> On Wed, 9 Sep 2009 07:02:13 -1000 >> Clifton Royston wrote: >> >>> On Wed, Sep 09, 2009 at 10:48:07AM +0200, Tobias Lott wrote: >>>> On Tue, 8 Sep 2009 12:19:45 +0200 >>>> Tobias Lott wrote: >>>>> Hey Everyone, >>>>> >>>>> I upgraded a Dual Core Machine to 7.2-Stable (2 Days ago), all >>>>> OS related Stuff is located on an UFS Slice, Application is on >>>>> a ZFS Volume. >>>>> >>>>> After the Upgrade everything seemed fine, but a User noticed one >>>>> PHP Script which is basically loading a plain Textfile into >>>>> Mysql times out. PHP Timeout was set to 60 secs, that was more >>>>> then enough just one day before the upgrade. >>> ... >>>>> Since I upgraded the Machines zpool to version 13 already I >>>>> don't really wanna go back to 7.0, but it seems the only way >>>>> out atm. >>>>> >>>>> Hopefully someone can give me a Hint where maybe I forgot to >>>>> check. >>>>> >>>>> Somehow it feels like the last Versions, I'd say starting with >>>>> 7.x doesn't really feel that Rock-Stable as Versions Prior used >>>>> to be. Prolly cause I'm using an Experimental Feature like ZFS, >>>>> so no Offense nor Blame and this is not intended as a Flame or >>>>> whatsoever! So don't get me wrong, I always liked, used, >>>>> recommended FreeBSD since 4.0 and will continue to do so! >>>>> >>>>> Best Regards >>>>> >>>> >>>> I've tested some more it seems the Bottleneck is the HD, Raid >>>> Array is Optimal checked it. >>> >>> Probably you already checked this, but did you go through the >>> dmesg output relating to ata and drive detection closely? >>> >>> In the past from time to time I've had machines suddenly start >>> crawling after an upgrade, and it turned out it was because some >>> change in the driver detection caused the ata to fall back to pio >>> mode. The symptoms are pretty much like you describe - all HD IO >>> takes forever. >>> >>> -- Clifton >>> >> >> Thanks for that Hint, checked again to be sure, but thats not the >> Case. >> >> mpt0:vol0(mpt0:0:0): Settings ( Hot-Plug-Spares High-Priority- >> ReSync ) >> mpt0:vol0(mpt0:0:0): Using Spare Pool: 0 >> mpt0:vol0(mpt0:0:0): 2 Members: >> (mpt0:1:32:0): Primary Online >> (mpt0:1:1:0): Secondary Online >> mpt0:vol0(mpt0:0:0): RAID-1 - Optimal >> mpt0:vol0(mpt0:0:0): Status ( Enabled ) >> (mpt0:vol0:1): Physical (mpt0:0:1:0), Pass-thru (mpt0:1:0:0) >> (mpt0:vol0:1): Online >> (mpt0:vol0:0): Physical (mpt0:0:32:0), Pass-thru (mpt0:1:1:0) >> (mpt0:vol0:0): Online >> acd0: CDROM at ata0-master UDMA33 >> acd1: CDROM at ata2-slave PIO3 >> da0 at mpt0 bus 0 target 0 lun 0 >> da0: Fixed Direct Access SCSI-5 device >> da0: 300.000MB/s transfers >> da0: Command Queueing Enabled >> SdMaP0:: A1P5 1C6P3U4 M#B1 (L3a1u0n5c4h6e4d3!2 >> 512 byte sectors: 255H 63S/T 19330C) >> >> > > Oh well just did some more research and found: > http://www.mail-archive.com/freebsd-performance@freebsd.org/msg02461.html > > Gonna try it out later and gonna give a Report. > > -- > Tobias Lott > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org > " -- Best Wishes, Stefan Lambrev ICQ# 24134177 From oliver at FreeBSD.org Wed Sep 23 16:30:30 2009 From: oliver at FreeBSD.org (Oliver Lehmann) Date: Wed Sep 23 16:30:36 2009 Subject: gjournal, hardware raid, software raid Message-ID: <20090923180347.ee0ae193.oliver@FreeBSD.org> Hi, I'll have soon the following System configuration: two 250GB harddisks (WD2500KS) - configured as RAID1 using gmirror - disks are attached to a Promise SATA300 TX2plus - are supposed to hold the whole base system+swap four 1TB harddisks (WD10EADS) - configured as RAID5 using a 3ware 3500-4LP with a battery backup unit having write cache enabled. - will hold one big (around 3TB) partition using GPT The system itself has 2GB of RAM and is an old dual PIII 850 running on an intel L440GX+ I now plan to setup gjournal for the 3TB partition to slow down the fsck run times. The system crashes from time to time so this is vital for me ;) I thought about what would be the best configuration here and I saw 3 solutions: 1) have one partition on the 3TB RAID sharing data and journal 2) have two partitions, one holding the journal, one holding the data. Both on the 3TB RAID. Preferable the journal at the "beginning" of the disks. 3) same partitions like above but the journal partition will be on the gmirror RAID1 holding the base system. I like the 3rd option because on a heavy I/O load on the RAID5 the 3ware must not switch between data and journal and can stick to handling the data only. The Promise controller will then stick to handle the data. Looks like some I/O balancing for me... I maybe want gjournal for the /usr partition of the RAID1 as well. So I would then have two 6GB (2GB*3) journaling partitions on the RAID1 if I go for option 3. What do you guys think. Please keep me CCed - I'm not subscribed. -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From fjwcash at gmail.com Wed Sep 23 17:34:32 2009 From: fjwcash at gmail.com (Freddie Cash) Date: Wed Sep 23 17:34:39 2009 Subject: gjournal, hardware raid, software raid In-Reply-To: <20090923180347.ee0ae193.oliver@FreeBSD.org> References: <20090923180347.ee0ae193.oliver@FreeBSD.org> Message-ID: On Wed, Sep 23, 2009 at 9:03 AM, Oliver Lehmann wrote: > I'll have soon the following System configuration: > > two 250GB harddisks (WD2500KS) > - configured as RAID1 using gmirror > - disks are attached to a Promise SATA300 TX2plus > - are supposed to hold the whole base system+swap > > four 1TB harddisks (WD10EADS) > - configured as RAID5 using a 3ware 3500-4LP with a > battery backup unit having write cache enabled. > - will hold one big (around 3TB) partition using GPT > > The system itself has 2GB of RAM and is an old dual PIII 850 running on > an intel L440GX+ > > I now plan to setup gjournal for the 3TB partition to slow down the fsck > run times. The system crashes from time to time so this is vital for me ;) > > I thought about what would be the best configuration here and I saw 3 > solutions: > > 1) have one partition on the 3TB RAID sharing data and journal > 2) have two partitions, one holding the journal, one holding the data. > Both on the 3TB RAID. Preferable the journal at the "beginning" of the > disks. > 3) same partitions like above but the journal partition will be on the > gmirror RAID1 holding the base system. > > I like the 3rd option because on a heavy I/O load on the RAID5 the 3ware > must not switch between data and journal and can stick to handling the > data only. The Promise controller will then stick to handle the data. > Looks like some I/O balancing for me... > > I maybe want gjournal for the /usr partition of the RAID1 as well. So I > would then have two 6GB (2GB*3) journaling partitions on the RAID1 if I > go for option 3. > > I've never done anything with gjournal, so can't really comment on what would be the better setup for it. However, I would like to point out that there's a fourth option: - configure the RAID controller to use 4 Single Disk arrays (or JBOD, not sure when 3Ware added Single Disk support) - use ZFS to create a raidz dataset using the 4 drives You now have a 3 TB pool of storage, without having to fight with GPT, without worrying about the "raid5 write hole", without worrying about fsck at boot, and without trying to figure out how to do journalling. You'll still get the benefits of the cache and BBU on the RAID controller, along with all the alerts from 3dm2, but it will be (in essence) acting as an IDE controller instead of a RAID controller. ZFS will handle the RAID, along with a lot of other niceties that come along with it (journalling/copy-on-write, snapshots, compression, end-to-end data integrity, etc). Of course, since this is a 32-bit system with only 2 GB of RAM, you'd need to do some tuning (via /boot/loader.conf) to make it work well. But it's a viable option, IMO/IME (I do something similar using a P4 system with 2 GB of RAM, at home). -- Freddie Cash fjwcash@gmail.com From oliver at FreeBSD.org Wed Sep 23 17:45:28 2009 From: oliver at FreeBSD.org (Oliver Lehmann) Date: Wed Sep 23 17:45:35 2009 Subject: gjournal, hardware raid, software raid In-Reply-To: References: <20090923180347.ee0ae193.oliver@FreeBSD.org> Message-ID: <20090923194527.0b3cfbb2.oliver@FreeBSD.org> Freddie Cash wrote: > I've never done anything with gjournal, so can't really comment on what > would be the better setup for it. However, I would like to point out that > there's a fourth option: > - configure the RAID controller to use 4 Single Disk arrays (or JBOD, not > sure when 3Ware added Single Disk support) > - use ZFS to create a raidz dataset using the 4 drives Uh... Ok, this might be an option generally but honestly not for me ;) Considering the money I've spent 3 years ago for buying the RAID controller and considering the load it takes from the system handling the RAID I think it is in the best interest for the system to keep the RAID-5 3ware internally. As you might have seen the system is not the fastest one with not that much of memory - so whatever load I can delegate I'm try to delegate off the CPUs. Today I would probably not spend the money buying a RAID controller again but use indeed ZFS instead. But back the time there was only (g)vinum - and I never liked it. -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From killing at multiplay.co.uk Mon Sep 28 22:50:31 2009 From: killing at multiplay.co.uk (Steven Hartland) Date: Mon Sep 28 22:50:37 2009 Subject: FreeBSD vs Ubuntu - Discuss... Message-ID: Just noticed the following posted on phoronix: http://www.phoronix.com/scan.php?page=article&item=freebsd8_ubuntu910&num=1 Comments? Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From francisco.cabrita at gmail.com Mon Sep 28 23:16:01 2009 From: francisco.cabrita at gmail.com (Francisco Cabrita) Date: Mon Sep 28 23:16:08 2009 Subject: FreeBSD vs Ubuntu - Discuss... In-Reply-To: References: Message-ID: On Mon, Sep 28, 2009 at 11:39 PM, Steven Hartland wrote: > Just noticed the following posted on phoronix: > http://www.phoronix.com/scan.php?page=article&item=freebsd8_ubuntu910&num=1 > > Comments? > > I didn't saw anything related to turning off witness and invariants... so... Regards, Francisco > Regards > Steve > > > ================================================ > This e.mail is private and confidential between Multiplay (UK) Ltd. and the > person or entity to whom it is addressed. In the event of misdirection, the > recipient is prohibited from using, copying, printing or otherwise > disseminating it or any information contained in it. > In the event of misdirection, illegible or incomplete transmission please > telephone +44 845 868 1337 > or return the E.mail to postmaster@multiplay.co.uk. > > _______________________________________________ > freebsd-performance@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-performance > To unsubscribe, send any mail to " > freebsd-performance-unsubscribe@freebsd.org" > -- blog: http://sufixo.com/raw http://www.linkedin.com/in/franciscocabrita From lists at stringsutils.com Tue Sep 29 00:04:07 2009 From: lists at stringsutils.com (Francisco Reyes) Date: Tue Sep 29 00:04:14 2009 Subject: FreeBSD vs Ubuntu - Discuss... References: Message-ID: Steven Hartland writes: > Just noticed the following posted on phoronix: > http://www.phoronix.com/scan.php?page=article&item=freebsd8_ubuntu910&num=1 > Comments? This was discussed in detail in slashdot.. starting with the fact that most likely debug switches were not turned off for FreeBSD. From leccine at gmail.com Tue Sep 29 00:29:34 2009 From: leccine at gmail.com (=?ISO-8859-1?B?SXN0duFu?=) Date: Tue Sep 29 00:29:40 2009 Subject: FreeBSD vs Ubuntu - Discuss... In-Reply-To: References: Message-ID: http://marc.info/?l=freebsd-current&m=125413848303229&w=2 On Tue, Sep 29, 2009 at 12:46 AM, Francisco Reyes wrote: > Steven Hartland writes: > > Just noticed the following posted on phoronix: >> >> http://www.phoronix.com/scan.php?page=article&item=freebsd8_ubuntu910&num=1 >> Comments? >> > > This was discussed in detail in slashdot.. starting with the fact that most > likely debug switches were not turned off for FreeBSD. > _______________________________________________ > freebsd-performance@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-performance > To unsubscribe, send any mail to " > freebsd-performance-unsubscribe@freebsd.org" > -- the sun shines for all From freebsd at sopwith.solgatos.com Tue Sep 29 04:07:50 2009 From: freebsd at sopwith.solgatos.com (Dieter) Date: Tue Sep 29 04:07:57 2009 Subject: FreeBSD vs Ubuntu - Discuss... In-Reply-To: Your message of "Mon, 28 Sep 2009 19:46:53 EDT." Message-ID: <200909290226.CAA28246@sopwith.solgatos.com> In message , Francisco Reyes writes: > Steven Hartland writes: > > > Just noticed the following posted on phoronix: > > http://www.phoronix.com/scan.php?page=article&item=freebsd8_ubuntu910&num=1 > > Comments? > > This was discussed in detail in slashdot.. starting with the fact that most > likely debug switches were not turned off for FreeBSD. "All of the FreeBSD and Ubuntu options were left at their defaults." My question is why is FreeBSD's disk i/o performance so bad? Not just in the benchmarks with debugging on, but in real world usage where it actually matters. From francisco.cabrita at gmail.com Tue Sep 29 08:51:42 2009 From: francisco.cabrita at gmail.com (Francisco Cabrita) Date: Tue Sep 29 08:51:49 2009 Subject: FreeBSD vs Ubuntu - Discuss... In-Reply-To: References: Message-ID: On Tue, Sep 29, 2009 at 1:29 AM, Istv?n wrote: > http://marc.info/?l=freebsd-current&m=125413848303229&w=2 > > well I didn't knew that fresh one. Nice to know. Gona test for RC too. > On Tue, Sep 29, 2009 at 12:46 AM, Francisco Reyes >wrote: > > > Steven Hartland writes: > > > > Just noticed the following posted on phoronix: > >> > >> > http://www.phoronix.com/scan.php?page=article&item=freebsd8_ubuntu910&num=1 > >> Comments? > >> > > > > This was discussed in detail in slashdot.. starting with the fact that > most > > likely debug switches were not turned off for FreeBSD. > > _______________________________________________ > > freebsd-performance@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-performance > > To unsubscribe, send any mail to " > > freebsd-performance-unsubscribe@freebsd.org" > > > > > > -- > the sun shines for all > _______________________________________________ > freebsd-performance@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-performance > To unsubscribe, send any mail to " > freebsd-performance-unsubscribe@freebsd.org" > -- blog: http://sufixo.com/raw http://www.linkedin.com/in/franciscocabrita From vilmos.gyorgy at gmail.com Tue Sep 29 08:07:00 2009 From: vilmos.gyorgy at gmail.com (=?ISO-8859-1?Q?Gy=F6rgy_Vilmos?=) Date: Tue Sep 29 11:24:57 2009 Subject: Performance evaluation of PostgreSQL's historic releases Message-ID: Hi, I've done a benchmark of recent versions of PostgreSQL's last five major releases to see how performance has changed during the past years from version to version. You can find the article here: http://suckit.blog.hu/2009/09/26/postgresql_history The tests were conducted on FreeBSD 8/amd64 on a midrange x86 server (4 CPUs, 24 cores, 128GiB RAM). -- http://suckit.blog.hu/ From attilio at freebsd.org Tue Sep 29 15:38:02 2009 From: attilio at freebsd.org (Attilio Rao) Date: Tue Sep 29 15:38:08 2009 Subject: Performance evaluation of PostgreSQL's historic releases In-Reply-To: References: Message-ID: <3bbf2fe10909290811p6ac49f7fxaf7e7d4bf631da4c@mail.gmail.com> 2009/9/29 Gy?rgy Vilmos : > Hi, > > I've done a benchmark of recent versions of PostgreSQL's last five major > releases to see how performance has changed during the past years from > version to version. > You can find the article here: > http://suckit.blog.hu/2009/09/26/postgresql_history > > The tests were conducted on FreeBSD 8/amd64 on a midrange x86 server (4 > CPUs, 24 cores, 128GiB RAM). Do you have informations about the systime when doing such tests? Attilio -- Peace can only be achieved by understanding - A. Einstein From lists at stringsutils.com Tue Sep 29 16:50:36 2009 From: lists at stringsutils.com (Francisco Reyes) Date: Tue Sep 29 16:50:48 2009 Subject: Performance evaluation of PostgreSQL's historic releases References: Message-ID: Gy?rgy Vilmos writes: > I've done a benchmark of recent versions of PostgreSQL's last five major > releases to see how performance has changed during the past years from > version to version. Thanks! Very interesting. Did you share it with the Postgresql list yet? I think they would find it very interesting. Any plans on doing simmilar tests with data that does not fit in memory? Also could you share what settings were used for postgres? Where any defaults changed? Effective memory, shared_buffers, etc... any of them adjusted for the machine's memory? From a.kuriger at liquidphlux.com Tue Sep 29 18:20:51 2009 From: a.kuriger at liquidphlux.com (Andrew Kuriger) Date: Tue Sep 29 18:21:24 2009 Subject: FreeBSD vs Ubuntu - Discuss... In-Reply-To: <200909290226.CAA28246@sopwith.solgatos.com> References: <200909290226.CAA28246@sopwith.solgatos.com> Message-ID: <689d500ec8c95542a53440b8a23ae773@mail.liquidphlux.com> On Mon, 28 Sep 2009 19:26:34 PDT, Dieter wrote: > In message , > Francisco Reyes writes: >> Steven Hartland writes: >> >> > Just noticed the following posted on phoronix: >> > http://www.phoronix.com/scan.php?page=article&item=freebsd8_ubuntu910&num=1 >> > Comments? >> >> This was discussed in detail in slashdot.. starting with the fact that >> most >> likely debug switches were not turned off for FreeBSD. > > "All of the FreeBSD and Ubuntu options were left at their defaults." > > My question is why is FreeBSD's disk i/o performance so bad? > Not just in the benchmarks with debugging on, but in real world usage > where it actually matters. > _______________________________________________ > freebsd-performance@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-performance > To unsubscribe, send any mail to > "freebsd-performance-unsubscribe@freebsd.org" Well for one if we look at /usr/src/UPDATING "NOTE TO PEOPLE WHO THINK THAT FreeBSD 8.x IS SLOW: FreeBSD 8.x has many debugging features turned on, in both the kernel and userland. These features attempt to detect incorrect use of system primitives, and encourage loud failure through extra sanity checking and fail stop semantics. They also substantially impact system performance. If you want to do performance measurement, benchmarking, and optimization, you'll want to turn them off. This includes various WITNESS- related kernel options, INVARIANTS, malloc debugging flags in userland, and various verbose features in the kernel. Many developers choose to disable these features on build machines to maximize performance. (To disable malloc debugging, run ln -s aj /etc/malloc.conf.)" Since the article says that they left the debugging features on I think this has a bit to do with it. Obviously the testers didn't care to read the documentation, and didn't seem to care to use the same compiler which is available in ports, I believe it is safe to chuck this lame benchmark. ~Andrew -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From schulra at earlham.edu Tue Sep 29 19:03:00 2009 From: schulra at earlham.edu (Randy Schultz) Date: Tue Sep 29 19:03:08 2009 Subject: FreeBSD vs Ubuntu - Discuss... In-Reply-To: <689d500ec8c95542a53440b8a23ae773@mail.liquidphlux.com> Message-ID: <458792029.144491254249841202.JavaMail.root@shee.earlham.edu> ----- "Andrew Kuriger" spaketh thusly: | | Since the article says that they left the debugging features on I | think | this has a bit to do with it. Obviously the testers didn't care to | read the | documentation, and didn't seem to care to use the same compiler which | is | available in ports, I believe it is safe to chuck this lame | benchmark. Hrm. IMHO, this benchmark actually tells us something interesting. It tells us that with the anchor thrown overboard, freebsd is nearly as fast as linux. -- Randy (schulra@earlham.edu) 765.983.1283 <*> The penguin cometh From francisco.cabrita at gmail.com Tue Sep 29 19:06:10 2009 From: francisco.cabrita at gmail.com (Francisco Cabrita) Date: Tue Sep 29 19:06:17 2009 Subject: FreeBSD vs Ubuntu - Discuss... In-Reply-To: <458792029.144491254249841202.JavaMail.root@shee.earlham.edu> References: <689d500ec8c95542a53440b8a23ae773@mail.liquidphlux.com> <458792029.144491254249841202.JavaMail.root@shee.earlham.edu> Message-ID: On Tue, Sep 29, 2009 at 7:44 PM, Randy Schultz wrote: > > ----- "Andrew Kuriger" spaketh thusly: > > | > | Since the article says that they left the debugging features on I > | think > | this has a bit to do with it. Obviously the testers didn't care to > | read the > | documentation, and didn't seem to care to use the same compiler which > | is > | available in ports, I believe it is safe to chuck this lame > | benchmark. > > > Hrm. IMHO, this benchmark actually tells us something interesting. It > tells us > that with the anchor thrown overboard, freebsd is nearly as fast as linux. > > mega lol :) > -- > > Randy (schulra@earlham.edu) 765.983.1283 <*> > > The penguin cometh > > _______________________________________________ > freebsd-performance@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-performance > To unsubscribe, send any mail to " > freebsd-performance-unsubscribe@freebsd.org" > -- blog: http://sufixo.com/raw http://www.linkedin.com/in/franciscocabrita From attilio at freebsd.org Tue Sep 29 19:09:57 2009 From: attilio at freebsd.org (Attilio Rao) Date: Tue Sep 29 19:10:03 2009 Subject: FreeBSD vs Ubuntu - Discuss... In-Reply-To: <458792029.144491254249841202.JavaMail.root@shee.earlham.edu> References: <689d500ec8c95542a53440b8a23ae773@mail.liquidphlux.com> <458792029.144491254249841202.JavaMail.root@shee.earlham.edu> Message-ID: <3bbf2fe10909291209h3c2b1c57se68e6030c2a5a044@mail.gmail.com> 2009/9/29 Randy Schultz : > > ----- "Andrew Kuriger" spaketh thusly: > > | > | Since the article says that they left the debugging features on I > | think > | this has a bit to do with it. Obviously the testers didn't care to > | read the > | documentation, and didn't seem to care to use the same compiler which > | is > | available in ports, I believe it is safe to chuck this lame > | benchmark. > > > Hrm. IMHO, this benchmark actually tells us something interesting. It tells us > that with the anchor thrown overboard, freebsd is nearly as fast as linux. I don't think this is the case. The tester claims to be using FreeBSD-RC1 which has all the mentioned debugging options off. And yes, we should adjust UPDATING in order to remove the (now) misleading writing about the debugging options. I think that the most interesting opionion these benchmarks tell is that we are slow on random, threaded I/O operations. I think we need to investigate more in this direction. Attilio -- Peace can only be achieved by understanding - A. Einstein From leccine at gmail.com Tue Sep 29 19:34:13 2009 From: leccine at gmail.com (=?ISO-8859-1?B?SXN0duFu?=) Date: Tue Sep 29 19:34:19 2009 Subject: FreeBSD vs Ubuntu - Discuss... In-Reply-To: <3bbf2fe10909291209h3c2b1c57se68e6030c2a5a044@mail.gmail.com> References: <689d500ec8c95542a53440b8a23ae773@mail.liquidphlux.com> <458792029.144491254249841202.JavaMail.root@shee.earlham.edu> <3bbf2fe10909291209h3c2b1c57se68e6030c2a5a044@mail.gmail.com> Message-ID: With........DTrace!!@#!#@! :) I think that the most interesting opionion these benchmarks tell is > that we are slow on random, threaded I/O operations. I think we need > to investigate more in this direction. > > Attilio > > > -- > Peace can only be achieved by understanding - A. Einstein > _______________________________________________ > freebsd-performance@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-performance > To unsubscribe, send any mail to " > freebsd-performance-unsubscribe@freebsd.org" > -- the sun shines for all From attilio at freebsd.org Tue Sep 29 19:37:19 2009 From: attilio at freebsd.org (Attilio Rao) Date: Tue Sep 29 19:37:26 2009 Subject: FreeBSD vs Ubuntu - Discuss... In-Reply-To: References: <689d500ec8c95542a53440b8a23ae773@mail.liquidphlux.com> <458792029.144491254249841202.JavaMail.root@shee.earlham.edu> <3bbf2fe10909291209h3c2b1c57se68e6030c2a5a044@mail.gmail.com> Message-ID: <3bbf2fe10909291237t50ac370ci71e2a32bde17bda1@mail.gmail.com> 2009/9/29 Istv?n : > With........DTrace!!@#!#@! :) > > I think that the most interesting opionion these benchmarks tell is >> that we are slow on random, threaded I/O operations. I think we need >> to investigate more in this direction. First thing, it would be interesting if someone could be reproduce such (or similar) numbers in a reproducible manner, so that we can start hammering down the effort. Attilio -- Peace can only be achieved by understanding - A. Einstein From ohartman at mail.zedat.fu-berlin.de Tue Sep 29 19:30:48 2009 From: ohartman at mail.zedat.fu-berlin.de (O. Hartmann) Date: Tue Sep 29 21:16:00 2009 Subject: FreeBSD vs Ubuntu - Discuss... In-Reply-To: <689d500ec8c95542a53440b8a23ae773@mail.liquidphlux.com> References: <200909290226.CAA28246@sopwith.solgatos.com> <689d500ec8c95542a53440b8a23ae773@mail.liquidphlux.com> Message-ID: <4AC25A1F.9000405@mail.zedat.fu-berlin.de> Andrew Kuriger wrote: > On Mon, 28 Sep 2009 19:26:34 PDT, Dieter > wrote: >> In message , >> Francisco Reyes writes: >>> Steven Hartland writes: >>> >>>> Just noticed the following posted on phoronix: >>>> > http://www.phoronix.com/scan.php?page=article&item=freebsd8_ubuntu910&num=1 >>>> Comments? >>> This was discussed in detail in slashdot.. starting with the fact that >>> most >>> likely debug switches were not turned off for FreeBSD. >> "All of the FreeBSD and Ubuntu options were left at their defaults." >> >> My question is why is FreeBSD's disk i/o performance so bad? >> Not just in the benchmarks with debugging on, but in real world usage >> where it actually matters. >> _______________________________________________ >> freebsd-performance@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-performance >> To unsubscribe, send any mail to >> "freebsd-performance-unsubscribe@freebsd.org" > > Well for one if we look at /usr/src/UPDATING > > "NOTE TO PEOPLE WHO THINK THAT FreeBSD 8.x IS SLOW: > FreeBSD 8.x has many debugging features turned on, in both the kernel and > userland. These features attempt to detect incorrect use of system > primitives, and encourage loud failure through extra sanity checking and > fail stop semantics. They also substantially impact system performance. If > you want to do performance measurement, benchmarking, and optimization, > you'll want to turn them off. This includes various WITNESS- related kernel > options, INVARIANTS, malloc debugging flags in userland, and various > verbose features in the kernel. Many developers choose to disable these > features on build machines to maximize performance. (To disable malloc > debugging, run ln -s aj /etc/malloc.conf.)" > > Since the article says that they left the debugging features on I think > this has a bit to do with it. Obviously the testers didn't care to read the > documentation, and didn't seem to care to use the same compiler which is > available in ports, I believe it is safe to chuck this lame benchmark. > > ~Andrew > I doubt that debugging switches left in some places a normal admin or user can't get so easy are the reason why FreeBSD 8.0-RC performs that bad compared to Ubuntu 9,1-Linux. The question at this point would be, whether debugging was enabled on Linux as well or not ... Oliver From attilio at freebsd.org Tue Sep 29 23:38:53 2009 From: attilio at freebsd.org (Attilio Rao) Date: Tue Sep 29 23:39:01 2009 Subject: FreeBSD vs Ubuntu - Discuss... In-Reply-To: <4AC2968C.6020206@mail.zedat.fu-berlin.de> References: <689d500ec8c95542a53440b8a23ae773@mail.liquidphlux.com> <458792029.144491254249841202.JavaMail.root@shee.earlham.edu> <3bbf2fe10909291209h3c2b1c57se68e6030c2a5a044@mail.gmail.com> <4AC2968C.6020206@mail.zedat.fu-berlin.de> Message-ID: <3bbf2fe10909291638o6901195sf60a4fd2e69f6215@mail.gmail.com> 2009/9/30 O. Hartmann : > Attilio Rao wrote: >> 2009/9/29 Randy Schultz : >>> ----- "Andrew Kuriger" spaketh thusly: >>> >>> | >>> | Since the article says that they left the debugging features on I >>> | think >>> | this has a bit to do with it. Obviously the testers didn't care to >>> | read the >>> | documentation, and didn't seem to care to use the same compiler which >>> | is >>> | available in ports, I believe it is safe to chuck this lame >>> | benchmark. >>> >>> >>> Hrm. IMHO, this benchmark actually tells us something interesting. It tells us >>> that with the anchor thrown overboard, freebsd is nearly as fast as linux. >> >> I don't think this is the case. >> The tester claims to be using FreeBSD-RC1 which has all the mentioned >> debugging options off. >> And yes, we should adjust UPDATING in order to remove the (now) >> misleading writing about the debugging options. >> >> I think that the most interesting opionion these benchmarks tell is >> that we are slow on random, threaded I/O operations. I think we need >> to investigate more in this direction. >> >> Attilio >> >> > > Well, since FreeBSD 8.0 started, I realized on several boxes (doens't > matter whether SMP or UP, 2 GB or 8 GB or 16 GB) massive performance > issues when compiling, even on a 8-core box. This is not 'measured' in > hard numbers, it is the 'feeling' since we swapped to 8.0, but still > using the same setup and software environment. On boxes with X11, on > heavy disk I/O and/or heavy compiling, X11 clients sometimes stops for > 90 seconds, mouse gets jumpy etc. This is well known and well ignored, > although I'm not the only one experiencing this. What do you mean with 'well known' and 'well ignored'? Do you have pointes to such issues? Attilio -- Peace can only be achieved by understanding - A. Einstein From ohartman at mail.zedat.fu-berlin.de Tue Sep 29 23:21:50 2009 From: ohartman at mail.zedat.fu-berlin.de (O. Hartmann) Date: Wed Sep 30 02:06:37 2009 Subject: FreeBSD vs Ubuntu - Discuss... In-Reply-To: <3bbf2fe10909291209h3c2b1c57se68e6030c2a5a044@mail.gmail.com> References: <689d500ec8c95542a53440b8a23ae773@mail.liquidphlux.com> <458792029.144491254249841202.JavaMail.root@shee.earlham.edu> <3bbf2fe10909291209h3c2b1c57se68e6030c2a5a044@mail.gmail.com> Message-ID: <4AC2968C.6020206@mail.zedat.fu-berlin.de> Attilio Rao wrote: > 2009/9/29 Randy Schultz : >> ----- "Andrew Kuriger" spaketh thusly: >> >> | >> | Since the article says that they left the debugging features on I >> | think >> | this has a bit to do with it. Obviously the testers didn't care to >> | read the >> | documentation, and didn't seem to care to use the same compiler which >> | is >> | available in ports, I believe it is safe to chuck this lame >> | benchmark. >> >> >> Hrm. IMHO, this benchmark actually tells us something interesting. It tells us >> that with the anchor thrown overboard, freebsd is nearly as fast as linux. > > I don't think this is the case. > The tester claims to be using FreeBSD-RC1 which has all the mentioned > debugging options off. > And yes, we should adjust UPDATING in order to remove the (now) > misleading writing about the debugging options. > > I think that the most interesting opionion these benchmarks tell is > that we are slow on random, threaded I/O operations. I think we need > to investigate more in this direction. > > Attilio > > Well, since FreeBSD 8.0 started, I realized on several boxes (doens't matter whether SMP or UP, 2 GB or 8 GB or 16 GB) massive performance issues when compiling, even on a 8-core box. This is not 'measured' in hard numbers, it is the 'feeling' since we swapped to 8.0, but still using the same setup and software environment. On boxes with X11, on heavy disk I/O and/or heavy compiling, X11 clients sometimes stops for 90 seconds, mouse gets jumpy etc. This is well known and well ignored, although I'm not the only one experiencing this. I think this will not change soon. ZFS is, at this moment, the only thing that keeps me with FreeBSD. In every other case, serving, number crunching (oh, we need a lot of I/O performance in those number crunching environments) and even simple desktop, Linux, mostly Ubuntu and RedHat, outperforms FreeBSD. From freebsd at sopwith.solgatos.com Wed Sep 30 04:24:43 2009 From: freebsd at sopwith.solgatos.com (Dieter) Date: Wed Sep 30 04:24:51 2009 Subject: A specific example of a disk i/o problem (was: FreeBSD vs Ubuntu) In-Reply-To: Your message of "Tue, 29 Sep 2009 12:42:13 EDT." Message-ID: <200909300226.CAA29195@sopwith.solgatos.com> > > My question is why is FreeBSD's disk i/o performance so bad? > > As I mentioned... this was discussed actively in slashdot. You will find > there many good comments on this. All I saw in slashdot was a ffs vs ext comment. I don't believe the problems I'm seeing are filesystem related. > > Not just in the benchmarks with debugging on, but in real world usage > > where it actually matters. > > Are you saying this from actual experience or from reading other people's > comments? Here is a specific demo of one disk i/o problem I'm seeing. Should be easy to reproduce? http://lists.freebsd.org/pipermail/freebsd-performance/2008-July/003533.html This was over a year ago, so add 7.1 to the list of versions with the problem. I believe that the swap_pager: indefinite wait buffer: bufobj: 0, blkno: 1148109, size: 4096 messages I'm getting are the same problem. A user process is hogging the bottleneck (disk buffer cache?) and the swapper/pager is getting starved. I frequently see problems where disk i/o on one disk starves a process that needs disk i/o on a different disk on a different controller, which is why I suspect the disk buffer cache as the bottleneck. > If it is from actual experience and XYZ version of Linux does a > particular job better then I don't see why you should not consider using > what works best. I was stuck running Linux on one machine for awhile and it scrambled my data. No thank you. Data integrity is essential. Thankfully I have been penguin free for awhile now. From leccine at gmail.com Wed Sep 30 05:31:41 2009 From: leccine at gmail.com (=?ISO-8859-1?B?SXN0duFu?=) Date: Wed Sep 30 05:31:47 2009 Subject: FreeBSD vs Ubuntu - Discuss... In-Reply-To: <4AC2968C.6020206@mail.zedat.fu-berlin.de> References: <689d500ec8c95542a53440b8a23ae773@mail.liquidphlux.com> <458792029.144491254249841202.JavaMail.root@shee.earlham.edu> <3bbf2fe10909291209h3c2b1c57se68e6030c2a5a044@mail.gmail.com> <4AC2968C.6020206@mail.zedat.fu-berlin.de> Message-ID: makes no sense to stay with freebsd for zfs: http://opensolaris.org/os/downloads/ I think this will not change soon. ZFS is, at this moment, the only > thing that keeps me with FreeBSD. In every other case, serving, number > crunching (oh, we need a lot of I/O performance in those number > crunching environments) and even simple desktop, Linux, mostly Ubuntu > and RedHat, outperforms FreeBSD. > _______________________________________________ > freebsd-performance@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-performance > To unsubscribe, send any mail to " > freebsd-performance-unsubscribe@freebsd.org" > -- the sun shines for all From kip.macy at gmail.com Wed Sep 30 05:33:37 2009 From: kip.macy at gmail.com (Kip Macy) Date: Wed Sep 30 05:33:43 2009 Subject: FreeBSD vs Ubuntu - Discuss... In-Reply-To: <4AC2968C.6020206@mail.zedat.fu-berlin.de> References: <689d500ec8c95542a53440b8a23ae773@mail.liquidphlux.com> <458792029.144491254249841202.JavaMail.root@shee.earlham.edu> <3bbf2fe10909291209h3c2b1c57se68e6030c2a5a044@mail.gmail.com> <4AC2968C.6020206@mail.zedat.fu-berlin.de> Message-ID: On Sep 29, 2009, at 4:21 PM, O. Hartmann wrote: > Well, since FreeBSD 8.0 started, I realized on several boxes (doens't > matter whether SMP or UP, 2 GB or 8 GB or 16 GB) massive performance > issues when compiling, even on a 8-core box. This is not 'measured' in > hard numbers, it is the 'feeling' since we swapped to 8.0, but still > crunching (oh, we need a lot of I/O performance in those number > crunching environments) and even simple desktop, Linux, mostly Ubuntu > and RedHat, outperforms FreeBSD. We certainly do periodically have performance issues, but it isn't realistic to expect us to tune for how it "feels" to you. Performance on concrete workloads would contribute a great deal more to the discussion. -Kip From leccine at gmail.com Wed Sep 30 05:37:49 2009 From: leccine at gmail.com (=?ISO-8859-1?B?SXN0duFu?=) Date: Wed Sep 30 05:37:56 2009 Subject: FreeBSD vs Ubuntu - Discuss... In-Reply-To: References: <689d500ec8c95542a53440b8a23ae773@mail.liquidphlux.com> <458792029.144491254249841202.JavaMail.root@shee.earlham.edu> <3bbf2fe10909291209h3c2b1c57se68e6030c2a5a044@mail.gmail.com> <4AC2968C.6020206@mail.zedat.fu-berlin.de> Message-ID: but if we measure the performance based on feelings we could advertise freebsd: "feels better" do not forget the marketing value :)) On Wed, Sep 30, 2009 at 6:12 AM, Kip Macy wrote: > > On Sep 29, 2009, at 4:21 PM, O. Hartmann wrote: > >> Well, since FreeBSD 8.0 started, I realized on several boxes (doens't >> matter whether SMP or UP, 2 GB or 8 GB or 16 GB) massive performance >> issues when compiling, even on a 8-core box. This is not 'measured' in >> > > hard numbers, it is the 'feeling' since we swapped to 8.0, but still >> crunching (oh, we need a lot of I/O performance in those number >> crunching environments) and even simple desktop, Linux, mostly Ubuntu >> and RedHat, outperforms FreeBSD. >> > > > We certainly do periodically have performance issues, but it isn't > realistic to expect us to tune for how it "feels" to you. Performance on > concrete workloads would contribute a great deal more to the discussion. > > > -Kip > > _______________________________________________ > freebsd-performance@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-performance > To unsubscribe, send any mail to " > freebsd-performance-unsubscribe@freebsd.org" > -- the sun shines for all From attilio at freebsd.org Wed Sep 30 06:30:35 2009 From: attilio at freebsd.org (Attilio Rao) Date: Wed Sep 30 06:37:10 2009 Subject: A specific example of a disk i/o problem (was: FreeBSD vs Ubuntu) In-Reply-To: <200909300226.CAA29195@sopwith.solgatos.com> References: <200909300226.CAA29195@sopwith.solgatos.com> Message-ID: <3bbf2fe10909292330t753bcad1r69ae67d7e898ee35@mail.gmail.com> 2009/9/30 Dieter : >> > My question is why is FreeBSD's disk i/o performance so bad? >> >> As I mentioned... this was discussed actively in slashdot. You will find >> there many good comments on this. > > All I saw in slashdot was a ffs vs ext comment. I don't believe the problems > I'm seeing are filesystem related. > >> > Not just in the benchmarks with debugging on, but in real world usage >> > where it actually matters. >> >> Are you saying this from actual experience or from reading other people's >> comments? > > Here is a specific demo of one disk i/o problem I'm seeing. Should be > easy to reproduce? > > http://lists.freebsd.org/pipermail/freebsd-performance/2008-July/003533.html > > This was over a year ago, so add 7.1 to the list of versions with the problem. > I believe that the > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 1148109, size: 4096 > messages I'm getting are the same problem. A user process is hogging > the bottleneck (disk buffer cache?) and the swapper/pager is getting starved. Sorry, do you have a PR/describing e-mail with this issue? Can you be a bit more precise? The problem reported in the earlier post, however, is interesting and worths more analysis. More speficially, would you be interested in reproducing and playing a bit with some diagnostic tool/configurations I can point you at? Attilio -- Peace can only be achieved by understanding - A. Einstein From lehmann at ans-netz.de Wed Sep 30 06:28:45 2009 From: lehmann at ans-netz.de (Oliver Lehmann) Date: Wed Sep 30 11:35:29 2009 Subject: (no subject) Message-ID: <20090930060202.45527.qmail@avocado.salatschuessel.net> Hi, I got 4 new SATA disks (WD Green, 1TB, WD10EADS) I want to use to replace my old 250GB disks attached to my 3ware controller. I want to reuse the old 250GB disks in some systems running old PATA disks ight now as system drives. So what I did now was gathering SATA performance tatistics with the new 1TB drive to just find out what would be the maximum performance I would get out of these disks to compare them later with my 3ware when they are configured as RAID-5. A colleague of mine has the same disks in a new Nvidia Atom 330 system and he told me that he reaches around 70MB/sec write speed with a single large file on a single disk running linux 2.6. I hooked the disk up to my client: FreeBSD 7.2-STABLE #0: Tue Jul 28 12:59:47 CEST 2009 CPU: AMD Athlon(tm) 64 Processor 3500+ (2200.10-MHz K8-class CPU) usable memory = 2138615808 (2039 MB) atapci0: port 0xd000-0xd007,0xc800-0xc803,0xc400-0xc407,0xc000-0xc003,0xb800-0xb80f,0xb400 -0xb4ff irq 20 at device 15.0 on pci0 ad4: 953869MB at ata2-master SATA150 because the on-board controller is a VIA 6420 I had to set the SATA150 Jumper on the harddisk to have the controller detect the drive. On FreeBSD I used gpart+gpt to create a 1TB partition and then simply ran newfs /dev/ad4p1 and mounted the new filesystem afterwards. I then ran a dd in=/dev/zero of=/mnt/tmp/test.dd bs=1M count=4069 and dd reported me a write speed of around 25MB/sec. This made me feel kinda bad so I gave bonnie++ a try. The result was: Version 1.96 ------Sequential Output------ --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP kartoffel.salats 4G 548 96 28924 3 14617 2 1141 96 36869 3 199.7 2 Latency 167ms 71702us 1759ms 23957us 75351us 2286ms Version 1.96 ------Sequential Create------ --------Random Create-------- kartoffel.salatschu -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 552 1 +++++ +++ 1486 2 531 1 +++++ +++ 1278 1 Latency 91403us 156us 28424us 22901us 87us 22820us 1.96,1.96,kartoffel.salatschuessel.net,1,1254282805,4G,,548,96,28924,3,14617 ,2,1141,96,36869,3,199.7,2,16,,,,,552,1,+++++,+++,1486,2,531,1,+++++,+++,127 8,1,167ms,71702us,1759ms,23957us,75351us,2286ms,91403us,156us,28424us,22901u s,87us,22820us This also did not look that good comparing to the bonnie output the colleague gave me from his shiny new ION system. I then booted the latest knoppix (Also a 2.6.whatever linux kernel), created a filesystem on /dev/sd1a (mkfs.ext3 /dev/sd1a) and mounted the filesystem as well. The same dd I ran on FreeBSD I also ran on Knoppix and this gave me 57.3MB/sec (wow compared to 25MB/sec). I then also started bonnie++ just to see that this one is also much better: Version 1.96 ------Sequential Output------ --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP Microknoppix 4G 305 99 55905 18 31896 9 959 98 80414 10 211.7 3 Latency 28579us 1075ms 1046ms 26376us 20962us 272ms Version 1.96 ------Sequential Create------ --------Random Create-------- Microknoppix -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 27135 59 +++++ +++ +++++ +++ 29369 62 +++++ +++ +++++ +++ Latency 23535us 9969us 9927us 11680us 1182us 9985us 1.96,1.96,Microknoppix,1,1254262392,4G,,305,99,55905,18,31896,9,959,98,80414 ,10,211.7,3,16,,,,,27135,59,+++++,+++,+++++,+++,29369,62,+++++,+++,+++++,+++ ,28579us,1075ms,1046ms,26376us,20962us,272ms,23535us,9969us,9927us,11680us,1 182us,9985us Does anyone know if there is something I can tune on FreeBSD to get more speed? hw.ata.wc is enabled of course. hw.ata.wc: 1 hw.ata.atapi_dma: 1 hw.ata.ata_dma_check_80pin: 1 hw.ata.ata_dma: 1 I'll retest both setups with a plugged in Promise SATA300 PCI controller but I doubt that it will get faster. I tried the controller before, and on an dual PIII-850 system with L440GX chipset and 2GB of RAM the controller gave me around 40MB/sec on write and on my amd64 system I also only got around 25MB/sec (even this makes no sense to me why my old PIII is faster then my much newer amd64) but I'll come back with better numbers for this controller later. From doconnor at gsoft.com.au Wed Sep 30 07:34:48 2009 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Wed Sep 30 11:35:46 2009 Subject: (no subject) In-Reply-To: <20090930060202.45527.qmail@avocado.salatschuessel.net> References: <20090930060202.45527.qmail@avocado.salatschuessel.net> Message-ID: <200909301646.35019.doconnor@gsoft.com.au> On Wed, 30 Sep 2009, Oliver Lehmann wrote: > A colleague of mine has the same disks in a new Nvidia Atom 330 > system and he told me that he reaches around 70MB/sec write speed > with a single large file on a single disk running linux 2.6. > > I hooked the disk up to my client: > > FreeBSD 7.2-STABLE #0: Tue Jul 28 12:59:47 CEST 2009 > CPU: AMD Athlon(tm) 64 Processor 3500+ (2200.10-MHz K8-class CPU) > usable memory = 2138615808 (2039 MB) > atapci0: port > 0xd000-0xd007,0xc800-0xc803,0xc400-0xc407,0xc000-0xc003,0xb800-0xb80f >,0xb400 -0xb4ff irq 20 at device 15.0 on pci0 > ad4: 953869MB at ata2-master SATA150 > > because the on-board controller is a VIA 6420 I had to set the > SATA150 Jumper on the harddisk to have the controller detect the > drive. I found I was getting timeouts with this controller and exactly those drives even with the SATA150 jumper connected. In the end I got a PCI Silicon Image 3114 based controller and it worked fine. That said I gave up on the hardware as I couldn't get the motherboard to boot off the CF/IDE adapter so I got an AMD SB700 based board which works well (fingers crossed :) I didn't do any stand alone drive performance tests though. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-performance/attachments/20090930/cd539813/attachment.pgp From lehmann at ans-netz.de Wed Sep 30 07:53:59 2009 From: lehmann at ans-netz.de (Oliver Lehmann) Date: Wed Sep 30 11:35:53 2009 Subject: SATA is to slow comparing with linux In-Reply-To: <200909301646.35019.doconnor@gsoft.com.au> References: <20090930060202.45527.qmail@avocado.salatschuessel.net> <200909301646.35019.doconnor@gsoft.com.au> Message-ID: <20090930075357.49914.qmail@avocado.salatschuessel.net> Daniel O'Connor writes: > In the end I got a PCI Silicon Image 3114 based controller and it worked > fine. I thought about getting a controller with a SiL-Chil too because they are kinda cheap and another system I intend to use with SATA harddisks has no SATA on-board. But then I searched through the web and read many posts telling me "stay away from Silicon Image controllers" so I did as advised.... I got a Promise SATA300 TX2plus instead. I'll rune some tests with later (when I'm back home ;)) From rnoland at FreeBSD.org Wed Sep 30 10:19:14 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Wed Sep 30 11:36:26 2009 Subject: SATA is to slow comparing with linux In-Reply-To: <20090930075357.49914.qmail@avocado.salatschuessel.net> References: <20090930060202.45527.qmail@avocado.salatschuessel.net> <200909301646.35019.doconnor@gsoft.com.au> <20090930075357.49914.qmail@avocado.salatschuessel.net> Message-ID: <1254304611.2268.962.camel@balrog.2hip.net> On Wed, 2009-09-30 at 09:53 +0200, Oliver Lehmann wrote: > Daniel O'Connor writes: > > > In the end I got a PCI Silicon Image 3114 based controller and it worked > > fine. > > I thought about getting a controller with a SiL-Chil too because they are > kinda cheap and another system I intend to use with SATA harddisks has no > SATA on-board. But then I searched through the web and read many posts > telling me "stay away from Silicon Image controllers" so I did as > advised.... > > I got a Promise SATA300 TX2plus instead. I'll rune some tests with later > (when I'm back home ;)) I would also be curious how that ahci driver from -CURRENT is performing relative to other implementations. robert. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Robert Noland FreeBSD From lehmann at ans-netz.de Wed Sep 30 11:17:37 2009 From: lehmann at ans-netz.de (Oliver Lehmann) Date: Wed Sep 30 11:36:34 2009 Subject: SATA is to slow comparing with linux In-Reply-To: <1254304611.2268.962.camel@balrog.2hip.net> References: <20090930060202.45527.qmail@avocado.salatschuessel.net> <200909301646.35019.doconnor@gsoft.com.au> <20090930075357.49914.qmail@avocado.salatschuessel.net> <1254304611.2268.962.camel@balrog.2hip.net> Message-ID: <20090930111734.58106.qmail@avocado.salatschuessel.net> Robert Noland writes: > On Wed, 2009-09-30 at 09:53 +0200, Oliver Lehmann wrote: >> I got a Promise SATA300 TX2plus instead. I'll rune some tests with later >> (when I'm back home ;)) > > I would also be curious how that ahci driver from -CURRENT is performing > relative to other implementations. So there is a new driver - never heard about ahci ;) Is it sufficient to boot 8.0-RC1 livefs? It looks like ahci is not included in GENERIC so I have to load the module in the 2nd bootloader I guess. Something else like disabling the old ata driver? Or will the new driver be used automatically. I was not sure about the man page what "this one" means (the ataahci or the ahaci?): AHCI hardware is also supported by ataahci driver from ata(4) subsystem. If both drivers are loaded at the same time, this one will be given precedence as the more functional of the two. From rnoland at FreeBSD.org Wed Sep 30 11:23:39 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Wed Sep 30 11:50:25 2009 Subject: SATA is to slow comparing with linux In-Reply-To: <20090930111734.58106.qmail@avocado.salatschuessel.net> References: <20090930060202.45527.qmail@avocado.salatschuessel.net> <200909301646.35019.doconnor@gsoft.com.au> <20090930075357.49914.qmail@avocado.salatschuessel.net> <1254304611.2268.962.camel@balrog.2hip.net> <20090930111734.58106.qmail@avocado.salatschuessel.net> Message-ID: <1254309807.2268.1052.camel@balrog.2hip.net> On Wed, 2009-09-30 at 13:17 +0200, Oliver Lehmann wrote: > Robert Noland writes: > > > On Wed, 2009-09-30 at 09:53 +0200, Oliver Lehmann wrote: > >> I got a Promise SATA300 TX2plus instead. I'll rune some tests with later > >> (when I'm back home ;)) > > > > I would also be curious how that ahci driver from -CURRENT is performing > > relative to other implementations. > > So there is a new driver - never heard about ahci ;) > Is it sufficient to boot 8.0-RC1 livefs? It looks like ahci is not included > in GENERIC so I have to load the module in the 2nd bootloader I guess. > Something else like disabling the old ata driver? Or will the new driver be > used automatically. I was not sure about the man page what "this one" means > (the ataahci or the ahaci?): > > AHCI hardware is also supported by ataahci driver from ata(4) > subsystem. > If both drivers are loaded at the same time, this one will be given > precedence as the more functional of the two. If the ahci driver is loaded via loader.conf it will override that ata driver. The ahci driver is being actively worked on, so I'm not certain how much of the new code is in RC1, but that is a start. robert. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Robert Noland FreeBSD From s4mmael at gmail.com Wed Sep 30 12:16:39 2009 From: s4mmael at gmail.com (S4mmael) Date: Wed Sep 30 12:16:45 2009 Subject: Fwd: FreeBSD vs Ubuntu - Discuss... In-Reply-To: <6e38aed80909300449h61d671a3i2281eb875f649eb6@mail.gmail.com> References: <200909290226.CAA28246@sopwith.solgatos.com> <689d500ec8c95542a53440b8a23ae773@mail.liquidphlux.com> <6e38aed80909300449h61d671a3i2281eb875f649eb6@mail.gmail.com> Message-ID: <6e38aed80909300449p24928d25v2a34d24f309fa808@mail.gmail.com> > Since the article says that they left the debugging features on I think > this has a bit to do with it. Obviously the testers didn't care to read the > documentation, and didn't seem to care to use the same compiler which is > available in ports, I believe it is safe to chuck this lame benchmark. What about FreeBSD 7.2? All debug featureas are 100% off in this version, but test results are the same as in 8.0 Besides, UFS is known to be not the fastest FS. So, there is no reason to be suprised. From leccine at gmail.com Wed Sep 30 12:22:08 2009 From: leccine at gmail.com (=?ISO-8859-1?B?SXN0duFu?=) Date: Wed Sep 30 12:22:14 2009 Subject: FreeBSD vs Ubuntu - Discuss... In-Reply-To: <6e38aed80909300449p24928d25v2a34d24f309fa808@mail.gmail.com> References: <200909290226.CAA28246@sopwith.solgatos.com> <689d500ec8c95542a53440b8a23ae773@mail.liquidphlux.com> <6e38aed80909300449h61d671a3i2281eb875f649eb6@mail.gmail.com> <6e38aed80909300449p24928d25v2a34d24f309fa808@mail.gmail.com> Message-ID: have you seen the previous mail about 8.0 and debug stuff? you might have overlooked it. yes UFS is not the fastest, it is FAT16, stick to that :) On Wed, Sep 30, 2009 at 12:49 PM, S4mmael wrote: > > Since the article says that they left the debugging features on I think > > this has a bit to do with it. Obviously the testers didn't care to read > the > > documentation, and didn't seem to care to use the same compiler which is > > available in ports, I believe it is safe to chuck this lame benchmark. > What about FreeBSD 7.2? All debug featureas are 100% off in this > version, but test results are the same as in 8.0 > Besides, UFS is known to be not the fastest FS. So, there is no reason > to be suprised. > _______________________________________________ > freebsd-performance@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-performance > To unsubscribe, send any mail to " > freebsd-performance-unsubscribe@freebsd.org" > -- the sun shines for all From mike at sentex.net Wed Sep 30 13:42:44 2009 From: mike at sentex.net (Mike Tancsa) Date: Wed Sep 30 13:42:50 2009 Subject: SATA is to slow comparing with linux In-Reply-To: <20090930141036.0000184b@unknown> References: <20090930060202.45527.qmail@avocado.salatschuessel.net> <200909301646.35019.doconnor@gsoft.com.au> <20090930075357.49914.qmail@avocado.salatschuessel.net> <1254304611.2268.962.camel@balrog.2hip.net> <20090930141036.0000184b@unknown> Message-ID: <200909301318.n8UDImSr014557@lava.sentex.ca> At 09:10 AM 9/30/2009, Bruce Cran wrote: >I ran the tiobench test on -CURRENT a few days ago and the ahci driver >showed an improvement in latency over the ata driver; I didn't >test transfer rates though. I was running the AHCI driver on the freebsd-current tinderbox for 3 weeks with very good results. I had to recently change back to the ata code as smartmontools are not (yet) supported and one of the drives started to throw errors. Other than that, I found it to be the same speed or faster (depending on the workload). This was on a Phenom 9950 Processor and ATI IXP700/800 SATA300 chipset on AMD64, 8G of RAM. ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From martin.mato at wanadoo.fr Wed Sep 30 15:29:33 2009 From: martin.mato at wanadoo.fr (Martin MATO) Date: Wed Sep 30 15:30:06 2009 Subject: FreeBSD vs Ubuntu - Discuss... In-Reply-To: References: <200909290226.CAA28246@sopwith.solgatos.com> <689d500ec8c95542a53440b8a23ae773@mail.liquidphlux.com> <6e38aed80909300449h61d671a3i2281eb875f649eb6@mail.gmail.com> <6e38aed80909300449p24928d25v2a34d24f309fa808@mail.gmail.com> Message-ID: <4AC37945.3070703@wanadoo.fr> Istv?n a ?crit?: have you seen the previous mail about 8.0 and debug stuff? you might have overlooked it. yes UFS is not the fastest, it is FAT16, stick to that :) On Wed, Sep 30, 2009 at 12:49 PM, S4mmael [1] wrote: Since the article says that they left the debugging features on I think this has a bit to do with it. Obviously the testers didn't care to read the documentation, and didn't seem to care to use the same compiler which is available in ports, I believe it is safe to chuck this lame benchmark. What about FreeBSD 7.2? All debug featureas are 100% off in this version, but test results are the same as in 8.0 Besides, UFS is known to be not the fastest FS. So, there is no reason to be suprised. _______________________________________________ [2]freebsd-performance@freebsd.org mailing list [3]http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to " [4]freebsd-performance-unsubscribe@freebsd.org" greetings maybe it is just a dumb thought, but? aio is enabled by default on linux kernels for vfs r/w operations? -- Ce message a ?t? v?rifi? par [5]MailScanner pour des virus ou des polluriels et rien de suspect n'a ?t? trouv?. CRI UPVD http://www.univ-perp.fr References 1. 3D"mailto:s4mmael@gmail.com" 2. 3D"mailto:freebsd-performance@fr 3. 3D"http://lists.freebsd.org/mailman 4. 3D"mailto:freebsd-performance-un 5. 3D"http://www.mailscanner.info/" From bruce at cran.org.uk Wed Sep 30 13:27:22 2009 From: bruce at cran.org.uk (Bruce Cran) Date: Wed Sep 30 16:57:10 2009 Subject: SATA is to slow comparing with linux In-Reply-To: <1254304611.2268.962.camel@balrog.2hip.net> References: <20090930060202.45527.qmail@avocado.salatschuessel.net> <200909301646.35019.doconnor@gsoft.com.au> <20090930075357.49914.qmail@avocado.salatschuessel.net> <1254304611.2268.962.camel@balrog.2hip.net> Message-ID: <20090930141036.0000184b@unknown> On Wed, 30 Sep 2009 04:56:51 -0500 Robert Noland wrote: > On Wed, 2009-09-30 at 09:53 +0200, Oliver Lehmann wrote: > > Daniel O'Connor writes: > > > > > In the end I got a PCI Silicon Image 3114 based controller and it > > > worked fine. > > > > I thought about getting a controller with a SiL-Chil too because > > they are kinda cheap and another system I intend to use with SATA > > harddisks has no SATA on-board. But then I searched through the web > > and read many posts telling me "stay away from Silicon Image > > controllers" so I did as advised.... > > > > I got a Promise SATA300 TX2plus instead. I'll rune some tests with > > later (when I'm back home ;)) > > I would also be curious how that ahci driver from -CURRENT is > performing relative to other implementations. I ran the tiobench test on -CURRENT a few days ago and the ahci driver showed an improvement in latency over the ata driver; I didn't test transfer rates though. -- Bruce From lehmann at ans-netz.de Wed Sep 30 16:47:09 2009 From: lehmann at ans-netz.de (Oliver Lehmann) Date: Wed Sep 30 16:57:24 2009 Subject: SATA is to slow comparing with linux In-Reply-To: <1254304611.2268.962.camel@balrog.2hip.net> References: <20090930060202.45527.qmail@avocado.salatschuessel.net> <200909301646.35019.doconnor@gsoft.com.au> <20090930075357.49914.qmail@avocado.salatschuessel.net> <1254304611.2268.962.camel@balrog.2hip.net> Message-ID: <20090930184707.26203403.lehmann@ans-netz.de> Robert Noland wrote: > I would also be curious how that ahci driver from -CURRENT is performing > relative to other implementations. I tried 8.0-RC1-i386.iso but the ahci driver didn't picked up my promise nor my VIA controller. So all the numbers now for the "old" ata driver. CPU: AMD Athlon(tm) 64 Processor 3500+ (2200.10-MHz K8-class CPU) usable memory = 2138615808 (2039 MB) atapci0: ad4: 953869MB at ata2-master SATA300 atapci1: ad10: 953869MB at ata5-master SATA150 A simple "dd if=/dev/zero of=/mntpoint/test.dd bs=1M count=4069" showed: FreeBSD 8.0-RC1-i386 (LiveCD) Promise: 42 MB/sec VIA: 43 MB/sec FreeBSD 7.2-STABLE-amd64 Promise: 39 MB/sec VIA: 40 MB/sec Knoppix Linux 2.6 (LiveCD) Promise: 52 MB/sec VIA: 57 MB/sec I only have bonnie results for Knoppix (where installing aplications works) and FreeBSD 7.2 since 8.0 was a LiveCD... FreeBSD 7.2-STABLE-amd64 Promise: Version 1.96 ------Sequential Output------ --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP kartoffel.salats 4G 588 99 41062 5 17618 2 1150 97 47672 3 201.2 2 Latency 26548us 72687us 1032ms 31840us 75449us 2497ms Version 1.96 ------Sequential Create------ --------Random Create-------- kartoffel.salatschu -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 956 1 +++++ +++ 1921 2 1022 1 +++++ +++ 1800 2 Latency 32679us 73us 56709us 41386us 154us 3340us FreeBSD 7.2-STABLE-i386 VIA: Version 1.96 ------Sequential Output------ --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP kartoffel.salats 4G 507 99 41771 5 18176 2 1031 96 47754 4 204.7 2 Latency 27839us 92373us 1027ms 59450us 75962us 192ms Version 1.96 ------Sequential Create------ --------Random Create-------- kartoffel.salatschu -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 1006 1 +++++ +++ 1937 2 1029 1 +++++ +++ 1908 3 Latency 38776us 97us 77620us 39084us 60us 3998us Knoppix Linux 2.6 (LiveCD) Promise: Version 1.96 ------Sequential Output------ --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP Microknoppix 4G 337 99 49887 15 30244 8 940 97 80670 10 213.8 3 Latency 32400us 1258ms 1080ms 60634us 35019us 317ms Version 1.96 ------Sequential Create------ --------Random Create-------- Microknoppix -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 24364 46 +++++ +++ +++++ +++ 29360 56 +++++ +++ 30707 50 Latency 31943us 33392us 33427us 18530us 33391us 33425us Knoppix Linux 2.6 (LiveCD) VIA: Version 1.96 ------Sequential Output------ --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP Microknoppix 4G 355 99 55556 16 31982 8 1098 97 80977 10 215.4 2 Latency 25281us 1307ms 703ms 37743us 30772us 299ms Version 1.96 ------Sequential Create------ --------Random Create-------- Microknoppix -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 14013 27 +++++ +++ +++++ +++ 31883 60 +++++ +++ +++++ +++ Latency 36642us 2973us 30053us 12843us 30014us 30030us As you can see linux has a much higher data transfer rate on both controller than FreeBSD offers. Any sugestions? -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From ohartman at mail.zedat.fu-berlin.de Wed Sep 30 18:00:23 2009 From: ohartman at mail.zedat.fu-berlin.de (O. Hartmann) Date: Wed Sep 30 19:51:53 2009 Subject: FreeBSD vs Ubuntu - Discuss... In-Reply-To: <4AC37945.3070703@wanadoo.fr> References: <200909290226.CAA28246@sopwith.solgatos.com> <689d500ec8c95542a53440b8a23ae773@mail.liquidphlux.com> <6e38aed80909300449h61d671a3i2281eb875f649eb6@mail.gmail.com> <6e38aed80909300449p24928d25v2a34d24f309fa808@mail.gmail.com> <4AC37945.3070703@wanadoo.fr> Message-ID: <4AC39CB4.9050600@mail.zedat.fu-berlin.de> Martin MATO wrote: > Istv?n a ?crit : > > have you seen the previous mail about 8.0 and debug stuff? > > you might have overlooked it. > > yes UFS is not the fastest, it is FAT16, stick to that :) > > On Wed, Sep 30, 2009 at 12:49 PM, S4mmael [1] wrote: > > > > Since the article says that they left the debugging features on I think > this has a bit to do with it. Obviously the testers didn't care to read That's possibly true, but the huge difference in threaded I/O and memory copy can't be explained by simply leaving debug switches to ON. > > > the > > > documentation, and didn't seem to care to use the same compiler which is > available in ports, I believe it is safe to chuck this lame benchmark. > > > What about FreeBSD 7.2? All debug featureas are 100% off in this > version, but test results are the same as in 8.0 > Besides, UFS is known to be not the fastest FS. So, there is no reason > to be suprised. UFS2 has its benefits, even over ZFS (less memory, speed in some cases). From lehmann at ans-netz.de Wed Sep 30 18:05:34 2009 From: lehmann at ans-netz.de (Oliver Lehmann) Date: Wed Sep 30 19:52:05 2009 Subject: SATA is to slow comparing with linux In-Reply-To: <4AC39B2A.4090900@icyb.net.ua> References: <20090930060202.45527.qmail@avocado.salatschuessel.net> <200909301646.35019.doconnor@gsoft.com.au> <20090930075357.49914.qmail@avocado.salatschuessel.net> <1254304611.2268.962.camel@balrog.2hip.net> <20090930184707.26203403.lehmann@ans-netz.de> <4AC39B2A.4090900@icyb.net.ua> Message-ID: <20090930200532.ba171eee.lehmann@ans-netz.de> Andriy Gapon wrote: > What mode do you have set for your controllers in BIOS? > AHCI or IDE/Legacy/etc? Yeah I read about this too but my BIOS offers only "RAID" and "SATA" - tried both so I think AHCI is just not supported on my K8T800Pro chipset for the SATA controller. -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From avg at icyb.net.ua Wed Sep 30 18:06:38 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Wed Sep 30 19:52:18 2009 Subject: SATA is to slow comparing with linux In-Reply-To: <20090930184707.26203403.lehmann@ans-netz.de> References: <20090930060202.45527.qmail@avocado.salatschuessel.net> <200909301646.35019.doconnor@gsoft.com.au> <20090930075357.49914.qmail@avocado.salatschuessel.net> <1254304611.2268.962.camel@balrog.2hip.net> <20090930184707.26203403.lehmann@ans-netz.de> Message-ID: <4AC39B2A.4090900@icyb.net.ua> on 30/09/2009 19:47 Oliver Lehmann said the following: > Robert Noland wrote: > >> I would also be curious how that ahci driver from -CURRENT is performing >> relative to other implementations. > > I tried 8.0-RC1-i386.iso but the ahci driver didn't picked up my promise > nor my VIA controller. So all the numbers now for the "old" ata driver. What mode do you have set for your controllers in BIOS? AHCI or IDE/Legacy/etc? -- Andriy Gapon From vilmos.gyorgy at gmail.com Wed Sep 30 18:06:50 2009 From: vilmos.gyorgy at gmail.com (=?ISO-8859-1?Q?Gy=F6rgy_Vilmos?=) Date: Wed Sep 30 19:52:33 2009 Subject: Performance evaluation of PostgreSQL's historic releases In-Reply-To: <3bbf2fe10909290811p6ac49f7fxaf7e7d4bf631da4c@mail.gmail.com> References: <3bbf2fe10909290811p6ac49f7fxaf7e7d4bf631da4c@mail.gmail.com> Message-ID: Hi, 2009/9/29 Attilio Rao > 2009/9/29 Gy?rgy Vilmos : > > Hi, > > > > I've done a benchmark of recent versions of PostgreSQL's last five major > > releases to see how performance has changed during the past years from > > version to version. > > You can find the article here: > > http://suckit.blog.hu/2009/09/26/postgresql_history > > > > The tests were conducted on FreeBSD 8/amd64 on a midrange x86 server (4 > > CPUs, 24 cores, 128GiB RAM). > > Do you have informations about the systime when doing such tests? > I haven't got enough time to do the measurement right, so I could not log that. But according to top there were idle times. BTW, even on one thread, Linux (2.6.31) performs much better, better means here 790 TPS vs. 580... -- http://suckit.blog.hu/ From vilmos.gyorgy at gmail.com Wed Sep 30 18:09:50 2009 From: vilmos.gyorgy at gmail.com (=?ISO-8859-1?Q?Gy=F6rgy_Vilmos?=) Date: Wed Sep 30 19:52:52 2009 Subject: Performance evaluation of PostgreSQL's historic releases In-Reply-To: References: Message-ID: 2009/9/29 Francisco Reyes > Gy?rgy Vilmos writes: > > I've done a benchmark of recent versions of PostgreSQL's last five major >> releases to see how performance has changed during the past years from >> version to version. >> > > Thanks! > Very interesting. > Did you share it with the Postgresql list yet? > I think they would find it very interesting. > > Any plans on doing simmilar tests with data that does not fit in memory? > Also could you share what settings were used for postgres? Where any > defaults changed? Effective memory, shared_buffers, etc... any of them > adjusted for the machine's memory? > I've updated the article with the used config. With this machine everything would fit in memory (72G disk versus 128 G RAM :). Of course I could artificially limit it... -- http://suckit.blog.hu/ From ertr1013 at student.uu.se Wed Sep 30 19:53:40 2009 From: ertr1013 at student.uu.se (Erik Trulsson) Date: Wed Sep 30 20:02:25 2009 Subject: SATA is to slow comparing with linux In-Reply-To: <20090930200532.ba171eee.lehmann@ans-netz.de> References: <20090930060202.45527.qmail@avocado.salatschuessel.net> <200909301646.35019.doconnor@gsoft.com.au> <20090930075357.49914.qmail@avocado.salatschuessel.net> <1254304611.2268.962.camel@balrog.2hip.net> <20090930184707.26203403.lehmann@ans-netz.de> <4AC39B2A.4090900@icyb.net.ua> <20090930200532.ba171eee.lehmann@ans-netz.de> Message-ID: <20090930193827.GA95011@owl.midgard.homeip.net> On Wed, Sep 30, 2009 at 08:05:32PM +0200, Oliver Lehmann wrote: > Andriy Gapon wrote: > > > What mode do you have set for your controllers in BIOS? > > AHCI or IDE/Legacy/etc? > > Yeah I read about this too but my BIOS offers only "RAID" and "SATA" - > tried both so I think AHCI is just not supported on my K8T800Pro chipset > for the SATA controller. No, AHCI isn't supported there. The VIA K8T800Pro chipset was one of the earlier chipsets with built-in support for SATA, and back then AHCI had not been defined yet. There are many other SATA controllers which also do not support AHCI. -- Erik Trulsson ertr1013@student.uu.se From ohartman at mail.zedat.fu-berlin.de Wed Sep 30 22:36:48 2009 From: ohartman at mail.zedat.fu-berlin.de (O. Hartmann) Date: Wed Sep 30 23:04:37 2009 Subject: SATA is to slow comparing with linux In-Reply-To: <20090930193827.GA95011@owl.midgard.homeip.net> References: <20090930060202.45527.qmail@avocado.salatschuessel.net> <200909301646.35019.doconnor@gsoft.com.au> <20090930075357.49914.qmail@avocado.salatschuessel.net> <1254304611.2268.962.camel@balrog.2hip.net> <20090930184707.26203403.lehmann@ans-netz.de> <4AC39B2A.4090900@icyb.net.ua> <20090930200532.ba171eee.lehmann@ans-netz.de> <20090930193827.GA95011@owl.midgard.homeip.net> Message-ID: <4AC3DD7D.2000507@mail.zedat.fu-berlin.de> Erik Trulsson wrote: > On Wed, Sep 30, 2009 at 08:05:32PM +0200, Oliver Lehmann wrote: >> Andriy Gapon wrote: >> >>> What mode do you have set for your controllers in BIOS? >>> AHCI or IDE/Legacy/etc? >> Yeah I read about this too but my BIOS offers only "RAID" and "SATA" - >> tried both so I think AHCI is just not supported on my K8T800Pro chipset >> for the SATA controller. > > No, AHCI isn't supported there. The VIA K8T800Pro chipset was one of the > earlier chipsets with built-in support for SATA, and back then AHCI had not > been defined yet. There are many other SATA controllers which also do not > support AHCI. ... as the nVidia nForce4/32 (CK804) on many Socket S939-boards for AMD Athlon64 or singlesocket Opterons. Regards, Oliver