it-swarm-eu.dev

Konfigurace PostgreSQL pro výkon zápisu

Jeden z mých serverů PostgreSQL hostí několik (1-3) databází, které přijímají konstantní tok dat. Data nejsou nijak zvlášť strukturovaná, jedná se o aktuální čas a různé pozorované údaje pro tento konkrétní okamžik. Rychlost dat je poměrně vysoká; pro jednu databázi to vyjde asi na 1 gigabajt denně, na další desetinu. Neočekávám, že se tato sazba zvýší. Výkon čtení je mnohem nižší prioritou a je v současné době přijatelný.

V protokolech mám tuto zprávu:

LOG:  checkpoints are occurring too frequently (15 seconds apart)
HINT:  Consider increasing the configuration parameter "checkpoint_segments".

Tato hodnota je aktuálně nastavena na 16, což je s laskavým svolením pgtune.

Jaká nastavení bych měl zvážit pro zlepšení výkonu zápisu? Raději bych ponechal co nejvíce bezpečnosti. S ohledem na objem přicházejících dat bych mohl přijít o ztrátu některých nedávných dat v selhání, pokud by byla většina dat neporušená.

Edit: Momentálně používám PostgreSQL 9.0, ale plánuji upgradovat na 9.1. Nezveřejňuji podrobnosti o hardwaru, protože i když uznávám jejich význam, nakonec budu muset provést tuto optimalizaci na několika počítačích s velmi rozmanitým hardwarem. Je-li hardware pro odpověď nezbytný, uveďte mi obecné informace, abych mohl odpovědět na stroje s různou konfigurací hardwaru.

30
Daniel Lyons

1 Gigabajt den není tak vysoké zatížení zápisu. Rozloženo po celý den, to vyjde na asi 50 kB za sekundu. To by zvládla pomalá USB palcová jednotka. Předpokládám však, že je to více prasklé. Jak naznačuje a_horse_with_no_name, zvyšte segmenty kontrolního bodu. 100 nebo tak není neobvyklé.

Poté zvyšte své checkpoint_timeout na 1 hodinu a také se podívejte na zvýšení vaší checkpoint_completion_target na něco blíže k 1,0 (100%). Cíl dokončení říká PostgreSQL, jak agresivně psát na pozadí, takže je x% dokončeno před spuštěním kontrolního bodu, což nutí všechna data, která mají být zapsána, okamžitě z WAL a zpomalí systém k procházení, zatímco se to děje.

Důvod, proč jej obvykle nenastavíte na 100%, je ten, že je docela běžné zapisovat do stejného bloku více než jednou, a odložením zápisu WAL do hlavního obchodu zabráníte tomu, aby se stejný blok zapisoval dvakrát bez důvodu.

Pokud je nepravděpodobné, že do stejného bloku zapíšete více než jednou, než dojde k vypršení časového limitu, tj. Vše, co uděláte, je vložit a poté nastavit docela vysoko, má smysl ho zvýšit na 0,9. Nejhorší, co se stane, je, že budete psát trochu častěji, než byste mohli jinak potřebovat, ale dopad kontrolních bodů se výrazně sníží.

24
Scott Marlowe

Ve velmi 'psát těžký' systém, budete pravděpodobně omezeni rychlostí WAL lze psát během aktivity vrcholu.

Pokud opravdu dokážete „přijít o ztrátu některých nedávných dat v selhání“, můžete vypnout synchronní potvrzení které:

může být užitečnou alternativou, pokud je výkon důležitější než přesná jistota o trvanlivosti transakce

Pokud dokážete změnit hardware, můžete zvážit některé z nich pro optimalizaci zápisů:

  • RAID10 nad RAID5
  • Spousta vřeten (například může znamenat 2,5 "místo 3,5")
  • SAS přes SATA
  • Jednotky 15 kB až 10 kB
  • SSD

--Upravit

Na základě vašeho komentáře k @ Scottova vynikající odpověď : "Objem zápisu je ve skutečnosti téměř zcela jednotný" a předpokládaná rychlost přenosu dat "50 kbytů za sekundu", pochybuji, že musíte udělat cokoli, co riskuje data ztráta. Možná by pomohlo zjistit, jaké jsou některé z vašich dalších konfiguračních parametrů.

Můžete také zkontrolovat frekvenci/velikost vašich závazků: ​​Nedávno jsem narazil na problém, ve kterém jsem se pokoušel aktualizovat> 1 milion záznamů v jedné transakci. Dostal jsem log zprávy podobné těm, které popisuje OP, ale transakce nemohla být dokončena ani po několika hodinách. Když jsem rozdělil zápis na několik menších transakcí (10 000 záznamů nebo tak podobně), celkový požadovaný čas se snížil na asi 15 minut.

Co se stalo myslím, bylo to, že Postgres strávil tolik času psaním protokolů, které checkpoint_timeout ​​ uplynulo dříve, než to mohlo podstatně ušetřit pokrok záznamy. Nejsem si jistý, jestli toto vysvětlení trvá. Stále dostávám varování, ale všechny zápisy jsou nakonec zpracovány. Potřeboval jsem (a našel) programové řešení, a ne ten, který vyžaduje rekonfiguraci databáze.

Viz také http://www.postgresql.org/docs/9.3/static/wal-configuration.html

5
Sarah Messer