ungenügend Speicher zum Optimieren einer mySQL Tabelle

[barnie]

Hallo Zusammen,

evt. kann mir jemand einen Tipp geben, wie ich meine Tabelle ab und zu Optimieren kann.

Eine mySQL Tabelle mit ca. 40Mio Datensätzen (Größe 4,5GB) erzeugt nach längerem Betrieb einen "Überhang". Wenn ich nun wie üblich auf optimize Table klicke, dann beginnt die Optimierung und nach ca. 20 Minuten fliege ich aus der DS raus und kann mich nicht mehr anmelden. Als meldung kommt, dass kein Speicher mehr da ist und dass ich neu starten soll. Habe das dann über Nacht laufen lassen. Am nächsten Morgen ist imme rnoch kein Login möglich. Also neu Booten. Anschl. ist die Tabelle kaputt. -> Tabelle löschen und den Backup einspielen... Dann ist zwar auch der Überhang weg, aber das kann nicht der normale "Wartungsweg" sein

Danke und Gruß RUDI

 

[jahlives]

wie voll ist denn deine Platte?

 

[barnie]

Platte hat noch 2TB frei... Also daran liegt es leider nicht!

Hatte vor der Umstellung auf das DS413 einen WIN2008 Server laufen, da war die Tabellengröße kein Problem. 45Mio Datensätze sollten für mySQL kein Problem sein...

 

[MoritzDorn]

Hallo,

du könntest ggf. die Tabellen jeweils einzeln optimieren, bzw. in Gruppen, das ist zwar mehr Arbeit aber vielleicht hilft das.

Gruß

 

[barnie]

Es geht nur um eine einzelne Tabelle... Die anderen dieser DB gehen ohne Probleme... Sind halt kleiner. Max. 1 Mio Einträge

Gruß RUDI

 

[jahlives]

hast du dir während der Optimierung mal mit htop die Speicher- und SWAP-Auslastung angeguckt? Vielleicht sind nicht die Platten das Problem, sondern der Cache oder RAM geht aus

 

[barnie]

Es ist definitiv das Memory, das ausgeht! Kann ich dem System einen Swap-File spendieren, bzw. diesen vergrößern?

RUDI

 

[Benares]

Probier mal das hier.
Glücklich wirst du aber mit der Methode auf Dauer nicht.

Gruß Benares

 

[barnie]

wieso werde ich damit nicht glücklich? Welche Nachteile kann ich damit haben? Mein System läuft im Moment so wie ich es will, mit dem kleinen Schönheitsfehlerchen, dass ich die eine Tabelle nicht optimieren kann. Als Workaround bei Performanceproblemen ist der Backup der Tabelle, das Löschen und anschließend neu einspielen eine Übergangslösung...

RUDI

 

[femo]

hallo barnie,

da wuerde ich mal ein ticket eroeffnen bei symology....
das ist schon ein eher spezieller fall, und ob du hier jemanden findest, der unter mysql
eine einzelne tabelle mit 40mio eintraegen laufen hat zweifle ich stark an....

und das resultat wuerde mich sehr interessieren, also es waere echt nett, wenn du ne
antwort von denen hast, du sie hier posten wuerdest.

viel glueck

 

[barnie]

werde ich wohl heute Abend machen müssen

Danke RUDI

 

[Benares]

wieso werde ich damit nicht glücklich?

Weil Swap-Space fehlenden RAM nicht wirklich ersetzen kann. Mag sein, dass es mit mehr Swap geht, aber die Performance dürfte grauenhaft sein.
Wieviel Swap zeigt "free" denn ohne Erweiterung an?

Gruß Benares

 

[barnie]

wenn ich einmal im Monat, oder nach einer größeren Aktion den Platz brauche und der nur benutzt wird, wenn kein RAM mehr da ist, dann ist mir die Performance fast egal... Aber wenn der Swap immer benutzt wird, dann ist das tatsächlich grauenvoll. Im Moment ist das RAM für alles was läuft ausreichend.

Ich schaue mir das heute Abend an und werde mal die zweitgrößte Tabelle optimieren und das beobachten...

Danke RUDI

 

[jahlives]

Das Problem beim SWAP ist folgendes: er liegt auf der Platte Sobald geswappt wird betrifft das alle Anwendungen welche auf zusätzlichen RAM angewiesen sind. Daher könnte es gut sein, dass bei der monatlichen Putzaktion dann auch andere Dienste eine miserable Performance haben, da aus sie swappen müssen. Das kann sich sogar richtig aufschaukeln bis zu einem Punkt wo dann gar nichts mehr geht und der Kernel anfängt Prozesse zu töten, damit wieder Speicher bzw SWAP frei wird. Sobald aber systemkritische Dienste getötet werden bleibt ein System dann meistens stehen und macht gar nichts mehr

 

