分类： LINUX
2008-04-26 11:15:21
Debian Administration System Administration Tips and Resources 现在还可以得到的许多Linux filesystems 比较，但是他们中大多数是古老的，基于为人任务的或者在更老的情况下完成。 这篇基准测试文基于与老一代的适合一台文件服务器的11项硬件(奔腾II/III，EIDE硬盘)。 从最初编制到出版，文章已经产生许多变化，意见和建议改进。我目前正努力进行一些新的试验。(回答在原文范围的问题)。 结果将在大约在(2006年5月8日)可提供 汉斯 为什么要做基准测试？ 我发现quantitative and reproductible benchmark基准使用2.6.x kernel。 Benoit在2003年在有512 MB RAM 的PIII 500服务器上使用大文件(1 + GB)实现12次试验。 这次试验信息十分丰富，但是结果对2.6.x kernel开始，主要适用于底座， 专门操作大的锉(例如，多媒体，科学，数据库)。 Piszcz 在2006年实现21项任务(有768 MB RAM 和一个400GBEIDE-133硬盘在PIII-500 模拟多种文件操作)。到目前为止，这测试看起来是在2.6.x kernel上的最全面的工作。 但是， 很多任务是人造的(例如， 复制和删除10，000个空目录，新建10，000个文件，递归分割文件)，把这些结论应用到现实世界可能是无意义的。 因此， 这里测试的基准的目标是验证一些Piszcz(2006)的结论， 通过专门应用于现实世界在小型企业文件服务器(看见任务描述)里找到。 测试基础 * Hardware Processor : Intel Celeron 533 * RAM : 512MB RAM PC100 * Motherboard : ASUS P2B * Hard drive : WD Caviar SE 160GB (EIDE 100, 7200 RPM, 8MB Cache) * Controller : ATA/133 PCI (Silicon Image) * OS Debian Etch (kernel 2.6.15), distribution upgraded on April 18, 2006 * All optional daemons killed (cron,ssh,saMBa,etc.) * Filesystems Ext3 (e2fsprogs 1.38) * ReiserFS (reiserfsprogs 1.3.6.19) * JFS (jfsutils 1.1.8) * XFS (xfsprogs 2.7.14) 选择的测试任务描述 *在一个大文件(ISO 镜像文件，700 MB)的从第2个磁盘复制到这个试验磁盘 *再从在另一个位置再复制这个 ISO 一次 *删除这个ISO 的两个副本 *操作一文件树(有7500 文件，900 目录，1.9GB)，从第2 磁盘复制到这个试验磁盘 *再从在另一个位置再复制这个文件树 一次 *删除这个文件树的两个副本 *用递归的方法遍历文件树目录和文件树的全部内容，复制到这个试验磁盘 *匹配通配符，在文件树查找具体的文件 *用(mkfs) 建立filesystem(全部FS都使用默认值) *mount filesystem *Umount filesystem 上述11项任务(从建立filesystem到umounting filesystem)的顺序，编写为Bash script运行完成3 次(报告平均成绩)。 每个顺序花费大约7分种，完成任务的时间用秒计算， GNU time utility (version 1.7) 记录任务时的CPU 的利用百分比。 结果 分区能力 (在filesystem 创造之后)初始化分区并重新划分block的过程里，Ext3有最差的初始利用率(92.77%)， 其它的filesystem 几乎可是使用全部的容量(ReiserFS = 99.83%，JFS = 99.82%，XFS = 99.95%)。 结论： 为了使用你的分区的的最大容量，选择ReiserFS，JFS或者XFS。 建立文件系统，mount和unmounting 在20GB的分区创造filesystem测试，划分为Ext3带14.7秒， 与为相比其他filesystem多2秒或更少。(ReiserFS = 2.2，JFS = 1.3，XFS = 0.7)。 不过，挂载ReiserFS 要比其他的FS多花费5-15倍时间(2.3秒)(Ext3 = 0.2, JFS = 0.2, XFS = 0.5)，umount以及要比其他的FS多花费2 倍时间(0.4秒)。 所有的FS都花费差不多CPU占用来创建FS(59%（ReiserFS） -74%（JFS）)，挂载FS(在6和9%之间)。 不过，Ext3 和XFS多用2倍的CPU占用 给umount(37% 和45%)， ReiserFS和JFS(14% 和27%)。 结论： 对创建FS性能和mounting/unmounting来说，选择JFS或者XFS。 大文件操作性能(ISO image，700 MB) 把大文件复制到Ext3(38.2秒)和ReiserFS(41.8)， 要比JFS和XFS(35.1和34.8)需要更多时间。使用XFS有助于提高在相同的磁盘上复制相同的文件(XFS=33.1,Ext3 = 37.3，JFS = 39.4，ReiserFS = 43.9)相比。 在JFS和XFS上删除那些ISO 大约要快100 倍(0.02秒)，（ReiserFS1.5秒，Ext32.5秒）！所有FS复制时的CPU利用(在46和51%之间)，再复制时(在38%到50%之间)。当其他FS使用大约10%时，ReiserFS使用49%的CPU。 比他FS大约少5到10%)，JFS使用较少的CPU。 结论： 对大文件操作性能来说，最好选择JFS或者XFS。 如果你需要使CPU利用减到最小，更推荐JFS。 目录树(7500个文件，900份目录，1.9GB)的操作 最初复制目录树时，Ext3(158.3秒)和XFS(166.1秒)更迅速， ReiserFS和JFS(172.1和180.1)。在第二次复制的时候有相似的结果。（Ext3=120秒，XFS = 135.2，ReiserFS = 136.9 和JFS = 151)。但是， 移动目录树时Ext3(22秒)相比ReiserFS(8.2秒， XFS(10.5秒)和JFS(12.5秒))大约多2倍时间！所有FS在复制和再复制目录树时都使用较多的CPU (复制在27和36%之间)，(再复制在29%-JFS和45%-ReiserFS之间)。 令人吃惊，ReiserFS 和XFS使用更多的CPU 删除目录树(86% 和65%)， 而其他FS只使用大约15%的(Ext3和JFS)。再次，与任何其他FS相比较，JFS的明显使用较少CPU。 当有较多的数量较小页面时适合ReiserFS。这个差别在目录树的再复制和移动里的ReiserFS将有更高的速度。 结论：对在大容量的目录树操作来说，选择Ext3或者XFS。 来自其他作者的基准测试已经证明如果使用ReiserFS，对大量的小文件更为合适。但是，目前包括各种各样尺寸(10KB在5 MB)数千文件的目录树操作上，建议使用Ext3或者XFS可能获得更好的性能。如果JFS的CPU占用减到最小，这种FS带着相当高的性能。 目录列表和文件查找 递归显示目录的目录列表，ReiserFS(1.4秒)和XFS更迅速的1.8)， Ext3和JFS(2.5和3.1)。文件查找有着相同的结果。在文件查找项目， ReiserFS(0.8秒)相比XFS(2.8)和Ext3(4.6秒)和JFS(5秒)更迅速。 Ext3和JFS有更好CPU占用：目录列表(35%)，文件查找(6%)。 XFS目录列表(70%)使用更多的CPU，文件查找(10%)。 ReiserFS 看起来是占用CPU最多的FS，目录列表71%，文件查找36% 。 结论： 结果表明那， 对于这些CPU占用任务来说，(ext3和JFS)filesystems 能更少的使用CPU的。 XFS作为好备选，带有相对适中的性能和CPU的占用。 总的结论 这些结果从Piszcz(2006)关于分解的Ext3，ReiserFS的磁盘能力报告一样。 这两篇文章两篇已经显示JFS是最低的CPU利用的FS。 最后，这份报告看起来没有显示出ReiserFS的high page faults activity 由于一个分区只能有一个filesystem，认识每种filesystem的优缺点很重要。如果，以这篇文章的全部测试为基准， XFS看起来是家庭或者小型企业最适合的应用于文件服务器的filesystem： *它使用你的服务器硬盘(s)的拥有最大的容量 *创建FS，mount和unmount很迅速 *操作大文件最迅速的FS(>500 MB) *这FS得第二名地方给经营关于许多在适度尺寸文件和目录小 *在CPU占用和目录列表或者文件搜寻性能之间比较平衡， *没有最小CPU要求，老一代硬件也可十分接受 Piszcz(2006)当时没有明确推荐XFS，他只是说："就个人来说，我仍然愿意选择同时具备性能和可伸缩性的XFS"。 现在我只能支持这个结论。 参考 贝努瓦，M.(2003)。 Linux 文件系统基准。 Piszcz，J.(2006)。 基准问题测试Filesystems第二部分。 Linux Gazette, 122 (January 2006)。 以下是原文 ----------------------------------------------------------------------- Debian Administration System Administration Tips and Resources [ About | Archive | FAQ | Hall of Fame | Search | Tagged Articles | Filesystems (ext3, reiser, xfs, jfs) comparison on Debian Etch There are a lot of Linux filesystems comparisons available but most of them are anecdotal, based on artificial tasks or completed under older kernels. This benchmark essay is based on 11 real-world tasks appropriate for a file server with older generation hardware (Pentium II/III, EIDE hard-drive). Since its initial publication, this article has generated a lot of questions, comments and suggestions to improve it. Consequently, I'm currently working hard on a new batch of tests to answer as many questions as possible (within the original scope of the article). Results will be available in about two weeks (May 8, 2006) Many thanks for your interest and keep in touch with Debian-Administration.org! Hans Why another benchmark test? I found two quantitative and reproductible benchmark testing studies using the 2.6.x kernel (see References). Benoit (2003) implemented 12 tests using large files (1+ GB) on a Pentium II 500 server with 512MB RAM. This test was quite informative but results are beginning to aged (kernel 2.6.0) and mostly applied to settings which manipulate exclusively large files (e.g., multimedia, scientific, databases). Piszcz (2006) implemented 21 tasks simulating a variety of file operations on a PIII-500 with 768MB RAM and a 400GB EIDE-133 hard disk. To date, this testing appears to be the most comprehensive work on the 2.6 kernel. However, since many tasks were "artificial" (e.g., copying and removing 10 000 empty directories, touching 10 000 files, splitting files recursively), it may be difficult to transfer some conclusions to real-world settings. Thus, the objective of the present benchmark testing is to complete some Piszcz (2006) conclusions, by focusing exclusively on real-world operations found in small-business file servers (see Tasks description). Test settings * Hardware Processor : Intel Celeron 533 * RAM : 512MB RAM PC100 * Motherboard : ASUS P2B * Hard drive : WD Caviar SE 160GB (EIDE 100, 7200 RPM, 8MB Cache) * Controller : ATA/133 PCI (Silicon Image) * OS Debian Etch (kernel 2.6.15), distribution upgraded on April 18, 2006 * All optional daemons killed (cron,ssh,saMBa,etc.) * Filesystems Ext3 (e2fsprogs 1.38) * ReiserFS (reiserfsprogs 1.3.6.19) * JFS (jfsutils 1.1.8) * XFS (xfsprogs 2.7.14) Description of selected tasks * Operations on a large file (ISO image, 700MB) Copy ISO from a second disk to the test disk * Recopy ISO in another location on the test disk * Remove both copies of ISO * Operations on a file tree (7500 files, 900 directories, 1.9GB) Copy file tree from a second disk to the test disk * Recopy file tree in another location on the test disk * Remove both copies of file tree * Operations into the file tree List recursively all contents of the file tree and save it on the test disk * Find files matching a specific wildcard into the file tree * Operations on the file system Creation of the filesystem (mkfs) (all FS were created with default values) * Mount filesystem * Umount filesystem The sequence of 11 tasks (from creation of FS to umounting FS) was run as a Bash script which was completed three times (the average is reported). Each sequence takes about 7 min. Time to complete task (in secs), percentage of CPU dedicated to task and number of major/minor page faults during task were computed by the GNU time utility (version 1.7). RESULTS Partition capacity Initial (after filesystem creation) and residual (after removal of all files) partition capacity was computed as the ratio of number of available blocks by number of blocks on the partition. Ext3 has the worst inital capacity (92.77%), while others FS preserve almost full partition capacity (ReiserFS = 99.83%, JFS = 99.82%, XFS = 99.95%). Interestingly, the residual capacity of Ext3 and ReiserFS was identical to the initial, while JFS and XFS lost about 0.02% of their partition capacity, suggesting that these FS can dynamically grow but do not completely return to their inital state (and size) after file removal. Conclusion : To use the maximum of your partition capacity, choose ReiserFS, JFS or XFS. File system creation, mounting and unmounting The creation of FS on the 20GB test partition took 14.7 secs for Ext3, compared to 2 secs or less for other FS (ReiserFS = 2.2, JFS = 1.3, XFS = 0.7). However, the ReiserFS took 5 to 15 times longer to mount the FS (2.3 secs) when compared to other FS (Ext3 = 0.2, JFS = 0.2, XFS = 0.5), and also 2 times longer to umount the FS (0.4 sec). All FS took comparable amounts of CPU to create FS (between 59% - ReiserFS and 74% - JFS) and to mount FS (between 6 and 9%). However, Ex3 and XFS took about 2 times more CPU to umount (37% and 45%), compared to ReiserFS and JFS (14% and 27%). Conclusion : For quick FS creation and mounting/unmounting, choose JFS or XFS. Operations on a large file (ISO image, 700MB) The initial copy of the large file took longer on Ext3 (38.2 secs) and ReiserFS (41.8) when compared to JFS and XFS (35.1 and 34.8). The recopy on the same disk advantaged the XFS (33.1 secs), when compared to other FS (Ext3 = 37.3, JFS = 39.4, ReiserFS = 43.9). The ISO removal was about 100 times faster on JFS and XFS (0.02 sec for both), compared to 1.5 sec for ReiserFS and 2.5 sec for Ext3! All FS took comparable amounts of CPU to copy (between 46 and 51%) and to recopy ISO (between 38% to 50%). The ReiserFS used 49% of CPU to remove ISO, when other FS used about 10%. There was a clear trend of JFS to use less CPU than any other FS (about 5 to 10% less). The number of minor page faults was quite similar between FS (ranging from 600 - XFS to 661 - ReiserFS). Conclusion : For quick operations on large files, choose JFS or XFS. If you need to minimize CPU usage, prefer JFS. Operations on a file tree (7500 files, 900 directories, 1.9GB) The initial copy of the tree was quicker for Ext3 (158.3 secs) and XFS (166.1) when compared to ReiserFS and JFS (172.1 and 180.1). Similar results were observed during the recopy on the same disk, which advantaged the Ext3 (120 secs) compared to other FS (XFS = 135.2, ReiserFS = 136.9 and JFS = 151). However, the tree removal was about 2 times longer for Ext3 (22 secs) when compared to ReiserFS (8.2 secs), XFS (10.5 secs) and JFS (12.5 secs)! All FS took comparable amounts of CPU to copy (between 27 and 36%) and to recopy the file tree (between 29% - JFS and 45% - ReiserFS). Surprisingly, the ReiserFS and the XFS used significantly more CPU to remove file tree (86% and 65%) when other FS used about 15% (Ext3 and JFS). Again, there was a clear trend of JFS to use less CPU than any other FS. The number of minor page faults was significantly higher for ReiserFS (total = 5843) when compared to other FS (1400 to 1490). This difference appears to come from a higher rate (5 to 20 times) of page faults for ReiserFS in recopy and removal of file tree. Conclusion : For quick operations on large file tree, choose Ext3 or XFS. Benchmarks from other authors have supported the use of ReiserFS for operations on large number of small files. However, the present results on a tree comprising thousands of files of various size (10KB to 5MB) suggest than Ext3 or XFS may be more appropriate for real-world file server operations. Even if JFS minimize CPU usage, it should be noted that this FS comes with significantly higher latency for large file tree operations. Directory listing and file search into the previous file tree The complete (recursive) directory listing of the tree was quicker for ReiserFS (1.4 secs) and XFS (1.8) when compared to Ext3 and JFS (2.5 and 3.1). Similar results were observed during the file search, where ReiserFS (0.8 sec) and XFS (2.8) yielded quicker results compared to Ext3 (4.6 secs) and JFS (5 secs). Ext3 and JFS took comparable amounts of CPU for directory listing (35%) and file search (6%). XFS took more CPU for directory listing (70%) but comparable amount for file search (10%). ReiserFS appears to be the most CPU-intensive FS, with 71% for directory listing and 36% for file search. Again, the number of minor page faults was 3 times higher for ReiserFS (total = 1991) when compared to other FS (704 to 712). Conclusion : Results suggest that, for these tasks, filesystems can be regrouped as (a) quick and more CPU-intensive (ReiserFS and XFS) or (b) slower but less CPU-intensive (ext3 and JFS). XFS appears as a good compromise, with relatively quick results, moderate usage of CPU and acceptable rate of page faults. OVERALL CONCLUSION These results replicate previous observations from Piszcz (2006) about reduced disk capacity of Ext3, longer mount time of ReiserFS and longer FS creation of Ext3. Moreover, like this report, both reviews have observed that JFS is the lowest CPU-usage FS. Finally, this report appeared to be the first to show the high page faults activity of ReiserFS on most usual file operations. While recognizing the relative merits of each filesystem, only one filesystem can be install for each partition/disk. Based on all testing done for this benchmark essay, XFS appears to be the most appropriate filesystem to install on a file server for home or small-business needs : * It uses the maximum capacity of your server hard disk(s) * It is the quickest FS to create, mount and unmount * It is the quickest FS for operations on large files (>500MB) * This FS gets a good second place for operations on a large number of small to moderate-size files and directories * It constitutes a good CPU vs time compromise for large directory listing or file search * It is not the least CPU demanding FS but its use of system ressources is quite acceptable for older generation hardware While Piszcz (2006) did not explicitly recommand XFS, he concludes that "Personally, I still choose XFS for filesystem performance and scalability". I can only support this conclusion. References Benoit, M. (2003). Linux File System Benchmarks. Piszcz, J. (2006). Benchmarking Filesystems Part II. Linux Gazette, 122 (January 2006). Comment on this article |
