Hardware-Frage
Andreas Kretschmer <[email protected]>
| Newsgroups | gmane.comp.db.postgresql.german |
|---|---|
| Message-ID | <20120324074234.GA5037@tux> |
Moin, da ich weiß, daß hier einige mitlesen, die auch mit großen Blechen hantieren, stelle ich mal folgendes Problem in den Raum: $Kunde hat derzeit einen Server mit 24GB RAM und 4 SAS-Platten im RAID10. Zwischen etwa 8 und 17 Uhr sind so viele Inserts und Selects durch einige hundert Clients, daß die Platte laut atop in dieser Zeit bei Diskusage eine sehr gerade waagerechte Linie zieht - bei 100%. (und der Server dann im Nagios nervt...) Lesen zu schreiben etwa 2/3 lesen, 1/3 schreiben. Datenbankgröße aktuell über 200 GB, täglich einige GB wachsend. Aktuell hat eine Tabelle am Tag ca. 2 Millionen Inserts. Ich rechne damit, daß in 1 Jahr da 1 TB drin sein wird. Aktuell 9.0, OS ist Linux. (was sonst ...) Dazu ein SR/Slave, der aktuell einen Teil der Leseanfragen bekommt, aber damit noch nicht voll ausgelastet ist - da werde ich noch mehr auf den Slave legen. Hardware identisch zum Server. Davor hängt noch ein extra Server mit pg-pool, der die Lastverteilung der Read-Only-Abfragen macht. (schreibende Anfragen gehen direkt zum Master-Server) So, der Kunde will wachsen - angepeilt ist etwa das 4-fache an gleichzeitigen Clients und damit Datenvolumen. Kann man mit halbwegs ruhigen Gewissen dies anbieten: - Server mit 128 GB RAM - 8 Platten SAS (RAID10 sinnvoll?) - 2 SSD (gespiegelt) (DELL irgendwas, 2 HE) Auf die SSD's würde ich die WALs legen. Dabei auch auf 9.1 ziehen. Alten Server mit mehr RAM und grüßeren Platten wieder als SR/Slave ins Rennen schicken, den anderen jetzigen Slave raus. (oder auch mit drin lassen, vielleicht auch nicht verkehrt ... natürlich dann auch mit 9.1, größeren Platten, RAM - muß man dann entscheiden) (Evtl. aber auch wieder identische Hardware für den Slave, damit bei Failover dieser nicht verglüht...) Der Server soll das geplante Wachstum halt verkraften, soll aber natürlich auch nicht oversized sein. Kommentare erwünscht! (@ads: Greenplum ist KEINE Option.) 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° -- Sent via pgsql-de-allgemein mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-de-allgemein