[raymond]

1 GB RAM der DS413 reicht scheinbar nicht...du lastest diese vielleicht doch zu sehr aus mit deinen Millionen an Datensätzen. Die DS413 ist immer noch für "Von Privatnutzern bis zu Firmen-Arbeitsgruppen", welche selten so eine Datenbank brauchen.

Also auf eine NAS mit mehr RAM umsteigen (DS1512+ mit max 3 GB RAM wäre eine Alternative) oder besser einen Rechner hinstellen mit 8 oder mehr GB RAM (kostet ja fast nix).

Die DS413 bekommst du sicherlich noch für gutes Geld los.

 

[barnie]

Die ganze Zeit stand da ein W2008 Server... Das muss nicht mehr sein. Das NAS ist ganz neu und erfüllt bis auf diesen einen kleinen Umstand meine privaten Anforderungen absolut super. Notfalls wird diese Tabelle wirklich alle paar Monate exportiert und dann neu eingelesen. Auf was anderes möchte ich im Moment nicht mehr gehen... Und wenn alles nichts bringt, dann kille ich diese Tabelle. Darin sind alle EXIF Daten meiner Fotodatenbank gespeichert. Ist ne Eigenentwicklung und dann verzichte ich halt auf den Luxus die EXIF Daten in meiner DB mitzuführen...

RUDI

 

[raymond]

Also alle paar Monate das machen, klingt sehr lästig. Eine Alternative die EXIF Daten zu kicken wäre es für mich auch nicht. Da würde ich lieber die NAS verticken und 300 EUR drauflegen und dann eine Synology DS1512+ nehmen. Diese kommt auch mit einem Bay mehr und Intel Prozessor her. Also ideal für noch mehr Aufgaben für die NAS.

Da Fotos tendentiell immer mehr werden (und größer) ist das Problem ja was du jetzt versuchst notgedrungen zu flicken, ja nicht mit einer extra SWAP Datei gelöst.

Aber vorher, klar, Synology anschreiben. Optimierungsmöglichkeiten bei der MySQL Datenbank gibts sicherlich viele (u.a. Versionsupgrade).

 

[barnie]

hier mal das was free sagt

total used free shared buffers
Mem: 1034720 1000836 33884 0 189900
Swap: 2097080 4332 2092748
Total: 3131800 1005168 2126632
NAS-barnie> free
total used free shared buffers
Mem: 1034720 900116 134604 0 189984
Swap: 2097080 4332 2092748
Total: 3131800 904448 2227352

einmal vor dem optimize der zweitgrößten Tabelle (900000 Einträge/100MB) und einmal danach. Die EXIF Tabelle hat jetzt immer noch 3,5GB und ich denke, die wird von mySQL komplett in den Speicher geladen.... Und da reicht das RAM nicht...

Ich stelle später noch die Anfrage und werde ansonsten einfach abwarten, wie sich das System entwickelt. Da die Tabelle wirklich nur beim Import im Moment benutzt wird, ist die Performance erstmal egal. Notfalls werde ich reagieren, wenn es mir zu heftig wird. Aber das NAS nach 3 Wochen wieder verkaufen will ich nicht. Es läuft gerade so "schön"...

Danke RUDI

 

[Benares]

Bei der zweitgrößten Tabelle wurde der Swap scheinbar garnicht genutzt. 2GB Swap hast du ja schon. Probier mal weitere 2GB mit der beschriebenen Methode anzuhängen. Vielleicht klappt es ja dann auch mit der großen Tabelle.

Gruß Benares

 

[jahlives]

einmal vor dem optimize der zweitgrößten Tabelle (900000 Einträge/100MB) und einmal danach.

interesant wäre während ;-) Zudem dürfte eine 100MB Tabelle zu klein sein
Ich würde mal die grösste nehmen und sofort nach dem Start des aufräumens auf der Konsole den Verbrauch live angucken. Dabei kann z.B. htop sehr hilfreich sein (das gibts aber nur via ipkg) oder top (sollte mit der Firmware geliefert werden) Dann könntest du sehen ob phpmyadmin aufgibt sobald der RAM ausgeht oder erst wenn auch der SWAP ausgeht. Was du zudem auch probieren könntest wäre es möglichst viele Dienste zu beenden. Denn was nicht läuft kann auch nicht abschmieren und will auch keinen RAM. Dann hättest du ein Maximum an RAM für phpmyadmin zur Verfügung. Für phpmyadmin muss eigentlich nur der Apache laufen. Und den SSH Daemon solltest du auch nicht beenden. Aber z.B. alle Mediendienste, samba, nfs (falls aktiviert) und noch mehr kann man deaktivieren. Gemäss Murphy fehlen die nur wenige MB oder gar nur KB RAM damit phpmyadmin durchlaufen kann ;-)