GELÖST: "Arbeitsspeicher" wird immer geringer

Moinsens,

ich benutze Nextcloud auf meinen Linux-Server (Debian 8). Nextcloud ist die ausschließlich gefahrene Anwendung auf dem Server. Läuft über Apache2. Der Server hat 8 GB Arbeitsspeicher.

Ich muss allerdings feststellen, dass der Arbeitsspeicher mit der Zeit immer geringer wird. Nach einem Neustart sind 668 MB genutzt, nach einigen Tagen sind bereits 2.1 GB genutzt, Tendenz weiter steigend, bis der Server letztlich nicht mehr erreichbar ist, ausser über SSH.

Hat jemand schon ähnliches festgestellt?

Nextcloud-Version 12.0.4

Vielen Dank.

Grüsskens Thomas_H

Nein, sowas bis jetzt nicht. Ich benutze ein Raspberry Pi 3 und dieser hat nur 1 Gigabyte. Dazu habe ich 100 Mb Swapspeicher. Aber selbst bei 2.1 GB sollte der Server dennoch erreibar sein. Was hast du denn noch für Applicationen am laufen?

LG

Hallo,

Es läuft noch Plesk (ich bin ein wenig faul :blush: ) aber sonst laufen dort keine weiteren Applikationen. Diesen Server habe ich ausschließlich Nextcloud zur Verfügung gestellt.
Dennoch vorsichtshalber mal ein ps -e:

root@ms556:~# ps -e
  PID TTY          TIME CMD
    1 ?        00:01:27 systemd
    2 ?        00:00:00 kthreadd
    3 ?        00:01:06 ksoftirqd/0
    5 ?        00:00:00 kworker/0:0H
    7 ?        00:09:10 rcu_sched
    8 ?        00:00:00 rcu_bh
    9 ?        00:00:01 migration/0
   10 ?        00:00:02 watchdog/0
   11 ?        00:00:01 watchdog/1
   12 ?        00:00:01 migration/1
   13 ?        00:00:50 ksoftirqd/1
   15 ?        00:00:00 kworker/1:0H
   16 ?        00:00:02 watchdog/2
   17 ?        00:00:02 migration/2
   18 ?        00:00:45 ksoftirqd/2
   20 ?        00:00:00 kworker/2:0H
   21 ?        00:00:01 watchdog/3
   22 ?        00:00:01 migration/3
   23 ?        00:00:49 ksoftirqd/3
   25 ?        00:00:00 kworker/3:0H
   26 ?        00:00:00 khelper
   27 ?        00:00:00 kdevtmpfs
   28 ?        00:00:00 netns
   29 ?        00:00:00 khungtaskd
   30 ?        00:00:00 writeback
   31 ?        00:00:00 ksmd
   32 ?        00:00:03 khugepaged
   33 ?        00:00:00 crypto
   34 ?        00:00:00 kintegrityd
   35 ?        00:00:00 bioset
   36 ?        00:00:00 kblockd
   41 ?        00:00:00 kswapd0
   42 ?        00:00:00 vmstat
   43 ?        00:00:00 fsnotify_mark
   49 ?        00:00:00 kthrotld
   50 ?        00:00:00 ipv6_addrconf
   51 ?        00:00:00 deferwq
   91 ?        00:00:00 khubd
   92 ?        00:00:00 ata_sff
   93 ?        00:00:00 scsi_eh_0
   94 ?        00:00:00 scsi_tmf_0
  100 ?        00:00:04 kworker/1:1H
  101 ?        00:00:04 kworker/2:1H
  102 ?        00:00:04 kworker/3:1H
  103 ?        00:00:00 kworker/0:1H
  123 ?        00:00:16 jbd2/sda4-8
  124 ?        00:00:00 ext4-rsv-conver
  159 ?        00:00:00 kauditd
  169 ?        00:00:14 systemd-udevd
  186 ?        00:00:53 systemd-journal
  196 ?        00:00:00 edac-poller
  206 ?        00:00:00 ttm_swap
  236 ?        00:00:00 kvm-irqfd-clean
  247 ?        00:00:00 jbd2/sda3-8
  248 ?        00:00:00 ext4-rsv-conver
  261 ?        00:00:00 radeon-crtc
  262 ?        00:00:00 radeon-crtc
  263 ?        00:00:01 kipmi0
  368 ?        00:00:01 kworker/1:1
  389 ?        00:00:00 iscsi_eh
  391 ?        00:00:00 ib_addr
  392 ?        00:00:00 ib_mcast
  393 ?        00:00:00 ib_cm
  394 ?        00:00:00 iw_cm_wq
  395 ?        00:00:00 rdma_cm
  397 ?        00:00:09 iscsid
  398 ?        00:00:41 iscsid
  402 ?        00:00:00 scsi_eh_1
  403 ?        00:00:00 scsi_tmf_1
  404 ?        00:00:00 iscsi_q_1
  405 ?        00:00:00 scsi_wq_1
  415 ?        00:00:08 psa-pc-remote
  416 ?        00:00:00 named
  417 ?        00:00:03 sw-engine-fpm
  421 ?        00:00:12 memcached
  429 ?        00:00:00 cron
  442 ?        00:00:05 systemd-logind
  453 ?        00:00:12 dbus-daemon
  480 ?        00:00:15 rsyslogd
  484 ?        00:00:00 acpid
  491 ?        00:14:35 dockerd
  502 ?        00:00:08 sshd
  526 tty1     00:00:00 agetty
  529 ?        00:00:00 dovecot
  534 ?        00:00:05 jbd2/sdb1-8
  535 ?        00:00:00 xinetd
  536 ?        00:00:00 ext4-rsv-conver
  537 ?        00:00:00 anvil
  538 ?        00:00:00 log
  654 ?        00:00:00 mysqld_safe
  878 ?        00:00:00 fail2ban-server
  934 ?        00:05:25 mysqld
  935 ?        00:00:00 logger
  964 ?        00:06:27 docker-containe
  966 ?        00:00:00 kworker/3:2
 1050 ?        00:00:00 sw-engine-kv
 1516 ?        00:00:52 master
 1519 ?        00:00:35 qmgr
 1652 ?        00:05:26 redis-server
 1656 ?        00:00:14 php5-fpm
 1662 ?        00:00:00 nginx
 1663 ?        00:00:15 nginx
 1664 ?        00:00:00 php5-fpm
 1665 ?        00:00:00 php5-fpm
 1673 ?        00:00:12 apache2
 1810 ?        00:00:00 kworker/0:2
 1817 ?        00:00:00 kworker/2:2
 1826 ?        00:00:00 kworker/3:1
 2217 ?        00:00:00 kworker/1:0
 2487 ?        00:00:00 kworker/2:1
 2511 ?        00:00:00 kworker/0:0
 2633 ?        00:00:00 kworker/3:0
 2910 ?        00:00:01 kworker/u8:2
 2921 ?        00:00:00 kworker/1:2
 3074 ?        00:00:00 sshd
 3078 ?        00:00:00 systemd
 3079 ?        00:00:00 (sd-pam)
 3081 pts/0    00:00:00 bash
 3101 ?        00:00:00 php-fpm
 3103 ?        00:00:00 sshd
 3104 ?        00:00:00 sshd
 3105 pts/0    00:00:00 ps
 5514 ?        00:00:00 tlsmgr
 8437 ?        00:00:00 sw-cp-serverd
 8438 ?        00:00:00 sw-cp-serverd
 9652 ?        00:00:04 kworker/u8:3
10652 ?        00:00:00 apache2
10653 ?        00:00:00 apache2
10654 ?        00:00:00 apache2
10655 ?        00:00:00 apache2
10656 ?        00:00:00 apache2
10657 ?        00:00:00 apache2
13435 ?        00:00:18 systemd
13436 ?        00:00:00 (sd-pam)
13618 ?        00:00:00 config
13620 ?        00:00:00 ssl-params
18987 ?        00:00:00 apache2
23806 ?        00:00:08 php-fpm
26720 ?        00:00:00 pickup
29323 ?        00:00:01 kworker/0:1
31866 ?        00:00:00 kworker/u8:1
32008 ?        00:00:12 kworker/2:0

Zur Sicherheit hier auch noch der Speicher:
root@ms556:~# free -lh
total used free shared buffers cached
Mem: 7.2G 2.8G 4.4G 148M 459M 1.7G
Low: 7.2G 2.8G 4.4G
High: 0B 0B 0B
-/+ buffers/cache: 660M 6.6G
Swap: 7.6G 0B 7.6G

