[SWAP plein] : remplissage progressif et inexpliqué du swap

Support
1

Matériel: Odroid N2+.
Version de YunoHost: 4.2.7 (stable)
J’ai accès à mon serveur : SSH
Êtes-vous dans un contexte particulier ou avez-vous effectué des modifications particulières sur votre instance ? : non

Bonjour,

Depuis une semaine, j’ai constaté (via le paquet netdata) :
a) qu’après un reboot le swap mettait une journée à se remplir
b) puis après quelques heures que le serveur était injoignable (serveur timeout);
c) que je devais débrancher et rebrancher le serveur pour y avoir de nouveau accès

  1. Mon installation est la suivante :
  • Odroid N2+ avec 4GB de ram ;
  • OS: armbian (avec zram comme swap) avec en surcouche yunohost ;
  • comme paquets majeurs d’installés via yunohost : nextcloud, navidrome, calibre web, jellifyn, netdata…

  1. Je n’ai plus que grav et nextcloud comme appli installé (j’ai desinstallé les autres applis une à une pour essayer de trouver l’origine)
    => Mais la swap se remplit toujours.

  2. si dessous le résultat de la commande top triée par SWAP

MiB Mem :   3696.9 total,    130.1 free,   1699.2 used,   1867.6 buff/cache
MiB Swap:   1848.5 total,   1539.0 free,    309.5 used.   1682.1 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                  SWAP
 7990 root      20   0  253364 104776  19608 S   0.0   2.8   0:24.29 python3                 66236
 2611 mysql     20   0 2873736 159248   9428 S   0.0   4.2   1:03.28 mysqld                  50308
 2469 root      39  19  144828  10588  10588 S   0.0   0.3   0:00.65 mono                    23900
 2479 rabbitmq  20   0 4267756  64392   5532 S   0.0   1.7   0:19.82 beam.smp                21584
 5519 root      20   0  102332  60348  10504 S   0.3   1.6   0:11.86 python3                 20456
 2966 _rspamd   20   0  120176  38384  11168 S   0.0   1.0   0:01.09 rspamd                  14928
 4042 _rspamd   20   0  120176  30604   3416 S   0.0   0.8   0:01.26 rspamd                  14528
 4043 _rspamd   20   0  121448  33852   6496 S   0.0   0.9   0:00.73 rspamd                  14436
 4044 _rspamd   20   0  120668  38732   8228 S   0.0   1.0   0:01.13 rspamd                  14160
 4048 _rspamd   20   0  120668  38652   7580 S   0.0   1.0   0:01.04 rspamd                  13576
 4047 _rspamd   20   0  120668  39668   8624 S   0.0   1.0   0:03.87 rspamd                  13512
 4046 _rspamd   20   0  120668  40736   8236 S   0.0   1.1   0:02.22 rspamd                  13384
 2304 www-data  20   0  280424  23516  11816 S   0.0   0.6   0:01.50 mono                    12516
 3234 openldap  20   0  481556  24716   3224 S   0.0   0.7   0:06.77 slapd                   12480
 2943 root      39  19 3063512 148328  16524 S 448.5   3.9 105:03.13 mono-sgen               11192
 7085 root       9 -11   95000   9516   5288 S   0.0   0.3   0:00.83 pulseaudio               9336
 3794 root      20   0  170656   5400    912 S   0.0   0.1   0:00.01 nginx                    7008
 5062 root      20   0  711060   1876   1776 S   0.0   0.0   0:00.07 observer                 6516

D’avance merci beaucoup

2

Est-ce que tu peux élaborer sur comment tu vois que le swap est plein ? Il y a une confusion classique qui consiste à regarder la colonne “free” plutôt que “available”

3

Bonjour Aleks,

alors de deux façons :

  • dans un premier temps quand j’avais encore l’app net data installé via netdata ;
  • maintenant en regardant la colonne used de la sortie de la commande free -h

=> la swap augmente très régulièrement (100 Mo toutes les demi-heure environ)

4

Bonjour @tous
@Maknho tu peux lancer cette commande pour voir les processus qui utilisent le swap :
for file in /proc/*/status ; do awk ‘/VmSwap|Name/{printf $2 " " $3}END{ print “”}’ $file; done | sort -k 2 -n -r | less

5

Bonjour mib,
merci de ta réponse :
en sortie de cette commande il m’est indiqué

zsh: aucun fichier ou dossier de ce type: Name/{printf

EDIT : la commande free -h m’indique après une nuit de “up” :

> # free -h                                                                               [11:49:14]
>               total        used        free      shared  buff/cache   available
> Mem:          3.6Gi       1.5Gi       268Mi        33Mi       1.8Gi       2.0Gi
> Swap:         1.8Gi       1.5Gi       318Mi
6

Je pense que c’est du à l’encodage du texte qui n’est pas respecté avec mon copié/collé, désolé

for file in /proc/*/status ; do awk '/VmSwap|Name/{printf $2 " " $3}END{ print ""}' $file; done | sort -k 2 -n -r | less
7

