Rijprestaties voor PostgreSQL met HAProxy

Databaseprestaties zijn een zeer belangrijk punt van zorg bij het onderhouden van uw databasecluster, vooral omdat het in de loop van de tijd groeit. Dit is met name het geval als uw toepassing begon met weinig verkeer en vervolgens uitgroeide tot matige of zware lees-schrijf-workloads.

Het ding om te onthouden is dat er geen perfecte configuratie is waar je lang op kunt vertrouwen, omdat bepaalde workloads in de loop van de tijd kunnen veranderen.

Met ClusterControl voert het maken of implementeren van een nieuw PostgreSQL-databasecluster een basisanalyse uit, zoals het controleren van uw hardwarebronnen, past vervolgens auto-tuning toe en stelt de waarden in voor de geselecteerde afstembare parameters. Naarmate PostgreSQL evolueert, zijn er ook veel tools ontwikkeld om verschillende configuraties te ondersteunen, met name voor taakverdeling.

In deze blog gaan we in op het belang van HAProxy en hoe het de prestaties kan helpen verbeteren. Het is een oude tool, maar toch een krachtige proxy en/of load balancer die niet alleen databaseservers ondersteunt, maar ook netwerktoepassingsspecifieke protocollen. HAProxy kan werken via respectievelijk laag vier en laag zeven, afhankelijk van het type installatie op basis van de configuratie.

PostgreSQL-prestaties afstemmen

Een van de belangrijkste factoren voor het aansturen van de prestaties voor PostgreSQL begint met het afstemmen van de basisparameters van initdb op runtime-parameterwaarden. Deze moet de gewenste werklast kunnen verwerken in overeenstemming met uw bepaalde vereisten. Voordat we op weg kunnen gaan naar de HAProxy-functie voor PostgreSQL, moet uw databaseserver stabiel zijn en afgestemd op de gewenste variabelen. Laten we een lijst maken met onderwerpen voor PostgreSQL over wat dingen zijn die van invloed kunnen zijn op het prestatievermogen van uw databaseserver.

Afstemming voor haalbaar geheugenbeheer

PostgreSQL is efficiënt en kan effectief worden uitgevoerd in slechts 256 MB geheugen. Geheugen is niet duur, maar de meeste datasets zijn minder dan 4Gib. Als je minimaal 4Gib hebt, kan je actieve dataset in file en/of shared_buffer cache blijven.

Het afstemmen van je PostgreSQL voor geheugenbeheer is een van de meest primaire en basale dingen die je moet instellen. Als u dit op de juiste manier instelt, kan dit van invloed zijn op het verbeteren van de prestaties van uw databaseserver. Hoewel het afhangt van wat voor soort tafels je speelt. Slechte query's en slechte tabeldefinities kunnen ook leiden tot slechte prestaties. Met de juiste indexen gedefinieerd voor uw tabellen en met query's die verwijzen naar indexen, kunnen de kansen oplopen van 80% - 100% van de query's kunnen uit uw geheugen worden opgehaald. Dit vooral als de indexbuffer de juiste waarde heeft om uw index te laden die op uw tabellen is gedefinieerd. Laten we eens kijken naar de parameters die gewoonlijk worden ingesteld voor prestatieverbetering.

