Řízení výkonu pro PostgreSQL s HAProxy

Výkon databáze je velmi důležitým problémem při údržbě vašeho databázového clusteru, zvláště když se postupem času rozrůstá. To platí zejména v případě, že vaše aplikace začínala s nízkým provozem, který pak rostl na střední nebo velké zatížení čtení a zápisu.

Mějte na paměti, že neexistuje žádná dokonalá konfigurace, na kterou byste se mohli dlouhodobě spolehnout, protože určité pracovní zátěže se mohou v průběhu času měnit.

Pomocí ClusterControl se při vytváření nebo nasazení nového databázového clusteru PostgreSQL provede základní analýza, jako je kontrola hardwarových prostředků, poté se použije automatické ladění a nastaví se hodnoty pro vybrané laditelné parametry. Jak se PostgreSQL vyvíjí, bylo vyvinuto také mnoho nástrojů pro podporu různých konfigurací, zejména pro vyrovnávání zátěže.

V tomto blogu se podíváme na důležitost HAProxy a na to, jak může pomoci zvýšit výkon. Je to starý nástroj, ale výkonný proxy a/nebo load balancer, který podporuje nejen databázové servery, ale také protokoly specifické pro síťové aplikace. HAProxy může fungovat přes vrstvu čtyři a sedmou, v závislosti na typu nastavení založeném na konfiguraci.

Ladění výkonu PostgreSQL

Jeden z primárních faktorů pro řízení výkonu pro PostgreSQL začíná laděním základních parametrů z initdb na hodnoty parametrů za běhu. To musí být schopno zvládnout požadovanou pracovní zátěž v souladu s vašimi určitými požadavky. Než se budeme moci vydat na cestu pro funkci HAProxy pro PostgreSQL, váš databázový server musí být stabilní a vyladěný na požadované proměnné. Podívejme se na seznam oblastí pro PostgreSQL, které jsou věci, které mohou ovlivnit výkon vašeho databázového serveru.

Ladění pro proveditelnou správu paměti

PostgreSQL je efektivní a lze jej efektivně provozovat již na 256Mb paměti. Paměť není drahá, přesto je většina datových sad menší než 4Gib. Pokud máte alespoň 4Gib, vaše aktivní datová sada může zůstat v mezipaměti souboru a/nebo sdílené vyrovnávací paměti.

Vyladění PostgreSQL pro správu paměti je jednou z nejzákladnějších a nejzákladnějších věcí, které musíte nastavit. Správné nastavení může mít vliv na zvýšení výkonu vašeho databázového serveru. I když záleží na tom, s jakými stoly hrajete. Špatné dotazy a špatné definice tabulek mohou také vést ke špatnému výkonu. Se správnými indexy definovanými pro vaše tabulky a s dotazy odkazujícími na indexy může být šance získat 80 % až 100 % dotazů z vaší paměti. To zejména v případě, že vyrovnávací paměť indexu má správnou hodnotu pro načtení vašeho indexu definovaného ve vašich tabulkách. Podívejme se na parametry, které se běžně nastavují pro zlepšení výkonu.

shared_buffers - PostgreSQL zvětšuje svůj hlavní paměťový prostor pomocí sdílených vyrovnávací paměti. Pracovní mezipaměť všech hot-tple (a položek indexu) v PostgreSQL. Tento parametr nastavuje množství paměti, kterou databázový server používá pro vyrovnávací paměti sdílené paměti. Je to předem přidělená mezipaměť (vyrovnávací paměti). Pro systémy založené na Linuxu je ideální nastavit parametr jádra kernel.shmmax, který lze trvale nastavit pomocí konfiguračního souboru jádra /etc/sysctl.conf.
temp_buffers - Nastavuje maximální počet dočasných vyrovnávacích pamětí použitých pro každou relaci. Jedná se o místní vyrovnávací paměti relací používané pouze pro přístup k dočasným tabulkám. Relace přiřadí dočasné vyrovnávací paměti podle potřeby až do limitu daného temp_buffers.
work_mem - Pracovní paměť dostupná pro pracovní operace (třídění) před PostgreSQL se vymění. Nenastavujte globálně (postgresql.conf). Použijte na transakci, protože to může být špatné na dotaz, na připojení nebo na řazení. Doporučuje se použít EXPLAIN ANALYZE, abyste zjistili, zda přetékáte nebo ne.
maintenance_work_mem – Určuje množství paměti, které se má použít pro operace údržby (VACUUM, CREATE INDEX a ALTER TABLE … PŘIDAT FOREIGN KEY…)

Ladění pro proveditelnou správu disků

Tady lze nastavit řadu parametrů běhu. Pojďme si vyjmenovat, co to je:

