[gelöst] Problem mit glusterFS - fork: Nicht genügend Hauptspeicher verfügbar
[gelöst] Problem mit glusterFS - fork: Nicht genügend Hauptspeicher verfügbar
Hallo,
wir haben in einem Fujitsu-Bladecenter 10 Blades für ein Terminal-basierendes Browser-System (Recobs) in Betrieb.
Über einen FreeNX-Server werden Firefox-Sessions an die User ausgeliefert.
Die Server werden über einen Loadbalancer im Round-Robin-Betrieb zugeteilt.
Bisher war es so, dass jeder User auf jedem Server ein Home-Verzeichnis und ein Firefox-Profil hatte.
Landete er bei der nächsten Anmeldung auf einem anderen Server wurden die relevanten Daten des Firefox-Profils
(Lesezeichen, Chronik) auf den aktuellen Server kopiert und dann die Session gestartet.
Etwas umständlich, hat aber 10 Jahre lang (mehr oder weniger) gut funktioniert.
Da nun ein aktuellerer Browser notwendig wurde (TLS 1.2 usw.) haben wir auch neue Hardware beschafft.
Die 10 neuen Blades haben je 2 Xeon E5-2640 @ 2.40GHz und je 256 GB RAM.
Um die Home-Verzeichnisse und damit auch die Firefox-Daten zu zentralisieren haben wir glusterFS installiert.
Ein Volume wird auf allen Servern nach /home gemounted.
Auf den Servern ist Debian 8.9 installiert.
Als Firefox kommt der 45.8 ESR zum Einsatz.
Diese Installation haben wir vorher, noch auf der alten Hardware mit 4 Servern mehrere Monate lang getestet.
Das Volume bestand hier aus 4 Bricks und war distributed-replicated (replica 2).
Allerdings standen uns "nur" 350 Tester zur Verfügung, von denen ca 50 gleichzeitig online waren, also ca. 12 - 13 pro Server.
In dem neuen System mit den 10 neuen Blades liegt /home auf einem distributed-replicated (replica 3) Volume mit 9 Bricks.
Inzwischen existieren dort über 5000 Home-Verzeichnissse und pro Server sind in Spitzenzeiten 100 - 120 User online.
Nach ca. einer Woche begannen die Probleme.
Authentifizierungen über ssh und /oder winbind waren plötzlich sporadisch nicht mehr möglich und Prozesse liessen sich nicht mehr starten.
Die Fehlermeldung lautet immer bash: fork: Nicht genügend Hauptspeicher verfügbar
Hier ein Anmeldeversuch mit putty und Ausgabe von free -h:
Zu der Zeit waren auf diesem Server 93 User online.
Laut Google sind solche Probleme mit Anpassungen von Kernel-Parametern zu beheben.
Folgende Parameter haben wir bisher augepasst (/etc/sysctl.d/gluster_opt.conf):
in Klammern stehen die default-Werte
------------------------------------------------------------------------------------------------------------------
# Shared Memory Limits
######################
kernel.shmmni = 65536 (4096)
# Messages Limits
#################
kernel.msgmax = 65536 (8192)
kernel.msgmnb = 65536 (16384)
kernel.msgmni = 262144 (32768)
# Semaphore Limits
##################
#kernel.sem = <SEMMSL> <SEMMNS> <SEMOPM> <SEMMNI>
kernel.sem = 250 1024000 32 65536 (250 32000 32 128)
# Netzwerk
##########
net.core.rmem_default = 212992
net.core.rmem_max = 4259840 (212992)
net.core.wmem_default = 212992
net.core.wmem_max = 1064960 (212992)
net.ipv4.tcp_keepalive_time = 300 (7200)
# Dateizugriff
##############
fs.aio-max-nr = 1064960 (65536)
fs.file-max = 26450162 (26450163)
fs.mqueue.msg_max = 8192 (10)
#VM
###
vm.swappiness = 1 (60)
vm.vfs_cache_pressure = 300 (100)
vm.dirty_background_ratio = 5 (10)
vm.dirty_ratio = 10 (20)
vm.admin_reserve_kbytes=32768 (8192)
Leider haben die Änderungen wenn überhaupt, dann nur kurzzeitig Verbesserungen gezeigt.
Weiterhin sind zu manchen Parametern differierende Aussagen zu finden.
Wir suchen also nach wie vor die Ursache für diese Fehlermeldung und
die entsprechenden Parameter mit denen sie beseitigt werden kann.
Ich hoffe, ich habe unser Problem verständlich dargelegt und bin für jede erdenkliche Hilfe dankbar!
Gruß
Andreas
wir haben in einem Fujitsu-Bladecenter 10 Blades für ein Terminal-basierendes Browser-System (Recobs) in Betrieb.
Über einen FreeNX-Server werden Firefox-Sessions an die User ausgeliefert.
Die Server werden über einen Loadbalancer im Round-Robin-Betrieb zugeteilt.
Bisher war es so, dass jeder User auf jedem Server ein Home-Verzeichnis und ein Firefox-Profil hatte.
Landete er bei der nächsten Anmeldung auf einem anderen Server wurden die relevanten Daten des Firefox-Profils
(Lesezeichen, Chronik) auf den aktuellen Server kopiert und dann die Session gestartet.
Etwas umständlich, hat aber 10 Jahre lang (mehr oder weniger) gut funktioniert.
Da nun ein aktuellerer Browser notwendig wurde (TLS 1.2 usw.) haben wir auch neue Hardware beschafft.
Die 10 neuen Blades haben je 2 Xeon E5-2640 @ 2.40GHz und je 256 GB RAM.
Um die Home-Verzeichnisse und damit auch die Firefox-Daten zu zentralisieren haben wir glusterFS installiert.
Ein Volume wird auf allen Servern nach /home gemounted.
Auf den Servern ist Debian 8.9 installiert.
Als Firefox kommt der 45.8 ESR zum Einsatz.
Diese Installation haben wir vorher, noch auf der alten Hardware mit 4 Servern mehrere Monate lang getestet.
Das Volume bestand hier aus 4 Bricks und war distributed-replicated (replica 2).
Allerdings standen uns "nur" 350 Tester zur Verfügung, von denen ca 50 gleichzeitig online waren, also ca. 12 - 13 pro Server.
In dem neuen System mit den 10 neuen Blades liegt /home auf einem distributed-replicated (replica 3) Volume mit 9 Bricks.
Inzwischen existieren dort über 5000 Home-Verzeichnissse und pro Server sind in Spitzenzeiten 100 - 120 User online.
Nach ca. einer Woche begannen die Probleme.
Authentifizierungen über ssh und /oder winbind waren plötzlich sporadisch nicht mehr möglich und Prozesse liessen sich nicht mehr starten.
Die Fehlermeldung lautet immer bash: fork: Nicht genügend Hauptspeicher verfügbar
Hier ein Anmeldeversuch mit putty und Ausgabe von free -h:
Zu der Zeit waren auf diesem Server 93 User online.
Laut Google sind solche Probleme mit Anpassungen von Kernel-Parametern zu beheben.
Folgende Parameter haben wir bisher augepasst (/etc/sysctl.d/gluster_opt.conf):
in Klammern stehen die default-Werte
------------------------------------------------------------------------------------------------------------------
# Shared Memory Limits
######################
kernel.shmmni = 65536 (4096)
# Messages Limits
#################
kernel.msgmax = 65536 (8192)
kernel.msgmnb = 65536 (16384)
kernel.msgmni = 262144 (32768)
# Semaphore Limits
##################
#kernel.sem = <SEMMSL> <SEMMNS> <SEMOPM> <SEMMNI>
kernel.sem = 250 1024000 32 65536 (250 32000 32 128)
# Netzwerk
##########
net.core.rmem_default = 212992
net.core.rmem_max = 4259840 (212992)
net.core.wmem_default = 212992
net.core.wmem_max = 1064960 (212992)
net.ipv4.tcp_keepalive_time = 300 (7200)
# Dateizugriff
##############
fs.aio-max-nr = 1064960 (65536)
fs.file-max = 26450162 (26450163)
fs.mqueue.msg_max = 8192 (10)
#VM
###
vm.swappiness = 1 (60)
vm.vfs_cache_pressure = 300 (100)
vm.dirty_background_ratio = 5 (10)
vm.dirty_ratio = 10 (20)
vm.admin_reserve_kbytes=32768 (8192)
Leider haben die Änderungen wenn überhaupt, dann nur kurzzeitig Verbesserungen gezeigt.
Weiterhin sind zu manchen Parametern differierende Aussagen zu finden.
Wir suchen also nach wie vor die Ursache für diese Fehlermeldung und
die entsprechenden Parameter mit denen sie beseitigt werden kann.
Ich hoffe, ich habe unser Problem verständlich dargelegt und bin für jede erdenkliche Hilfe dankbar!
Gruß
Andreas
Zuletzt geändert von abrodeck am 08.12.2017 14:05:20, insgesamt 1-mal geändert.
- heisenberg
- Beiträge: 3559
- Registriert: 04.06.2015 01:17:27
- Lizenz eigener Beiträge: MIT Lizenz
Re: Problem mit glusterFS - fork: Nicht genügend Hauptspeicher verfügbar
Bitte Mal die Ausgabe von dmesg via NoPaste hier rein und vielleicht einen Textscreenshot(via Maus per Copy+Paste) von top nach Speicherverbrauch sortiert hier per Code-Tags reinstellen.
Sind vtl. noch weitere Meldungen in /var/log/{syslog,kern,daemon.log} ?
Grundsätzlich würde ich mal die genannten Stellen nach Warnungen und Fehler durchforsten.
Weiterhin würde ich zur Recherche die locales jeweils auf "C" stellen und dann die so erhaltenen exakten englischen Fehlermeldungen googlen.
Also:
Im übrigen ist ein gutes Performancemonitoring in solchen Fällen sehr hilfreich(Ich verwende Check_MK dafür). Ich könnte mir vorstellen, dass das Problem evtl. durch einen Reboot vorläufig nochmal Entlastung findet. Wenn man dann anhand mancher Werte sieht, was sich da tut, dann hat man vielleicht Anhaltspunkte, wann und warum es bricht.
Ansonsten warte ich mal auf die mit Sicherheit guten Tips der anderen.
Sind vtl. noch weitere Meldungen in /var/log/{syslog,kern,daemon.log} ?
Grundsätzlich würde ich mal die genannten Stellen nach Warnungen und Fehler durchforsten.
Weiterhin würde ich zur Recherche die locales jeweils auf "C" stellen und dann die so erhaltenen exakten englischen Fehlermeldungen googlen.
Also:
Code: Alles auswählen
export LC_ALL=C
... irgend ein Befehl ...
Ansonsten warte ich mal auf die mit Sicherheit guten Tips der anderen.
Jede Rohheit hat ihren Ursprung in einer Schwäche.
Re: Problem mit glusterFS - fork: Nicht genügend Hauptspeicher verfügbar
Hallo heisenberg,
danke für die schnelle Antwort.
Bevor ich mich daran mache Deinen weiteren Ansätzen zu folgen hier schon mal die Auagabe von dmesg unt top.
Beides wurde etwa zur selben Zeit auf dem selben Server erstellt. Ich habe extra einen ausgewählt der gerade richtig Probleme hat.
Ich konnte z.B. erst nach mehreren Versuchen eine ssh-Verbindung aufbauen.
dmesg:
40080
top:
Gruß
Andreas
danke für die schnelle Antwort.
Bevor ich mich daran mache Deinen weiteren Ansätzen zu folgen hier schon mal die Auagabe von dmesg unt top.
Beides wurde etwa zur selben Zeit auf dem selben Server erstellt. Ich habe extra einen ausgewählt der gerade richtig Probleme hat.
Ich konnte z.B. erst nach mehreren Versuchen eine ssh-Verbindung aufbauen.
dmesg:
40080
top:
Code: Alles auswählen
Tasks: 826 total, 2 running, 822 sleeping, 0 stopped, 2 zombie
%Cpu(s): 4,2 us, 1,3 sy, 0,0 ni, 94,2 id, 0,2 wa, 0,0 hi, 0,1 si, 0,0 st
KiB Mem: 26452168+total, 66525088 used, 19799659+free, 137448 buffers
KiB Swap: 9764860 total, 0 used, 9764860 free. 42146552 cached Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1902 root 20 0 4014280 3,027g 7232 S 0,3 1,2 295:50.14 glusterfs
8918 xxxxxxxx 20 0 0,243t 827756 71440 S 3,6 0,3 31:20.67 firefox
13131 xxxxxxxx 20 0 56,223g 426260 73100 S 0,3 0,2 6:40.91 firefox
32884 xxxxxxxx 20 0 3085860 402900 72344 S 15,4 0,2 116:53.47 firefox
25834 xxxxxxxx 20 0 2803268 327980 73636 S 0,0 0,1 6:58.37 firefox
24325 xxxxxxxx 20 0 2043344 314108 68696 S 104,4 0,1 95:08.39 firefox
6160 xxxxxxxx 20 0 1973148 311424 71532 R 28,2 0,1 16:52.97 firefox
13823 xxxxxxxx 20 0 1935096 302736 68912 S 0,3 0,1 4:47.52 firefox
13328 xxxxxxxx 20 0 1946684 293464 72732 S 3,6 0,1 24:54.60 firefox
17774 xxxxxxxx 20 0 1927640 282204 72912 S 1,3 0,1 1:50.53 firefox
17470 xxxxxxxx 20 0 1895252 259736 67860 S 0,3 0,1 0:27.35 firefox
1795 root 20 0 1952384 194396 7824 S 71,2 0,1 846:24.24 glusterfsd
27279 xxxxxxxx 20 0 232288 157312 8164 S 2,0 0,1 14:22.09 nxagent
13043 xxxxxxxx 20 0 240816 153232 8228 S 0,0 0,1 3:04.06 nxagent
20033 xxxxxxxx 20 0 231360 144744 8216 S 0,0 0,1 0:21.13 nxagent
20990 xxxxxxxx 20 0 217364 141516 8184 S 0,0 0,1 6:00.12 nxagent
8872 xxxxxxxx 20 0 221196 133576 8208 S 0,3 0,1 2:13.69 nxagent
22727 xxxxxxxx 20 0 189712 114772 8156 S 0,0 0,0 0:32.78 nxagent
13611 xxxxxxxx 20 0 190652 111084 8228 S 0,0 0,0 2:25.37 nxagent
14563 xxxxxxxx 20 0 189392 107952 8208 S 0,3 0,0 1:29.36 nxagent
459 root 20 0 143988 100400 99748 S 0,0 0,0 0:18.32 systemd-journal
2058 xxxxxxxx 20 0 159316 84192 8128 S 0,0 0,0 0:07.54 nxagent
16883 xxxxxxxx 20 0 150184 72844 8228 S 0,0 0,0 0:02.16 nxagent
5891 root 20 0 288328 34620 30432 S 0,0 0,0 0:00.84 winbindd
22132 xxxxxxxx 20 0 1017268 33616 23492 S 0,0 0,0 0:00.08 firefox
17652 xxxxxxxx 20 0 968020 33156 23272 S 0,0 0,0 0:00.30 firefox
1510 root 20 0 273728 32240 28160 S 0,0 0,0 0:43.34 winbindd
2107 root 20 0 295268 22924 20488 S 0,0 0,0 0:02.59 smbd
2102 root 20 0 272604 20944 18900 S 0,0 0,0 0:03.84 winbindd
2103 root 20 0 272192 20556 18520 S 0,0 0,0 0:03.50 winbindd
1519 root 20 0 267220 20152 17880 S 0,0 0,0 0:01.53 winbindd
1792 root 20 0 266048 17748 15672 S 0,0 0,0 0:00.16 winbindd
1651 root 20 0 949908 13340 5916 S 0,0 0,0 2:21.10 glusterfs
1351 xxxxxxxx 20 0 307336 12576 8100 S 0,0 0,0 0:00.11 colord
23896 xxxxxxxx 20 0 94652 12108 8048 S 0,0 0,0 0:00.03 nxagent
17636 xxxxxxxx 20 0 94652 12080 8024 S 0,0 0,0 0:00.03 nxagent
36141 xxxxxxxx 20 0 94652 11976 7916 S 0,0 0,0 0:00.04 nxagent
28799 xxxxxxxx 20 0 105932 11956 7896 S 0,0 0,0 0:00.03 nxagent
21750 xxxxxxxx 20 0 106172 11940 7880 S 0,0 0,0 0:00.04 nxagent
8959 xxxxxxxx 20 0 94492 11840 7780 S 0,0 0,0 0:00.02 nxagent
1089 root 20 0 470212 10176 7240 S 0,0 0,0 0:07.69 glusterd
1 root 20 0 33200 8680 3028 S 0,0 0,0 0:37.53 systemd
2125 root 20 0 295792 8076 5640 S 0,0 0,0 0:00.27 smbd
root@poldx03:~#
Andreas
- heisenberg
- Beiträge: 3559
- Registriert: 04.06.2015 01:17:27
- Lizenz eigener Beiträge: MIT Lizenz
Re: Problem mit glusterFS - fork: Nicht genügend Hauptspeicher verfügbar
Im würde ich grundsätzlich entweder davon ausgehen, dass der Arbeitsspeicher tatsächlich voll ist oder dass da irgendwelche Resourcen aufgrund von zu gering gewählten Kernel-/Systemparametern nicht komplett nutzbar sind, da die Systeme ja doch etwas grösser dimensioniert ist, als übliche Systeme und insofern evtl. nicht passend vorkonfiguriert sind.
Man könnte auch mal testweise etwas Swap hinzufügen(vielleicht mal 50 GB), um zu sehen, ob der denn tatsächlich auch gleich aufgebraucht wird. Browser verbrauchen ja teilweise immense Mengen an RAM.
Im dmesg fällt mir auf, dass da viele "segfaults" sind, wobei ich mich frage, ob dass das typische Fehlerbild bei zu wenig Speicher ist, oder ob es da noch Hardwareprobleme gibt.
Wenn man einen von den Servern(bzw. sukzessive einzelne Server nacheinander) mal offline nehmen, kann würde ich auch mal einen Speichertest(memtest) drüberlaufen lassen. Das dauert dann wohl aber bei der RAM-Menge mehrere Tage.
Man könnte auch mal testweise etwas Swap hinzufügen(vielleicht mal 50 GB), um zu sehen, ob der denn tatsächlich auch gleich aufgebraucht wird. Browser verbrauchen ja teilweise immense Mengen an RAM.
Im dmesg fällt mir auf, dass da viele "segfaults" sind, wobei ich mich frage, ob dass das typische Fehlerbild bei zu wenig Speicher ist, oder ob es da noch Hardwareprobleme gibt.
Wenn man einen von den Servern(bzw. sukzessive einzelne Server nacheinander) mal offline nehmen, kann würde ich auch mal einen Speichertest(memtest) drüberlaufen lassen. Das dauert dann wohl aber bei der RAM-Menge mehrere Tage.
Jede Rohheit hat ihren Ursprung in einer Schwäche.
Re: Problem mit glusterFS - fork: Nicht genügend Hauptspeicher verfügbar
Damit bestätigst Du prinzipiell unsere Vermutungen.
Die Server swappen laut free und top überhaupt nicht.
Ebenso ist der RAM zu keiner Zeit mehr als zu 40 % belegt.
Da es sich um ECC-RAM handelt und auch noch 10 Server
das gleiche Verhalten zeigen schliessen wir RAM-Fehler eher aus.
Der Grund so viel RAM einzusetzen war genau der, dass der Firefox 45 +
wesentlich mehr RAM frisst als der alte 17er, der bis vor kurzem bei uns noch lief.
Aber gerade auf Grund dessen, dass weder RAM noch Swap scheinbar an ihre Grenzen kommen
und wir trotzdem solche Probleme haben, haben wir uns auch den Kernel-Parametern zugewandt.
Als Quellen für die geposteten Einstellungen haben wir vor allem diese Seiten herangezogen:
https://www.ibm.com/support/knowledgece ... 08238.html
https://books.google.de/books?id=1vGVAg ... rk&f=false
Auch deine Vermutung, dass ein Reboot vorübergehende Entlastung schafft ist richtig.
Allerdings ist das im Livebetrieb natürlich nicht praktikabel.
Das durchsehen der Logfiles hat folgendes ergeben:
cat /var/log/daemon.log | grep memory (Auszug, die selben Meldungen erscheinen auch im syslog)
Am kern.log sind wir noch dran.
Gruß
Andreas
Die Server swappen laut free und top überhaupt nicht.
Ebenso ist der RAM zu keiner Zeit mehr als zu 40 % belegt.
Da es sich um ECC-RAM handelt und auch noch 10 Server
das gleiche Verhalten zeigen schliessen wir RAM-Fehler eher aus.
Der Grund so viel RAM einzusetzen war genau der, dass der Firefox 45 +
wesentlich mehr RAM frisst als der alte 17er, der bis vor kurzem bei uns noch lief.
Aber gerade auf Grund dessen, dass weder RAM noch Swap scheinbar an ihre Grenzen kommen
und wir trotzdem solche Probleme haben, haben wir uns auch den Kernel-Parametern zugewandt.
Als Quellen für die geposteten Einstellungen haben wir vor allem diese Seiten herangezogen:
https://www.ibm.com/support/knowledgece ... 08238.html
https://books.google.de/books?id=1vGVAg ... rk&f=false
Auch deine Vermutung, dass ein Reboot vorübergehende Entlastung schafft ist richtig.
Allerdings ist das im Livebetrieb natürlich nicht praktikabel.
Das durchsehen der Logfiles hat folgendes ergeben:
cat /var/log/daemon.log | grep memory (Auszug, die selben Meldungen erscheinen auch im syslog)
Code: Alles auswählen
Dec 6 08:10:57 poldx03 systemd[19760]: Failed to fork: Cannot allocate memory
Dec 6 08:13:09 poldx03 systemd[19855]: Failed to fork: Cannot allocate memory
Dec 6 08:16:38 poldx03 systemd[20143]: Failed at step PAM spawning /lib/systemd/systemd: Cannot allocate memory
Dec 6 08:18:33 poldx03 systemd[19855]: Failed at step PAM spawning /lib/systemd/systemd: Cannot allocate memory
Dec 6 08:20:58 poldx03 systemd[38874]: Failed to fork: Cannot allocate memory
Dec 6 08:22:14 poldx03 systemd[7176]: Failed at step PAM spawning /lib/systemd/systemd: Cannot allocate memory
Dec 6 08:25:23 poldx03 systemd[23001]: Failed to fork: Cannot allocate memory
Dec 6 08:25:59 poldx03 systemd[37094]: Failed to fork: Cannot allocate memory
Dec 6 08:26:00 poldx03 systemd[37094]: systemd-exit.service failed to run 'start' task: Cannot allocate memory
Dec 6 08:29:54 poldx03 systemd[31168]: Failed at step PAM spawning /lib/systemd/systemd: Cannot allocate memory
Dec 6 08:31:11 poldx03 systemd[28367]: Failed at step PAM spawning /lib/systemd/systemd: Cannot allocate memory
Dec 6 08:33:40 poldx03 systemd[19801]: Failed to fork: Cannot allocate memory
Dec 6 08:41:50 poldx03 systemd[32561]: Failed to fork: Cannot allocate memory
Dec 6 08:41:51 poldx03 systemd[32561]: systemd-exit.service failed to run 'start' task: Cannot allocate memory
Dec 6 08:42:49 poldx03 systemd[11418]: Failed at step PAM spawning /lib/systemd/systemd: Cannot allocate memory
Dec 6 08:53:22 poldx03 systemd[19760]: Failed at step PAM spawning /lib/systemd/systemd: Cannot allocate memory
Dec 6 08:56:16 poldx03 systemd[19681]: Failed at step PAM spawning /lib/systemd/systemd: Cannot allocate memory
Dec 6 08:59:25 poldx03 systemd[14532]: Failed at step PAM spawning /lib/systemd/systemd: Cannot allocate memory
Dec 6 09:00:00 poldx03 systemd[18278]: Failed to fork: Cannot allocate memory
Dec 6 09:05:25 poldx03 systemd[19047]: Failed at step PAM spawning /lib/systemd/systemd: Cannot allocate memory
Dec 6 09:06:47 poldx03 systemd[32646]: Failed to fork: Cannot allocate memory
Dec 6 09:08:54 poldx03 systemd[16240]: Failed at step PAM spawning /lib/systemd/systemd: Cannot allocate memory
Dec 6 09:13:08 poldx03 systemd[27504]: Failed to fork: Cannot allocate memory
Dec 6 09:17:47 poldx03 systemd[11405]: Failed at step PAM spawning /lib/systemd/systemd: Cannot allocate memory
Dec 6 11:59:51 poldx03 systemd[39983]: Failed to fork: Cannot allocate memory
Dec 6 11:59:51 poldx03 systemd[39983]: systemd-exit.service failed to run 'start' task: Cannot allocate memory
Dec 6 12:17:50 poldx03 systemd[40936]: Failed to fork: Cannot allocate memory
Dec 6 13:31:17 poldx03 systemd[15016]: systemd-exit.service failed to run 'start' task: Cannot allocate memory
Dec 6 13:31:20 poldx03 systemd[11325]: Failed at step PAM spawning /lib/systemd/systemd: Cannot allocate memory
Dec 6 13:34:09 poldx03 systemd[24167]: Failed at step PAM spawning /lib/systemd/systemd: Cannot allocate memory
Dec 6 14:37:50 poldx03 systemd[3434]: Failed at step PAM spawning /lib/systemd/systemd: Cannot allocate memory
Dec 6 14:39:48 poldx03 systemd[8389]: Failed at step PAM spawning /lib/systemd/systemd: Cannot allocate memory
Gruß
Andreas
- heisenberg
- Beiträge: 3559
- Registriert: 04.06.2015 01:17:27
- Lizenz eigener Beiträge: MIT Lizenz
Re: Problem mit glusterFS - fork: Nicht genügend Hauptspeicher verfügbar
Anzahl geöffneter Dateien?
Code: Alles auswählen
lsof | wc -l
cat /proc/sys/fs/file-max
Jede Rohheit hat ihren Ursprung in einer Schwäche.
Re: Problem mit glusterFS - fork: Nicht genügend Hauptspeicher verfügbar
lsof | wc -l:
zwischen 2.628.503 und 11.524.247
cat /proc/sys/fs/file-max:
auf allen Servern: 26.450.162
Gruß
Andreas
zwischen 2.628.503 und 11.524.247
cat /proc/sys/fs/file-max:
auf allen Servern: 26.450.162
Gruß
Andreas
Re: Problem mit glusterFS - fork: Nicht genügend Hauptspeicher verfügbar
Gibt es innerhalb einer FreeNX-Session irgendwelche Beschränkungen?
Gibt es für den User, unter dem die Session läuft, z.B. ulimits, quota, etc.?
Was sagt denn z.B. ulimit -a als spezifischer User (nicht root)?
Gibt es für den User, unter dem die Session läuft, z.B. ulimits, quota, etc.?
Was sagt denn z.B. ulimit -a als spezifischer User (nicht root)?
Re: Problem mit glusterFS - fork: Nicht genügend Hauptspeicher verfügbar
Hallo MSfree,
quotas haben wir nicht eingerichtet
und die ulimits haben wir bisher auch nicht angefasst:
Gruß
Andreas
quotas haben wir nicht eingerichtet
und die ulimits haben wir bisher auch nicht angefasst:
Code: Alles auswählen
root@poldx11:/etc#
root@poldx11:/# su - xxxxxxxx
xxxxxxxx@poldx11:~$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 1033221
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 65536
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 1033221
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
Andreas
- heisenberg
- Beiträge: 3559
- Registriert: 04.06.2015 01:17:27
- Lizenz eigener Beiträge: MIT Lizenz
Re: Problem mit glusterFS - fork: Nicht genügend Hauptspeicher verfügbar
ulimit-Probleme halte ich für unwahrscheinlich. Wie man oben(erster Beitrag, Screenshot) sieht, tritt die Problematik auch als root auf.
Jede Rohheit hat ihren Ursprung in einer Schwäche.
- heisenberg
- Beiträge: 3559
- Registriert: 04.06.2015 01:17:27
- Lizenz eigener Beiträge: MIT Lizenz
Re: Problem mit glusterFS - fork: Nicht genügend Hauptspeicher verfügbar
Ich habe mir den top von oben nochmal angeschaut:
Heisst das, dass PID 8918 ganze 243 GB virtuellen Speicher verbraucht und PID 13131 ganze 56 GB? Ist nur virtuell, aber trotzdem.
Vielleicht hilft es da doch mal ein paar Limits zu setzen. Ich kenne Leute, die machen Tabs nur auf und nie zu(Überspitzt ausgedrückt).
Siehe auch:
https://support.mozilla.org/en-US/kb/fi ... memory-ram
Code: Alles auswählen
8918 xxxxxxxx 20 0 0,243t 827756 71440 S 3,6 0,3 31:20.67 firefox
13131 xxxxxxxx 20 0 56,223g 426260 73100 S 0,3 0,2 6:40.91 firefox
Vielleicht hilft es da doch mal ein paar Limits zu setzen. Ich kenne Leute, die machen Tabs nur auf und nie zu(Überspitzt ausgedrückt).
Siehe auch:
https://support.mozilla.org/en-US/kb/fi ... memory-ram
Jede Rohheit hat ihren Ursprung in einer Schwäche.
Re: Problem mit glusterFS - fork: Nicht genügend Hauptspeicher verfügbar
Asche auf unsere Häupter,
das mit dem virtuellen Speicher haben wir total übersehen.
Tatsächlich gibt es auf jedem Server einen oder mehrere solcher Kandidaten.
Wir haben diese User erst mal unsanft entfernt und haben bisher zumindest
subjektiv den Eindruck dass eine Besserung eingetreten ist.
Danke für Deine Aufmerksamkeit @heisenberg
Wir haben jetzt in /etc/security/limits.d eine Datei user.conf angelegt und den Wert
für den Virtuellen Speicher auf 20 GB begrenzt.
Da die Fehlermeldungen nicht regelmäßig auftreten werden wir das jetzt mal beobachten.
Was die User mit den vielen offenen Tabs angeht hast Du absolut recht.
Daher haben wir auch einen Tab-Limiter im Einsatz und lassen "nur" 10 Tabs zu.
Allerdings gibt es auch Seiten bei denen braucht es nur einen Tab und sie
greifen sich 14GB wenn es nicht limitiert wird.
Auf diesem Firefox war nur Sputnik Nachrichten offen.
https://de.sputniknews.com/
Allerdings hat er sich nach einer Limitierung auf 10 GB mit 8 GB zufrieden gegeben.
Daher war Dein Rat zu limitieren ganz richtig.
Genaueres können wir erst morgen berichten, wenn alle Sessions neu sind.
Gruß
Andreas
das mit dem virtuellen Speicher haben wir total übersehen.
Tatsächlich gibt es auf jedem Server einen oder mehrere solcher Kandidaten.
Wir haben diese User erst mal unsanft entfernt und haben bisher zumindest
subjektiv den Eindruck dass eine Besserung eingetreten ist.
Danke für Deine Aufmerksamkeit @heisenberg
Wir haben jetzt in /etc/security/limits.d eine Datei user.conf angelegt und den Wert
für den Virtuellen Speicher auf 20 GB begrenzt.
Code: Alles auswählen
root@poldx10:/etc/security/limits.d# cat user.conf
# /etc/security/limits.d/user.conf
#
# Beispiele
#########
#<domain> <type> <item> <value>
#* soft core 0
#root hard core 100000
#* hard rss 10000
#@student hard nproc 20
#@faculty soft nproc 20
#@faculty hard nproc 50
#ftp hard nproc 0
#ftp - chroot /ftp
#@student - maxlogins 4
#
# Eigene Parameter
###############
# Setzt das address space limit (as) auf ~ 20 GB
# legt damit die Obergrenze fuer den virtuellen Speicherverbrauch fest (siehe top -> VIRT)
#<domain> <type> <item> <value>
@domänen-benutzer hard as 20000000
# End of file
Was die User mit den vielen offenen Tabs angeht hast Du absolut recht.
Daher haben wir auch einen Tab-Limiter im Einsatz und lassen "nur" 10 Tabs zu.
Allerdings gibt es auch Seiten bei denen braucht es nur einen Tab und sie
greifen sich 14GB wenn es nicht limitiert wird.
Auf diesem Firefox war nur Sputnik Nachrichten offen.
https://de.sputniknews.com/
Code: Alles auswählen
Tasks: 632 total, 1 running, 631 sleeping, 0 stopped, 0 zombie
%Cpu(s): 3,0 us, 0,9 sy, 0,0 ni, 95,7 id, 0,2 wa, 0,0 hi, 0,1 si, 0,0 st
KiB Mem: 74378112 total, 11208548 used, 63169564 free, 140288 buffers
KiB Swap: 9764860 total, 0 used, 9764860 free. 2789500 cached Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
26730 xxxxxxxx 20 0 14,017g 450184 72848 S 3,6 0,6 5:08.21 firefox
25912 xxxxxxxx 20 0 39944 4132 3440 S 0,0 0,0 0:00.01 systemd
25913 xxxxxxxx 20 0 228364 2500 0 S 0,0 0,0 0:00.00 (sd-pam)
25916 xxxxxxxx 20 0 105856 4228 3228 S 0,0 0,0 0:00.00 sshd
25917 xxxxxxxx 20 0 14028 3832 2832 S 0,0 0,0 0:00.02 nxnode
26324 xxxxxxxx 20 0 14028 2188 1164 S 0,0 0,0 0:00.00 nxnode
26326 xxxxxxxx 20 0 14168 3956 2776 S 0,0 0,0 0:00.03 nxnode
26683 xxxxxxxx 20 0 14216 2368 1160 S 0,0 0,0 0:00.00 nxnode
26686 xxxxxxxx 20 0 14224 2776 1536 S 0,0 0,0 0:00.00 nxnode
26688 xxxxxxxx 20 0 6184 1728 1632 S 0,0 0,0 0:00.00 tee
26689 xxxxxxxx 20 0 14236 2780 1536 S 0,0 0,0 0:00.01 nxnode
26693 xxxxxxxx 20 0 189556 124500 8140 S 0,0 0,2 2:49.55 nxagent
26801 xxxxxxxx 20 0 30688 1992 1680 S 0,0 0,0 0:00.00 dbus-launch
26802 xxxxxxxx 20 0 46276 2404 2000 S 0,0 0,0 0:00.00 dbus-daemon
26806 xxxxxxxx 20 0 56252 5396 4904 S 0,0 0,0 0:00.01 gconfd-2
Daher war Dein Rat zu limitieren ganz richtig.
Genaueres können wir erst morgen berichten, wenn alle Sessions neu sind.
Gruß
Andreas
- heisenberg
- Beiträge: 3559
- Registriert: 04.06.2015 01:17:27
- Lizenz eigener Beiträge: MIT Lizenz
Re: Problem mit glusterFS - fork: Nicht genügend Hauptspeicher verfügbar
Super. Bleibt zu hoffen, dass es das war.
Nochmal der Hinweis auf das Monitoring. Im Standardregelsatz von Check_MK ist dann auch eine Einstellung drin, die gleich eine dauerhafte Warnung produziert hätte, die man nicht so einfach übersieht wie ein kleines "g" oder "t" im top.
Nochmal der Hinweis auf das Monitoring. Im Standardregelsatz von Check_MK ist dann auch eine Einstellung drin, die gleich eine dauerhafte Warnung produziert hätte, die man nicht so einfach übersieht wie ein kleines "g" oder "t" im top.
Jede Rohheit hat ihren Ursprung in einer Schwäche.
Re: Problem mit glusterFS - fork: Nicht genügend Hauptspeicher verfügbar
Es scheint so.
Bisher läuft alles stabil.
Die Limitierung hat geholfen.
Wir denken, dass der Firefox irgend ein Problem bekommt, wenn er eine solche Menge RAM sieht.
Seit wir auf 20 GB limitiert haben gehören die Fehlermeldungen und nicht erreichbare Server
jedenfalls der Vergangenheit an.
Das Monitoring werden wir uns auf jeden Fall genauer ansehen.
Vielen Dank nochmal heisenberg!!
Ein schönes Wochenende und einen schönen 2. Advent!
Gruß
Andreas
Bisher läuft alles stabil.
Die Limitierung hat geholfen.
Wir denken, dass der Firefox irgend ein Problem bekommt, wenn er eine solche Menge RAM sieht.
Seit wir auf 20 GB limitiert haben gehören die Fehlermeldungen und nicht erreichbare Server
jedenfalls der Vergangenheit an.
Das Monitoring werden wir uns auf jeden Fall genauer ansehen.
Vielen Dank nochmal heisenberg!!
Ein schönes Wochenende und einen schönen 2. Advent!
Gruß
Andreas
- heisenberg
- Beiträge: 3559
- Registriert: 04.06.2015 01:17:27
- Lizenz eigener Beiträge: MIT Lizenz
Re: Problem mit glusterFS - fork: Nicht genügend Hauptspeicher verfügbar
Sieht aber auch so aus, als ob man da möglicherweise irgendwann mal gegen das Limit rennen könnte. (Auch wieder ein Fall für das Monitoring)abrodeck hat geschrieben:07.12.2017 09:20:10lsof | wc -l:
zwischen 2.628.503 und 11.524.247
cat /proc/sys/fs/file-max:
auf allen Servern: 26.450.162
Jede Rohheit hat ihren Ursprung in einer Schwäche.
Re: [gelöst] Problem mit glusterFS - fork: Nicht genügend Hauptspeicher verfügbar
Wir werden diese Werte im Auge behalten und bei Bedarf anpassen.
Monitoring wird wie gesagt in allernächster Zeit Thema sein.
Gruß
Andreas
Monitoring wird wie gesagt in allernächster Zeit Thema sein.
Gruß
Andreas