PostgreSQL na EXT3/4, XFS, BTRFS a ZFS

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

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

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

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

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

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

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

SSD

Souborové systémy

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

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)

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

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.)

Obecné mount options

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

Specifické mount options

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

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...

Benchmark

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)

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

Ale to není reprezentativní!

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

pgbench read-only

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

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

pgbench read-write

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

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

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

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

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

Variabilita výkonu

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

4kB vs. 8kB

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

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

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

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)

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)

Závěr

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

Otázky?

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

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

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

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...

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 Metadata: total=8.00mb, used=0.00 : total=364.00mb, used=0.00 <= full (0.5GB for btrfs) $ btrfs balance start dusage=10 /mnt/ssd s3700 https://btrfs.wiki.kernel.org/index.php/balance_filters

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/