MariaDB RAM Zuteilung wird überschritten / OOM-Killer

felon

Neuer Benutzer
Beiträge
4
Hallo zusammen :)

nachdem ich eine Herausforderung mit unserem MariaDB Server habe schlage ich nun hier auf und suche um Rat.
Ich hab schon einige Speichersettings und Anpassungen durch und mit Google bzw. Foren-Beiträge bin ich leider nicht schlauer geworden.


Worum gehts:
Wir haben einen MariaDB Server am laufen der sich nach 2-3 Tagen Laufzeit 18GB RAM und mehr nimmt, obwohl wir das so gar nicht konfiguriert haben.
Irgendwann wird nach ein paar Tagen dann ein OOM-Killer von PHP-FPM ausgelöst, da dieser Prozess kein RAM mehr bekommt.

Leider schaffe ich es nicht, MariaDB auf unter 8GB RAM zu begrenzen.

Hätte hier jemand einen Tipp warum es bei uns aus dem Ruder läuft mit dem Speicher?

Beste Grüße
Ralph

Details zum Server:
- ISPConfig-Container+MariaDB (nur webhosting für vtiger Instanzen)
- Debian 9.13 stretch
- Mariadb: 10.2.41-MariaDB-10.2.41+maria~stretch
- 30GB RAM

folgende Config nutzen wir für den Server:

# # These groups are read by MariaDB server. # Use it for options that only the server (but not clients) should see # # See the examples of server my.cnf files in /usr/share/mysql/ # # this is read by the standalone daemon and embedded servers [server] # this is only for the mysqld standalone daemon [mysqld] # # * Basic Settings # user = mysql pid-file = /var/run/mysqld/mysqld.pid socket = /var/run/mysqld/mysqld.sock port = 3306 basedir = /usr datadir = /var/lib/mysql tmpdir = /tmp lc-messages-dir = /usr/share/mysql skip-external-locking # Instead of skip-networking the default is now to listen only on # localhost which is more compatible and is not less secure. #bind-address = 127.0.0.1 sql-mode="NO_ENGINE_SUBSTITUTION" # # * Fine Tuning # max_sp_recursion_depth = 100 optimizer_search_depth = 0 key_buffer_size = 16M max_allowed_packet = 20M thread_stack = 512K thread_cache_size = 8 # This replaces the startup script and checks MyISAM tables if needed # the first time they are touched myisam_recover_options = BACKUP max_connections = 200 # # * Query Cache Configuration # query_cache_type = OFF query_cache_size = 0 # # * Logging and Replication # # Both location gets rotated by the cronjob. # Be aware that this log type is a performance killer. # As of 5.1 you can enable the log at runtime! #general_log_file = /var/log/mysql/mysql.log #general_log = 1 # # Error log - should be very few entries. # log_error = /var/log/mysql/error.log # # Enable the slow query log to see queries with especially long duration #slow_query_log_file = /var/log/mysql/mariadb-slow.log #long_query_time = 10 #log_slow_rate_limit = 1000 #log_slow_verbosity = query_plan #log-queries-not-using-indexes # # The following can be used as easy to replay backup logs or for replication. # note: if you are setting up a replication slave, see README.Debian about # other settings you may need to change. #server-id = 1 #log_bin = /var/log/mysql/mysql-bin.log expire_logs_days = 10 max_binlog_size = 100M # # * InnoDB # # InnoDB is enabled by default with a 10MB datafile in /var/lib/mysql/. # Read the manual for more InnoDB related options. There are many! innodb_buffer_pool_size=256M # # Set the log file size to about 25% of the buffer pool size innodb_log_file_size=64M innodb_log_buffer_size=64M # # * Security Features # # Read the manual, too, if you want chroot! # chroot = /var/lib/mysql/ # # For generating SSL certificates you can use for example the GUI tool "tinyca". # # ssl-ca=/etc/mysql/cacert.pem # ssl-cert=/etc/mysql/server-cert.pem # ssl-key=/etc/mysql/server-key.pem # # Accept only connections using the latest and most secure TLS protocol version. # ..when MariaDB is compiled with OpenSSL: # ssl-cipher=TLSv1.2 # ..when MariaDB is compiled with YaSSL (default in Debian): # ssl=on # # * Character sets # # MySQL/MariaDB default is Latin1, but in Debian we rather default to the full # utf8 4-byte character set. See also client.cnf # character-set-server = utf8 collation-server = utf8_general_ci # # * Unix socket authentication plugin is built-in since 10.0.22-6 # # Needed so the root database user can authenticate without a password but # only when running as the unix root user. # # Also available for other users if required. # See https://mariadb.com/kb/en/unix_socket-authentication-plugin/ # this is only for embedded server [embedded] # This group is only read by MariaDB servers, not by MySQL. # If you use the same .cnf file for MySQL and MariaDB, # you can put MariaDB-only options here [mariadb] # This group is only read by MariaDB-10.1 servers. # If you use the same .cnf file for MariaDB of different versions, # use this group for options that older servers don't understand [mariadb-10.1]
 
Werbung:
@dabadepdu
Ein Upgrade vom Container habe ich mich noch nicht getraut, bevor ich nicht den Rest in den Griff bekomme.
Bei einem Testsetup mit ISPConfig konnte ich maximal MariaDB 10.2 nutzen. Mit DB-Versionen darüber gab es Fehler nach der ISPConfig Installation.
 
Sorry, ich hatte den Beitrag wieder gelöscht. Diese Maria Version ist ja sogar noch so eben in der Wartung. Beim OS bin ich mir da nicht so sicher.
 
