SQL Speichereinstellungen mySQl, MariaDB?

[dreivier]

Moin, kennt sich eventuell jemand mit den mySQL-Speichereinstellungen aus?
Ich habe heute die neueste xampp Distribution installiert und in der my.ini gesehen das die dortigen Einstellungen für Systeme
<= 64MB sind, und dachte, da ich ja 32GB im System an Ram habe, SQL etwas mehr geben um es eventuell flotter und stabieler zu machen...ich habe nämlich gelegentilich Crashes der MariaDB die sich auch nicht mehr reparieren lässt. Viele schreiben dass das meistens wegen Speichermangel passiert.
Leider habe ich keine deutsche und verständlich Doku oder Epfehlungen für Entwicklungsumgebungen am PC mit mehr Ram gefunden.

Eventuell ist hier ja jemand dabei der weiß welche Werte man erhöhen sollte und von welchen man die Finger lassen sollte.

Dies sind die Standardeinstellungen nach der Installation von xampp:

[mysqld]
key_buffer=16M
max_allowed_packet=1M
sort_buffer_size=512K
net_buffer_length=8K
read_buffer_size=256K
read_rnd_buffer_size=512K

innodb_data_file_path=ibdata1:10M:autoextend
innodb_buffer_pool_size=16M
innodb_log_file_size=5M
innodb_log_buffer_size=8M

[mysqldump]
max_allowed_packet=16M

[mysql]
# Remove the next comment character if you are not familiar with SQL
#safe-updates

[isamchk]
key_buffer=20M
sort_buffer_size=20M
read_buffer=2M
write_buffer=2M

[myisamchk]
key_buffer=20M
sort_buffer_size=20M
read_buffer=2M
write_buffer=2M

 

[Bagbag]

Dazu wäre es noch gut zu wissen, welche engine deine Datenbanken bzw Tabellen nutzen. MyISAM, Aria, InnoDB, sonst was?

 

[dreivier]

Ich habe extra die myisam EInstellungen rausgenommen und nur die InnoDB dringelassen weil ich auf die Intelligenz der Menschen gehofft habe :-/
InnoDB!

 

[Bagbag]

key_buffer ist aber MyISAM, wenn ich mich recht erinnere. Wenn du MyISAM nicht nutzt, solltest du die Einstellungen aber nicht rausnehmen, sondern einfach sehr klein setzen.

innodb_buffer_pool_size ist aber ziemlich klein. Das würde ich eher auf mehrere GB setzen. Im Idealfall passt da die gesamte DB rein.

 

[dreivier]

key_buffer..ja kann sein das ich da noch was vergessen habe...

Nur pool_size? der Rest kann bleiben?

 

[Bagbag]

Den Rest kann man nicht pauschal beantworten. Das hängt davon ab, was für Hardware du hast (IOPS), wie groß deine Transaktionen sind und und und.

 

[dreivier]

Alles klar, danke.

 

[blackbirdone]

Kannst ja eher mal schauen was zu crashes führt. Mit ist noch nie eine gecrasht die sind eigendlich sehr robust und genügsam

 

[dreivier]

Es crasht einfach, bin aber nicht der einzige...niemand weiß derzeit woran es liegt..aber auch erst seit ich xampp aktualisiert habe, vorher hatte ich eine portable Version von 2015, damit habe ich nie Probleme gehabt.
Bei xampp im Forum häufen sich auch die Beiträge, seit ca. März haben Leute Probleme damit...in der Windows Ereignisanzeige wird dann auch immer ein Fehler gesetzt, irgendwas mit I/O Buffer unknown User blabla - muss ich mir das nächste mal mal aufschreiben.

