O2e

Database optimalisaties / fijnafstemming

Fijnafstemming uw database parameters om het maximale halen uit!

Hallo,

Dit zijn enkele van mijn ervaring, terwijl ik was het bouwen van een zoekmachine en optmising de PostgreSQL database naar sonic-snelheid!

Onze configuratie voor de PostgreSQL-server was:
Redhat 7.2
PIV 2,00 Ghz Systeem
1024MB RAM

Een van de eerste dingen gemerkt nadat de Servlet programma was dat hoewel vragen werden bijna terug zo snel als de vorige MySQL systeem, de belasting van de server is veel hoger. Toen begon ik naar beneden te gaan in de diepe details van dingen. Ik had geoptimaliseerd MySQL voordat door de aanzienlijke verhoging cache en buffer maten en door het gooien van meer ram in de richting van het probleem. De grootste ding dat men te maken heeft voordat u Postgresql, is het bieden van voldoende gedeelde bufferruimte. Maar dan,
Hoeveel is genoeg?
Er is een verhit debat over het, tussen mensen die zeggen dat logischerwijs de gehele RAM zou kunnen worden besteed ten opzichte van degenen die zeggen dat het gooien van meer RAM-geheugen na een bepaalde grens geen nut heeft. Hoe meer gedeelde buffercache je hebt, hoe groter het percentage van uw database dat noch oorzaken read () 's, noch geheugen kopiëren vanaf de OS buffer cache.But algemeen, zult u de cache een kleiner aantal blokken, omdat je wordt buffering ze twee keer . Wanneer u een blok kopiëren van de OS buffer gedeeld geheugen, de kopie bestaat nog steeds in het besturingssysteem buffer. Zodat blok nu tweemaal gebufferd. Een enkele disk I / O is veel duurder dan honderden exemplaren tussen het OS buffer cache en een gedeeld geheugen postgres '. Kijk ook eens naar alle andere dingen die je doet op de machine - slechts kleine dingen, zoals cron en dergelijke. Alles wat geheugen neemt. Daarom is het gevaarlijk om het niet te laten de OS te beheren een goede brok van het geheugen.
Het komt voor dat deze twee tegengestelde factoren kunnen worden uitgezet en maak iets van een lijn per stuk. Het ideale punt zou zijn waar ze gekruist.

Daarnaast heb ik ook geoptimaliseerd SQL-query's speciaal op maat gemaakt voor mijn doel. Een belangrijk nadeel in PostgreSQL ligt in de uitvoering van de evaluatie van query's met 'IN' en 'bestaat'. Stel:
Query 1. SELECT * FROM db1 WHERE id IN ((SELECT id FROM db2 WAAR woord = 'whatever')) LIMIT 20;
Query 2. SELECT * FROM db1 WHERE ID IN (1234,2345,1242,1256,1245,1567,2222,22,345,234,567,456,35,56);

Database optimalisaties / fijnafstemming. Hoeveel is genoeg?
Database optimalisaties / fijnafstemming. Hoeveel is genoeg?

(Waar ID is de primaire sleutel)

De latere query wordt gescand met behulp van de index op ID

De latere query wordt gescand met behulp van de index op ID, terwijl de voormalige loopt in een sequentiële scan. Ik denk dat dit wordt genoemd "fout van de piloot", waarin de database van de subquery voor elke rij in de buitenste query wordt uitgevoerd. In plaats daarvan, als we gebruik maken uitdrukkelijke SLUIT ZICH AAN (zoals hieronder) dan kunnen we dwingen de database naar een index-scan te gebruiken.
Final Query:
select * from db1, db2 a, b db2
waar id = a.id en a.word = 'woord1'
en id = b.id en b.word = 'woord2'
enz.

OPMERKING: U kan ook draaien in een sequentiële scan plaats van een verwachte index scan, als het aantal tupels te scannen meer dan 30-40% van de totale tupels in de tabel. Hoewel dit kan worden gevarieerd door de gewichten toegewezen random_page_cost, cpu_tuple_cost, cpu_index_cost en cpu_operator_cost door de optimizer voor het maken van deze decesions.

Ik heb ook besloten om meer RAM-geheugen voor het doel te gooien

Ik heb ook besloten om meer RAM-geheugen voor het doel te gooien. Ik toegewezen 64MB RAM in de richting van de gedeelde bufferruimte. Het bestand / var / lib / pgsql / data / postgresql.conf bevat instellingen voor de database server. PostgreSQL gebruikt het systeem van gedeeld geheugen als buffer. Op een Linux systeem, kunt u zien hoeveel geheugen in werd toegewezen door uw systeembeheerder door het uitvoeren van het commando:
cat / proc / sys / kernel / SHMMAX
En om gedeeld geheugen gebruik zijn op het systeem:
IPCS
Het resultaat zal in bytes. Standaard RedHat 7.2 wijst 32MB gedeeld geheugen, wat niet kan genoeg zijn voor postgresql. Ik verhoogde deze limiet naar 64MB door het doen van de opdracht:
echo 67108864> / proc / sys / kernel / SHMMAX

U moet deze lijn plaatsen in uw postgresql opstartbestand, of door het bewerken van het bestand / etc / rc.d / rc.local bestand voor een meer permanente setting.Then in onze postgresql.conf ik shared_buffers ingesteld op 8192.I ook onze sort_mem tot 16384 (16Megs voor een soort geheugen gebied). Sinds pooling van verbindingen van kracht was, ik max_connections tot 50.
En fsync werd ook ingesteld op false.

shared_buffers = 8192
sort_mem = 16384
max_connections = 50
fsync = false

De latere query wordt gescand met behulp van de index op ID. False.
De latere query wordt gescand met behulp van de index op ID. False.

Een kink in de kabel vond ik in eerste instantie was dat het systeem moest bouwen en af ​​te breken een postgresql verbinding met elk verzoek. Dit was ondraaglijk, dus begon ik om de pooling van verbindingen functies van Resin (http://caucho.com) te gebruiken.

-----
Varun

Dankwoord: Curt, Bruce, Andrew et al voor het opruimen van mijn twijfels!