@dabadepdu nichts zu entschuldigen - bin ja wirklich dankbar über alle Hinweise :)

Das Upgrade auf die nächst höhere OS Version werde ich auch noch durchführen.
Ich verstehe nur nicht warum er so grob über den definierten Speicher hinausgeht...
Ist dir vllt. eine Variable aufgefallen die ich vergessen habe in der Config, die das verursachen könnte?
 
Hallo Ralph,

deine Frage lässt sich leider nicht so einfach beantworten. Das ganze Spiel hängt davon ab was du mit der DB anstellen möchtest / musst. z.B welche Engine du nutzt, wieviel Connections du max hast und wie gut oder schlecht deine Queries sind, denn daraus ergeben sich unterschiedliche Größen für sort buffer , etc und ob du mehr lese oder schreibzugriffe hast.

Denn einfach das RAM begrenzen hilft nicht. dann kann es sein das die Kiste langsam wird oder nicht genug clients sich anmelden können.

Gruß

Bernd
 
Ich hab keine Ahnung (von maria), neben dem was Bernd schreibt, finde ich das unten etwas verdächtig. Wirklich aus? Und schaltet es der folgende Eintrag vielleicht ein und zwar auf unlimeted?
query_cache_type = OFF
query_cache_size = 0

Und: Ist überhaupt klar, dass der wachsende Speicherbedarf von maria kommt? Wenn der reine (erfolgreiche) Neustart von Maria zu dieser Überlegung führt, das kann auch einfach ein Randeffekt sein. DB ist weg, also bauen sich auch andere Prozesse ab und beim Neustart neu auf...
 
P.S: Neben dem Blick auf eine statische Config hilft u.U. auch ein Blick auf die realen Werte, also die "amtierenden", am besten innerhalb einer Session per SQL. (Sofern das geht bei Maria)
 
Sorry,

das mit dem Query cache ist das einzig richtige !!!
Es kann nicht sein das das System entscheidet welche Queries in den cache kommen. Die einzige Möglichkeit den Cache sinnvoll zu nutzen ist ON DEMAND, denn dann kann ICH festlegen ob das Ergebnis in den cache gehört oder nicht.

Ein schlecht genutzter cache verlangsamt das System um bis zu 13%. Denn er legt dann alle Ergebnisse rein und ist mit dem Prüfen und freigeben von gerade eingestelleten und schon veralteten Queries beschäftigt.


Gruß Bernd
 
Hm, wie gesagt, ich habe keine Ahnung von Maria, ich nutze es nicht.
Aber was Du da schreibst, entspricht nicht meiner Vorstellung von einem Cache. Ich habe noch nie irgendwo ein Chache benutzt, wo ich mich daneben gesetzt hab, um zu soufflieren, was er sich merken soll und was nicht.
 
Mir kommen die max_connections = 200 sehr viel vor - selbst bei einem gut genutzten Datenbankserver brauchte ich bisher nie so hohe Werte - und manche Einstellungen verbrauchen ja RAM pro Connection.

Lad Dir mal das Tool Mysqltuner herunter:

Die Empfehlungen des Tools sind zwar zum Teil nicht ernst zu nehmen, aber es sagt Dir wenigstens, wieviel RAM mit Deinen Einstellungen maximal verbraucht wird.
 
Hallo Walter max_connections spielt keine Rolle, da MySQL / MariaDB sich nur ein paar KB je Connection reserviert und Werte über 200 sind nicht selten z.B. bei Shopsystemen ist ein Wert von 1000 nicht unüblich.

Viel wichtiger ist der Buffer Pool der ca. 60% des zu verwendeten RAMs betragen soll. Also z.B. 12GB wenn du Maria 16GB geben möchtest. Ralph hat 256M verwendet. und file_per_table sollte gesetzt sein. Falls nich gesetzt muss die DB neu eingespielt werden und überprüft werden ob genügend handels ferfügbar sind. Man rechnet dann 4 pro Tabelle.

Also...., es gibt viel zu tun.

Gruß Bernd
 
da MySQL / MariaDB sich nur ein paar KB je Connection reserviert

Soweit kenne ich mich nicht so schlecht aus :) Aber ich habe schon Anfänger und angebliche Profis gesehen, die ihr Mysql mit unmöglichen Werten konfiguriert haben und "Profihosts" die z.B. keinen Innodb-Puffer vorgesehen hatten etc.
 
Ist auch nicht ganz einfach wenn man bedenkt das es über 1000 Werte gibt die man "NETT" verdrehen kann und das MySQL und auch MariaDB in jeder Version die DEFAULT Werte ändert. Somit kann es sein das deine Config bisher super war aber nach einem Upgrade nur noch schlecht performt.
 
Ist auch nicht ganz einfach wenn man bedenkt das es über 1000 Werte gibt die man "NETT" verdrehen kann und das MySQL und auch MariaDB in jeder Version die DEFAULT Werte ändert. Somit kann es sein das deine Config bisher super war aber nach einem Upgrade nur noch schlecht performt.
kann ich mir jetzt nicht verkneifen, aber mit PostgreSQL ist das einfacher ;-)
 
Werbung:
kann ich mir jetzt nicht verkneifen, aber mit PostgreSQL ist das einfacher ;-)
Sorry, ich glaube ja viel, bzw. fast alles, aber das nicht. Ich habe PostgreSQL noch nie produktiv eingesetzt, aber wenn man nichts einstellen kann ist das schon die erste Riesen Schwachstelle. Denn woher will ein System wissen wie es arbeiten soll.
Und die Doku scheint da auch andrer Meinung zu sein.


Da sind wir heute mal nicht einer Meinung :)
 
Zurück
Oben