shared_buffers - PostgreSQL past zijn hoofdgeheugen aan met shared_buffers. De werkende cache van alle hot tuples (en indexvermeldingen) binnen PostgreSQL. Deze parameter stelt de hoeveelheid geheugen in die de databaseserver gebruikt voor gedeelde geheugenbuffers. Het is een vooraf toegewezen cache (buffers). Voor op Linux gebaseerde systemen is het ideaal om de kernelparameter kernel.shmmax in te stellen, die permanent kan worden ingesteld via het /etc/sysctl.conf kernelconfiguratiebestand.
temp_buffers - Stelt het maximum aantal tijdelijke buffers in dat voor elke sessie wordt gebruikt. Dit zijn lokale sessiebuffers die alleen worden gebruikt om toegang te krijgen tot tijdelijke tabellen. Een sessie zal de tijdelijke buffers naar behoefte toewijzen tot de limiet die wordt gegeven door temp_buffers.
work_mem - Het beschikbare werkgeheugen voor werkbewerkingen (sorteren) voordat PostgreSQL wordt verwisseld. Niet globaal instellen (postgresql.conf). Gebruik per transactie aangezien dit slecht kan zijn per zoekopdracht, per verbinding of per soort. Het gebruik van EXPLAIN ANALYZE wordt aanbevolen om te zien of je overloopt of niet.
maintenance_work_mem - Specificeert de hoeveelheid geheugen die moet worden gebruikt voor onderhoudswerkzaamheden (VACUUM, CREATE INDEX en ALTER TABLE ... ADD FOREIGN KEY ...)

Afstemming voor haalbaar schijfbeheer

Een aantal runtime-parameters om hier in te stellen. Laten we eens opsommen wat dit zijn:

temp_file_limit - Specificeert de maximale hoeveelheid schijfruimte die een sessie kan gebruiken voor tijdelijke bestanden, zoals tijdelijke bestanden sorteren en hashen, of het opslagbestand voor een vastgehouden cursor. Een transactie die deze limiet probeert te overschrijden, wordt geannuleerd.
fsync - Als fsync is ingeschakeld, zal PostgreSQL proberen ervoor te zorgen dat de updates fysiek naar de schijf worden geschreven. Dit zorgt ervoor dat het databasecluster kan worden hersteld naar een consistente staat na een besturingssysteem- of hardwarecrash. Hoewel het uitschakelen van fsync over het algemeen de prestaties verbetert, kan het gegevensverlies veroorzaken in het geval van een stroomstoring of een systeemcrash. Daarom is het alleen raadzaam om fsync te deactiveren als u eenvoudig uw volledige database kunt recreëren op basis van externe gegevens
synchronous_commit - Wordt gebruikt om die commit af te dwingen, wacht tot WAL op schijf is geschreven voordat de client een successtatus krijgt. Deze variabele heeft afwegingen tussen prestaties en betrouwbaarheid. Als u meer prestaties nodig hebt, stelt u dit in op uit, wat betekent dat wanneer de server crasht, de neiging bestaat tot gegevensverlies. Als betrouwbaarheid belangrijk is, zet u dit anders aan. Dit betekent dat er een tijdsverschil zit tussen de successtatus en een gegarandeerde schrijfactie naar schijf, wat dus van invloed kan zijn op de prestaties.
checkpoint_timeout, checkpoint_completion_target - PostgreSQL schrijft wijzigingen in WAL, wat een dure operatie is. Als het regelmatig wijzigingen in WAL schrijft, kan dit een slechte invloed hebben op de prestaties. Dus hoe het werkt, het controlepuntproces spoelt de gegevens in de gegevensbestanden. Deze activiteit wordt uitgevoerd wanneer CHECKPOINT optreedt en kan een enorme hoeveelheid IO veroorzaken. Dit hele proces omvat dure lees-/schrijfbewerkingen voor schijven. Hoewel u (admin-gebruiker) altijd CHECKPOINT kunt gebruiken wanneer het nodig lijkt, of dit kunt automatiseren door de gewenste waarden voor deze parameters in te stellen. De parameter checkpoint_timeout wordt gebruikt om de tijd tussen WAL-controlepunten in te stellen. Als u dit te laag instelt, wordt de hersteltijd voor crashes verkort, omdat er meer gegevens naar de schijf worden geschreven, maar het gaat ook ten koste van de prestaties, aangezien elk controlepunt waardevolle systeembronnen verbruikt. De checkpoint_completion_target is de fractie van de tijd tussen de checkpoints voor het voltooien van de checkpoint. Een hoge frequentie van controlepunten kan de prestaties beïnvloeden. Voor soepele controlepunten moet checkpoint_timeout een lage waarde hebben. Anders verzamelt het besturingssysteem alle vuile pagina's totdat de verhouding is bereikt en gaat het vervolgens voor een grote spoeling.

