Pg+dSpam: zvyseni vykonu

Tomas Vondra tv na fuzzy.cz
Úterý Prosinec 13 14:14:15 CET 2011


On 13 Prosinec 2011, 13:33, Jan Kasprzak wrote:
> Tomas Vondra wrote:
> : Jasně, ale je to hodně vágní formulace a přístup core týmu je takový že
> : pokud něco nelze implementovat tak aby to části prokazatelně pomohlo a
> : zbytku neškodilo, tak se to nechá jako vypnuté.
>
> 	Ono by taky stacilo (zvlast v pripade dSpamu, ktery bezi
> podle vseho v AutoCommitu) neodhadovat ty siblings, ktere muzou patrit
> kdovijakym dlouhodobym transakcim, ale divat se zejmena na ty autocommity,
> protoze tam vime, ze se je snazime vyridit co HW da, a vime, ze nebudeme
> cekat na klienta.
>
> 	Nebo odhadovat kolik casu tahle transakce zatim stravila cekanim
> na I/O (ne na klienta) a dovolit si treba jeste 20 % z toho pockat s tim
> fsync.
> Nebo zjistovat kolik % casu cekani cele databaze na I/O jsou bezne
> I/O operace, a kolik % casu je fsync(). A chovat se tak, aby ten fsync()
> nebyl vetsina cekani.
>
> 	Ale mozna je tam fakt jeste nejaky dalsi problem ktery ted nevidim.
> Jen tak strilim od boku.

Nevím. Problém je že v PostgreSQL obecně zatím nejsou k dispozici
informace kolik času daný backend strávil čekáním na I/O - mimo jiné i
proto že gettimeofday je na některých systémech dost pomalý, a volání
před/po každém bufferu je pak značná zátěž. Na Linuxu to díky vsyscall
není většinou až takový problém, ale jsou systémy kde EXPLAIN ANALYZE
zabere 10x tolik času co prosté spuštění dotazu.

Je možné že v některé další verzi už tohle bude řešené, ale nevím že by se
něco takového dělo a mně osobně ladění přes delay+siblings zatím stačí.

> 	Jeste teda zpatky k tem checkpointum: neni to naopak tak, ze ja
> vlastne chci at databaze zapisuje jen do WAL, pokud to jde (sekvencne,
> rychle,
> hodne transakci) a az to fakt nejde jinak, tak naraz at zapisuje do
> datafilu,
> pricemz necha OS at si ty pozadavky setridi jak chce, a tim vytizi disky
> na 100 %? A nevadi mi, ze dSpam jednou za 5 minut pobezi minutu, pokud
> toho celkove zvladnu 5x tolik.

To je otázka na kterou neexistuje jednoznačná odpověď - ladění checkpointu
je o hledání kompromisu mezi latencí a propustností. Na jednom konci je
systém s nízkou latencí, tj. průběžně odpovídající klientům, na druhém
konci je systém celkový průměrný tps je o něco vyšší ale latence hodně
skáče a může být i několik minut "mrtvý" protože došlo k checkpointu a na
disk se tlačí hrozně moc dat. Osobně jsem příznivcem první varianty, pokud
s tím nějak (byť) minimálně interagují uživatelé (např. chtějí
odesílat/přijímat poštu).

1) nízká latence
----------------
/proc/sys/vm/dirty_background_bytes = 134217728 (128MB)
/proc/sys/vm/dirty_bytes = 1073741824 (1GB)
/proc/sys/vm/dirty_expire_centiseconds = 500 (5 vteřin)
shared_buffers = 5GB
checkpoint_segments = 64
checkpoint_timeout = 30m
checkpoint_completion_target = 0.9 (postupný checkpoint)

2) vysoká celková propustnost
-----------------------------
/proc/sys/vm/dirty_background_bytes = 1073741824 (1GB)
/proc/sys/vm/dirty_bytes = 4294967296 (4GB)
/proc/sys/vm/dirty_expire_centiseconds = 6000 (60 vteřin)
shared_buffers = 5GB
checkpoint_segments = 64
checkpoint_timeout = 30m
checkpoint_completion_target = 0 (všechno hned)

Ale je třeba si s tím hrát. Princip je takový že pokud zkrátíte
checkpoint_completion_target (0 znamená "zapiš všechno hned" a např. 0.9
znamená "rozlož checkpoint tak aby byl dokončen v 90% času do dalšího
checkpointu") a zvětšíte write cache v page cache, tím vyšší propustnost
dostanete ale o to větší problémy čekejte. IMHO je ale lepší první
přístup.

Tomáš



Další informace o konferenci Linux