limit_temp_file_limit - Určuje maximální množství místa na disku, které může relace použít pro dočasné soubory, jako jsou dočasné soubory řazení a hash nebo soubor úložiště pro podržený kurzor. Transakce, která se pokusí překročit tento limit, bude zrušena.
fsync - Pokud je fsync povoleno, PostgreSQL se pokusí zajistit, aby byly aktualizace fyzicky zapsány na disk. To zajišťuje, že po zhroucení operačního systému nebo hardwaru lze databázový cluster obnovit do konzistentního stavu. I když deaktivace fsync obecně zlepšuje výkon, může způsobit ztrátu dat v případě výpadku napájení nebo zhroucení systému. Proto je vhodné deaktivovat fsync pouze tehdy, pokud můžete snadno znovu vytvořit celou databázi z externích dat
synchronous_commit - Používá se k vynucení toho, že potvrzení bude čekat na zapsání WAL na disk, než vrátí klientovi stav úspěchu. Tato proměnná má kompromisy mezi výkonem a spolehlivostí. Pokud potřebujete vyšší výkon, nastavte toto na vypnuto, což znamená, že když server havaruje, má tendenci ke ztrátě dat. V opačném případě, pokud je důležitá spolehlivost, zapněte. To znamená, že mezi stavem úspěchu a zaručeným zápisem na disk bude časová mezera, což může ovlivnit výkon.
checkpoint_timeout, checkpoint_completion_target - PostgreSQL zapisuje změny do WAL, což je nákladná operace. Pokud často zapisuje změny do WAL, může to mít špatný dopad na výkon. Takže jak to funguje, proces kontrolního bodu vyprázdní data do datových souborů. Tato činnost se provádí, když nastane CHECKPOINT a může způsobit velké množství IO. Celý tento proces zahrnuje drahé operace čtení/zápisu na disk. I když vy (administrátor) můžete vždy vydat CHECKPOINT, kdykoli to bude nutné, nebo jej zautomatizovat nastavením požadovaných hodnot pro tyto parametry. Parametr checkpoint_timeout se používá k nastavení času mezi kontrolními body WAL. Nastavení této hodnoty na příliš nízkou hodnotu zkracuje dobu obnovy po havárii, protože se na disk zapisuje více dat, ale také to snižuje výkon, protože každý kontrolní bod spotřebovává cenné systémové zdroje. Checkpoint_completion_target je zlomek času mezi kontrolními body pro dokončení kontrolního bodu. Vysoká frekvence kontrolních bodů může ovlivnit výkon. Pro hladké kontrolní bod musí mít checkpoint_timeout nízkou hodnotu. V opačném případě bude operační systém hromadit všechny špinavé stránky, dokud nebude poměr splněn, a poté dojde k velkému propláchnutí.

Ladění dalších parametrů pro výkon

Existují určité parametry, které poskytují podporu a podporu výkonu v PostgreSQL. Níže si uveďme, co to je:

wal_buffers - PostgreSQL zapíše svůj záznam WAL (zápis dopředu) do vyrovnávacích pamětí a tyto vyrovnávací paměti jsou poté vyprázdněny na disk. Výchozí velikost vyrovnávací paměti, definovaná pomocí wal_buffers, je 16 MB, ale pokud máte mnoho souběžných připojení, vyšší hodnota může poskytnout lepší výkon.
effective_cache_size - Efektivní_cache_size poskytuje odhad paměti dostupné pro ukládání do mezipaměti disku. Je to pouze vodítko, nikoli přesná přidělená paměť nebo velikost mezipaměti. Nepřiděluje skutečnou paměť, ale informuje optimalizátor o množství dostupné mezipaměti v jádře. Pokud je tato hodnota nastavena příliš nízko, může se plánovač dotazů rozhodnout některé indexy nepoužívat, i když by byly užitečné. Nastavení velké hodnoty je proto vždy výhodné.
default_statistics_target - PostgreSQL shromažďuje statistiky z každé tabulky ve své databázi, aby rozhodl, jak se na ně budou provádět dotazy. Ve výchozím nastavení neshromažďuje příliš mnoho informací, a pokud nedostáváte dobré plány provádění, měli byste tuto hodnotu zvýšit a poté znovu spustit ANALYZE v databázi (nebo počkat na AUTOVACUUM).

Efektivita dotazů PostgreSQL

PostgreSQL má velmi výkonnou funkci pro optimalizaci dotazů. S vestavěným Genetic Query Optimizer (známým jako GEQO). Využívá genetický algoritmus, což je metoda heuristické optimalizace prostřednictvím náhodného vyhledávání. To se používá při provádění optimalizace pomocí JOINů, které poskytují velmi dobrou optimalizaci výkonu. Každý kandidát v plánu spojení je reprezentován posloupností, ve které se má připojit k základním vztahům. Náhodně provádí genetický vztah jednoduše generováním nějaké možné spojovací sekvence, ale náhodně.