Andere parameters afstemmen voor prestaties

Er zijn bepaalde parameters die zorgen voor een boost en drive voor prestaties in PostgreSQL. Laten we hieronder opsommen wat dit zijn:

wal_buffers - PostgreSQL schrijft zijn WAL-record (write ahead log) naar de buffers en vervolgens worden deze buffers naar schijf gespoeld. De standaardgrootte van de buffer, gedefinieerd door wal_buffers, is 16 MB, maar als je veel gelijktijdige verbindingen hebt, kan een hogere waarde betere prestaties opleveren.
effectieve_cache_size - De effectieve_cache_grootte geeft een schatting van het geheugen dat beschikbaar is voor schijfcaching. Het is slechts een richtlijn, niet de exacte toegewezen geheugen- of cachegrootte. Het wijst geen daadwerkelijk geheugen toe, maar vertelt de optimizer hoeveel cache er in de kernel beschikbaar is. Als de waarde hiervan te laag is ingesteld, kan de queryplanner besluiten om sommige indexen niet te gebruiken, zelfs als ze nuttig zouden zijn. Daarom is het altijd voordelig om een hoge waarde in te stellen.
default_statistics_target - PostgreSQL verzamelt statistieken van elk van de tabellen in zijn database om te beslissen hoe query's daarop worden uitgevoerd. Standaard verzamelt het niet te veel informatie, en als u geen goede uitvoeringsplannen krijgt, moet u deze waarde verhogen en vervolgens ANALYSE opnieuw in de database uitvoeren (of wachten op de AUTOVACUUM).

PostgreSQL-query-efficiëntie

PostgreSQL heeft een zeer krachtige functie voor het optimaliseren van zoekopdrachten. Met de ingebouwde Genetic Query Optimizer (bekend als GEQO). Het maakt gebruik van een genetisch algoritme dat een heuristische optimalisatiemethode is door middel van willekeurig zoeken. Dit wordt toegepast bij het uitvoeren van optimalisatie met behulp van JOIN's, wat een zeer goede prestatie-optimalisatie oplevert. Elke kandidaat in het lidmaatschapsplan wordt vertegenwoordigd door een volgorde waarin de basisrelaties moeten worden toegevoegd. Het voert willekeurig een genetische relatie uit door simpelweg een mogelijke join-sequentie te genereren, maar willekeurig.

Voor elke beschouwde join-reeks wordt de standaard planner-code aangeroepen om de kosten te schatten van het uitvoeren van de query met behulp van die join-reeks. Dus voor elk van de JOIN-reeksen hebben ze allemaal hun aanvankelijk bepaalde relatiescanplannen. Vervolgens berekent het queryplan het meest haalbare en performante plan, d.w.z. met lagere geschatte kosten en worden ze als "fitter" beschouwd dan die met hogere kosten.

Aangezien het een krachtige functie heeft die is geïntegreerd in PostgreSQL en de juiste geconfigureerde parameters in overeenstemming met uw gewenste vereisten, verslaat het de haalbaarheid niet als het gaat om prestaties als de belasting alleen naar een primaire knoop. Load balancing met HAProxy zorgt voor nog betere prestaties voor PostgreSQL.

Prestaties voor PostgreSQL met splitsen voor lezen en schrijven

Je hebt misschien geweldige prestaties met je PostgreSQL-serverknooppunt, maar je kunt misschien niet anticiperen op wat voor soort werklast je zou kunnen hebben, vooral wanneer veel verkeer toeslaat en de vraag buiten de grenzen valt. Het balanceren van de belasting tussen een primaire en secundaire zorgt voor een prestatieverbetering binnen uw toepassing en/of clients die verbinding maken met uw PostgreSQL-databasecluster. Hoe dit kan, is geen vraag meer, want het is een veel voorkomende opstelling voor een hoge beschikbaarheid en redundantie als het gaat om het verdelen van de belasting en om te voorkomen dat het primaire knooppunt vastloopt als gevolg van hoge belastingverwerking.