und die Diskspeicherbelegung:

root@ms556:~# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda4        21G  5.2G   16G  25% /
udev             10M     0   10M   0% /dev
tmpfs           1.5G   81M  1.4G   6% /run
tmpfs           3.7G     0  3.7G   0% /dev/shm
tmpfs           5.0M   20K  5.0M   1% /run/lock
tmpfs           3.7G     0  3.7G   0% /sys/fs/cgroup
/dev/sda3       946M   53M  829M   6% /boot
/dev/sdb1       985G  168G  767G  18% /storage
tmpfs           739M     0  739M   0% /run/user/10000
tmpfs           739M     0  739M   0% /run/user/0

Irgendeine Idee? Oder kann ich hier definitiv ausschließen, dass es an NextCloud liegt?

Grüsskens,

Thomas_H

kannst du irgendwie schauen welches prozess wie viel belegt, ähnlich wie der taskmanager in windows?

Unter Linux funktioniert das mit TOP. Besser und grafisch ansehnlicher finde ich noch htop. Dort sieht man direkt welcher Prozess, was “zieht”. :wink:

Bei mir siehts so aus:
@raspberrypi:~ $ free -lh
total used free shared buff/cache available
Mem: 976M 387M 45M 38M 543M 491M
Low: 976M 931M 45M
High: 0B 0B 0B
Swap: 99M 78M 21M

Ich bin also relativ am Limit :smiley: Jedoch muss ich noch sagen, dass ich noch pihole benutze als zusätzlichen DNS Server im Heimnetz und noch eine fhem Instanz. Das gelbe vom Ei ist es natürlich nicht und die Webseiten sind natürlich auch nicht das schnellste, aber das wesentliche, die Synchronisation über Webdav funktioniert bei mir sehr flott :slight_smile:.

Ich glaube es liegt dabei echt an Plesk, weil Plesk die ganzen Systeme, soweit ich weiß, auch noch überwacht und dabei mitloggt. :wink:
Was ich mir noch vorstellen kann, ist ein fehlendes Logrotate :wink:

