[gelöst] Problem mit glusterFS - fork: Nicht genügend Hauptspeicher verfügbar

Probleme mit Samba, NFS, FTP und Co.
abrodeck
Beiträge: 16
Registriert: 23.11.2013 13:35:06

[gelöst] Problem mit glusterFS - fork: Nicht genügend Hauptspeicher verfügbar

Beitrag von abrodeck » 05.12.2017 15:03:24

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:
Bild

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.

Benutzeravatar
heisenberg
Beiträge: 1113
Registriert: 04.06.2015 01:17:27

Re: Problem mit glusterFS - fork: Nicht genügend Hauptspeicher verfügbar

Beitrag von heisenberg » 05.12.2017 16:38:11

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:

Code: Alles auswählen

export LC_ALL=C
... irgend ein Befehl ...
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.

abrodeck
Beiträge: 16
Registriert: 23.11.2013 13:35:06

Re: Problem mit glusterFS - fork: Nicht genügend Hauptspeicher verfügbar

Beitrag von abrodeck » 06.12.2017 08:10:35

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:

NoPaste-Eintrag40080

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:~#
Gruß
Andreas

Benutzeravatar
heisenberg
Beiträge: 1113
Registriert: 04.06.2015 01:17:27

Re: Problem mit glusterFS - fork: Nicht genügend Hauptspeicher verfügbar

Beitrag von heisenberg » 06.12.2017 12:52:34

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.

abrodeck
Beiträge: 16
Registriert: 23.11.2013 13:35:06

Re: Problem mit glusterFS - fork: Nicht genügend Hauptspeicher verfügbar

Beitrag von abrodeck » 06.12.2017 15:16:07

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)

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
Am kern.log sind wir noch dran.

Gruß
Andreas


abrodeck
Beiträge: 16
Registriert: 23.11.2013 13:35:06

Re: Problem mit glusterFS - fork: Nicht genügend Hauptspeicher verfügbar

Beitrag von abrodeck » 07.12.2017 09:20:10

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

MSfree
Beiträge: 2728
Registriert: 25.09.2007 19:59:30

Re: Problem mit glusterFS - fork: Nicht genügend Hauptspeicher verfügbar

Beitrag von MSfree » 07.12.2017 09:45:13

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)?

abrodeck
Beiträge: 16
Registriert: 23.11.2013 13:35:06

Re: Problem mit glusterFS - fork: Nicht genügend Hauptspeicher verfügbar

Beitrag von abrodeck » 07.12.2017 10:32:04

Hallo MSfree,

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
Gruß
Andreas

Benutzeravatar
heisenberg
Beiträge: 1113
Registriert: 04.06.2015 01:17:27

Re: Problem mit glusterFS - fork: Nicht genügend Hauptspeicher verfügbar

Beitrag von heisenberg » 07.12.2017 10:36:20

ulimit-Probleme halte ich für unwahrscheinlich. Wie man oben(erster Beitrag, Screenshot) sieht, tritt die Problematik auch als root auf.

Benutzeravatar
heisenberg
Beiträge: 1113
Registriert: 04.06.2015 01:17:27

Re: Problem mit glusterFS - fork: Nicht genügend Hauptspeicher verfügbar

Beitrag von heisenberg » 07.12.2017 10:44:33

Ich habe mir den top von oben nochmal angeschaut:

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
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

abrodeck
Beiträge: 16
Registriert: 23.11.2013 13:35:06

Re: Problem mit glusterFS - fork: Nicht genügend Hauptspeicher verfügbar

Beitrag von abrodeck » 07.12.2017 14:54:02

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 :THX:

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
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/

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
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

Benutzeravatar
heisenberg
Beiträge: 1113
Registriert: 04.06.2015 01:17:27

Re: Problem mit glusterFS - fork: Nicht genügend Hauptspeicher verfügbar

Beitrag von heisenberg » 07.12.2017 15:25:14

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.

abrodeck
Beiträge: 16
Registriert: 23.11.2013 13:35:06

Re: Problem mit glusterFS - fork: Nicht genügend Hauptspeicher verfügbar

Beitrag von abrodeck » 08.12.2017 13:59:16

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

Benutzeravatar
heisenberg
Beiträge: 1113
Registriert: 04.06.2015 01:17:27

Re: Problem mit glusterFS - fork: Nicht genügend Hauptspeicher verfügbar

Beitrag von heisenberg » 08.12.2017 14:30:41

abrodeck hat geschrieben: ↑ zum Beitrag ↑
07.12.2017 09:20:10
lsof | wc -l:

zwischen 2.628.503 und 11.524.247

cat /proc/sys/fs/file-max:

auf allen Servern: 26.450.162
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)

Antworten