ich schlage mit massiven Performance-Problemen bei meiner Postgresql-Datenbank rum.
Habe -leider- auf osm2pgsql umgestellt und die Updates per Diff sind so langsam, daß das Lag von derzeit 11 Tagen so nie und nimmer abgebaut wird.
Hab einen nicht geraden kleinen Server und meine, daß ich PostgreSQL wohl großzügig konfiguriert habe. Ich sehen aber einen IO-Engpass (viele Waits) bei den Platten. Derzeit verteile ich die Indices auf mehrere Laufwerke und erhoffe mir davon einige Verbesserungen
Frage: **Hat jemand praktische Erfahrungen mit SSD im Datenbankbereich? **
Klar, eine 64GB oder 128 GB SSD einbauen und die Indices drauflegen, ist ja kein Problem. Das kriegt ich gerade noch so hin
Aber was ist mit der Stabilität? Indices werden sehr oft geschrieben und ich habe Sorgen mit der maximalen Anzahl an Schreibvorgängen bei SSD. Ich möchte schon, daß die mehrere Jahre durchhalten.
Für Tips in diese Richtung (Stabilität/Robustheit) würde ich mich freuen. Gute Quellen zum Kaufen natürlich auch.
In meiner Firma betreiben wir seit mehreren Jahren die Hauptdatenbank mit SSDs. Allerdings ist der zu erwartende Geschwindigkeitsgewinn davon abhängig, wie schlecht Indices im Speicher gehalten werden können. In der Regel hilft eine Erhöhung des Hauptspeichers mehr als eine Umstellung auf SSDs. Sobald die Indices alle in den Hauptspeicher passen, ist die Geschwindigkeit der Platten (außer bei fast ausschließlich Updates und Inserts) nicht mehr stark der Flaschenhals. Deshalb würde ich eher darauf achten, dass die Indices alle in den Hauptspeicher passen als dass sie auf einer SSD liegen. Unsere Indices sind z.B. 47 GB groß, die Datenbank hat 72GB Hauptspeicher. I/O ist für uns kein Thema. Darf ich fragen, wie groß Deine Indices insgesamt auf der Festplatte sind und wie viel Speicher Du hast? Nutzt Du ein 64bit Betriebssystem?
Um den zweiten Teil der Frage zu beantworten: Wir nutzen diese Platten hier: Intel® SSD 710 Series 300GB, 2.5in SATA Ausfälle gab es noch nie, wir haben davon 8 Stück als raid 1+0 im Dauerbetrieb und die Datenbank langweilt sich definitiv nicht ;o)
planet2# \d+
List of relations
Schema | Name | Type | Owner | Size | Description
--------+--------------------+-------+----------+---------+-------------
...
public | planet_osm_line | table | postgres | 45 GB |
public | planet_osm_nodes | table | postgres | 374 GB |
public | planet_osm_point | table | postgres | 13 GB |
public | planet_osm_polygon | table | postgres | 57 GB |
public | planet_osm_rels | table | postgres | 1369 MB |
public | planet_osm_roads | table | postgres | 7188 MB |
public | planet_osm_ways | table | postgres | 111 GB |
...
und die Indices sind auch noch da:
public | planet_osm_line_index | index | postgres | planet_osm_line | 5070 MB |
public | planet_osm_line_pkey | index | postgres | planet_osm_line | 1842 MB |
public | planet_osm_line_tags_index | index | postgres | planet_osm_line | 13 GB |
public | planet_osm_nodes_pkey | index | postgres | planet_osm_nodes | 43 GB |
public | planet_osm_point_index | index | postgres | planet_osm_point | 2717 MB |
public | planet_osm_point_pkey | index | postgres | planet_osm_point | 1047 MB |
public | planet_osm_point_tags_index | index | postgres | planet_osm_point | 8223 MB |
public | planet_osm_polygon_index | index | postgres | planet_osm_polygon | 6937 MB |
public | planet_osm_polygon_pkey | index | postgres | planet_osm_polygon | 2464 MB |
public | planet_osm_polygon_tags_index | index | postgres | planet_osm_polygon | 13 GB |
public | planet_osm_rels_idx | index | postgres | planet_osm_rels | 264 kB |
public | planet_osm_rels_parts | index | postgres | planet_osm_rels | 946 MB |
public | planet_osm_rels_pkey | index | postgres | planet_osm_rels | 47 MB |
public | planet_osm_roads_index | index | postgres | planet_osm_roads | 463 MB |
public | planet_osm_roads_pkey | index | postgres | planet_osm_roads | 166 MB |
public | planet_osm_roads_tags_index | index | postgres | planet_osm_roads | 1521 MB |
public | planet_osm_ways_idx | index | postgres | planet_osm_ways | 2641 MB |
public | planet_osm_ways_nodes | index | postgres | planet_osm_ways | 94 GB |
public | planet_osm_ways_pkey | index | postgres | planet_osm_ways | 9345 MB |
Uii, das sprengt wohl meinen Kostenrahmen - aber für ne Firma sind das wohl nur Peanuts.
Ich werde mir wohl nach und nach 1-3 SSD zulegen und die wichtigsten Indices (*) drauflegen aber ich hab immer noch ein ungutes Gefühl bezüglich der Robustheit.
Danke für deine Antwort
Gruss
walter
*) wie krieg ich die raus? Muß mich wohl mal mit Postgresql-Monitoring beschäftigen.
@all: die UK-Toolchain in England macht ja das gleiche: Diff-Files mit osm2pgsql in die Postgresql-DB einspielen. Bei denen flutscht das prima. Kann man sich die Configs bei denen ansehen? Klar, die verwendete Software ist im Download, aber was ist mit den Live-Configs?
Ich taste mich mal ran.
Ich verwende seit zwei Jahren SSDs als Systemplatte. Die Stabilität ist so eine Sache: Es kommt gelegentlich vor, dass alle paar Stunden ein Bluescreen auftaucht. Nach ein paar Tagen ist der Spuk dann wieder vorbei. Bei der ersten SSD trat es dann aber so häufig auf, dass ich sie (auch wegen der Größe) ausgemustert habe. Bei einer dritten (auf einem anderen Rechner) war bisher Ruhe. Auf dieser Grundlage möchte ich aber keine Aussage über heutige SSDs machen. In der IT ist ein Jahr fast eine Ewigkeit.
Bei SSD ist das Schreiben ganz klar der kritischere Vorgang. Trotz der Verteilung der Schreibvorgänge (wear leveling) ist irgendwann Feierabend, wenn das zu häufig passiert. Es kommt aber darauf an, wieviel geschrieben wird. Der Index-File einer DB wird ja nicht jedesmal komplett neu geschrieben, oft werden ja nur ein paar Hash-Werte hinzugefügt. Ich habe mich jedenfalls getraut, den swapfile auch auf die SSD zu legen, da es Untersuchungen gibt, dass auf den gar nicht so viel geschrieben wird, wie man eigentlich annimmt.
Bis die SSD dann den Geist aufgibt, gibt es vielleicht so viel schnellere, günstigere und größere Exemplare, dass ich froh bin, einen unwiderlegbaren Grund zum Wechsel zu haben
Zur Aussage von Nadjita: Natürlich ist RAM schneller (und unempfindlicher) als eine SSD. Jede DB-SW wird daher einen Teil des Index im RAM als Cache zu halten versuchen. Je mehr RAM, desto besser. Wenn der Index zu groß für RAM ist, kommt es auf das Verhältnis Lesen/Schreiben an. Die SSD kann ihre Vorteile (gegenüber HD) vor allem beim Lesen ausspielen.
Kannst du mir sagen, welchen Hersteller du bevorzugst und welchen Typ du einsetzt?
Derzeit laß ich autovacuum ziemlich oft über die Tabellen und auch Indices huschen. vacuum analyze ist ja nur lesend und vacuum alleine schreibt ja auch die Indices nicht neu - glaub ich zumindest. Nur ein Rebuild oder vacuum full schreibt das Zeug neu.
Ich glaub, ich werde das mal riskieren. Datenfiles liegen auf einem Raid und wenn ein Index abfackelt, kann man den jederzeit neu aufsetzen - wenn man es kann
Ja, nutze auf meinem Kartenserver seit einigen Jahren nur noch SSDs für die Datenbank.
Geschwindigkeitsgewinn bei Datenbankoperationen ca. Faktor 5, wenn Du flatfile benutzt könnte es auch mehr sein, das gabs bei meiner Vergleichsmessung damals noch nicht.
Probleme gab es bisher keine. DB wird alle 3 Tage komplett importiert und Server ist permanent am Rendern. Wichtig ist daß Dein Kernel eine saubere TRIM-Unterstützung hat, muß evtl. dafür neu gebaut werden.
Evtl. fährst Du günstiger wenn Du 2 kleinere SSDs nimmst und zu einem virtuellen Laufwerk zusammenlegst, so ist mein Server konfiguriert.
Ich würde bei einer DB (zumindest Oracle) erwarten, daß es performancemäßig am meisten bringt, die Redo-Logs auf SSD zu verlagern, erst nachrangig die Daten oder die Indizes. Keine Ahnung wie das bei pgsql heißt.
Ich nutze aktuell eine Samsung 840 für die Generierung der RadReiseKarte. Bei den Größen deiner DB freue ich mich richtig, dass ich mit einem komprimierten planet arbeiten kann…
Muß ich mir mal ansehen. Dachte, flatfile wäre irgend so ein altes Zeug. Ich importiere im Slim-Modus; damit und nur damit kann man Diffs einspielen. Und das ist wohl sowas ähnliches? Mal sehen.
TRIM im Kernel? Das sagt mir absolut nichts. Ansonsten fahr ich das allerneueste 13.10 Ubuntu mit 3.11.0-Kernel. Da sollte doch wohl alles sauber sein.
Wenn - und das ist schon fast sicher - fange ich mit einer SSD an und schau mal was das bringt. Striping kommt, wenn ich noch eine 2. SSD von euch geschenkt bekomme kaufe
Danke für den Tip.
Die Redo-Logs nennen sich bei Postgresql WAL (Write Ahead Logging), liegen in der Directory pg_xlog und das man man natürlich überall hinlegen. (*)
Kommt auf jeden Fall ganz oben auf meine Liste.
Gruss
walter
*) Am besten in eine RAM-Disk, schneller geht es nimmer
Sieh dir die Dokumentation unter http://www.postgresql.org/docs/9.3/static/monitoring-stats.html insbesondere zu pg_stat_user_indexes und pg_statio_user_indexes an. Damit solltest du dir ein Bild von der Wichtigkeit der Indizes für deine Abfragen machen können.
Flatfile ist ein neueres Feature und cached die Koordinaten der Nodes in einer simplen Datei anstatt in der Datenbank. Viel weniger Platzverbrauch, viel schnellerer Zugriff und auf einer SSD rockt das.
Zu Ubuntu kann ich nix sagen, aber ich habe hier ein frisch installiertes aktuelles Debian Wheezy und da mußte man den Kernel für besseres TRIM nochmal bauen.
Interessant. wie ich sehe, hat kai krueger die finger drin. werd ich mal checken.
So, bin endlich von einer Baustelle zurück, auf der ich mich verlaufen hatte: Trim ist für mich Zeichenkettenverarbeitung gewesen und das passte irgendwie nicht in den Kernel
TRIM für SSD sollte zumindest in meinem Ubuntu (13.10) drin sein. Zumindest weiss ich jetzt, dass ich darauf achten muß.
Gruss
walter
ps: wenn jetzt die letzte Tabelle (planet_osm_nodes mit 370 GB!) in einen anderen Tablespace verschoben wurde, schau ich mal ob es etwas schneller wird. Ab jetzt sind zumindest Indices und Daten physikalisch getrennt. Danach lege ich pg_xlog (Wal) mal auf ein eigenes Laufwerk, das hier ungenutzt in der Ecke liegt.
Neee, RAM-Disk ist nicht die beste Lösung. Datenbanken sind Weltmeister darin, Speicher sinnvoll zu nutzen, alles was Du als RAM-Disk abzweigst fehlt zum Cachen. Abgesehn davon, dass bei vielen Updates und Inserts die WAL-Logs extrem groß werden. Diese auf eine SSD zu packen ist aber durchaus sinnvoll, da dort die meiste Aktivität ist. Wenn nicht auf eine SSD, dann zumindest auf ein separates Laufwerk. Wenn ich allerdings sehe, dass planet_osm_nodes_pkey 43GB groß ist (und planet_osm_ways_nodes noch größer), dann ist das durchaus ein Problem bei “nur” 32GB Arbeitsspeicher. Wenn der Index nicht in den Speicher passt, wird es einfach langsam, da die Datenbank dann swappen muss. Wenn es meine Datenbank wäre, würde ich den Index in Teile zerlegen die in den Speicher passen (z.B. in einen Index mit nodes id < 5000000000, einenen >= 5000000000 und < 10000000000, usw.). Wenn Du Dich allerdings mit Datenbanken im Allgemeinen und PostgreSQL im Speziellen nicht auskennst, fällt das vermutlich flach. Ich vermute mal, dass Du mit einer einzigen SSD von 128GB und einem Swapfile auf der Platte schon einen deutlichen Geschwindigkeitsgewinn bekommst. Hätte ich die Hardware hier, würde ich entsprechend schauen, ob ich deine Konfiguration nachbauen und optimieren kann, aber momentan fliegt das nicht hier herum ;o)
TRIM ist überhaupt kein Problem in neueren Ubuntu-Kerneln und die Anzahl der Schreiboperationen sollte man auch nicht überschätzen. Faktisch ist eine SSD schneller zu klein für ihren Einsatzzweck als dass sie den Geist aufgibt. Natürlich kann es Dir immer wieder passieren, dass sie sich nach einem Jahr verabschiedet wenn Du keine SSD wie die von mir gepostete nimmst, aber der Preisunterschied rechtfertigt es im privaten Umfeld einfach nicht. So lange keine sensiblen Daten darauf liegen, ist doppelt kaufen billiger als extrem teuer kaufen ;o)
TRIM (Mitteilung, dass Blöcke nicht mehr gebraucht werden) ist in Linux seit 2010 (2.6.33) dabei, bei MS seit W7. Es kann aber sein, dass es neuere Varianten (-> Nop) gibt.
Voll drauf reingefallen - und dabei hab ich extra drei Smilies drangehängt. Wer die WAL-Files (bei mir übrigens 1.1 GB) in den Speicher legt, der gehört erschossen. Die werden doch genau dann gebraucht, wenn der Rechner abgestürzt ist - und dann ist der Memory natürlich auch weg. War wirklich nur ein Scherz.
Nönö, das trau ich mir durchaus zu. Aber mit dem Aspekt hab ich mich noch nicht beschäftigt.
Meinst du wirklich, den Memory per Swap aufzubohren und den Postgresql zum Fressen geben? Also postgresql.conf noch mehr aufzubohren als es der reale Memory erlaubt? Fragt sich dann, was schneller ist: Daten von der Platte lesen oder Index swappen? Mal sehen, Swapfiles sind ja schnell erstellt und Plattenplatzt hab ich eh genug.
Ich schau mal im Keller nach, ob ich noch so eine Kiste zusammenbauen kann Nee, Danke für dein “Angebot” aber soooo kritisch ist die Sache ja auch nicht.
“Deine” Samsung 830 mit 128 GB gibt es für ca 125€, das sollte im November wohl drin sein. Aber ich mach mich gerade erst so richtig schlau über das Thema. Will halt keinen Schrott vom Discounter-Krabbeltisch kaufen.
Aber wenn Du wüsstest, was ich schon alles gesehen habe… da sind WAL-Files in RAM-Disk noch harmlos…