Datenbank komplett in den Ram - Gute Idee?

[stefanstp]

Meine Datenbank ist mittlerweile fast 2 GB groß und hat nochmal 2 GB Indexe.

Ist es eine gute Idee, die gesamte Datenbank in den Ram zu legen, damit die Geschwindigkeit besser wird (auf Computerbase konnte ich lesen, dass die auch viel Ram einsetzen, damit vieles da gepuffert werden kann, bin mir aber nicht sicher, ob jetzt da alles im Ram liegt => https://www.computerbase.de/news/in-eigener-sache/das-neue-server-setup-von-computerbase.37198/ ) . Weil die Seite wird zunehmend von Monat zu Monat langsamer. Oder lieber nur mehr Ram kaufen und den Cache entsprechend erhöhen?

Danke im Voraus

Stefan

 

[RiseAgainstx]

was bitte wird von monat zu monat langsamer?? o.O

 

[stefanstp]

Die Geschwindigkeit der Webseite ... ich bekomme alle paar Tage eine automatische Mail aus unserem Forum, dass es für paar Sekunden nicht erreichbar war, weil MySQL gerade überfordert ist.

 

[andy_0]

Eine SQL Datenbank versucht eh soviel RAM wie notwendig zu allokieren. Wie viel RAM hat dein Server? Alternativ eben die Performance analysieren und z.B. einige Einstellungen ändern. Im Notfall die DB Engine wechseln, es gibt DBs die laufen per Design "nur" im RAM. Die Daten einfach so in den RAM schieben würde ich nicht, ansonsten hast du beim Stromausfall ein Problem. Ist der Server dagegen abgesichert und es werden täglich Backups gemacht, wäre es doch eine Möglichkeit - wenn es denn überhaupt an der HDD liegt.

Wie von Pitam beschrieben, wäre eine SSD dann eine wohl sinnvollere Möglichkeit.

Ohne die genauen Daten des Servers und der der auftretenden Probleme zu kennen, kann man aber keine pauschale Aussage treffen.

 

[Pitam]

SSD wäre effektiver und sicherer.

 

[stefanstp]

Ja unser Webhoster will jetzt ein Angebot machen über einen Server mit SSD-Platten und ausreichend RAM. Soll ich noch auf etwas achten?

 

[andy_0]

Kann man so nicht sagen, da wir die Anwendung nicht kennen. Rechenleistung wird auch benötigt - abhängig wie viele Zugriffe gleichzeitig stattfinden. Solange es nicht sehr viele sind, muss man darauf aber nicht speziell achten.

Wenn ihr das System wechselt, würde ich mal schauen ob ihr nicht auf den MySQL Nachfolger MariaDB wechseln wollt, wenn er mal ein Release hat. Da hat sich etwas bei der Performance getan, während MySQL länger stagniert. Das ist vom neuen Eigentümer Oracle so gewollt, die wollen schließlich Geld mit ihrer bezahlten Software machen.

 

[stefanstp]

Wir haben ca. 900 Leute gleichzeitig auf www.psd-tutorials.de Kann man einfach die Datenbank so wechseln? Gibt es da keine Problem mit z. b. vBulletin?

 

[andy_0]

Naja, "einfach" wechseln tut man nicht. Testen und Co. sollte man schon. Der Aufwand lohnt sich aber, da der Performanceunterschied vorhanden ist (http://blog.mariadb.org/sysbench-oltp-mysql-5-6-vs-mariadb-10-0/). Größere Probleme sollten nicht entstehen, da MariaDB kompatibel zu MySQL ist. Wikipedia (http://www.heise.de/ix/meldung/Wikipedia-wechselt-von-MySQL-auf-MariaDB-1848140.html) ist auch kürzlich gewechselt.

Ich wollte nur darauf hinweisen, dass ein Wechsel der Engine vor allem langfristig Vorteile bringt. Die meisten von Oracle aufgekauften Open Source Projekte haben neue Projekte gegründet (OpenOffice -> LibreOffice, MySQL -> MariaDB, ...).

 

[Daaron]

Eine SQL Datenbank versucht eh soviel RAM wie notwendig zu allokieren.

Stimmt so nicht. Die wichtigste Variable ist, gerade bei MySQL InnoDB, die Cache-Größe. Selbige wird manuell konfiguriert. Bei den MySQL-Paketen für Debian (und Ableger wie Ubuntu) sind sämtliche Caching-Einstellungen etc. sehr "konservativ". Ich kann nur dazu raten, die Einstellungen manuell zu überprüfen, bevor sonstige Aktionen durchgeführt werden. Etwas mehr Lese-Cache sorgt für einen extremen Performance-Zuwachs.

Im Notfall die DB Engine wechseln, es gibt DBs die laufen per Design "nur" im RAM.

Wenn sie dabei noch versuchen, Datenverluste nicht vorkommen zu lassen können sie nicht (deutlich) schneller sein als InnoDB mit gut eingestelltem Cache.

Wenn ihr das System wechselt, würde ich mal schauen ob ihr nicht auf den MySQL Nachfolger MariaDB wechseln wollt, wenn er mal ein Release hat.

Wieso "wenn"? Es gibt schon lange stabile Versionen. Ich hab schon mit dem Gedanken gespielt, unseren neuesten Webserver mit MariaDB statt MySQL anzufüttern. Noch brauchen wir die zusätzliche Performance aber nicht.
Es muss ja nicht die Version 10 sein. Die 5.5(?) ist auch flotter als das aktuell stabile MySQL und genauso stabil.

Wir haben ca. 900 Leute gleichzeitig auf www.psd-tutorials.de Kann man einfach die Datenbank so wechseln? Gibt es da keine Problem mit z. b. vBulletin?

Was isses für ein Server? Angenommen, es ist ein Debian/Ubuntu-Server:
- Paketquelle von MariaDB in die sources.list aufnehmen
- apt-get update
- apache & mysql abschalten (kriegen die Leute halt kurz n paar 404's)
- apt-get install [hier mariadb-pakete einfügen]
- apache und mysql neu starten (statt dann eben mariadb statt mysql)

Is ne Sache von 2-3 Minuten.

 

[stefanstp]

Alle Tabellen sind bisher MyISAM. Sollten wir die einfach mal in InnoDB konvertieren? Ansonsten hört sich das mit mariadb auch sehr interessant an.

 

[Daaron]

Alles, das keinen Fulltext-Index hat, kannst du gefahrlos in InnoDB konvertieren. Nur bei FULLTEXT musst du bei MyISAM bleiben (noch).
Natürlich trotzdem vorher Backup machen...

 

[stefanstp]

Und was haltet ihr davon, mein vorhandenes MySQL 5.1 erst mal auf 5.6 zu updaten? Soll ja angeblich deutlich schneller sein laut Golem: http://www.golem.de/1009/78067.html

 

[andy_0]

Jap. Das bringt dir natürlich auch ein Performanceschub. Dazu dann eben schauen, was wie stark belastet wird (CPU, RAM, HDD, ...) und dann bei Bedarf nachjustieren (größerer Cache oder ähnliches).

 

[stefanstp]

Laut Webhoster ist der Server gar nicht so extrem belastet, was nur den Server oft stört, sind die zahlreichen locks bei den Tabellen, wenn was geschrieben wird. Was hilft da am besten?

 

[andy_0]

Das kann man pauschal nicht sagen, da müsste man wissen was da so lange dauert. Zuwenig im RAM (Cache) und daher HDD ausgelastet? Software (vBulletin?) lockt falsch/zu viel? Abgesehen davon wüsste ich nicht, warum es komplette Tabellen Locks geben muss. Ein zeilenweiser Lock beim Schreiben ist doch absolut ausreichend. Auf vBulletin würde ich es pauschal nicht schieben, andere haben damit ja offenbar keine Probleme?

Ich würde erst mal schauen, wann genau das Problem auftritt und woran es im Detail liegt. Den Cache vergrößern bringt euch sicherlich auch bei Schreibzugriffen was, aber das weiß ich nicht genau.

 

[Daaron]

http://dev.mysql.com/doc/refman/5.0/en/slow-query-log.html <- Das schon gefilzt? Zwar kostet das Anschalten des Logs wieder etwas Performance, aber es ist ja nur temporär, um Fehlerursachen zu finden.

 

[ice-breaker]

Alle Tabellen sind bisher MyISAM. Sollten wir die einfach mal in InnoDB konvertieren? Ansonsten hört sich das mit mariadb auch sehr interessant an.

Nein, einfach stupide alles in InnoDB umzuwandeln, kann die Performance noch schlechter machen. Da dann jeder Schreibzugriff in einer eigenen Transaktion ausgeführt wird (autocommit mode).

Habt ihr eigentlich schonmal genau analysiert, was für Probleme ihr habt? Auf mich wirken die Beschreibungen wie bloßes raten. Also ist es wirklich der MySQL-Server weil die Queryzeiten hoch sind und nicht der Webserver? Welche Queries sind schuld? Und warum (EXPLAIN) ?

Und so weiter, also was habt ihr denn da schon geprüft?


@andy_0: MyISAM, dieses Relikt, hat noch Fulltable-Locks bei jeglichen Schreiboperationen, das ist schon in "Ordnung".