Srovnání výkonu PostgreSQL na EXT3/4, XFS, BTRFS a ZFS (a obecně na současných Linuxových souborových systémech).

1. PostgreSQL na EXT3/4, XFS,
BTRFS a ZFS
OpenAlt 2015, 7-8 listopad, Brno
Tomáš Vondra
tomas.vondra@2ndquadrant.com
http://blog.pgaddict.com

2. ne inženýr souborových systémů
databázový inženýr

3. Který souborový systém bychom měli
použít pro PostgreSQL na produkci?

4. Podle našich benchmarků z roku
2003 je nejlepší souborový systém ...

5. Co to vlastně znamená že souborový systém
je “stabilní” a “production ready”?

6. 1) spolehlivost
2) konzistentní výkon
3) nástroje

7. DISCLAIMER
Proti žádnému ze zmiňovaných souborových
systémů nic osobního nemám.

8. SSD

9. Souborové systémy

10. EXT3, EXT4, XFS, ...
● EXT3/4, XFS, … (a další)
– tradiční design z 90. let, případně doplněný o žurnál
– totožné cíle, podobné koncepty, různé implementace
– postupné vylepšování a modernizace
– vyzrálé, spolehlivé, prověřené časem a produčními instalacemi
● historie stručně
– 2001 - EXT3
– 2002 - XFS (1994 - SGI Irix 5.3, 2000 GPL, 2002 Linux)
– 2008 - EXT4

11. EXT3, EXT4, XFS, ...
● evoluce, nikoliv revoluce
– doplňování vlastností (e.g. TRIM, write barriers, ...)
– vylepšení škálovatelnosti (metadata, ...)
– opravy chyb
● počaty v době rotačních disků
– víceméně fungují na SSD discích
– stop-gap pro budoucí systémy (NVRAM, ...)
● žádná podpora pro
– volume management, více disků, snapshoty
– řeší se přes LVM a RAID (hw/sw)

12. BTRFS, ZFS
● základní myšlenky
– integrace vrstev (LVM + dm + ...)
– zaměřeno na consumer-level hardware (častá selhání)
– zaměřeno na velké datové objemy
● což nám (doufejme) přinese ...
– flexibilní management
– zabudovaný snapshotting
– kompresi, deduplikaci
– kontrolní součty