Pro každou uvažovanou sekvenci spojení je vyvolán standardní kód plánovače, aby se odhadly náklady na provedení dotazu pomocí této sekvence spojení. Takže pro každou ze sekvencí JOIN mají všechny své původně určené plány skenování vztahů. Potom plán dotazů vypočítá nejschůdnější a nejvýkonnější plán, tj. s nižšími odhadovanými náklady a považuje se za „vhodnější“ než ty s vyššími náklady.

Vzhledem k tomu, že má výkonnou funkci integrovanou v PostgreSQL a správně nakonfigurované parametry v souladu s vašimi požadovanými požadavky, nenarušuje proveditelnost, pokud jde o výkon, pokud je zatížení přenášeno pouze na primární uzel. Vyvažování zátěže pomocí HAProxy pomáhá ještě více zvýšit výkon PostgreSQL.

Zvýšení výkonu pro PostgreSQL pomocí rozdělení čtení a zápisu

Můžete mít skvělý výkon při práci s uzlem serveru PostgreSQL, ale možná nebudete schopni předvídat, jaký typ zátěže byste mohli mít, zvláště když je vysoká návštěvnost a poptávka překračuje hranice. Vyvážení zátěže mezi primární a sekundární poskytuje zvýšení výkonu vaší aplikace a/nebo klientů připojujících se k vašemu databázovému clusteru PostgreSQL. Jak to lze provést, již není otázkou, protože jde o velmi běžné nastavení pro vysokou dostupnost a redundanci, pokud jde o distribuci zátěže a zabránění uvíznutí primárního uzlu kvůli zpracování vysoké zátěže.

Nastavení pomocí HAProxy je snadné. S ClusterControl je to však efektivnější a rychlejší. Použijeme ClusterControl, abychom to nastavili.

Nastavení PostgreSQL pomocí HAProxy

Aby to bylo možné, budeme muset nainstalovat a nastavit HAProxy nad clustery PostgreSQL. HAProxy má funkci pro podporu PostgreSQL prostřednictvím volby pgsql-check, ale její podpora je velmi jednoduchá implementace pro určení, zda je uzel aktivní nebo ne. Nemá kontroly pro identifikaci primárního a obnovovacího uzlu. Možností je použít xinetd, u kterého se budeme spoléhat na to, že HAProxy bude naslouchat prostřednictvím naší služby xinetd, která kontroluje stav konkrétního uzlu v našem clusteru PostgreSQL.

V části ClusterControl přejděte na Spravovat → Load Balancer stejně jako níže,

Potom postupujte podle uživatelského rozhraní podle níže uvedeného snímku obrazovky. Můžete kliknout na Zobrazit pokročilá nastavení a zobrazit pokročilejší možnosti. Sledování uživatelského rozhraní je však velmi jednoduché. Viz níže,

Importuji pouze jeden uzel HAProxy bez redundance, ale za účelem tento blog, pojďme to zjednodušit.

Můj ukázkový pohled HAProxy je uveden níže

Jak je uvedeno výše, 192.168.30.20 a 192.168.30.30 jsou primární a sekundární/obnovovací uzly, v tomto pořadí. Zatímco HAProxy je nainstalován v sekundárním/obnovovacím uzlu. V ideálním případě byste mohli nainstalovat svůj HAProxy na více uzlů, abyste měli větší redundanci a vysokou dostupnost, nejlepší je izolovat jej proti uzlům databáze. Pokud máte omezený rozpočet nebo šetříte své použití, můžete se rozhodnout nainstalovat uzly HAProxy, kde jsou nainstalovány i uzly vaší databáze.

ClusterControl to nastaví automaticky a obsahuje také službu xinetd pro kontrolu PostgreSQL. To lze ověřit pomocí netstat stejně jako níže,

[email protected]:~# netstat -tlv4np|grep haproxy

tcp        0      0 0.0.0.0:5433            0.0.0.0:*               LISTEN      28441/haproxy

tcp        0      0 0.0.0.0:5434            0.0.0.0:*               LISTEN      28441/haproxy

tcp        0      0 0.0.0.0:9600            0.0.0.0:*               LISTEN      28441/haproxy

Přičemž port 5433 je pro čtení a zápis a 5444 je pouze pro čtení.

Pro PostgreSQL zkontrolujte službu xinetd, konkrétně postgreshk, jak je vidět níže,

[email protected]:~# cat /etc/xinetd.d/postgreschk

