Re: Hardware-Frage

Michael Renner <michael(dot)renner(at)amd(dot)co(dot)at> wrote:

> Hey Andreas,
>
> Ich fasse zusammen:
>
> Aktuell: 24GB RAM, 4 SAS RAID10, 200GiB DB Size + paar GiB/Tag, SR f r
> RO-queries
> Avisiert: 128GB RAM, 8 SAS RAID10, 2 SSD WAL, SR wie gehabt
>
>
> Dein Ziel sollte sein, dass das Working Set der Datenbank immer in den page
> cache & shared_buffers des Servers passt ("Memory backed architecture") - das
> hat zum Ziel dass die Blockdevices (abseits von Kaltstartszenarien) gro fl chig
> nurmehr zum schreiben verwendet werden.
>
> Ein verdoppeln der SAS-Disken wird nur einen marginalen Performance-Zuwachs
> bringen - das erh hen des RAM wird die gr ten nderungen bringen IMO.
>
>
> Meine Checkliste ist typischerweise:
>
> *) Mehr RAM!
> *) Verifizieren das battery backed write cache f r spinning Rust aktiviert ist
> *) Verifizieren dass die Platten vern nftige Responsezeiten haben (kaputte
> Disks, Vibrationen, etc)
> *) Trennen von OLTP und DWH-style queries (Bessere Verwendung des Workingsets)
> *) Partitionieren der heavy append&read Tables um write/read lokalit t zu erh
> hen
> *) synchronous_commit off? (Bei hohem Commit-Durchsatz und berschaubaren
> durability-Anforderungen)
> *) DB auf SSDs (Momentan noch ein bisschen abenteuerlich, greg smith hat da
> IIRC mehr infos zu)
>
> Und bevor ihr zum basteln Anfang - sinnvolle OS- (BIO-Layer!!) [1] und PG Daten
> sammeln (Munin, Cacti, etc.)
>
> Bottom line: Mit der skizzierten Hardware werdet ihr f r einige Zeit lang gut
> fahren, f r exakte Prognosen braucht man eine bessere Datenbasis ;)

Hi,

vielen Dank.

Ja, ich vergaß noch zu erwähnen, daß ich bei der Gelegenheit zumindest
eine Tabelle partitionieren möchte. Diese enthält aktuell ca. 550
Millionen Daten, unpartitioniert, von etwa 1 Jahr.
Da kommen aktuell täglich 2 Millionen neue rein - pro Sekunde in der
Spitze über 100, in einzelnen Transaktionen - jetzt schon.

Da die Daten 3 Jahre aufgehoben werden sollen (allerdinge werden wir da
nach ca. 1/2 Jahr Daten auslagern (auf einen dedizierten Archiv-Server,
das startet die nächsten Tage). Bei dem geplanten Wachstum rechne ich
dennoch damit, daß da mal die 1 Milliarde zusammenkommt. Gebraucht wird
aber fast nur die letzten 7-14 Tage oder so. Also partitionieren,
tagweise, macht bei 6 Monaten ca. 180 Child-Tabellen, was sicher kein
Problem darstellt und das 'Workingset' damit vermutlich im RAM halten
kann.

Eine Frage noch bzgl. SSD: man sagt ja, man solle vermeiden, daß nur
bestimmte Stellen immer beschrieben werden. Ich plane, das WAL da drauf
zu tun, und zwar so, daß ich die SSD damit faktisch fülle (Größe der SSD
geteilt durch 16 MByte je WAL -> Anzahl der aufzuhebenden WAL-Files)
Liege ich richtig mit der Annahme, damit auch zu erreichen, das die SSD
schön gleichmäßig benutzt wird? Die WAL's werden ja zyklisch recycled,
das sollte also exakt passen, oder?
(evtl. SWAP von vielleicht 32 GByte auf die SSD, der Rest WAL)

Ja, also noch mal Danke für Deine Hinweise, ich denke, da einen ganz
sinnvollen Ansatz zu haben. Mal sehen, was mein Kunde sagt ...

Andreas
--
Really, I'm not out to destroy Microsoft. That will just be a completely
unintentional side effect. (Linus Torvalds)
"If I was god, I would recompile penguin with --enable-fly." (unknown)
Kaufbach, Saxony, Germany, Europe. N 51.05082°, E 13.56889°