und im top steht`bei dir wohl der webserver ganz weit oben?

ich hab ja deine top ausgabe noch nie gesehen, aber logrotate lönnte vlt helfen.

falls es dich interessiert :wink:

Ich sollte aber in Fhem auch die Logs nach MySQL umziehen :smiley: würd meinen Pi auch um einiges Performanter machen. Habe den eh letzten Monat neu aufgesetzt, und ich kam auch noch nicht dazu einen Cache zu installieren. Sprich APCu und Redis :wink:

ach mysql, je nachdem wie viel der macht kann man iirc auch dem ein bisschen den cache abdrehen.

warum der mysqld aber 5 mal dasteht wundert mich eher.

vielleicht könnte @Thomas_H auch mal einen htop zeigen, damit kann sowas gut sichtbar werden was hier grad am meisten will.

@My1 MySQL hat ein anderes thread-Modell als Apache.
Hier ist die Anzahl nicht wirklich zu regulieren.

Quelle Google :smiley:

Ich habe bei mir mal in phpmyadmin nachgeschaut:

Threads cachedDokumentation 6 Anzahl der Prozesse im Prozess-Zwischenspeicher. Die Zwischenspeicher-Zugriffsrate kann mit Threads_created/Connections berechnet werden. Wenn dieser Wert rot ist, sollte der thread_cache_size erhöht werden.
Threads connectedDokumentation 2 Anzahl der momentan offenen Verbindungen.
Threads createdDokumentation 27 Anzahl der Prozesse, die zur Handhabung von Verbindungen erzeugt wurden. Wenn Threads_created hoch ist, sollten Sie eventuell die Thread_cache_size-Variable herauf setzen. (Normalerweise ergibt sich daraus keine bemerkbare Performance-Steigerung wenn eine gute Prozess-Implementierung vorliegt.)
Threads runningDokumentation 1 Anzahl der Prozesse, die nicht schlafen.

Sieht doch ganz normal aus :slight_smile: oder etwa nicht? :smiley:

Edit: Ich habs nochmal als Grafik gemacht :smiley:

okay, gut in windows mit xampp wars iirc immer ein prozess.

Windows ist so offen, wie ein altes Bunkerfenster :wink: Also nie ganz dicht :smiley:

Was ich damit meine: Ein Bekannter hat es mir damals so erklärt: In Linux muss man für jedes System es erstmal für das System öffnen und konfigurieren. In Windows ist schon alles offen und man muss es dicht machen, damit der Server sicher wird :wink:

So, ich habe mal htop installiert und einen Screenshot gemacht. Aber es gibt mE. nicht so wirklich her, wo der Speicher bleibt.

Und es reduziert sich weiter:

root@ms556:~# free -m
         total       used       free     shared    buffers     cached
Mem:          7387       3183       4203        205        489       1961
-/+ buffers/cache:        732       6654
Swap:         7812          0       7812

Also an Plesk kann es IMHO nicht liegen. Ich hab’s auch auf anderen Servern drauf und die laufen wochenlang ohne Probleme.

was für eine reine Dev-Maschine auch nicht all zu doof ist, wenn man einfach rein schauen kann.

als server würde ich windows nicht unbedingt nutzen.

hm… ich sehe auch nur dass n ganzer stapel mysql prozesse ihren spaß haben, kann man das ding eigentlich mal von sortieren nach CPU auf sortieren nach RAM stellen?

Unten ist das Menu :smiley: Einfach F6 drücken und das Sortierte auswählen :wink:

Sieht für mich eher normal aus.

Ja, aber wie gesagt, der Speicher wird von Tag zu Tag kontinuierlich weniger, bis irgendwann ein Neustart erforderlich ist.

Ich gehe nun einfach mal davon aus, dass bisher keiner dieses Problem hatte und es daher eigentlich nicht an Nextcloud liegen kann.

Dann sortier htop nach Memory und mach mal ein Screenshot bevor du den neustartest :wink: Dann sollte man ja sehen, welches Programm, was zieht :blush:

genau das war im prinzip das was ich meinte als Thomas seinen shot postete und ich fragte ob man das sortieren kann.

So… gelöst. Hat ein Weilchen gedauert und auf die Lösung stieß ich auch nur zufällig. Aber ich will die Lösung hier nicht vorenthalten.

Symptom:

Der Arbeitsspeicher des Nextcloud-Servers verringert sich, solange bis der Service von Nextcloud gänzlich oder weitestgehend eingestellt wird. Eine Synchronisation mit den Clients ist nicht mehr möglich, ein Einloggen per SSH auf den Server nur noch mit zeitlich großem Aufwand und Geduld möglich.

Ursache:
Bei einem nornal eingerichteten Linux-System wird der Cache-Speicher vom System verwaltet und bestimmt. Auch noch ungeklärter Ursache wurde dieser Cache-Speicher jedoch nicht oder nicht vollständig wieder freigegeben.

Lösung:
Eine auf der Konsole eingegebene Befehlsfolge leerte den Cache und gab wieder Speicher frei:

free && sync && echo 3 > /proc/sys/vm/drop_caches && free

Das setzte ich nun zusammen mit einem Script, welches ich ebenfalls im Netz fand:

#!/bin/bash
#######################################################################################
#Script Name    :alertmemory.sh
#Description    :send alert mail when server memory is running low
#Args           :
#Author         :Aaron Kili Kisinga
#Email          :aaronkilik@gmail.com
#License       : GNU GPL-3
#######################################################################################
## get total free memory size in megabytes(MB)
free=$(free -mt | grep Total | awk '{print $4}')
## check if free memory is less or equals to  1000MB
echo $free
if [[ "$free" -le 1000  ]]; then
    sync && echo 3 > /proc/sys/vm/drop_caches
fi
exit 0

Rutscht der freie Arbeitsspeicher nun unter 1 GB (-le 1000) wird der Befehl

sync && echo 3 > /proc/sys/vm/drop_caches

ausgeführt und der Arbeitsspeicher freigegeben.

Es gibt auch die Möglichkeit, den Cache-Speicher generell zu begrenzen. Das halte ich aber für mich persönlich, angesichts meiner nicht ausreichenden Kenntnisse über das “Wie” und die möglichen Folgen für keine gute Idee.

Gruß Thomas_H