Re: Low nfs write throughput
On Thursday, December 01, 2011 12:35:23 am Jeremy Chadwick wrote: > On Tue, Nov 29, 2011 at 10:36:44AM -0500, John Baldwin wrote: > > On Monday, November 28, 2011 7:12:39 pm Daryl Sayers wrote: > > > > "Bengt" == Bengt Ahlgren writes: > > > > > > > Daryl Sayers writes: > > > >> Can anyone suggest why I am getting poor write performance from my nfs > > > >> setup. > > > >> I have 2 x FreeBSD 8.2-STABLE i386 machines with ASUS P5B-plus mother > > > >> boards, > > > >> 4G mem and Dual core 3g processor using 147G 15k Seagate SAS drives > > > >> with > > > >> onboard Gb network cards connected to an idle network. The results > > > >> below show > > > >> that I get nearly 100Mb/s with a dd over rsh but only 15Mbs using nfs. > > > >> It > > > >> improves if I use async but a smbfs mount still beats it. I am using > > > >> the same > > > >> file, source and destinations for all tests. I have tried alternate > > > >> Network > > > >> cards with no resulting benefit. > > > > > > > [...] > > > > > > >> Looking at a systat -v on the destination I see that the nfs test does > > > >> not > > > >> exceed 16KB/t with 100% busy where the other tests reach up to 128KB/t. > > > >> For the record I get reads of 22Mb/s without and 77Mb/s with async > > > >> turned on > > > >> for the nfs mount. > > > > > > > On an UFS filesystem you get NFS writes with the same size as the > > > > filesystem blocksize. So an easy way to improve performance is to > > > > create a filesystem with larger blocks. I accidentally found this out > > > > when I had two NFS exported filesystems from the same box with 16K and > > > > 64K blocksizes respectively. > > > > > > > (Larger blocksize also tremendously improves the performance of UFS > > > > snapshots!) > > > > > > Thanks to all that answered. I did try the 'sysctl -w vfs.nfsrv.async=1' > > > with > > > no reportable change in performance. We are using a UFS2 filesystem so the > > > zfs command was not required. I did not try the patch as we would like to > > > stay > > > as standard as possible but will upgrade if the patch is released in new > > > kernel. > > > > If you can test the patch then it is something I will likely put into the > > next release. I have already tested it as far as robustness locally, what > > I don't have are good performance tests. It would really be helpful if you > > were able to test it. > > John, > > We'd like to test this patch[1], but need to know if it needs to be > applied to just the system acting as the NFS server, or the NFS clients > as well. > > [1]: http://www.freebsd.org/~jhb/patches/nfs_server_cluster.patch Just the NFS server. I'm going to commit it to HEAD later today. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Possible: Configure SAS Sun Jbod J4200 ?
On Wed, 30 Nov 2011 15:01:09 +0100, Denny Schierz wrote: hi, we have a Sun Jbod SAS J4200 and actually there is a running daemon under Solaris 10, which is needed, to configure the JBOD over a (badly) Java Sun tool from a other host machine (Windows XP, for example). If I switch from Solaris to FreeBSD, I don't know, if I can view the status and configure from/over FBSD… The Jbod is only connected through the SAS channel, nothing more. :-/ It means, it doest' have any Network/serial access … any suggestions? cu denny___ Can you boot FreeBSD on it and mail a dmesg output to the mailinglist? That gives people a clue about your hardware setup. Ronald. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
FreeNAS to Custom FAMP Server
Hello Everyone!! Server I have: 4 Drives No-RAID - 500GB Each 2GB RAM Dual core Xeon 2.4 GHz I'm looking to make an internal office machine running: - Backup System (Software RAID5 or ZFS) - Apache - MySQL - PHP Traffic is just internal (Website) and a Backup Server Looking to Install Backup Raid (FreeNAS or something else) Install Ports from FreeBSD Port Tree for extra software Reconfigure the Default Apache config for an internal Webserver using MySQL and PHP Looked into install FreeBSD with ( Gvinum and graid) -- 9.0 Gives me error to bootcode On boot to cd went to cd setup drives with gvinum with raid5 and started the gvinum setup Went back to installer again and on the drive setup I used Guided installer and it gives me "bootcode error" My next option I was looking at is installing FreeNAS (But Close to Minimum) Thanks -- Ben Adams http://www.SpryMed.com/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: www/Apache22 fails to build when configured for LDAP and AUTHNZ_LDAP
On Wed, Nov 30, 2011 at 11:41 AM, Mark Saad wrote: > You need to just rebuild the apr port with ldap. Confirm what version > of apr you have installed and then use make config in that port to add > ldap support. Remove the installed port and reinstall the new one with > ldap support . They you should be able to install apache with ldap > hooks. > That did it. I was spending too much energy looking at www/apache22. Thank you, Gentlemen. Regards, Shaun ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Sporadic 9.0-RC2 boot-time panic
On 11/28/11 5:48 PM, Ronald Klop wrote: On Mon, 28 Nov 2011 23:37:27 +0100, Mike Andrews wrote: *Sometimes* when booting 9.0-RC2 on *some* of my machines, I'll get one of the following two panics during multiuser startup, usually while running the /usr/local/etc/rc.d scripts. (The instruction pointer is always exactly one of these two, and they look fairly related.) If after two or three reboots it manages to not panic, the system will run perfectly stable. For some probably-unrelated reason, the dump never finishes in either case. First panic (note em0 warning before it): - em0: discard frame w/o packet header Fatal trap 9: general protection fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x20:0x805e4fc5 stack pointer = 0x28:0xff80003299e0 frame pointer = 0x28:0xff8000329a00 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (irq256: em0:rx 0) trap number = 9 panic: general protection fault cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 panic() at panic+0x187 trap_fatal() at trap_fatal+0x290 trap() at trap+0x10a calltrap() at calltrap+0x8 --- trap 0x9, rip = 0x805e4fc5, rsp = 0xff80003299e0, rbp = 0xff8000329a00 --- m_freem() at m_freem+0x25 ether_nh_input() at ether_nh_input+0x82 netisr_dispatch_src() at netisr_dispatch_src+0x20b em_rxeof() at em_rxeof+0x1ca em_msix_rx() at em_msix_rx+0x24 intr_event_execute_handlers() at intr_event_execute_handlers+0x104 ithread_loop() at ithread_loop+0xa4 fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff8000329d00, rbp = 0 --- Uptime: 49s Dumping 679 out of 12263 MB: - Second panic (no em0 discard warning this time): - Fatal trap 9: general protection fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x20:0x8063c0e4 stack pointer = 0x28:0xff8000329a00 frame pointer = 0x28:0xff8000329a40 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (irq256: em0:rx 0) trap number = 9 panic: general protection fault cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 panic() at panic+0x187 trap_fatal() at trap_fatal+0x290 trap() at trap+0x10a calltrap() at calltrap+0x8 --- trap 0x9, rip = 0x8063c0e4, rsp = 0xff8000329a00, rbp = 0xff8000329a40 --- ether_nh_input() at ether_nh_input+0x94 netisr_dispatch_src() at netisr_dispatch_src+0x20b em_rxeof() at em_rxeof+0x1ca em_msix_rx() at em_msix_rx+0x24 intr_event_execute_handlers() at intr_event_execute_handlers+0x104 ithread_loop() at ithread_loop+0xa4 fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff8000329d00, rbp = 0 --- Uptime: 46s Dumping 657 out of 12263 MB:..3% Does it help if you disable msix on your em0? Google for 'sysctl em msix'. Or run 'sysctl -a | grep msix'. OK, setting hw.em.enable_msix=0 in /boot/loader.conf does NOT help. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
