Date: Fri, 30 Nov 2001 16:58:22 +1030 From: Richard Sharpe <sharpe@ns.aus.com> To: freebsd-hackers@FreeBSD.ORG Subject: A comparison of Samba performance on FreeBSD 4.3-RELEASE and Linux 2.4.13ac4 Message-ID: <3C072706.2030501@ns.aus.com>
next in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format. --------------080403080306040403040308 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, attached is a preliminary report on a comparison of Samba performance on FreeBSD 4.3-RELEASE and Linux 2.4.13ac4. I have posted it because I promised to do so, however, I think you should take the numbers with a grain of salt. It demonstrates that overall, for the client tests I did (including up to 100 clients, but not reported), on the same hardware (well pretty much), the two operating systems are comparable. Until I resolve issues around why FreeBSD thinks that my SIS730-equiped PCchips 810MLR board has a UDMA33 controller only and Linux thinks it is capable of UDMA100, the dbench numbers do not mean much. In addition, I continue to look at the tbench numbers to see what the story is with respect to FreeBSD and TCP performance. Perhaps I have done something wrong. Feedback welcome, but I will have limited time to respond over the next week. -- Richard Sharpe, rsharpe@ns.aus.com, LPIC-1 www.samba.org, www.ethereal.com, SAMS Teach Yourself Samba in 24 Hours, Special Edition, Using Samba --------------080403080306040403040308 Content-Type: text/plain; name="freebsd-vs-linux-netbench.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="freebsd-vs-linux-netbench.txt" Measuring the performance of Samba under FreeBSD and Linux Richard Sharpe 25-Nov-2001 INTRODUCTION One of the tools available for measuring the performance of Samba and other CIFS servers is NetBench, the ZiffDavis benchmark. This menchmark attempts to simulate the workload applied to a CIFS server by one of more CIFS clients. The Samba team has developed a number of tools that can be used to gain feel for the ability of various parts of a Samba system (the whole system, the file system, or the networking subsystem) to handle the NetBench workload. This workload is based on a network trace. These tools are: smbtorture, which can provide an indication of the ability of a server to handle the NetBench load from one or more clients; dbench, which can provide an indication of the ability of the filesystem on a server to handle the workload offered by one or more clients; and tbench, which can provide an indication of the ability of the networking subsystem to handle the workload offered by one or more NetBench clients. The smbtorture test uses a trace taken from a NetBench run and replays the trace for the number of clients specified. Each client uses a separate area on the server, but their file system areas are all created in the same directory, eg \\server\public\CLIENTS\CLIENT0, \\server\public\CLIENTS\CLIENT1, and so on. The test involves reading and writing large files using large reads (up to 65535 bytes). The dbench test takes the NetBench trace and applies all the file IOs that it would cause without causing any network traffic or involving any protocol handling. Thus it only tests file system performance. It creates its working directories in the same way as smbtorture/NetBench. The tbench test tests out the performance of the networking system between the two machines. It sends exactly the same amount of data that a NetBench test would, but does no file system activity, nor any protocol handling, etc. I set about to measure the relative ability of FreeBSD 4.3-RELEASE and Linux 2.4.13-ac4 (on a RedHat 7.2 system) to handle the workload presented by 10, 20, 30, 40, and 50 NetBench clients. To understand better the limits of each operating system, I also ran dbench and tbench against both FreeBSD 4.3-RELEASE and Linux 2.4.13. The results show that both operating systems can provide similar levels of performance, so performance is not metric that can be used to choose between them. An interesting result is that Linux seems to be better at driving a 100Mb/s link, as well as providing higher file system throughput, but tuning FreeBSD might improve its performance. The rest of this report covers the methods that I used to setup and run the tests, the results I obtained, some obesrvations I made while running the tests and provide some conclusions. METHOD FreeBSD 4.3-RELEASE was loaded onto a 30GB IBM disk drive, while RedHat 7.2 was loaded onto a 20GB Western Digital drive. The 2.4.7 kernel on the RedHat system was replaced with Linux 2.4.13ac4, and the EXT3 file system was used, while the FreeBSD system used the standard file system with soft updates enabled. The drives were an IBM DTLA 307030 UDMA33 for FreeBSD and a WDC WD200EM UDMA100 for Linux. These drives were then booted on a Duron-750MHz based system with a PC Chips motherboard (SIS 730 chipset) with 1GB of memory. The system had two Ethernet controllers, both 100Mb/s. The controller used for the test was a 3C905B. A recent CVS version of Samba (2.2.3pre) was built on each system using the same, default, options, and then installed. Similar smb.conf files were built for each. The config files are shown in the appendix. The NetBench tests were all run from the one driver system, a dual-Celeron 533MHz Abit BP6 with 384MB of memory. They were all performed across a single 100Mb/s link. The dbench tests were run directly on the test system under FreeBSD and Linux. The dbench source and make were modified slightly to ensure that they would build under FreeBSD and to ensure that both the FreeBSD and Linux versions used fsync, since FreeBSD does not seem to contain the fdatasync routine that dbench initially used. The tbench runs were run from the dual-Celeron Linux system, with client counts of 1, 2, 3, 4, 5, 6, and 7 to determine the number of clients that saturated the 100Mb/s link. For the NetBench runs, smbtorture was used to perform 10, 20, 30, 40, and 50 client runs of NBWNT against FreeBSD and Linux. For the dbench runs, 1, 2, 5, 10, and 20 client runs were performed. RESULTS The smbtorture NetBench and dbench runs provide a result of Mb/s for each run, along with the actual duration of each run. Table 1 shows the results for FreeBSD and Linux for 10 and 20 clients. +---------+------------+------------+------------+------------+------------+ | OS | 10 clients | 20 clients | 30 clients | 40 clients | 50 clients | +---------+------------+------------+------------+------------+------------+ | FreeBSD | 66.9 Mb/s | 64.7 Mb/s | 58.9 Mb/s | 58.1 Mb/s | 55.3 Mb/s | | FreeBSD | 66.9 Mb/s | 63.3 Mb/s | 58.9 Mb/s | 57.0 Mb/s | 54.3 Mb/s | | FreeBSD | 68.1 Mb/s | 60.9 Mb/s | 58.3 Mb/s | 57.0 Mb/s | 55.5 Mb/s | | Linux | 62.1 Mb/s | 62.9 Mb/s | 63.3 Mb/s | 62.9 Mb/s | 59.6 Mb/s | | Linux | 62.7 Mb/s | 63.5 Mb/s | 63.1 Mb/s | 63.7 Mb/s | 60.3 Mb/s | | Linux | 62.7 Mb/s | 64.6 Mb/s | 63.8 Mb/s | 63.4 Mb/s | 60.8 Mb/s | +---------+------------+------------+------------+------------+------------+ Table 1. NetBench results Other data I have shows FreeBSD provides about 48Mb/s with a load of 100 clients. Table 2 shows the results of running dbench on FreeBSD 4.3-RELEASE and Linux 2.4.13ac4. +----------+-----------+-----------+-----------+-------------+------------+ | OS | 1 client | 2 clients | 5 clients | 10 clients | 20 clients | +----------+-----------+-----------+-----------+-------------+------------+ | FreeBSD | 255.5Mb/s | 216.1Mb/s | 125.7Mb/s | 91.6Mb/s | 71.5Mb/s | | FreeBSD | 211.0Mb/s | 222.2Mb/s | 122.3Mb/s | 93.5Mb/s | 75.7Mb/s | | FreeBSD | 210.8Mb/s | 208.5Mb/s | 121.8Mb/s | 95.5Mb/s | 70.5Mb/s | | LINUX | 341.0Mb/s | 276.4Mb/s | 322.2Mb/s | 341.7Mb/s | 204.6Mb/s | | LINUX | 696.2Mb/s | 346.3Mb/s | 309.5Mb/s | 319.3Mb/s | 216.4Mb/s | | LINUX | 692.7Mb/s | 356.7Mb/s | 320.0Mb/s | 289.7Mb/s | 234.4Mb/s | +----------+-----------+-----------+-----------+-------------+------------+ Table 2: dbench results Table 3 shows the results of running tbenchon FreeBSD 4.3-RELEASE and Linux 2.4.13ac4. +----------+----------+-----------+-----------+-----------+-----------+ | OS | 1 client | 2 clients | 3 clients | 4 clients | 5 clients | +----------+----------+-----------+-----------+-----------+-----------+ | FreeBSD | 26.2Mb/s | 45.7Mb/s | 63.0Mb/s | 75.1Mb/s | 85.3Mb/s | | FreeBSD | 26.1Mb/s | 46.1Mb/s | 63.6Mb/s | 75.3Mb/s | 85.8Mb/s | | FreeBSD | 26.2Mb/s | 46.1Mb/s | 61.8Mb/s | 78.8Mb/s | 85.0Mb/s | | LINUX | 68.7Mb/s | 92.2Mb/s | Saturated | Saturated | Saturated | | LINUX | 68.7Mb/s | 92.5Mb/s | Saturated | Saturated | Saturated | | LINUX | 68.0Mb/s | 92.6Mb/s | Saturated | Saturated | Saturated | +----------+----------+-----------+-----------+-----------+-----------+ Table 3: tbench results The FreeBSD runs did not saturate the link until I ran a 7-client test. OBSERVATIONS While watching the NetBench runs, FreeBSD's loadaverage rarely got above 5, and there was a reasonable amount of free CPU available on the system. In addition, the disk led continued to flash throughout. On the other hand, when these runs were performed against Linux, the loadaverage often got up to within one or two of the number of clients run. Thus, for a 10 client run, the load average often got up to 8 or 9. In addition, there was still some free CPU on the system. When the loadaverage got up to five or so under FreeBSD, response became very sluggish on the console, while Linux 2.4.13 was still able to respond reasoably well with a load average up to around 8 or 9. In addition, until I resolve the issues around FreeBSD regarding the IBM DTLA as a UDMA33 device, but Linux regarding the WDC WD200 as UDMA100 capable, the dbench numbers are suspect. CONCLUSIONS TBD APPENDIX TBD ACKNOWLEDGMENTS I would like to thank Greg Lehey for assistance with FreeBSD, as well as Jonathan Lemon for suggestions relating to these matters. Any errors are my responsibility. --------------080403080306040403040308-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C072706.2030501>