Gebruik eerst altijd de nieuwste versie van PostgreSQL. Er komen altijd prestatieverbeteringen aan, dus u verspilt waarschijnlijk uw tijd als u een oude versie afstemt. PostgreSQL 9.2 verbetert bijvoorbeeld aanzienlijk de snelheid van TRUNCATE en voegt natuurlijk alleen-index scans toe. Zelfs kleine releases moeten altijd worden gevolgd; zie het versiebeleid.
Niet doen
Doe NIET plaats een tablespace op een RAM-disk of andere niet-duurzame opslag.
Als u een tabelruimte verliest, kan de hele database beschadigd raken en moeilijk te gebruiken zijn zonder veel werk. Dit heeft weinig voordelen vergeleken met het gebruik van UNLOGGED tabellen en toch veel RAM voor de cache.
Als je echt een op ramdisk gebaseerd systeem wilt, initdb een geheel nieuw cluster op de ramdisk door initdb door een nieuwe PostgreSQL-instantie op de ramdisk te installeren, zodat u een volledig beschikbare PostgreSQL-instantie hebt.
PostgreSQL-serverconfiguratie
Tijdens het testen kunt u uw server configureren voor een niet-duurzame maar snellere werking.
Dit is een van de weinige acceptabele toepassingen voor de fsync=off instelling in PostgreSQL. Deze instelling vertelt PostgreSQL vrijwel dat het zich niet bezig moet houden met geordende schrijfbewerkingen of andere vervelende dingen op het gebied van gegevensintegriteitsbescherming en crashbeveiliging, waardoor het toestemming krijgt om uw gegevens volledig te vernietigen als u de stroom verliest of een besturingssysteem crasht.
Onnodig te zeggen dat u fsync=off nooit moet inschakelen in productie, tenzij u Pg gebruikt als een tijdelijke database voor gegevens die u elders opnieuw kunt genereren. Als en alleen als je doet om fsync uit te schakelen, kun je ook full_page_writes inschakelen af, want dan heeft het geen zin meer. Pas op dat fsync=off en full_page_writes solliciteer bij het cluster niveau, dus ze zijn van invloed op alle databases in uw PostgreSQL-instantie.
Voor productie gebruik kun je eventueel synchronous_commit=off . gebruiken en stel een commit_delay . in , aangezien u veel van dezelfde voordelen krijgt als fsync=off zonder het gigantische risico op gegevenscorruptie. Je hebt een klein venster van verlies van recente gegevens als je asynchrone vastlegging inschakelt - maar dat is alles.
Als u de mogelijkheid heeft om de DDL enigszins te wijzigen, kunt u ook UNLOGGED . gebruiken tabellen in Pg 9.1+ om WAL-logging volledig te vermijden en een echte snelheidsboost te krijgen ten koste van het wissen van de tabellen als de server crasht. Er is geen configuratie-optie om alle tabellen uit het loggen te halen, deze moet worden ingesteld tijdens CREATE TABLE . Behalve dat het goed is om te testen, is dit ook handig als je tabellen vol gegenereerde of onbelangrijke gegevens hebt in een database die anders dingen bevat die je veilig moet houden.
Controleer uw logboeken en kijk of u waarschuwingen krijgt over te veel controlepunten. Als dat zo is, moet u uw checkpoint_segments verhogen. Misschien wilt u ook uw checkpoint_completion_target afstemmen om het wegschrijven te vergemakkelijken.
Stem shared_buffers af passen bij uw werkdruk. Dit is afhankelijk van het besturingssysteem, hangt af van wat er nog meer met uw machine aan de hand is en vereist wat vallen en opstaan. De standaardinstellingen zijn uiterst conservatief. Mogelijk moet u de maximale limiet voor gedeeld geheugen van het besturingssysteem verhogen als u shared_buffers verhoogt op PostgreSQL 9.2 en lager; 9.3 en hoger hebben de manier veranderd waarop ze gedeeld geheugen gebruiken om dat te voorkomen.
Als u slechts een paar verbindingen gebruikt die veel werk doen, verhoog dan work_mem om ze meer RAM te geven om mee te spelen enz. Pas op voor een te hoge work_mem instelling kan problemen met onvoldoende geheugen veroorzaken omdat het per soort is en niet per verbinding, dus één query kan veel geneste soorten hebben. Jij alleen echt moet work_mem verhogen als je kunt zien dat sorteringen op de schijf terechtkomen in EXPLAIN of ingelogd met de log_temp_files instelling (aanbevolen), maar een hogere waarde kan Pg ook slimmere plannen laten kiezen.
Zoals een andere poster hier al zei, is het verstandig om de xlog en de hoofdtabellen/indexen indien mogelijk op aparte HDD's te zetten. Aparte partities is vrij zinloos, je wilt echt aparte schijven. Deze scheiding heeft veel minder voordeel als u werkt met fsync=off en bijna geen als je UNLOGGED gebruikt tabellen.
Stem tot slot uw vragen af. Zorg ervoor dat uw random_page_cost en seq_page_cost weerspiegelen de prestaties van uw systeem, zorg ervoor dat uw effective_cache_size is correct, enz. Gebruik EXPLAIN (BUFFERS, ANALYZE) om individuele queryplannen te onderzoeken en de auto_explain module aan om alle langzame vragen te melden. U kunt de queryprestaties vaak drastisch verbeteren door gewoon een geschikte index te maken of de kostenparameters aan te passen.
AFAIK er is geen manier om een hele database of cluster in te stellen als UNLOGGED . Het zou interessant zijn om dat te kunnen doen. Overweeg om te vragen op de PostgreSQL-mailinglijst.
Host OS-afstemming
Er is ook enige afstemming die u kunt doen op het niveau van het besturingssysteem. Het belangrijkste dat u misschien wilt doen, is het besturingssysteem overtuigen om schrijfbewerkingen niet agressief door te spoelen, aangezien het u echt niet kan schelen wanneer/of ze op de schijf komen.
In Linux kun je dit regelen met de dirty_* . van het subsysteem van het virtuele geheugen instellingen, zoals dirty_writeback_centisecs .
Het enige probleem met het afstellen van de terugschrijfinstellingen om te slap te zijn, is dat een flush door een ander programma ertoe kan leiden dat alle verzamelde buffers van PostgreSQL ook worden leeggemaakt, waardoor grote haperingen ontstaan terwijl alles blokkeert bij het schrijven. Je kunt dit misschien verminderen door PostgreSQL op een ander bestandssysteem uit te voeren, maar sommige flushes kunnen op apparaatniveau of op hele hostniveau zijn en niet op bestandssysteemniveau, dus daar kun je niet op vertrouwen.
Deze afstemming vereist echt spelen met de instellingen om te zien wat het beste werkt voor uw werklast.
Op nieuwere kernels wil je er misschien voor zorgen dat vm.zone_reclaim_mode is ingesteld op nul, omdat het ernstige prestatieproblemen kan veroorzaken met NUMA-systemen (de meeste systemen tegenwoordig) vanwege interacties met hoe PostgreSQL shared_buffers beheert .
Afstemming van query's en werkbelasting
Dit zijn dingen die WEL codeveranderingen vereisen; ze passen misschien niet bij je. Sommige dingen kun je misschien toepassen.
Als u geen werk in grotere transacties bundelt, begin dan. Veel kleine transacties zijn duur, dus u moet dingen batchen wanneer dit mogelijk en praktisch is. Als je asynchrone commit gebruikt, is dit minder belangrijk, maar toch sterk aanbevolen.
Gebruik waar mogelijk tijdelijke tabellen. Ze genereren geen WAL-verkeer, dus ze zijn veel sneller voor invoegingen en updates. Soms is het de moeite waard om een heleboel gegevens in een tijdelijke tabel te slurpen, deze te manipuleren zoals je wilt, en vervolgens een INSERT INTO ... SELECT ... te doen om het naar de finaletafel te kopiëren. Merk op dat tijdelijke tabellen per sessie zijn; als uw sessie eindigt of u uw verbinding verliest, verdwijnt de tijdelijke tabel en kan geen enkele andere verbinding de inhoud van de tijdelijke tabel(len) van een sessie zien.
Als u PostgreSQL 9.1 of nieuwer gebruikt, kunt u UNLOGGED gebruiken tabellen voor gegevens die u zich kunt veroorloven te verliezen, zoals sessiestatus. Deze zijn zichtbaar in verschillende sessies en bewaard tussen verbindingen. Ze worden afgekapt als de server onrein wordt afgesloten, zodat ze niet kunnen worden gebruikt voor iets dat u niet opnieuw kunt maken, maar ze zijn geweldig voor caches, gematerialiseerde weergaven, statustabellen, enz.
Over het algemeen niet DELETE FROM blah; . Gebruik TRUNCATE TABLE blah; in plaats van; het is een stuk sneller als je alle rijen in een tabel dumpt. Kap veel tabellen af in één TRUNCATE bel als je kunt. Er is een waarschuwing als je veel TRUNCATES doet van kleine tafels over en weer, dat wel; zie:Postgresql-afbreeksnelheid
Als u geen indexen op externe sleutels heeft, DELETE s met betrekking tot de primaire sleutels waarnaar door die externe sleutels wordt verwezen, zullen vreselijk traag zijn. Zorg ervoor dat u dergelijke indexen maakt als u ooit verwacht dat u DELETE uit de tabel(len) waarnaar wordt verwezen. Indexen zijn niet vereist voor TRUNCATE .
Maak geen indexen die u niet nodig hebt. Elke index heeft een onderhoudskost. Probeer een minimale set indexen te gebruiken en laat bitmapindexscans deze combineren in plaats van te veel enorme, dure indexen met meerdere kolommen te onderhouden. Als indexen vereist zijn, probeer dan eerst de tabel te vullen en maak vervolgens indexen aan het einde.
Hardware
Het hebben van voldoende RAM voor de hele database is een enorme overwinning als je het kunt beheren.
Als je niet genoeg RAM hebt, hoe sneller je opslagruimte krijgt, hoe beter. Zelfs een goedkope SSD maakt een enorm verschil ten opzichte van draaiende roest. Vertrouw echter geen goedkope SSD's voor productie, ze zijn vaak niet crashveilig en kunnen uw gegevens opeten.
Leren
Het boek van Greg Smith, PostgreSQL 9.0 High Performance, blijft relevant ondanks de verwijzing naar een wat oudere versie. Het zou een nuttige referentie moeten zijn.
Word lid van de algemene postgreSQL-mailinglijst en volg deze.
Lezen:
- Uw PostgreSQL-server afstemmen - PostgreSQL-wiki
- Aantal databaseverbindingen - PostgreSQL-wiki