# default: on

# description: postgreschk

service postgreschk

{

        flags           = REUSE

        socket_type     = stream

        port            = 9201

        wait            = no

        user            = root

        server          = /usr/local/sbin/postgreschk

        log_on_failure  += USERID

        disable         = no

        #only_from       = 0.0.0.0/0

        only_from       = 0.0.0.0/0

        per_source      = UNLIMITED

}

Služby xinetd také spoléhají na /etc/services, takže možná budete moci najít port, který je určen k mapování.

[email protected]:~# grep postgreschk /etc/services

postgreschk        9201/tcp

Pokud potřebujete změnit port vašeho postgreschku, na jaký port se má mapovat, musíte změnit i tento soubor kromě konfiguračního souboru služby a poté nezapomeňte restartovat démona xinetd.

Služba postgreschk obsahuje odkaz na externí soubor, který v podstatě kontroluje uzly, zda je zapisovatelný, což znamená, že je primární nebo hlavní. Pokud je uzel v obnově, pak je to replika nebo obnovovací uzel.

[email protected]:~# cat /usr/local/sbin/postgreschk

#!/bin/bash

#

# This script checks if a PostgreSQL server is healthy running on localhost. It will

# return:

# "HTTP/1.x 200 OK\r" (if postgres is running smoothly)

# - OR -

# "HTTP/1.x 500 Internal Server Error\r" (else)

#

# The purpose of this script is make haproxy capable of monitoring PostgreSQL properly

#



export PGHOST='localhost'

export PGUSER='s9smysqlchk'

export PGPASSWORD='password'

export PGPORT='7653'

export PGDATABASE='postgres'

export PGCONNECT_TIMEOUT=10



FORCE_FAIL="/dev/shm/proxyoff"



SLAVE_CHECK="SELECT pg_is_in_recovery()"

WRITABLE_CHECK="SHOW transaction_read_only"



return_ok()

{

    echo -e "HTTP/1.1 200 OK\r\n"

    echo -e "Content-Type: text/html\r\n"

    if [ "$1x" == "masterx" ]; then

        echo -e "Content-Length: 56\r\n"

        echo -e "\r\n"

        echo -e "<html><body>PostgreSQL master is running.</body></html>\r\n"

    elif [ "$1x" == "slavex" ]; then

        echo -e "Content-Length: 55\r\n"

        echo -e "\r\n"

        echo -e "<html><body>PostgreSQL slave is running.</body></html>\r\n"

    else

        echo -e "Content-Length: 49\r\n"

        echo -e "\r\n"

        echo -e "<html><body>PostgreSQL is running.</body></html>\r\n"

    fi

    echo -e "\r\n"



    unset PGUSER

    unset PGPASSWORD

    exit 0

}



return_fail()

{

    echo -e "HTTP/1.1 503 Service Unavailable\r\n"

    echo -e "Content-Type: text/html\r\n"

    echo -e "Content-Length: 48\r\n"

    echo -e "\r\n"

    echo -e "<html><body>PostgreSQL is *down*.</body></html>\r\n"

    echo -e "\r\n"



    unset PGUSER

    unset PGPASSWORD

    exit 1

}



if [ -f "$FORCE_FAIL" ]; then

    return_fail;

fi



# check if in recovery mode (that means it is a 'slave')

SLAVE=$(psql -qt -c "$SLAVE_CHECK" 2>/dev/null)

if [ $? -ne 0 ]; then

    return_fail;

elif echo $SLAVE | egrep -i "(t|true|on|1)" 2>/dev/null >/dev/null; then

    return_ok "slave"

fi



# check if writable (then we consider it as a 'master')

READONLY=$(psql -qt -c "$WRITABLE_CHECK" 2>/dev/null)

if [ $? -ne 0 ]; then

    return_fail;

elif echo $READONLY | egrep -i "(f|false|off|0)" 2>/dev/null >/dev/null; then

    return_ok "master"

fi



return_ok "none";

Kombinace uživatel/heslo musí být platná ROLE na vašem PostgreSQL serveru. Protože instalujeme přes ClusterControl, je to řešeno automaticky.

Nyní, když máme kompletní instalaci HAProxy, toto nastavení nám umožňuje mít rozdělení pro čtení a zápis, kdy čtení a zápis směřují do primárního nebo zapisovatelného uzlu, zatímco pouze pro čtení pro primární i sekundární/ zotavovací uzly. Toto nastavení neznamená, že je již výkonné, stále bylo vyladěno, jak bylo diskutováno dříve, s kombinací HAProxy pro vyrovnávání zátěže přidává další zvýšení výkonu pro vaši aplikaci a příslušné databázové klienty.