Okay, I just did my write tests. You may be a bit supprised at my results. I know I was. :/
Upgraded to samba 2.2.8 custom build Used speedtest.tar.bz2. Changed to socket options = TCP_NODELAY SO_RCVBUF=32768 SO_SNDBUF=32768 3/21/03 /dev/hdc nyonker 1972.375 287 412.34 6.87 Used speedtest.tar.bz2. Changed to socket options = TCP_NODELAY SO_RCVBUF=32768 SO_SNDBUF=32768 3/22/03 nyonker /dev/hdc 1972.375 272 435.08 7.25 Used speedtest directory. Changed to socket options = TCP_NODELAY SO_RCVBUF=32768 SO_SNDBUF=32768 3/22/03 /dev/hdc nyonker 2,026 290 419.13 6.99 Used speedtest directory. Changed to socket options = TCP_NODELAY SO_RCVBUF=32768 SO_SNDBUF=32768 3/22/03 nyonker /dev/hdc 2,026 294 413.42 6.89 The speedtest directory has 416 files in 29 directories. According to these results, I'm getting the same performance on reads AND writes. Combine this with the data I got from upgrading my CPU and switching to 2.2.8 leaves me with only one conclusion: I am getting the maximum speed I can over a 100Mb network (switched)... That means SMB incurs an almost 30% performance hit as compared to FTP. The only real way for me to make sure though is to go to gigabit. It's not that important to me right now. If anyone else has numbers to compare, I would be glad to see them. Has anyone gotten better than 7.5MB/sec over 100BT using Samba? > Samba does have some overhead above and beyond FTP. This is > something that I believe I read is being worked on for the next major > release of Samba. Of course, the transfer rate isn't incredibly bad, > comparison to running a Windows fileserver. On the exact same hardware, > Samba actually reads and writes files faster then our old Windows NT 4.0 > Install did. > > I would HIGHLY recommend staying away from ext2fs, unless you > are running a very good/long lasting UPS and also have redundant power > supplies. Otherwise all you would need is one crash and then bang, you > will either be stuck with a looooong fsck that may require you to > manually rebuild inodes. Sure performance could be better without > journaling, but I would sacrifice performance EVERYTIME if I got better > reliability, quicker recoveries and fewer potential data loss events. > > Regards, > Robert Adkins II > IT Manager/Buyer > Impel Industries, Inc. > 586-254-5800 > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Me > Sent: Saturday, March 22, 2003 8:07 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: Ext3fs/ReiserFS Performance Enhancing > > Have you posted this information on the Samba list? > > I've currently got a thread going where I have posted benchmark results > after making various changes. > > So far I have been concentrating on read performance but I'll start > getting some write benchmarks today. > > I'm currently using ext3. I got a test hard drive that I'll be trying > XFS > and riserfs on. I really have no idea why I can't get better read > performance. I'm stuck at 7-7.5MB/sec. I find it really hard to > believe > that the protocal has that kind of overhead. I can currently get > 10.5MB/sec when transfering the same info using FTP... > > Do you have any results to share? > >> Hello All, >> >> I have been doing some research to find a method to increase the >> performance of writes to the hard drives in my servers. I am running >> Samba and all writes to the server hard drives are taking at least 3 > to >> 10 times (It varies) the amount of time it took to write such files on >> our older Windows NT 4.0 File Server. >> >> The following information is provided to keep this issue on >> track... >> >> It is not a NIC or network issue. Reads of files from those >> drives take place almost instantly. I have been able to copy an entire >> 700MB CD-ROM ISO image off of the server in less then 3 minutes, yet >> writing a 5 MB file to the server will take approximately the 3 > minutes, >> or more. I have also optimized the smb.conf file as best as it can be. >> This resulted in a gain of approximately 15 seconds. >> >> This happens regardless of how busy the server is in serving >> files to other users as I have tested this while all PCs were in use > on >> the network and also when none were in use. >> >> In some of my searching, I have read that ReiserFS has faster >> write performance then Ext3FS. So, I blew away the "share" partition > on >> our test server, recreated that with ReiserFS and rebuilt the share. > So >> far, I have only seen a few seconds of speed increase. (The other odd >> thing is that the Windows Explorer file copy progress bar is much more >> consistent to the ReiserFS share then the ext3fs share.) >> >> I have a few ideas about why there is a slowdown and a few ideas >> of what could possibly increase performance. However, I am at a loss > as >> to how to implement those changes or how to verify that they are even >> possible. (Except by asking this list.) >> >> My Google searches have come up dry with actual methods (ie. >> Commands to look at or actually use.) to implement some performance >> enhancements. All they say are things like, change ext3fs's method of >> writing the journal from the stock "conservative" method to the much >> faster, yet slightly dangerous, method. There is just no mention of > how >> that is done. I have read through the man pages and there is nothing >> that leaps out and says, "This is the command that alters the ext3fs >> journal method." >> >> From what I read, so far, about the two journaling methods it is >> a VERY acceptable risk for the potential performance increase. (It is >> even more acceptable if it can be setup only to affect the share >> partition, which is also its own separate drive.) >> >> There are a few other ideas that I have, but after thinking >> those over, they would likely be far more of a hassle then they would > be >> worth. >> >> Are there any suggestions for increasing HD Write performance, >> while still using a journaling FS? At this time, I do not have the >> resources and additional funds to rebuild the hard drives using XFS or >> JFS. So, it has to be ReiserFS or ext3fs. >> >> Thanks for any assistance! >> >> Regards, >> Robert Adkins II >> IT Manager/Buyer >> Impel Industries, Inc. >> 586-254-5800 >> >> >> >> >> -- >> redhat-list mailing list >> unsubscribe mailto:[EMAIL PROTECTED] >> https://listman.redhat.com/mailman/listinfo/redhat-list > > > > > > -- > redhat-list mailing list > unsubscribe mailto:[EMAIL PROTECTED] > https://listman.redhat.com/mailman/listinfo/redhat-list -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/redhat-list