13. BTRFS, ZFS
● BTRFS
– zamergováno v 2009, nadále “experimental”
– on-disk formát označený jako “stable” (1.0)
– někdo tvrdí že “stable” nebo dokonce “production ready” ...
– default v některých distribucích
● ZFS
– původně Sun / Solaris, ale “got Oracled” :-(
– mírně fragmentovaný vývoj (Illumos, Oracle, ...)
– dostupný i na jiných BSD systémech (FreeBSD)
– “ZFS on Linux” projekt (ale CDDL vs. GPL apod.)

14. Obecné “mount options”

15. Obecné “mount options”
● TRIM (discard)
– zapne zasílání TRIM příkazů z kernelu na SSD
– ovlivňuje interní čistící procesy (mazání bloků) / wear leveling
– ne úplně nutné, ale může pomoci SSD s “garbage collection”
● write barriers
– brání řadiči měnit pořadí zápisů (journal x data)
– zaručuje konzistenci souborového systému, nebrání ztrátě dat
– write cache + baterka => write barriers lze vypnout
● SSD alignment

16. Specifické “mount options”

17. BTRFS
● nodatacow
– vypne “copy on write” (CoW), pro snapshoty dočasně zapne
– současně vypne kontrolní součty (vyžadují “plné” CoW)
– také zřejmě vypne “torn-page resiliency” (full_page_writes=on)
● ssd
– zapne různé SSD optimalizace (ale není jasné které)
● compress=lzo/zlib
– spekulativní komprese

18. ZFS
● recordsize=8kB
– standardní ZFS stránka má 128kB (PostgreSQL používá 8kB stránky)
– problémy s ARC cachí (menší počet “slotů”)
● logbias=throughput [latency]
– ovlivňuje práci se ZIL
– priorita latence vs. propustnost
● zfs_arc_max
– omezení velikosti ARC cache
– měla by se nastavovat automaticky, ale externí modul ...

19. Benchmark

20. pgbench (TPC-B)
● transakční benchmark (TPC-B) / stress-test
– spousta malých dotazů (přístup přes PK, ...)
– mix různých typů I/O (čtení/zápis, náhodně/sekvenčně)
● dvě varianty
– read-only (SELECT)
– read-write (SELECT + INSERT + UPDATE)
● tři kategorie datových objemů
– malý (~200MB)
– střední (~50% RAM)
– velký (~200% RAM)

21. Hardware
● CPU: Intel i5-2500k
– 4 cores @ 3.3 GHz (3.7GHz)
– 6MB cache
– 2011-2013
● 8GB RAM (DDR3 1333)
● SSD Intel S3700 100GB (SATA3)
● Gentoo + kernel 4.0.4
● PostgreSQL 9.4

22. Ale to není reprezentativní!

23. Výsledky
● více než 40 kombinací otestováno
– další jsou v plánu
● každý test běží > 4 dny
https://bitbucket.org/tvondra/fsbench-i5

24. pgbench read-only

25. 0 2 4 6 8 10 12 14 16 18
0
10000
20000
30000
40000
50000
60000
pgbench / small (150 MB) read-only
počet klientů
transakcízavteřinu

26. 0 2 4 6 8 10 12 14 16 18
0
5000
10000
15000
20000
25000
30000
35000
40000
pgbench / velký (16GB) read-only
ZFS ZFS (recordsize=8k) BTRFS
BTRFS (nodatacow) F2FS ReiserFS
EXT4 EXT3 XFS
počet klientů
transakcízavteřinu

27. pgbench read-write

28. 0 2 4 6 8 10 12 14 16 18
0
1000
2000
3000
4000
5000
6000
7000
8000
pgbench / malý (150MB) read-write
BTRFS (ssd, nobarrier) BTRFS (ssd, nobarrier, discard, nodatacow)
EXT3 EXT4 (nobarrier, discard)
F2FS (nobarrier, discard) ReiserFS (nobarrier)
XFS (nobarrier, discard) ZFS
ZFS (recordsize, logbias)
počet klientů
transakcízavteřinu

29. 0 2 4 6 8 10 12 14 16 18
0
1000
2000
3000
4000
5000
6000
7000
8000
pgbench / small (150MB) read-write
BTRFS (ssd, nobarrier, discard, nodatacow) ZFS (recordsize, logbias)
F2FS (nobarrier, discard) EXT4 (nobarrier, discard)
ReiserFS (nobarrier) XFS (nobarrier, discard)
počet klientů
transakcízavteřinu

30. 0 2 4 6 8 10 12 14 16 18
0
1000
2000
3000
4000
5000
6000
pgbench / large (16GB) read-write
ZFS BTRFS (ssd)
ZFS (recordsize) ZFS (recordsize, logbias)
F2FS (nobarrier, discard) BTRFS (ssd, nobarrier, discard, nodatacow)
EXT3 ReiserFS (nobarrier)
XFS (nobarrier, discard) EXT4 (nobarrier, discard)
počet klientů
transakcízavteřinu

31. 0 2 4 6 8 10 12 14 16 18
0
1000
2000
3000
4000
5000
6000
pgbench / large (16GB) read-write
ZFS (recordsize, logbias) F2FS (nobarrier, discard)
BTRFS (ssd, nobarrier, discard, nodatacow) ReiserFS (nobarrier)
XFS (nobarrier, discard) EXT4 (nobarrier, discard)
počet klientů
transakcízavteřinu

32. 0 50 100 150 200 250 300
0
1000
2000
3000
4000
5000
6000
7000
Write barriers
ext4 and xfs (defaults, noatime)
ext4 (barrier) ext4 (nobarrier) xfs (barrier) xfs (nobarrier)
čas benchmarku (vteřina)
transakcízavteřinu

33. Variabilita výkonu

34. 0 50 100 150 200 250 300
0
1000
2000
3000
4000
5000
6000
7000
pgbench / large (16GB) read-write
počet transakcí po vteřinách
btrfs (ssd, nobarrier, discard) btrfs (ssd, nobarrier, discard, nodatacow)
ext4 (nobarrier, discard) xfs (nobarrier, discard)
zfs (recordsize, logbias)
doba benchmarku (vteřina)
transakcízavteřinu

35. 4kB vs. 8kB

36. discard nodiscard
0
1000
2000
3000
4000
5000
3115 3128
4052 4111
PostgreSQL se 4kB a 8kB stránkami
pgbench read-write, 16 klientů, scale 5000 (~80GB)
8 kB 4 kB

37. 8 kB 4 kB
0
200
400
600
800
1000
1200
962
805
Host_Writes_32MB vs. 4kB/8kB stránky
množství dat zapsaných na SSD (4 hodiny)
GBs

38. 8 kB 4 kB
0
200
400
600
800
1000
1200
962
805
962
612
Host_Writes_32MB vs. 4kB/8kB stránky
množství dat zapsaných na SSD (4 hodiny)
raw compensated
GBs

39. EXT / XFS
● obdobné chování
– víceméně kompromis propustnost-latence
– EXT4 – vyšší propustnost, větší fluktuace
– XFS – nižší propustnost, menší fluktuace
● zásadní vliv “write barriers”
– vyžaduje spolehlivé disky / RAID řadič s BBU
● minimální impact TRIM
– záleží na modelu SSD (různý over-provisioning atd.)
– záleží na tom jak “plné” SSD je
– benchmark nemaže data (přepisuje stránky)

40. BTRFS, ZFS
● značná cena za vlastnosti (založené na CoW)
– zhruba 50% redukce výkonu při zápisech
● BTRFS
– všechny problémy na které jsem narazil byly na BTRFS
– dobré: žádné data corruption problémy (ale netestováno)
– špatné: nestabilní a nekonzistentní chování
● ZFS
– cizinec ve světě Linuxu
– daleko vyzrálejší než BTRFS, pěkné stabilní chování
– ZFSonLinux projekt aktivně vyvíjen (aktuální 0.6.5, testováno 0.6.3)

41. Závěr

42. Závěr
● pokud vám stačí tradiční souborový systém
– použijte EXT4/XFS, podle preferencí vaší distribuce
– žádné zásadní rozdíly, určitě jde “vytunit” na stejný výkon
– vyplatí se věnovat čas tuningu
● pokud využijete “advanced” vlastnosti
– např. snapshotting, integraci LVM apod.
– ZFS je dobrá volba (možná např. ve FreeBSD)
– BTRFS (zatím) jednoznačně nedoporučuji

43. Otázky?

44. 0 2 4 6 8 10 12 14 16 18
0
1000
2000
3000
4000
5000
6000
pgbench / large (16GB) read-write
ext4 (noatime, discard, nobarrier)
cfq noop deadline
počet klientů
transakcízavteřinu

45. 0 200 400 600 800 1000 1200
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
pgbench / large (16GB) read-write (16 clients)
průměrná latence
cfq noop deadline
doba benchmarku (vteřina)
latence[ms]

46. 0 50 100 150 200 250 300
0
2
4
6
8
10
12
14
16
18
20
pgbench / large read-write (16 clients)
rozptyl (STDDEV) latencí
cfq noop deadline
doba benchmarku (vteřina)
rozptyllatencí(ms)

47. BTRFS, ZFS
Tasks: 215 total, 2 running, 213 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0%us, 12.6%sy, 0.0%ni, 87.4%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 16432096k total, 16154512k used, 277584k free, 9712k buffers
Swap: 2047996k total, 22228k used, 2025768k free, 15233824k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
24402 root 20 0 0 0 0 R 99.7 0.0 2:28.09 kworker/u16:2
24051 root 20 0 0 0 0 S 0.3 0.0 0:02.91 kworker/5:0
1 root 20 0 19416 608 508 S 0.0 0.0 0:01.02 init
2 root 20 0 0 0 0 S 0.0 0.0 0:09.10 kthreadd
...
Samples: 59K of event 'cpu­clock', Event count (approx.): 10269077465
Overhead Shared Object Symbol
37.47% [kernel] [k] btrfs_bitmap_cluster
30.59% [kernel] [k] find_next_zero_bit
26.74% [kernel] [k] find_next_bit
1.59% [kernel] [k] _raw_spin_unlock_irqrestore
0.41% [kernel] [k] rb_next
0.33% [kernel] [k] tick_nohz_idle_exit
...

48. BTRFS, ZFS
$ df /mnt/ssd­s3700/
Filesystem 1K­blocks Used Available Use% Mounted on
/dev/sda1 97684992 71625072 23391064 76% /mnt/ssd­s3700
$ btrfs filesystem df /mnt/ssd­s3700
Data: total=88.13GB, used=65.82GB
System, DUP: total=8.00MB, used=16.00KB
System: total=4.00MB, used=0.00
Metadata, DUP: total=2.50GB, used=2.00GB <= full (0.5GB for btrfs)
Metadata: total=8.00MB, used=0.00
: total=364.00MB, used=0.00
$ btrfs balance start ­dusage=10 /mnt/ssd­s3700
https://btrfs.wiki.kernel.org/index.php/Balance_Filters

49. EXT3/4, XFS
● Linux Filesystems: Where did they come from?
(Dave Chinner @ linux.conf.au 2014)
https://www.youtube.com/watch?v=SMcVdZk7wV8
● Ted Ts'o on the ext4 Filesystem
(Ted Ts'o, NYLUG, 2013)
https://www.youtube.com/watch?v=2mYDFr5T4tY
● XFS: There and Back … and There Again?
(Dave Chinner @ Vault 2015)
https://lwn.net/Articles/638546/
● XFS: Recent and Future Adventures in Filesystem Scalability
(Dave Chinner, linux.conf.au 2012)
https://www.youtube.com/watch?v=FegjLbCnoBw
● XFS: the filesystem of the future?
(Jonathan Corbet, Dave Chinner, LWN, 2012)
http://lwn.net/Articles/476263/