---

Jeg har netop migreret en større database fra Mysql til PostgreSQL
(7.2). Nu er udfordringen så at få den samme performance fra sidstnævnte
som jeg indtil videre har fået fra Mysql.

Mht. til inserts har jeg opnået en acceptabel (dog ikke helt
tilsvarende) performance ved at sætte fsync=false. Derimod har jeg ikke
haft det store held med SELECT statements - her er performance ca.
dobbelt så god ved Mysql. Min database er opbygget omkring en vigtigt
tabel, common_part, hvor der til hver række svarer (ved kolonnen id) en
række i mindst en af tabellerne part_1, part_2 og part_3:

CREATE TABLE common_part (id int4, .., ..., ...) - ca 20 kolonner
CREATE TABLE part_1 (id int4, .., ..., ...) - ca 20 kolonner
CREATE TABLE part_2 (id int4, .., ..., ...) - ca 20 kolonner
CREATE TABLE part_3 (id int4, .., ..., ...) - ca 20 kolonner

Fra ovenstående tabeller, som hver indeholder 100.000 - 1.000.000 rækker
udføres en række ret krævende SELECTs (summeringer, GROUP osv.) og ofte
JOINES common_part med en eller flere af de andre tabeller. Der er
selvfølgelig lavet index på id samt kolonner der ofte søges/grupperes
på. Dette havde jeg til at virke tilfredsstillende under mysql mens det
kniber mere med postgres.

Indtil videre er det jeg har gjort for at forbedre performance at øge
antallet af shared memory buffere samt størrelse på sortbufferen. Er der
andre tweaks jeg kan benytte mig af? Er der f.eks nogle avancerede
features der kan disables?

-Mikkel

PS Mit $PGDATA dir har efterhånden sneget sig op på at bruge 700 MB -
langt mere end jeg mener databasen burde bruge pt. Kan problemet evt.
ligge her? - eller laver postgres bare noget smart diskhåndtering?

---

Først lige lidt generelt...

Kør postgresql v. 7.2, den er helt ny og hver ny version giver
væsentlig bedre performance..

Mine indstillering er (for 512 ram)

Sharedmem 5120 (5k)
Sortbuffers 32678 (32k)
vacuum mem 65536 (64k)

Du er nok nødt til at køre en sysctl for at tillade så stor mængde
shared mem bruges (for mig ca. 150 mb).

Herefter kører den ved mig ca. 120 tpc-b ved 200 simultane brugere.

Derpå til selve databasen.. Husk at køre

"vacuum analyse <tabel>" efter du har fyldt mange data i tabellen
lav et cron til at køre "vaccumdb -z -a -q" (all databases all tables,
analyse, quiet).
Det er begynderfejlen at glemme det :)

Mht. vaccum. I gamle dage var den ret kedelig, i dag locker den på
rowlevel (dvs. du kan ikke mærke det på databasen at den arbejder).
Hvis du vil opnå samme pladsfrigørelse som i gamle dage skal du køre
"vacuum full <tabelnavn>"

Ellers kan du søge hjælp i comp.databases.postgresql.generel. Husk
tabledefinition, antal række og outputtet af "explain <query>"

Mht. plads.. data fylder og det er ikke et mål for PGSQL at være
pladsbesparende...

Det lyder lidt underligt med beskrivelsen af dine tabeller, er du
sikker på de ikke kan designes anderledes/bedre?

Jeg er ikke så sikker på, det er en god ide at slå fsync fra.. du skal
hellere pakke dine inserts ind i transaktioner.. og skal du køre mange
på en gang, så kig på copy kommandoen.. den sparker for vildt røv..

Mvh

Svenne
--
Job-offerings with more than a googolplex* USD a year are instantly accepted.
* = http://www.fpx.de/fp/Fun/Googolplex/

---

Svenne Krap wrote:
> Først lige lidt generelt...
>
> Kør postgresql v. 7.2, den er helt ny og hver ny version giver
> væsentlig bedre performance..

Det gør jeg allerede....

> Mine indstillering er (for 512 ram)
>
> Sharedmem 5120 (5k)
> Sortbuffers 32678 (32k)
> vacuum mem 65536 (64k)
>
> Du er nok nødt til at køre en sysctl for at tillade så stor mængde
> shared mem bruges (for mig ca. 150 mb).

Også gjort - kører pt med 64 MB shared mem. Noget der undrer mig er at
der spawnes 3-4 postmaster processer ved opstart - som tilsyneladende
hver især insisterer på at æde op til 64 MB shared mem....


> Herefter kører den ved mig ca. 120 tpc-b ved 200 simultane brugere.
>
> Derpå til selve databasen.. Husk at køre
>
> "vacuum analyse <tabel>" efter du har fyldt mange data i tabellen
> lav et cron til at køre "vaccumdb -z -a -q" (all databases all tables,
> analyse, quiet).
> Det er begynderfejlen at glemme det :)

Støvsuger regelmæssigt

> Ellers kan du søge hjælp i comp.databases.postgresql.generel. Husk
> tabledefinition, antal række og outputtet af "explain <query>"
>
> Mht. plads.. data fylder og det er ikke et mål for PGSQL at være
> pladsbesparende...

Tjae... Det er vel som man ser det, jo mindre data fylder jo større del
af databasen buffres i ram. Men det der undrede mig var speciet at
$PGDATA diret fylder ca 4-5 gange mere end den mængde data der ligger i
databasen - der er selvfølgelig noget overhed til indexes og log buffere
mm, men det forklarar ikke at databasen fylder ~400-500 MB mere end jeg
regnede med....

> Det lyder lidt underligt med beskrivelsen af dine tabeller, er du
> sikker på de ikke kan designes anderledes/bedre?

Nej... Men umiddelbart er alternativet at lave en stor tabel med hele
indholdet af de andre tabeller = meget spild + _stor_ tabel. Data kommer
fra flade filer som indeholder et stort antal records i et tekstbaseret
format som så parses og gemmes i DB. Da et af formålene med databasen er
at kunne læse/liste de enkelte records i deres helhed vil en større
opsplitning af records føre til en forfærdelig masse JOINS på de mindre
tabeller.

> Jeg er ikke så sikker på, det er en god ide at slå fsync fra.. du skal
> hellere pakke dine inserts ind i transaktioner.. og skal du køre mange
> på en gang, så kig på copy kommandoen.. den sparker for vildt røv..

Har jeg også overvejet - men da data ikke umiddelbart er kritiske og kan
genfindes er det ikke blevet til noget endnu. Pt. får jeg en performance
forbedring på ca. 500%-1000% på inserts ved at slå fsync fra... (fsync
er dog blevet væsentlig hurtigere siden ver 7.0 her var performance ca.
2000% bedre uden)

-Mikkel

---

On Fri, 15 Feb 2002 11:12:31 +0100, Mikkel Carlsen <mlca@poet.dk>
wrote:

>Tjae... Det er vel som man ser det, jo mindre data fylder jo større del
>af databasen buffres i ram. Men det der undrede mig var speciet at
>$PGDATA diret fylder ca 4-5 gange mere end den mængde data der ligger i
>databasen - der er selvfølgelig noget overhed til indexes og log buffere
>mm, men det forklarar ikke at databasen fylder ~400-500 MB mere end jeg
>regnede med....

Det er formodentlig WAL-loggen.... de fylder også som nogle sindssyge
på MSSQL og Oracle - selvom de hedder noget andet :)

Svenne
--
Job-offerings with more than a googolplex* USD a year are instantly accepted.
* = http://www.fpx.de/fp/Fun/Googolplex/