Ich habe aber festgestelt, das wenn ich xampp komplett neu installiere - zb. Update, das bereits dann in der schon angelegte Datenbank ,,mysql,, einige Tabellen korrupt sind, die man aber reparieren kann...diese Tabellen gehen aber nach einer Weile wieder kaputt...ich denke mal das es ein Bug ist der sich nicht auf jedem System bemerkbar macht..keine Ahnung. Ich habe das aber auf jeder Windows Version die ich nutzen, W10, 8.1, 7..immer das gleiche, xampp neu installiert...ein paar Tage dann damit gearbeitet, beim nächsten starten bricht das laden von mySQL aufeinmal mit einem Fehler ab...lässt sich auch nicht mehr reparieren.
Ich helfe mir jetzt so indem ich ein komplettes sauberes BackUp habe und drüber kopiere, hält dann wieder paar Tage/Wochen.

 

[Dalek]

Kenne mich bei MySQL nicht aus, aber ganz gut mit PostgreSQL. Egal ob noch Speicher frei ist oder nicht sollte eine Datenbank keine korrupten Tabellen produzieren. Es gibt natürlich bugs, aber diese Art von Bug sollte recht selten sein. Die weit wahrscheinlichere Ursache ist defekte Hardware, oder z.B. Hardware/OS die die Datenbank anlügen und behaupten Daten sind schon geschrieben die nur im Cache liegen.

Ich hab keine besonders hohe Meinung von MySQL (aber hab auch schon lange nichts damit gemacht), aber selbst dann ist Datenkorruption innerhalb von Tagen/Wochen einfach undenkbar. Da läuft irgendwas grundsätzlich schief.

MySQL dürfte sich auch ähnlich wie PostgreSQL etwas wohler unter Linux fühlen, falls das eine Alternative ist würde ich das auch mal versuchen.

 

[dreivier]

Unter Linux gibt es das Problem nicht, nur unter Windows. Wie gesagt, wenn ich der einzige wäre mit dem Fehler was ich am Anfang dachte und genau wie du meinte ich hätte eventuell einen defekten Ram, habe ich mich erst durchs Netz gelesen und dabei festgestellt das es schon etliche mit dem gleichen Problem gibt.
Also müsste es schon ein großer Zufall sein das alle einen Hardware-Defekt haben wobei der sich ja dann auch in anderen Software bemerkbar machen müsste z.B. in Spielen, Grafikbearbeitung oder Videobearbeitung.

Warum soll ein Bug dieser Art selten sein? welche sind denn nicht selten? verstehe jetzt nicht genau die Logik dahinter.

 

[GroMag]

Unter Linux gibt es das Problem nicht, nur unter Windows.

Dann baue eine VM für die DB (über vagrant zB). Mit diesem xampp-Gefrickel hab ich schon lange aufgehört. Privat wie auch auf Arbeit.

 

[dreivier]

Mit diesem xampp-Gefrickel hab ich schon lange aufgehört. Privat wie auch auf Arbeit.

Ja ich glaub auch langsam dass das nix ganzes und nix halbes ist.

 

[konkretor]

Seit WSL2 gibt es doch keinen Grund für XAMP, WSL2 aktivieren und los gehts.

https://docs.microsoft.com/de-de/windows/wsl/tutorials/wsl-database

https://askubuntu.com/questions/1249973/connect-mysql-workbench-to-wsl2

 

[Dalek]

Unter Linux gibt es das Problem nicht, nur unter Windows. Wie gesagt, wenn ich der einzige wäre mit dem Fehler was ich am Anfang dachte und genau wie du meinte ich hätte eventuell einen defekten Ram, habe ich mich erst durchs Netz gelesen und dabei festgestellt das es schon etliche mit dem gleichen Problem gibt.
Also müsste es schon ein großer Zufall sein das alle einen Hardware-Defekt haben wobei der sich ja dann auch in anderen Software bemerkbar machen müsste z.B. in Spielen, Grafikbearbeitung oder Videobearbeitung.

Warum soll ein Bug dieser Art selten sein? welche sind denn nicht selten? verstehe jetzt nicht genau die Logik dahinter.

