cgroup: fork rejected by pids controller in /system.slice/mysql.service
Hallo zusammen, ich sitze gerade vor einem Server, der mich mit einem lustigen MySQL- Fehler "unterhält": Connect: Can't create a new thread (errno 11 "Resource temporarily unavailable"); if you are not out of available memory, you can consult the manual for a possible OS-dependent bug Diese Meldung kommt beim Aufruf von PostfixAdmin's list-virtual.php, aber nicht bei jedem Aufruf, sondern (grob geschätzt) bei jedem dritten Aufruf. Nach etwas Suche habe ich auch im Syslog und dmesg etwas gefunden: cgroup: fork rejected by pids controller in /system.slice/mysql.service Das scheint wohl des Pudels Kern zu sein, aber meine bisherigen Suchergebnisse zu beiden Fehlermeldungen waren wenig hilfreich. Ein Neustart von MySQL und sogar ein Reboot ändern nichts an der Situation. Hat jemand eine Idee, was dieses Problem auslösen könnte, und wie ich es beheben kann? Auf dem gleichen Server läuft auch ein Typo3 mit hunderten Seiten - soweit ich das sehe, läuft es problemlos, obwohl es vermutlich mehr MySQL-Queries macht. Der Server läuft mit Leap 42.2, Updates sind alle installiert. Ich bin für Tips und Vorschläge dankbar ;-) Gruß Christian Boltz -- [KDE3 vs. KDE4] My guess is the vocal minority will only be satisfied when KDE4 gets dropped. We need to let them know that might happen round about the release of KDE5.4 . [from a comment on http://blogs.warwick.ac.uk/bweber/entry/opensuse_110_kde4/] -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Mittwoch, 25. Januar 2017, 23:30:17 CET schrieb Christian Boltz:
[...] cgroup: fork rejected by pids controller in /system.slice/mysql.service
Das scheint wohl des Pudels Kern zu sein, aber meine bisherigen Suchergebnisse zu beiden Fehlermeldungen waren wenig hilfreich. [...]
Ich weiß zwar nicht was du so gefunden hast und ich habe hier kein mysql installiert und auch keine großartige Ahnung von systemd. Google sagt dazu https://lkml.org/lkml/2016/6/20/1085 | This patch adds more visibility into the pids controller when the controller | rejects a fork request. Whenever fork fails because the limit on the number | of pids in the cgroup is reached, the controller will log this and also | notify the newly added cgroups events file. The `max` key in the events file | represents the number of times fork failed because of the pids controller. https://www.freedesktop.org/software/systemd/man/systemd.resource-control.ht... redet von "TasksMax" welches dieses "pids.max" control group attribute steuert und von "DefaultTasksMax" in https://www.freedesktop.org/software/systemd/man/systemd-system.conf.html wo dann aber wieder steht, dass "DefaultTasksMax" nicht für slice units gilt. "systemctl status mysql.service" sagt was zu Tasks: xxx (limit: yyy)? Gruß Jan -- What men learn from history, is that men do not learn from history. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo Jan, hallo zusammen, Am Donnerstag, 26. Januar 2017, 00:00:37 CET schrieb Jan Ritzerfeld:
Am Mittwoch, 25. Januar 2017, 23:30:17 CET schrieb Christian Boltz:
[...] cgroup: fork rejected by pids controller in /system.slice/mysql.service
Das scheint wohl des Pudels Kern zu sein, aber meine bisherigen Suchergebnisse zu beiden Fehlermeldungen waren wenig hilfreich. [...]
Ich weiß zwar nicht was du so gefunden hast und ich habe hier kein mysql installiert und auch keine großartige Ahnung von systemd. Google sagt dazu https://lkml.org/lkml/2016/6/20/1085
Hatte ich auch gesehen - das ist der Patch, der die Fehlermeldung in den Kernel gebracht hat.
| This patch adds more visibility into the pids controller when the | controller rejects a fork request. Whenever fork fails because the | limit on the number of pids in the cgroup is reached, the | controller will log this and also notify the newly added cgroups | events file. The `max` key in the events file represents the number | of times fork failed because of the pids controller. https://www.freedesktop.org/software/systemd/man/systemd.resource-cont rol.html redet von "TasksMax" welches dieses "pids.max" control group attribute steuert und von "DefaultTasksMax" in https://www.freedesktop.org/software/systemd/man/systemd-system.conf.h tml wo dann aber wieder steht, dass "DefaultTasksMax" nicht für slice units gilt.
"systemctl status mysql.service" sagt was zu Tasks: xxx (limit: yyy)?
Üblicherweise ist da reichlich Luft: Tasks: 47 (limit: 512) Allerdings habe ich es gerade geschafft, den Wert (durch mehrfache Reloads von PostfixAdmin - ich kann aber andere Ursachen nicht ausschließen) auf 456 hochzutreiben, was gefährlich nah am Limit ist. Ich habe das Limit gerade hochgesetzt: # cat /etc/systemd/system/mysql.service.d/tasks.conf [Service] TasksMax=2000 Nach einem systemctl daemon-reload und MySQL-Neustart kann ich das Problem nicht mehr reproduzieren - das war also offenbar wirklich die Lösung. Danke, dass Du mich in die richtige Richtung gestupst hast! :-) Wenn ich jetzt noch wüsste, _warum_ PostfixAdmin so viele MySQL-Tasks verursacht... (falls es wirklich PostfixAdmin ist und nicht Typo3 / $whatever) Gruß Christian Boltz --
mit ist aufgefallen, dass die SPF Records von mailbox.org ungültige Parameter enthalten. Psssst, was erlauben Urban! :) Das ist ja fast wie Gotteslästerung! [> Urban Loesch und Django in postfixbuch-users]
-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Donnerstag, 26. Januar 2017, 11:40:05 CET schrieb Christian Boltz:
Hallo Jan, hallo zusammen,
Am Donnerstag, 26. Januar 2017, 00:00:37 CET schrieb Jan Ritzerfeld: (...).
"systemctl status mysql.service" sagt was zu Tasks: xxx (limit: yyy)?
Üblicherweise ist da reichlich Luft: Tasks: 47 (limit: 512)
Ja, sonst würden sich wahrscheinlich viele Leute darüber beklagen, aber wie du schon geschrieben hast, man findet da bei Google praktisch nichts zu.
Allerdings habe ich es gerade geschafft, den Wert (durch mehrfache Reloads von PostfixAdmin - ich kann aber andere Ursachen nicht ausschließen) auf 456 hochzutreiben, was gefährlich nah am Limit ist.
Das ist jedenfalls schon einmal ein starkes Indiz.
Ich habe das Limit gerade hochgesetzt:
# cat /etc/systemd/system/mysql.service.d/tasks.conf [Service] TasksMax=2000
Nach einem systemctl daemon-reload und MySQL-Neustart kann ich das Problem nicht mehr reproduzieren - das war also offenbar wirklich die Lösung.
Der Debian-Bug #823530 über Chrome der von /system.slice/xdm.service daran gehindert wurde, seine Threads zu erzeugen, führt wenigstens zum systemd 228 Changelog in dem steht, dass dieses Limit von 512 neu ist und services durchaus angepasst werden müssen.
Danke, dass Du mich in die richtige Richtung gestupst hast! :-)
Ja, gerne, ich hätte fast nicht geantwortet, weil ich mir nicht vorstellen konnte, dass du den Kernel-Patch nicht schon selbst gefunden hättest. Manchmal braucht man halt einfach eine rubber duck.
Wenn ich jetzt noch wüsste, _warum_ PostfixAdmin so viele MySQL-Tasks verursacht... (falls es wirklich PostfixAdmin ist und nicht Typo3 / $whatever) (...).
Wenn man nach mysql und threads sucht findet man einiges. Vielleicht steht da auch, wie man heraus bekommen kann, wer die threads überhaupt braucht. Ich würde da wahrscheinlich erst einmal mit innotop drauf gucken, bevor ich mir die passenden tables heraussuchen würde. :) Gruß Jan -- Statistical analysis has often meant the manipulation of ambiguous data by means of dubious methods to solve a problem that has not been defined. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
participants (2)
-
Christian Boltz -
Jan Ritzerfeld