Andrew Debenham put forth on 10/25/2010 6:17 AM: > Stan - > > Thank you for your response and I apologize if my initial explanation wasn't clear. The applications will be running on identical hardware (see specs. below) but each application will be running on a dedicated system. My original spreadsheet had this information but it obviously didn't come through correctly. I would like to tune the XFS file systems to accommodate the two different applications. As I mentioned before, I experimented with various parameters (e.g. sunit, swidth, log size, etc.) and different mounting options (e.g. logbufs, logbsize, etc.), but it sounds like I may have been wasting my time attempting to benchmark the file systems. Any information or recommendations you can provide would be greatly appreciated. Also, can you recommend a tool that would be good for benchmarking an XFS file system (if one exists)? Thanks again! No apology necessary. Regarding benchmarking... 1. Good for apples to apples comparisons between a. Two or more different storage subsystems b. Two or more different kernel versions c. Two or more different RAID controllers d. Two or more different elevators e. Two or more different mkfs/mount options 2. _Not_ good for determining specific application performance You could tweak and test every mkfs and mount option until you squeezed maximum throughput and IOPs from your array, and then see abysmal performance from your apps, if their access patterns are sufficiently different than the synthetic tests. You need to use the applications themselves as the benchmark. Create multiple XFS filesystems with different mkfs parms and mount options and see which combination performs best with your application. If your applications lack sufficient performance measuring instrumentation, now might be a good time to add some, assuming these are home grown apps. But, before doing this, read my comments below regarding the age of your OS and utils. When you do this in depth app testing, do it on your much newer OS platform. > System Specs > ----------------- > Motherboard: Supermicro X8DTU Good choice. I've been a SuperMicro fan for over 10 years--built many a system using their boards. > Chipset: Intel 5520 (Tylersburg) > Processors: Dual Intel Xeon E5540 @2.53GHz > RAM: 32GB PC3-8500 1066MHz > OS: CentOS 5.3 > Kernel: 2.6.18-128.el5 You need a much newer kernel. 2.6.18 is _ancient_ released in 2006, though CentOS have patched the bejesus out of it--128 times. > RAID Controller: 3ware 9650SE-12M > Disk Type: SATA > Disk Size: 1.82 TB > RAID Level: 6 > # of disks: 11 > Stripe Size: 256 KB > File System Size: 16.37 TB > XFS Info: kmod-xfs-0.4-2, xfsprogs-2.9.4-1.el5.centos You also need a much newer xfsprogs. 2.9.4 is ancient. Your XFS kernel module is 2 years old. Not quite ancient yet, but getting there. You'd be doing yourself a huge favor by moving to something like Fedora 13 or OpenSuSE 11.3, which have much newer code in all these areas, and more. If you're not wed to RedHat and the RPM package standard, Ubuntu 10.4 LTS would be a good option as well. Or, maybe you can get all these things as binary RPMs from a 3rd party? I'm not at all familiar with the CentOS ecosystem. I've been a Debian user for almost a decade. There are some XFS specific problems you might run into with that old of a kernel, module, and xfsprogs. Dave Chinner and other devs can provide the details. I can't recall the specific issues, though one or two of them were discussed here not long ago due to OPs with problems. IIRC one of them having problems was running CentOS 5.4, slightly newer than yours. Hopes this helps, and I hope I'm not sounding preachy. Just giving direct answers. -- Stan _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
