Re: 7.2-p7 -> 8-STABLE mergemaster core dump
> Can others with remote systems comment about what they do in this step? installkernel, reboot, installworld, mergemaster, reboot. *But* - for remote systems I never make huge leaps. I would certainly never upgrade across a major version like you are doing. Fpr those upgrades (which are only once per yer maximum) I make the effort to go down there and do it physically in front of the machine. Within a single major release, however, I have never had any problems with the above prcedure. -pete. ___ 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: Freeze on closing terminal that runs wpa_supplicant
On 3/17/10, Mathias Sogorski wrote: > Hello! > I am running 8.0-RELEASE on a notebook with the Intel 3945 WiFi. I usually > start wpa_supplicant [...]& on a terminal when entering gnome followed by > the dhcpcd call to use the WiFi connection. After having finished work and > closing the terminal that runs wpa_supplicant, everything freezes and I have > to turn the power off. Any suggestions? That should not happen. So report the bug. You managed to get backtrace? Did kernel actually crashed? ___ 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"
TSO and pf(4) reply-to/route-to combination problem
Hello, Could anyone who knows the TCP/IP stack well please review kern/144311? In summary, on a multi-homed server I have a trouble when using pf(4) 'reply-to' to return reply packets of incoming TCP connections to the incoming interface. When TSO is enabled on the interface which is used for the default route, redirecting packets to other interfaces using 'reply-to'(or 'route-to') causes massive 'ICMP unreachable - need to frag' storm on lo0 (up to 10Mbytes/sec on my server). The problem doesn't happen when TSO is disabled on the default NIC. I reproduced the problem on msk(4) and em(4), so I guess it is not device specific. http://www.freebsd.org/cgi/query-pr.cgi?pr=144311 Regards, -- Yoshiaki Kasahara Research Institute for Information Technology, Kyushu University kasah...@nc.kyushu-u.ac.jp ___ 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"
wpi0 stability and acpi_hp problems
I'm running RELENG_8 (built yesterday) and have encountered problems with wpi and acpi_hp. The thing about acpi_hp is that it misses most of the hardware when activated in the loader.conf. The WLAN, BT and other sysctls are only available if I load the module after boot. My wpi problems are more severe. I recently purchased a new battery for my notebook and to improve my battery uptime I deactivated the bluetooth device in the BIOS (HP6510b). Ever since the wlan connection is less reliable. The device tends to spontaneously turn itself off. I also occasionally see: wpi0: could not configure bluetooth coexistence The last time this happended (~2 hours ago) I went to the first console to witness the dmesg events. I pressed the WLAN switch, the dmesg showed a radion on message, then the system paniced. Unfortunately it didn't create a dump, probably because I've got 8gb RAM and only 4gb of swap space, though with the new minidumps that shouldn't really be a problem, I think. Anyway, I at least copied the screen output on a sheet of paper and will provide it tonight (I'm on a train at the moment, typing it now is too inconvenient). Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ 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: Strange problem: if_xe only works in GENERIC kernel
On Thursday 18 March 2010 3:27:58 pm Joerg Wunsch wrote: > I'm running into a strange problem with 8-current (or 8.0-RELEASE) on > an elderly Thinkpad 600E. > > As long as I'm using the GENERIC kernel, an Intel Etherexpress PC card > works as expected: > > interrupt storm detected on "irq11:"; throttling interrupt source > xe0: at port 0x100-0x10f iomem 0x2000-0x2fff irq 11 function 0 config 1 on pccard1 > xe0: version 0x45/0x04, 100Mbps capable > xe0: Ethernet address: 00:a0:c9:bc:b5:ef > xe0: [ITHREAD] > > However, as soon as I start removing unneeded stuff from the kernel > config file, the driver completely jams. It just sits there, the > machine blocks, until I eventually pop out the card, when I get the > following messages: > > cbb1: ready never happened, status = 00 > xe0: at port 0x100-0x10f iomem 0x2000-0x2fff irq 11 function 0 config 1 on pccard1 > xe0: version 0xff/0x07, 100Mbps capable > xe0: Ethernet address: 00:a0:c9:bc:b5:ef > xe0: [ITHREAD] > xe0: detached > cbb1: Bad Vcc requested > > As the CPU is a little slow, recompiling kernels takes an eternity on > it (even with NO_KERNELCLEAN), so I could not isolate it to a single > line in the config file so far. Sounds like the process of removing things prevented the interrupt storm from being throttled somehow, and that ejecting the card caused the interrupt storm to finally stop at which point the card was probed. I would talk to Warner (imp@) about trying to fix the interrupt storm. Also, if you could narrow down which particular item that you trim "breaks" it, that would be helpful. -- 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: Strange problem: if_xe only works in GENERIC kernel
In message: <201003190837.48346@freebsd.org> John Baldwin writes: : On Thursday 18 March 2010 3:27:58 pm Joerg Wunsch wrote: : > I'm running into a strange problem with 8-current (or 8.0-RELEASE) on : > an elderly Thinkpad 600E. : > : > As long as I'm using the GENERIC kernel, an Intel Etherexpress PC card : > works as expected: : > : > interrupt storm detected on "irq11:"; throttling interrupt source : > xe0: at port : 0x100-0x10f iomem 0x2000-0x2fff irq 11 function 0 config 1 on pccard1 : > xe0: version 0x45/0x04, 100Mbps capable : > xe0: Ethernet address: 00:a0:c9:bc:b5:ef : > xe0: [ITHREAD] : > : > However, as soon as I start removing unneeded stuff from the kernel : > config file, the driver completely jams. It just sits there, the : > machine blocks, until I eventually pop out the card, when I get the : > following messages: : > : > cbb1: ready never happened, status = 00 : > xe0: at port : 0x100-0x10f iomem 0x2000-0x2fff irq 11 function 0 config 1 on pccard1 : > xe0: version 0xff/0x07, 100Mbps capable : > xe0: Ethernet address: 00:a0:c9:bc:b5:ef : > xe0: [ITHREAD] : > xe0: detached : > cbb1: Bad Vcc requested : > : > As the CPU is a little slow, recompiling kernels takes an eternity on : > it (even with NO_KERNELCLEAN), so I could not isolate it to a single : > line in the config file so far. : : Sounds like the process of removing things prevented the interrupt storm from : being throttled somehow, and that ejecting the card caused the interrupt storm : to finally stop at which point the card was probed. I would talk to Warner : (imp@) about trying to fix the interrupt storm. Also, if you could narrow : down which particular item that you trim "breaks" it, that would be helpful. Yes. Do other cards cause this same problem? The cbb1: Bad Vcc is a big clue something is going wrong with the bridge, not the card. Warner ___ 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: Strange problem: if_xe only works in GENERIC kernel
As M. Warner Losh wrote: > Yes. Do other cards cause this same problem? Nope, but the xe card is the only one I've got that tries to use the memory space. The remaining cards use the ep(4) driver which only uses IO space access. > The cbb1: Bad Vcc is a > big clue something is going wrong with the bridge, not the card. Hmm, I accused that as a side-effect of having the card already pulled by the time it appears to finish probing. Remember, nothing of those messages appears when *inserting* the card, the machine just sits there until I pull it. I've alreay re-introduced the entire bunch of NIC drivers into the config file, which didn't help. Next I'll try either the SCSI or the USB block, don't know yet. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ 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: Strange problem: if_xe only works in GENERIC kernel
As John Baldwin wrote: > Sounds like the process of removing things prevented the interrupt > storm from being throttled somehow, and that ejecting the card > caused the interrupt storm to finally stop at which point the card > was probed. I would talk to Warner (imp@) about trying to fix the > interrupt storm. Also, if you could narrow down which particular > item that you trim "breaks" it, that would be helpful. OK, at kernel #11 :), I can now say it's the USB subsystem. Just leaving "device usb" (and also "device uhci") in makes it work. So the question appears to be why keeping the USB driver in makes the interrupt storm detection work... -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ 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"
Samba read speed performance tuning
On a FreeBSD 8.0-RELEASE/amd64 system with a Supermicro X7SPA-H board using an Intel gigabit nic with the em driver, running on top of a ZFS mirror, I was seeing a strange issue. Local reads and writes to the pool easily saturate the disks with roughly 75mb/s throughput, which is roughly the best these drives can do. However, working with Samba, writes to a share could easily pull off 75mb/s and saturate the disks, but reads off a share were resulting in rather pathetic 18mb/s throughput. I found a threadon the FreeBSD forums (http://forums.freebsd.org/showthread.php?t=9187) and followed the suggested advice. I rebuilt Samba with AIO support, kldloaded the aio module and made the following changes to my smb.conf From: socket options=TCP_NODELAY To: socket options=SO_RCVBUF=131072 SO_SNDBUF=131072 TCP_NODELAY min receivefile size=16384 use sendfile=true aio read size = 16384 aio write size = 16384 aio write behind = true dns proxy = no[/CODE] This showed a very welcome improvement in read speed, I went from 18mb/s to 48mb/s. The write speed remained unchanged and was still saturating the disks. Now I tried the suggested sysctl tunables: atombsd# sysctl net.inet.tcp.delayed_ack=0 net.inet.tcp.delayed_ack: 1 -> 0 atombsd# sysctl net.inet.tcp.path_mtu_discovery=0 net.inet.tcp.path_mtu_discovery: 1 -> 0 atombsd# sysctl net.inet.tcp.recvbuf_inc=524288 net.inet.tcp.recvbuf_inc: 16384 -> 524288 atombsd# sysctl net.inet.tcp.recvbuf_max=16777216 net.inet.tcp.recvbuf_max: 262144 -> 16777216 atombsd# sysctl net.inet.tcp.sendbuf_inc=524288 net.inet.tcp.sendbuf_inc: 8192 -> 524288 atombsd# sysctl net.inet.tcp.sendbuf_max=16777216 net.inet.tcp.sendbuf_max: 262144 -> 16777216 atombsd# sysctl net.inet.tcp.sendspace=65536 net.inet.tcp.sendspace: 32768 -> 65536 atombsd# sysctl net.inet.udp.maxdgram=57344 net.inet.udp.maxdgram: 9216 -> 57344 atombsd# sysctl net.inet.udp.recvspace=65536 net.inet.udp.recvspace: 42080 -> 65536 atombsd# sysctl net.local.stream.recvspace=65536 net.local.stream.recvspace: 8192 -> 65536 atombsd# sysctl net.local.stream.sendspace=65536 net.local.stream.sendspace: 8192 -> 65536 This improved the read speeds a further tiny bit, now I went from 48mb/s to 54mb/s. This is it however, I can't figure out how to increase Samba read speed any further. Any ideas? ___ 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: Does zfs have it's own nfs server?
On 17-3-2010 9:27, Matthias Gamsjager wrote: sharenfs does work in freebsd but iscsi does not. I'm not sure about smb. about nfs: you should take a look at /etc/zfs/exports On Wed, Mar 17, 2010 at 9:15 AM, Harald Schmalzbauer wrote: Hello, I observed some very strange filesystem security problems. Now I found that if I set sharenfs=yes data/pub I can mount_nfs but it does't respect any settings in /etc/exports. Also I get very strange uid numbers when writing. If I turn sharenfs off, limitations in /etc/exports work as expected. I thought sharenfs and sharesmb are only working on OpenSolaris. What about shareiscsi? I do not use /etc/exports for zfs shares But instead of yes as value, you can use the NFS-options as string and that gets it into /etc/zfs/exports. --WjW ___ 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: Does zfs have it's own nfs server?
On Fri, 19 Mar 2010, Willem Jan Withagen wrote: On 17-3-2010 9:27, Matthias Gamsjager wrote: sharenfs does work in freebsd but iscsi does not. I'm not sure about smb. about nfs: you should take a look at /etc/zfs/exports On Wed, Mar 17, 2010 at 9:15 AM, Harald Schmalzbauer wrote: Hello, I observed some very strange filesystem security problems. Now I found that if I set sharenfs=yes data/pub I can mount_nfs but it does't respect any settings in /etc/exports. Also I get very strange uid numbers when writing. If I turn sharenfs off, limitations in /etc/exports work as expected. I thought sharenfs and sharesmb are only working on OpenSolaris. What about shareiscsi? I do not use /etc/exports for zfs shares But instead of yes as value, you can use the NFS-options as string and that gets it into /etc/zfs/exports. Just wondering, is this using the base nfsd/mountd, or is there some in-kernel nfs code strictly for zfs? I haven't found much info on the share* options in the manpage or wiki. Could you give an example of passing options that would say, limit to a subnet and map root to root using the zfs sharenfs command? Thanks, Charles --WjW ___ 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" ___ 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: Does zfs have it's own nfs server?
On Fri, Mar 19, 2010 at 07:50:24PM -0400, Charles Sprickman wrote: > On Fri, 19 Mar 2010, Willem Jan Withagen wrote: > > >On 17-3-2010 9:27, Matthias Gamsjager wrote: > >>sharenfs does work in freebsd but iscsi does not. I'm not sure about smb. > >> > >>about nfs: you should take a look at /etc/zfs/exports > >> > >> > >> > >>On Wed, Mar 17, 2010 at 9:15 AM, Harald Schmalzbauer > >> wrote: > >>>Hello, > >>> > >>>I observed some very strange filesystem security problems. > >>>Now I found that if I set sharenfs=yes data/pub I can mount_nfs but it > >>>does't respect any settings in /etc/exports. Also I get very strange uid > >>>numbers when writing. > >>>If I turn sharenfs off, limitations in /etc/exports work as expected. > >>>I thought sharenfs and sharesmb are only working on > >>>OpenSolaris. What about > >>>shareiscsi? > > > >I do not use /etc/exports for zfs shares > >But instead of yes as value, you can use the NFS-options as string > >and that gets it into /etc/zfs/exports. > > Just wondering, is this using the base nfsd/mountd, or is there some > in-kernel nfs code strictly for zfs? I haven't found much info on > the share* options in the manpage or wiki. ZFS on FreeBSD's "sharenfs" option does nothing more than manage data in a flat file (/etc/zfs/exports) and automatically send a SIGHUP to mountd's pid (based on reading the contents of the file _PATH_MOUNTDPID). If you grep through /usr/src/cddl you can see what I'm referring to. "So how does mountd know about /etc/zfs/exports?" $ ps -auxw | grep mount root 861 0.0 0.0 6836 1716 ?? Is 10Mar10 0:00.00 /usr/sbin/mountd -r -l /etc/exports /etc/zfs/exports This is defined/referenced in /etc/rc.d/mountd. All that said: I avoid use of the "sharenfs" option in ZFS on RELENG_7 and RELENG_8, as I found certain quirks/behavioural oddities (such as mountd not picking up changes, or claims of not exporting something which visually confirmed should have been exported -- and in one case, mounting of a ZFS-exported NFS filesystem worked but then any I/O would block on the client indefinitely. Don't ask me how/why that happened). Possibly these were bugs that existed during ZFS's transitional phase between 7.x and 8.x, but the unreliable nature of the situation left a bad taste in my mouth. The workaround: Using /etc/exports to reference the local ZFS filesystems I want exported, HUP mountd, done. Above oddities/quirks no longer happened. And there's an added bonus: all your exports are therefore kept in one single place: a text file that's existed since what, 1989 or so? Of course, the advantage is that with ZFS properties you can inherit options -- that might be useful to some, but not to me. There's also known quirks/issues with the parsing logic with "sharenfs". This was discussed in December 2009. > Could you give an example of passing options that would say, limit > to a subnet and map root to root using the zfs sharenfs command? zfs create pool/fs zfs set sharenfs="-maproot=blah -network x.x.x.x -mask y.y.y.y" pool/fs Right now I'm more or less "avoiding" NFS as much as possible, as the number of severe/major bug reports on RELENG_8 keep coming in, and that scares me greatly. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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: Samba read speed performance tuning
On Fri, Mar 19, 2010 at 11:14 PM, Dan Naumov wrote: > On a FreeBSD 8.0-RELEASE/amd64 system with a Supermicro X7SPA-H board > using an Intel gigabit nic with the em driver, running on top of a ZFS > mirror, I was seeing a strange issue. Local reads and writes to the > pool easily saturate the disks with roughly 75mb/s throughput, which > is roughly the best these drives can do. However, working with Samba, > writes to a share could easily pull off 75mb/s and saturate the disks, > but reads off a share were resulting in rather pathetic 18mb/s > throughput. > > I found a threadon the FreeBSD forums > (http://forums.freebsd.org/showthread.php?t=9187) and followed the > suggested advice. I rebuilt Samba with AIO support, kldloaded the aio > module and made the following changes to my smb.conf > > From: > socket options=TCP_NODELAY > > To: > socket options=SO_RCVBUF=131072 SO_SNDBUF=131072 TCP_NODELAY > min receivefile size=16384 > use sendfile=true > aio read size = 16384 > aio write size = 16384 > aio write behind = true > dns proxy = no[/CODE] > > This showed a very welcome improvement in read speed, I went from > 18mb/s to 48mb/s. The write speed remained unchanged and was still > saturating the disks. Now I tried the suggested sysctl tunables: > > atombsd# sysctl net.inet.tcp.delayed_ack=0 > net.inet.tcp.delayed_ack: 1 -> 0 > > atombsd# sysctl net.inet.tcp.path_mtu_discovery=0 > net.inet.tcp.path_mtu_discovery: 1 -> 0 > > atombsd# sysctl net.inet.tcp.recvbuf_inc=524288 > net.inet.tcp.recvbuf_inc: 16384 -> 524288 > > atombsd# sysctl net.inet.tcp.recvbuf_max=16777216 > net.inet.tcp.recvbuf_max: 262144 -> 16777216 > > atombsd# sysctl net.inet.tcp.sendbuf_inc=524288 > net.inet.tcp.sendbuf_inc: 8192 -> 524288 > > atombsd# sysctl net.inet.tcp.sendbuf_max=16777216 > net.inet.tcp.sendbuf_max: 262144 -> 16777216 > > atombsd# sysctl net.inet.tcp.sendspace=65536 > net.inet.tcp.sendspace: 32768 -> 65536 > > atombsd# sysctl net.inet.udp.maxdgram=57344 > net.inet.udp.maxdgram: 9216 -> 57344 > > atombsd# sysctl net.inet.udp.recvspace=65536 > net.inet.udp.recvspace: 42080 -> 65536 > > atombsd# sysctl net.local.stream.recvspace=65536 > net.local.stream.recvspace: 8192 -> 65536 > > atombsd# sysctl net.local.stream.sendspace=65536 > net.local.stream.sendspace: 8192 -> 65536 > > This improved the read speeds a further tiny bit, now I went from > 48mb/s to 54mb/s. This is it however, I can't figure out how to > increase Samba read speed any further. Any ideas? Oh my god... Why did noone tell me how much of an enormous performance boost vfs.zfs.prefetch_disable=0 (aka actually enabling prefetch) is. My local reads off the mirror pool jumped from 75mb/s to 96mb/s (ie. they are now nearly 25% faster than reading off an individual disk) and reads off a Samba share skyrocketed from 50mb/s to 90mb/s. By default, FreeBSD sets vfs.zfs.prefetch_disable to 1 on any i386 systems and on any amd64 systems with less than 4GB of avaiable memory. My system is amd64 with 4gb ram, but integrated video eats some of that, so the autotuning disabled the prefetch. I had read up on it and a fair amount of people seemed to have performance issues caused by having prefetch enabled and get better results with it turned off, in my case however, it seems that enabling it gave a really solid boost to performance. - Sincerely Dan Naumov ___ 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: Samba read speed performance tuning
It MAY make a big diff, but make sure during your tests you use unique files or flush the cache or you'll me testing cache speed and not disk speed. - Original Message - From: owner-freebsd-questi...@freebsd.org To: freebsd-...@freebsd.org ; freebsd-questi...@freebsd.org ; FreeBSD-STABLE Mailing List ; freebsd-performa...@freebsd.org Sent: Fri Mar 19 20:28:02 2010 Subject: Re: Samba read speed performance tuning On Fri, Mar 19, 2010 at 11:14 PM, Dan Naumov wrote: > On a FreeBSD 8.0-RELEASE/amd64 system with a Supermicro X7SPA-H board > using an Intel gigabit nic with the em driver, running on top of a ZFS > mirror, I was seeing a strange issue. Local reads and writes to the > pool easily saturate the disks with roughly 75mb/s throughput, which > is roughly the best these drives can do. However, working with Samba, > writes to a share could easily pull off 75mb/s and saturate the disks, > but reads off a share were resulting in rather pathetic 18mb/s > throughput. > > I found a threadon the FreeBSD forums > (http://forums.freebsd.org/showthread.php?t=9187) and followed the > suggested advice. I rebuilt Samba with AIO support, kldloaded the aio > module and made the following changes to my smb.conf > > From: > socket options=TCP_NODELAY > > To: > socket options=SO_RCVBUF=131072 SO_SNDBUF=131072 TCP_NODELAY > min receivefile size=16384 > use sendfile=true > aio read size = 16384 > aio write size = 16384 > aio write behind = true > dns proxy = no[/CODE] > > This showed a very welcome improvement in read speed, I went from > 18mb/s to 48mb/s. The write speed remained unchanged and was still > saturating the disks. Now I tried the suggested sysctl tunables: > > atombsd# sysctl net.inet.tcp.delayed_ack=0 > net.inet.tcp.delayed_ack: 1 -> 0 > > atombsd# sysctl net.inet.tcp.path_mtu_discovery=0 > net.inet.tcp.path_mtu_discovery: 1 -> 0 > > atombsd# sysctl net.inet.tcp.recvbuf_inc=524288 > net.inet.tcp.recvbuf_inc: 16384 -> 524288 > > atombsd# sysctl net.inet.tcp.recvbuf_max=16777216 > net.inet.tcp.recvbuf_max: 262144 -> 16777216 > > atombsd# sysctl net.inet.tcp.sendbuf_inc=524288 > net.inet.tcp.sendbuf_inc: 8192 -> 524288 > > atombsd# sysctl net.inet.tcp.sendbuf_max=16777216 > net.inet.tcp.sendbuf_max: 262144 -> 16777216 > > atombsd# sysctl net.inet.tcp.sendspace=65536 > net.inet.tcp.sendspace: 32768 -> 65536 > > atombsd# sysctl net.inet.udp.maxdgram=57344 > net.inet.udp.maxdgram: 9216 -> 57344 > > atombsd# sysctl net.inet.udp.recvspace=65536 > net.inet.udp.recvspace: 42080 -> 65536 > > atombsd# sysctl net.local.stream.recvspace=65536 > net.local.stream.recvspace: 8192 -> 65536 > > atombsd# sysctl net.local.stream.sendspace=65536 > net.local.stream.sendspace: 8192 -> 65536 > > This improved the read speeds a further tiny bit, now I went from > 48mb/s to 54mb/s. This is it however, I can't figure out how to > increase Samba read speed any further. Any ideas? Oh my god... Why did noone tell me how much of an enormous performance boost vfs.zfs.prefetch_disable=0 (aka actually enabling prefetch) is. My local reads off the mirror pool jumped from 75mb/s to 96mb/s (ie. they are now nearly 25% faster than reading off an individual disk) and reads off a Samba share skyrocketed from 50mb/s to 90mb/s. By default, FreeBSD sets vfs.zfs.prefetch_disable to 1 on any i386 systems and on any amd64 systems with less than 4GB of avaiable memory. My system is amd64 with 4gb ram, but integrated video eats some of that, so the autotuning disabled the prefetch. I had read up on it and a fair amount of people seemed to have performance issues caused by having prefetch enabled and get better results with it turned off, in my case however, it seems that enabling it gave a really solid boost to performance. - Sincerely Dan Naumov ___ freebsd-questi...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org" "This email is intended to be reviewed by only the intended recipient and may contain information that is privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any review, use, dissemination, disclosure or copying of this email and its attachments, if any, is strictly prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system." ___ 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: Samba read speed performance tuning
On Fri, Mar 19, 2010 at 8:28 PM, Dan Naumov wrote: > Oh my god... Why did noone tell me how much of an enormous performance > boost vfs.zfs.prefetch_disable=0 (aka actually enabling prefetch) is. > My local reads off the mirror pool jumped from 75mb/s to 96mb/s (ie. > they are now nearly 25% faster than reading off an individual disk) > and reads off a Samba share skyrocketed from 50mb/s to 90mb/s. > > By default, FreeBSD sets vfs.zfs.prefetch_disable to 1 on any i386 > systems and on any amd64 systems with less than 4GB of avaiable > memory. My system is amd64 with 4gb ram, but integrated video eats > some of that, so the autotuning disabled the prefetch. I had read up > on it and a fair amount of people seemed to have performance issues > caused by having prefetch enabled and get better results with it > turned off, in my case however, it seems that enabling it gave a > really solid boost to performance. > My home VBox server is similar specs and I enabled the prefetch from the start. A few days ago, I added an intel SSD as the zpool cache device and the read speed is mind blowing now. This is from inside a VM frunning on it meaning ad0 is really a vdi. Once the cache is populated, HD latency is mostly a thing of the past. # diskinfo -tv /dev/ad0 /dev/ad0 512 # sectorsize 12884901888 # mediasize in bytes (12G) 25165824# mediasize in sectors 24966 # Cylinders according to firmware. 16 # Heads according to firmware. 63 # Sectors according to firmware. VBf9752473-05343e4e # Disk ident. Seek times: Full stroke: 250 iter in 0.082321 sec =0.329 msec Half stroke: 250 iter in 0.078944 sec =0.316 msec Quarter stroke: 500 iter in 0.161266 sec =0.323 msec Short forward:400 iter in 0.128624 sec =0.322 msec Short backward: 400 iter in 0.131770 sec =0.329 msec Seq outer: 2048 iter in 0.667510 sec =0.326 msec Seq inner: 2048 iter in 0.691691 sec =0.338 msec Transfer rates: outside: 102400 kbytes in 0.722864 sec = 141659 kbytes/sec middle:102400 kbytes in 0.813619 sec = 125857 kbytes/sec inside:102400 kbytes in 0.838129 sec = 122177 kbytes/sec -- Adam Vande More ___ 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"
