Re: 4.4 Samba write performance
Whyzzi wrote: Answers to your questions are inline /w the question 2008/11/18 tico [EMAIL PROTECTED]: 1. Why is this sent to the ports@ mailing list ? I've lurked the list for a long time - since around 2.8. I've asked the odd question here and/or there, and got flamed once when I asked about a question in misc about a port and was subsequently corrected. Since the main topic is about using samba it belongs in ports. See ports general interest list comment @ http://www.openbsd.org/mail.html Perhaps I should have phrased my comment better, or possibly I'm wrong altogether, but I don't see where you showed that the problem was with *Samba* throughput (which would obviously be directed to ports@ or even [EMAIL PROTECTED] as you state) versus hardware/OS/configuration. What network throughput can your system handle? What disk I/O throughput can your system handle? What network and disk throughput can your clients handle? 2. What performance comparison is showing you that the write throughput that you *are* achieving is bad? The beginning of email before I *tweaked* (which I didn't want to do) 170meg copy was really slow. So I tossed in the aforementioned crap based on an internet search that didn't really have a satisfactory discussion on the subject - just things to try. What consistently slow speed did you get on average running a specific test, and what better speed did you get running the exact same test after changing each setting one-by-one ? I have much nicer systems on nicer 100Mbit managed switches that individual Windows clients are not able to drive at higher than 9MB/sec ~= 72Mbits. If you're ranging from 4-12MBytes/sec, those are good real-world numbers. One of these days I should learn how to apply the math I learned. I still am not good at math problems like this one. Thus I still have no idea what I should be expecting - and I guess that was the real problem. Last time I had my little home network file storage served by OpenBSD (by nearly the same hardware, by the way) it just *felt* faster. My previous install still does feel faster. This post is a result of that. Find a way to test and measure those things that feel faster. Technical people can sometimes help with technical issues when given the appropriate level of detail, but only therapists and priests will help you with your feelings. 3. If you want to test out your problem, why haven't you tested out the network throughput capability of your system/network, separately from the disk I/O capability? /dev/null and /dev/zero exist. use them. Didn't think of it. But then didn't suspect it to begin with. See the rest in answer the answer to #4. Certainly something to try. There are gazillions of messages out there describing ways to test the throughput of a network, of a disk subsystem, of various daemons serving data, et cetera. Only you have access to your hardware, so only you will be able to isolate where a problem, if it exists, is located. And only you will be able to retrieve a sufficient amount of technical detail about that specific problem to make it remotely possible that someone else can or will help you fix it. 4. Why are you trying to tweak the TCP stack of your system, if you don't know what each piece does, whether or not it's a bottleneck, and what the trade-offs are from adjusting it? There is no kern.system.go.faster=true option for a reason. I know. Hence this conversation. I've got no peer in all of the technologists that I know to learn from @ the moment. Read mailing list archives and documentation. I don't have tons of friends that are more technical than me to learn from either, but I read and practice and test. I have systems that serve 100's of megs of data where multiple NICs are sharing the same IRQ. Don't drink the kool-aid that you find on random forums. Only attempt to optimize what you can establish is *actually* a problem. Do you want to see one of my client's fileserver systems that serves data faster than the Windows clients can eat it? You bet, and thanks for including it! You'll notice, hopefully, that there are no tweaks added to any relevant conf file, because the defaults just plain work, and I've not been able to show a bottleneck in real-world performance that is solvable through hackery ... and most importantly, the customer is happy and I don't have to write even more documentation for the next sysadmin that walks through the door. --- from a stock smb.conf: [global] workgroup = BHD server string = Samba Server passdb backend = tdbsam log file = /var/log/smbd.%m max log size = 50 os level = 33 preferred master = Yes domain master = Yes dns proxy = No wins support = Yes hosts allow = 192.168.1., 192.168.0., 127. -- # uname -m -r -v 4.4 GENERIC#1915 amd64 # grep -v ^# /etc/sysctl.conf
Re: 4.4 Samba write performance
Answers to your questions are inline /w the question 2008/11/18 tico [EMAIL PROTECTED]: 1. Why is this sent to the ports@ mailing list ? I've lurked the list for a long time - since around 2.8. I've asked the odd question here and/or there, and got flamed once when I asked about a question in misc about a port and was subsequently corrected. Since the main topic is about using samba it belongs in ports. See ports general interest list comment @ http://www.openbsd.org/mail.html 2. What performance comparison is showing you that the write throughput that you *are* achieving is bad? The beginning of email before I *tweaked* (which I didn't want to do) 170meg copy was really slow. So I tossed in the aforementioned crap based on an internet search that didn't really have a satisfactory discussion on the subject - just things to try. I have much nicer systems on nicer 100Mbit managed switches that individual Windows clients are not able to drive at higher than 9MB/sec ~= 72Mbits. If you're ranging from 4-12MBytes/sec, those are good real-world numbers. One of these days I should learn how to apply the math I learned. I still am not good at math problems like this one. Thus I still have no idea what I should be expecting - and I guess that was the real problem. Last time I had my little home network file storage served by OpenBSD (by nearly the same hardware, by the way) it just *felt* faster. My previous install still does feel faster. This post is a result of that. 3. If you want to test out your problem, why haven't you tested out the network throughput capability of your system/network, separately from the disk I/O capability? /dev/null and /dev/zero exist. use them. Didn't think of it. But then didn't suspect it to begin with. See the rest in answer the answer to #4. Certainly something to try. 4. Why are you trying to tweak the TCP stack of your system, if you don't know what each piece does, whether or not it's a bottleneck, and what the trade-offs are from adjusting it? There is no kern.system.go.faster=true option for a reason. I know. Hence this conversation. I've got no peer in all of the technologists that I know to learn from @ the moment. Premature optimization is the root of all evil -- Knuth Are you sure that PCI cards sharing the same IRQ is a performance problem? No, but I wanted to point it out - because being more of a hardware guy I've seen the cause of problems from it before. Though much less prevalent these days. I have systems that serve 100's of megs of data where multiple NICs are sharing the same IRQ. Don't drink the kool-aid that you find on random forums. Only attempt to optimize what you can establish is *actually* a problem. Do you want to see one of my client's fileserver systems that serves data faster than the Windows clients can eat it? You bet, and thanks for including it! --- from a stock smb.conf: [global] workgroup = BHD server string = Samba Server passdb backend = tdbsam log file = /var/log/smbd.%m max log size = 50 os level = 33 preferred master = Yes domain master = Yes dns proxy = No wins support = Yes hosts allow = 192.168.1., 192.168.0., 127. -- # uname -m -r -v 4.4 GENERIC#1915 amd64 # grep -v ^# /etc/sysctl.conf net.inet.ip.forwarding=1# 1=Permit forwarding (routing) of IPv4 packets # em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr 00:30:48:9a:17:34 description: internal net (VLAN100 untagged) media: Ethernet autoselect (100baseTX full-duplex) status: active inet6 fe80::230:48ff:fe9a:1734%em0 prefixlen 64 scopeid 0x1 inet 192.168.0.252 netmask 0xff00 broadcast 192.168.0.255 I'm running a single RAID1 volume (should be slower than your single disk) Actually I disagree. You've got hardware RAID (a host processor to handle and optimize the duplication of data without bothering the rest of the computer) /w a large cache. I've got an add-in 32bit pci card 32M cache on the drive. on a pair of SATA drives on an Areca controller: arc0 at pci2 dev 14 function 0 Areca ARC-1210 rev 0x00: irq 5 arc0: 4 ports, 256MB SDRAM, firmware V1.43 2007-4-17 scsibus0 at arc0: 16 targets, initiator 16 sd0 at scsibus0 targ 0 lun 0: Areca, firstRAID1volume, R001 SCSI3 0/direct fix ed sd0: 715255MB, 512 bytes/sec, 1464843264 sec total no exotic filesystem mounts either: /dev/sd0j on /home/art type ffs (local, noatime, nodev, nosuid, softdep) /dev/sd0e on /home type ffs (local, noatime, nodev, nosuid, softdep) /dev/sd0k on /home/sandbox type ffs (local, noatime, nodev, nosuid, softdep) If it ain't broke, don't fix^H^H^H break it. ::yawn:: -Tico !- snip original message -!