mysqld 238292 kB
python3 119888 kB
php7.3 114596 kB
mono-sgen 103256 kB
python3 46712 kB
beam.smp 44812 kB
node 43172 kB
rspamd 42116 kB
rspamd 38844 kB
rspamd 38116 kB
rspamd 38024 kB
rspamd 38012 kB
php-fpm7.3 37924 kB
php-fpm7.3 37688 kB
php-fpm7.3 37648 kB
rspamd 37320 kB
rspamd 37304 kB
php-fpm7.3 35992 kB
yunohost-api 35900 kB
poezio 33084 kB
slapd 32924 kB
dockerd 26916 kB
mono 24172 kB
mono 23900 kB

8

Maintenant tu connais les processus qui consomment du swap, je ne pourrais pas t’en dire plus sur cette consommation :roll_eyes:

9

Merci beaucoup néanmoins mib,

mon serveur est inaccessible encore…dans l’attente de comprendre ce qui se passe…je fais ce qu’Aleks dit être une manip pas top :slight_smile: ; je débranche et je rebranche

EDIT : bon mais le problème vient de mysql apparemment
EDIT 2 : y aurait-il une solution ici (The MySQL “swap insanity” problem and the effects of the NUMA architecture – Jeremy Cole ) ?

10

Après des désinstallations et réinstallations cela parait venir de nextcloud. Embêtant dans la mesure où je ne souhaites pas le désinstaller.

11

@Maknho : ton problème ressemble un peu à ça : Out of memory lors d'une mise à jour, et serveur ralenti/peu stable depuis - #4 by tomdereub.

12

Hello tomdereub,

Merci beaucoup pour l’info. Oui ça ressemble bien à ça mon problème.

j’ai fait donc :

sudo nano /etc/php/7.3/cli/conf.d/20-apcu.ini

Et ajouter la ligne suivante
apc.enable_cli=1

Puis enregistrer le fichier

Redémarrer php
yunohost service restart php7.3-fpm

mais après une “fresh install” de nextcloud (donc après la maj). J’espère que ça fonctionnera quand même…

EDIT : j’ai ajouté aussi la ligne apc.enable_cli=1 à php.ini (21.0.3 OC\HintException: Memcache \OC\Memcache\APCu not available · Issue #27781 · nextcloud/server · GitHub) mais la swap se remplit tjs :frowning:

13

Bonjour,
J’ai également un problème de swap depuis début août (sur un Raspberry Pi 3B+), que je pense lié à Nextcloud.

Les manips que tu décris ci-dessus ont-elles finalement réglé ton problème @Maknho ?

14

Hello @aoz ,

non malheureusement ça n’a pas réglé mon problème de “fuite mémoire”.

Pour l’instant j’ai désinstallé nedxtcloud.

Si tu trouves le “truc” n’hésites pas à le mettre sur ce fil, je ferai de même…

15

Pour l’instant j’ai testé la manip que tu décris. J’observe et je ferai un retour.

16

Hello @aoz ,

la “manip” a-t-elle finalement fonctionné de ton côté ?

17

Pardon, désolé pour mon silence, je n’étais plus sur le forum.

De mon côté, plus de problème de fuite mémoire. Par contre, Nextcloud met régulièrement mon RPi à genou : process mysql & php qui bouffent du CPU et sollicitent le disque externe durant de nombreuses minutes…

18

Salut aoz,

merci de ta réponse.

Pour que tu n’ais plus de “fuite mémoire” as-tu fait ceci :

j’ai fait donc :

sudo nano /etc/php/7.3/cli/conf.d/20-apcu.ini

Et ajouter la ligne suivante
apc.enable_cli=1

Puis enregistrer le fichier

Redémarrer php
yunohost service restart php7.3-fpm

mais après une “fresh install” de nextcloud (donc après la maj). J’espère que ça fonctionnera quand même…

EDIT : j’ai ajouté aussi la ligne apc.enable_cli=1 à php.ini (21.0.3 OC\HintException: Memcache \OC\Memcache\APCu not available · Issue #27781 · nextcloud/server · GitHub)

Ou alors une mise à jour seulement ?

Si ça marche de ton côté (hormis le fait Nextcloud sollicite apparemment “trop” ton RPi), je vais tenter une réinstall et refaire les manips décrites plus haut.

19

Salut,
J’ai juste ajouté la ligne “apc.enable_cli=1” au fichier “20-apcu.ini” et redémarré php7.3-fpm
Et depuis il y a eu une mise à jour, mais cela tient toujours.

20

OK. Merci