Instellen met HAProxy is eenvoudig. Toch is het efficiënter, sneller en haalbaarder met ClusterControl. Daarom gebruiken we ClusterControl om dit voor ons in te stellen.

PostgreSQL instellen met HAProxy

Om dit te doen, hoeven we alleen HAProxy te installeren en in te stellen bovenop de PostgreSQL-clusters. HAProxy heeft een functie om PostgreSQL te ondersteunen via de optie pgsql-check, maar de ondersteuning is een zeer eenvoudige implementatie om te bepalen of een knooppunt actief is of niet. Het heeft geen controles voor het identificeren van een primair en een herstelknooppunt. Een optie is om xinetd te gebruiken waarvoor we zullen vertrouwen op het communiceren van de HAProxy om te luisteren via onze xinetd-service die de gezondheid van een bepaald knooppunt in ons PostgreSQL-cluster controleert.

Navigeer onder ClusterControl naar Beheren → Load Balancer zoals hieronder,

Volg dan gewoon op basis van de gebruikersinterface volgens onderstaand screenshot. U kunt op Geavanceerde instellingen weergeven klikken om meer geavanceerde opties te bekijken. Het volgen van de gebruikersinterface is echter heel eenvoudig. Zie hieronder,

Ik importeer alleen HAProxy met één knooppunt zonder redundantie, maar met het oog op deze blog, laten we het eenvoudiger maken.

Mijn voorbeeld HAProxy-weergave wordt hieronder weergegeven,

Zoals hierboven weergegeven, zijn de 192.168.30.20 en 192.168.30.30 de primaire en respectievelijk secundaire/herstelknooppunten. Terwijl de HAProxy is geïnstalleerd in het secundaire/herstelknooppunt. In het ideale geval zou u uw HAProxy op meerdere knooppunten kunnen installeren om meer redundantie en hoge beschikbaarheid te hebben. Het is het beste om het te isoleren tegen de databaseknooppunten. Als u een krap budget heeft of uw gebruik bezuinigt, kunt u ervoor kiezen om uw HAProxy-knooppunten te installeren, waar ook uw databaseknooppunten zijn geïnstalleerd.

ClusterControl stelt dit automatisch in en bevat ook de xinetd-service voor PostgreSQL-controle. Dit kan worden geverifieerd met netstat zoals hieronder,

[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

Terwijl poort 5433 lezen-schrijven is en 5444 alleen-lezen is.

Controleer voor PostgreSQL op xinetd-service, namelijk postgreshk zoals hieronder te zien is,

[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

}

De xinetd-services vertrouwen ook op /etc/services, dus u kunt mogelijk de poort vinden die is toegewezen om in kaart te brengen.

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

postgreschk        9201/tcp

Als je de poort van je postgreschk moet wijzigen naar welke poort je moet toewijzen, moet je dit bestand ook naast het serviceconfiguratiebestand wijzigen en vergeet dan niet om de xinetd-daemon opnieuw te starten.

De postgreschk-service bevat een verwijzing naar een extern bestand dat in feite controleert op knooppunten of het beschrijfbaar is, wat betekent dat het een primair of een master is. Als een knooppunt in herstel is, is het een replica of een herstelknooppunt.

[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";

De combinatie gebruiker/wachtwoord moet een geldige ROL zijn op uw PostgreSQL-server. Aangezien we via ClusterControl installeren, wordt dit automatisch afgehandeld.

Nu we een complete HAProxy-installatie hebben, stelt deze opstelling ons in staat om een lees-schrijfsplitsing te hebben waarbij lees-schrijfbewerkingen naar het primaire of beschrijfbare knooppunt gaan, terwijl alleen-lezen voor zowel primaire als secundaire/ herstel knooppunten. Deze setup betekent niet dat het al performant is, het is nog steeds aangepast zoals eerder besproken met een combinatie van HAProxy voor taakverdeling en voegt meer prestatieverbetering toe voor uw applicatie en respectieve databaseclients.