How do you choose the right filesystem for your database management system?
Administrators have a variety of filesystems to choose from, as well as volume management and hardware or software RAID. This talk will examine how different the performance of filesystems really are, and how do you go about systematically determining which configuration will be the best for your application and hardware.
This talk will present data generated by a group of volunteers running performance tests for database tuning. We were curious if the file systems would really behave like we expected them to, especially when used in conjunction with RAID or volume management.
There is also more to file systems than how fast we can read to or write to them. Reliability is critical for production environments, and proving that is a key part of evaluating performance.
The talk will review and confirm or deny assumptions that many system administrators and developers make about filesystems and databases.
Data shared will include baseline throughput determined with exhaustive fio tests.
The Codex of Business Writing Software for Real-World Solutions 2.pptx
Filesystem Performance from a Database Perspective
1. Filesystem Performance
From a Database Perspective
Mark Wong
markwkm@postgresql.org
LinuxFest Northwest 2009
April 25 - 26, 2009
2. How we are here today
Generous equipment donations from HP and hosting from
Command Prompt, Inc.
3. Setting Expectations
This is not:
This is:
A comprehensive Linux
◮
A guide for how to
◮
filesystem evaluation.
understand the i/o behavior
A filesystem tuning guide
◮
of your own system.
(mkfs and mount options).
A model of simple i/o
◮
Representative of your
◮
behavior based on
system (unless you have the
PostgreSQL
exact same hardware.)
Suggestion for testing your
◮
A test of reliability or
◮
own system.
durability (mostly).
4. __ __
/ ~~~/ . o O ( Know your system! )
,----( oo )
/ __ __/
/| ( |(
^ /___ / |
|__| |__|-quot;
5. Contents
Testing Criteria
◮
What do we want to test.
◮
How we test it with fio.
◮
Test Results
◮
6. Hardware Details
HP DL380 G5
◮
2 x Quad Core Intel(R) Xeon(R) E5405
◮
HP 32GB Fully Buffered DIMM PC2-5300 8x4GB DR LP
◮
Memory
HP Smart Array P800 Controller w/ 512MB Cache
◮
HP 72GB Hot Plug 2.5 Dual Port SAS 15,000 rpm Hard
◮
Drives
__ __
/ ~~~/ . o O ( Thank you HP! )
,----( oo )
/ __ __/
/| ( |(
^ /___ / |
|__| |__|-quot;
7. Test Criteria
PostgreSQL dictates the following (even though some of them are
actually configurable:
8KB block size
◮
No use of posix fadvise
◮
No use of direct i/o
◮
No use of async i/o
◮
Uses processes, not threads.
◮
Based on the hardware:
56GB data set - To minimize any caching in the 32GB of
◮
system memory. (Want to use 64GB but these 72GB disks are
in millions of bytes, i.e. not big enough for the 1 disk tests.)
8 processes performing i/o - One fio process per core, except
◮
for sequential i/o tests, otherwise the i/o won’t be sequential.
9. Hardware RAID Configurations
These are the RAID configurations supported by the HP Smart
Array p8001 disk controller:
RAID 0
◮
RAID 1+0
◮
RAID 5
◮
RAID 6
◮
__ __
/ ~~~/ . o O ( Which RAID would you use? )
,----( oo )
/ __ __/
/| ( |(
^ /___ / |
|__| |__|-quot;
1
Firmare v5.22
10. Test Program
Use fio2 (Flexible I/O) v1.23 by Jens Axboe to test:
Sequential Read
◮
Sequential Write
◮
Random Read
◮
Random Write
◮
Random Read/Write
◮
2
http://brick.kernel.dk/snaps/
17. __ __
/ ~~~/ . o O ( Results! )
,----( oo )
/ __ __/
/| ( |(
^ /___ / |
|__| |__|-quot;
There is more information than what is in this presentation, raw
data is at:
http://207.173.203.223/~ markwkm/community10/fio/linux-2.6.28-gentoo/
Raw mpstat, vmstat, iostat, and sar data.
◮
18. A few words about statistics...
Not enough time or data to calculate good statistics. My excuses:
1 hour per test
◮
5 tests per filesystem
◮
6 filesystems per RAID configuration (1 filesystem consistently
◮
halts testing, requiring manual intervention...)
7 RAID configurations for this presentation
◮
210+ hours of continuous testing for this presentation.
◮
26. A couple notes about the following charts
If you see missing data, it means the test didn’t complete
◮
successfully.
Charts are not all scaled the same, focus is on trends within a
◮
chart. (But maybe that is not a good choice?)
27. Results for all the filesystems when using only a single disk...
28.
29. Results for all the filesystems when striping across four disks...
38. Trends might not be the same when adding disks to other RAID
configurations. (We didn’t test it because we moved on to
database systems testings.)
39. What is the best use of disks with respect to capacity?
40.
41.
42.
43.
44.
45.
46. Filesystem Readahead
Values are in number of 512-byte segments, set per device.
To get the current readahead size:
$ blockdev --getra /dev/sda
256
To set the readahead size to 8 MB:
$ blockdev --setra 16384 /dev/sda
47.
48. What does this all mean for my database system?
It depends... Let’s look at one sample of just using difference
filesystems.
49.
50. Raw data for comparing filesystems
Initial inspection of results suggests we are close to being bound by
processor and storage performance, meaning we don’t really know
who performs the best:
◮ http://207.173.203.223/~ markwkm/community6/dbt2/m-fs/ext2.1500.2/
◮ http://207.173.203.223/~ markwkm/community6/dbt2/m-fs/ext3.1500.2/
◮ http://207.173.203.223/~ markwkm/community6/dbt2/m-fs/ext4.1500.2/
◮ http://207.173.203.223/~ markwkm/community6/dbt2/m-fs/jfs.1500.2/
◮ http://207.173.203.223/~ markwkm/community6/dbt2/m-fs/reiserfs.1500.2/
◮ http://207.173.203.223/~ markwkm/community6/dbt2/m-fs/xfs.1500.2/
51. Linux I/O Elevator Algorithm
To get current algorithm in []’s:
$ cat /sys/block/sda/queue/scheduler
noop anticipatory [deadline] cfq
To set a different algorithm:
$ echo cfg > /sys/block/sda/queue/scheduler
noop anticipatory [deadline] cfq
52. Why use deadline?3
Attention! Database servers, especially those using ”TCQ”
◮
disks should investigate performance with the ’deadline’ IO
scheduler. Any system with high disk performance
requirements should do so, in fact.
Also, users with hardware RAID controllers, doing striping,
◮
may find highly variable performance results with using the
as-iosched. The as-iosched anticipatory implementation is
based on the notion that a disk device has only one physical
seeking head. A striped RAID controller actually has a head
for each physical device in the logical RAID device.
3
Linux source code: Documentation/block/as-iosched.txt
53. Final Notes
You have to test your own system to see what it can do, don’t take
someone else’s word for it.
57. License
This work is licensed under a Creative Commons Attribution 3.0
Unported License. To view a copy of this license, (a) visit
http://creativecommons.org/licenses/by/3.0/us/; or, (b)
send a letter to Creative Commons, 171 2nd Street, Suite 300, San
Francisco, California, 94105, USA.