Es gibt auch systematische "defekte" Hardware die ich mit "die Datenbank anlügen" meinte. Wenn die Datenbank dem OS sagt "schreib alles jetzt auf die Festplatte", das OS antwortet "hab ich gemacht" obwohl es die Daten nur im RAM hat, dann hat die Datenbank keine Chance Korruption zu verhindern. Diese Art von Schreibcache ist natürlich super für die Performance, aber es gibt dann keine Datensicherheit mehr.

Bugs die zu Datenkorruption führen werden sehr, sehr ernst genommen (meine Erfahrung hier ist wieder eher Postgres). Es gibt sie natürlich, aber sie sind einfach selten weil die Enwickler da auch sehr vorsichtig sind.

Ich würde deutlich eher XAMPP zutrauen das es irgendwas dämliches macht, und das ein Bug dort ist als in MySQL.

 

[GroMag]

Seit WSL2 gibt es doch keinen Grund für XAMP, WSL2 aktivieren und los gehts.

Auch wenn WSL(2) grad als der "heiße Scheiss" gehandelt wird, ziehe ich VMs über VirtualBox/vagrant vor. Schon allein, weil man multiple Maschinen gleichzeitig laufen lassen kann und auch der Wechsel zwischen verschiedenen nicht so ein Gefrickel wie bei WSL ist.

 

[dreivier]

Seit WSL2 gibt es doch keinen Grund für XAMP, WSL2 aktivieren und los gehts.

https://docs.microsoft.com/de-de/windows/wsl/tutorials/wsl-database

https://askubuntu.com/questions/1249973/connect-mysql-workbench-to-wsl2

Auch unter Windows 8.1? ich habe ein Notebook auf dem das ganze läuft, lässt sich leider nicht auf Windows 10 upgraden da zu alt, Treiberprobleme, keine Ahnung, mache mir da kein Kopf drüber.

 

[konkretor]

Hast nicht dazu geschrieben das du noch unter Windows 8.1 rumgurkst.

Dann bleibt dir nur VirtualBox oder Vmware Workstation übrig

 

[dreivier]

Es gibt auch systematische "defekte" Hardware die ich mit "die Datenbank anlügen" meinte. Wenn die Datenbank dem OS sagt "schreib alles jetzt auf die Festplatte", das OS antwortet "hab ich gemacht" obwohl es die Daten nur im RAM hat, dann hat die Datenbank keine Chance Korruption zu verhindern. Diese Art von Schreibcache ist natürlich super für die Performance, aber es gibt dann keine Datensicherheit mehr.

Naja komm, das ganze hat mit einer alten Version von Xampp funktioniert, und wie gesagt, dann müsste sich das doch auch in anderer Software bemerkbar machen...irgendwann..irgendwie..

Ich würde deutlich eher XAMPP zutrauen das es irgendwas dämliches macht, und das ein Bug dort ist als in MySQL.

Auch meine Vermutung, xampp killt mysql wohl zu hart und irgendwann kommt dann die Quittung..wenn ich es logisch betrachte sollte das Problem eigentlich keines mehr sein wenn man mySQL als Dienst einrichtet. Vermutlich hat die Mehrheit der Benutzer das auch so, und der Grund das nicht jeder die Probleme hat.
Werde ich mal testen...als letztes, danach überlege ich mir eine Alternative.

 

[Dalek]

Auch meine Vermutung, xampp killt mysql wohl zu hart und irgendwann kommt dann die Quittung.

Auch das sollte bei einer vernünftigen Datenbank egal sein. Man kann Postgres hart abschießen, oder den Rechner einfach vom Strom nehmen und es passiert gar nichts. Die Datenbank wird beim Neustart automatisch in einen konsistenten Zustand gebracht.

Es gibt bei Postgres eine Option die die Performance enorm steigert, aber Korruption beim Absturz verursacht. Evtl. gibt es etwas ähnliches bei MySQL, könnte z.B. "disable fsync" heissen.