Blocage brutal / arrêt serveur. Problème mémoire?

Support
1

Bonjour à tous.
J’ai un petit cailloux dans ma chaussure et je ne trouve pas de solution… Peut-être que mes compétences s’arrêtent où commencent les votres (J’espère en fait…)

Mon serveur YunoHost

Matériel: Cloud VPS chez onetsolution, 2Go de RAM, 120Go SSD, 2coeurs

{
    "host": "Debian 9.12",
    "kernel": "4.9.0-12-amd64",
    "packages": {
        "yunohost": {
            "repo": "stable",
            "version": "3.6.5.3"
        },
        "yunohost-admin": {
            "repo": "stable",
            "version": "3.6.5.1"
        },
        "moulinette": {
            "repo": "stable",
            "version": "3.6.4.1"
        },
        "ssowat": {
            "repo": "stable",
            "version": "3.6.4"
        }
    },
    "backports": [],
    "system": {
        "disks": {
            "dm-0": "Mounted on /, 95.7GiB (71.5GiB free)",
            "sda1": "Mounted on /boot, 235.3MiB (173.0MiB free)"
        },
        "memory": {
            "ram": "1.9GiB (1.2GiB free)",
            "swap": "2.0GiB (2.0GiB free)"
        }
    },
    "nginx": [
        "nginx: the configuration file /etc/nginx/nginx.conf syntax is ok",
        "nginx: configuration file /etc/nginx/nginx.conf test is successful"
    ],
    "services": {
        "glances": "running (enabled)",
        "nslcd": "running (enabled)",
        "postgresql": "exited (enabled)",
        "metronome": "running (enabled)",
        "postfix": "exited (enabled)",
        "rspamd": "running (enabled)",
        "yunohost-firewall": "exited (enabled)",
        "nginx": "running (enabled)",
        "php7.0-fpm": "running (enabled)",
        "dnsmasq": "running (enabled)",
        "fail2ban": "running (enabled)",
        "yunohost-api": "running (enabled)",
        "mysql": "running (enabled)",
        "avahi-daemon": "running (enabled)",
        "dovecot": "running (enabled)",
        "redis-server": "running (enabled)",
        "slapd": "running (enabled)",
        "ssh": "running (enabled)"
    },
    "applications": {
        "onlyoffice": "OnlyOffice",
        "ampache": "Ampache",
        "nextcloud": "Nextcloud"
    },
    "security": {
        "CVE-2017-5754": {
            "name": "meltdown",
            "vulnerable": false
        }
    }
}

J’ai accès à mon serveur : En SSH | Par la webadmin
Êtes-vous dans un contexte particulier ou avez-vous effectué des modificiations particulières sur votre instance ? : une seule :
La modif : pm.max_children = 8 dans le nextcloud.conf (au lieu de 4 par défaut)

Description du problème

J’ai installé sans difficulté Yunohost dont je me sert pour me dégoogliser depuis plusieurs mois. J’utilise nextcloud et ampache principalement. Aucune panne à signaler.
Depuis mi Janvier environ, le serveur virtuel s’arrête tous les 2 à 3 jours… sans prévenir.
Je relance la machine, tout repart nickel… puis arrêt à nouveau deux jours plus tards.

Je constate avec l’outil de monitoring de l’hébergeur que l’utilisation de la mémoire augmente constament puis se stabilise juste sous la limite du serveur (2Go). Pourquoi la mémoire augmente en permanence même sans utilisation (un cron à la con qui serait buggé?)? Est-ce que le problème vient de là : lorsque le serveur atteint la limite, il tue les process au hasard?
J’ai posé la question à l’hébergeur qui ne retrouve aucun trace de problème ou de stabilité de ses machines.

Voici ce que je constate :

Syslog :

Mar 20 20:09:01 rby CRON[22805]: (root) CMD (  [ -x /usr/lib/php/sessionclean ] && if [ ! -d /run/systemd/system ]; then /usr/lib/php/sessionclean; fi)
Mar 20 20:09:05 rby systemd[1]: Starting Clean php session files...
Mar 20 20:09:05 rby systemd[1]: Started Clean php session files.
Mar 21 08:42:17 rby systemd[1]: Starting Flush Journal to Persistent Storage...
Mar 21 08:42:18 rby fake-hwclock[470]: Current system time: 2020-03-21 07:42:09
Mar 21 08:42:18 rby fake-hwclock[470]: fake-hwclock saved clock information is in the past: 2020-03-20 18:17:02
Mar 21 08:42:18 rby fake-hwclock[470]: To set system time to this saved clock anyway, use "force"
Mar 21 08:42:18 rby systemd[1]: Started Flush Journal to Persistent Storage.

J’ai ça aussi mais on dirait que c’est une tâche automatique :

Mar 19 06:25:01 rby CRON[13161]: (root) CMD (test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily ))
Mar 19 06:25:01 rby CRON[13164]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Mar 19 06:25:05 rby slapd[1264]: slap_global_control: unrecognized control: 1.3.6.1.4.1.4203.666.5.16
Mar 19 06:25:08 rby systemd[1]: Stopping Supervisor process control system for UNIX...
Mar 19 06:25:11 rby supervisorctl[13357]: Shut down
Mar 19 06:25:11 rby supervisord[938]: 2020-03-19 06:25:11,596 INFO waiting for metrics, spellchecker, gc, docservice, converter to die
Mar 19 06:25:11 rby supervisord[938]: 2020-03-19 06:25:11,620 WARN received SIGTERM indicating exit request
Mar 19 06:25:11 rby supervisord[938]: 2020-03-19 06:25:11,707 INFO stopped: metrics (exit status 0)
Mar 19 06:25:11 rby supervisord[938]: 2020-03-19 06:25:11,722 INFO stopped: converter (terminated by SIGTERM)
Mar 19 06:25:11 rby supervisord[938]: 2020-03-19 06:25:11,797 INFO stopped: spellchecker (terminated by SIGTERM)
Mar 19 06:25:11 rby supervisord[938]: 2020-03-19 06:25:11,818 INFO stopped: docservice (terminated by SIGTERM)
Mar 19 06:25:11 rby supervisord[938]: 2020-03-19 06:25:11,911 INFO stopped: gc (terminated by SIGTERM)
Mar 19 06:25:12 rby systemd[1]: Stopped Supervisor process control system for UNIX.
Mar 19 06:25:12 rby systemd[1]: Started Supervisor process control system for UNIX.
Mar 19 06:25:12 rby systemd[1]: Reloading LSB: Metronome XMPP Server.
Mar 19 06:25:13 rby metronome[13375]: Reloading Metronome XMPP Server: metronome.
Mar 19 06:25:13 rby systemd[1]: Reloaded LSB: Metronome XMPP Server.

Hier soir il s’est arreté mais il a redémarré seul… A ne rien comprendre

Journal de php

[19-Mar-2020 19:01:45] NOTICE: [pool nextcloud] child 26261 exited with code 0 after 10371.711904 seconds from start
[19-Mar-2020 19:01:45] NOTICE: [pool nextcloud] child 31197 started
[19-Mar-2020 20:21:17] NOTICE: [pool nextcloud] child 27860 exited with code 0 after 10952.023409 seconds from start
[19-Mar-2020 20:21:17] NOTICE: [pool nextcloud] child 616 started
[21-Mar-2020 08:42:42] NOTICE: fpm is running, pid 935
[21-Mar-2020 08:42:43] NOTICE: ready to handle connections
[21-Mar-2020 08:42:43] NOTICE: systemd monitor interval set to 10000ms
[21-Mar-2020 11:12:55] WARNING: [pool nextcloud] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 8 children, there are 0 idle, and 7 total children
[21-Mar-2020 11:12:56] WARNING: [pool nextcloud] server reached pm.max_children setting (8), consider raising it
2

Persone n’aurait une idée??

3

Salut,

Si tu penses que c’est un problème de fuite de mémoire, alors il faudrait savoir quel programme ou service prend de plus en plus de RAM:

top

Fais SHIFT+F pour aller sélectionner et trier en fonction de la RAM %MEM et appuie sur S.

image
image786×342 15.8 KB

Q pour retourner à la liste. Tu peux appuyer sur E pour changer l’unité pour quelle soit plus lisible.

image
image813×349 16.7 KB

Dans mon cas, par exemple, c’est Gitea qui prend le plus de RAM.

4

Oui, j’ai déjà observé que c’est nextcloud qui me prend le plus de mémoire.
Mais je ne comprends pas pourquoi l’occupation mémoire augmente continuellement jusqu’à l’arrêt de la machine…
Je fais peut-être fausse piste avec la mémoire, le syslog ne m’apprend pas grand chose hélas

5

De mon expérience OnlyOffice utilise beaucoup de mémoire, as-tu les prérequis listés ici, notamment le swap ?

1 Like
6

Salut @Romain,

J’ai le même VPS chez Onetsolutions, et je rencontre le même problème que toi depuis fin février. (Avec parfois une extinction par jour)

Je n’ai pas encore pris le temps d’investiguer, mais le fait que nous ayons tous les deux la même offre VPS chez le même prestataire me fait penser qu’il doit y avoir quelque chose de spécifique à OnetSolutions (car j’ai d’autres instances Yunohost avec bcp plus d’utilisateurs et d’applications sur d’autres serveurs / VPS depuis plusieurs années et je n’ai jamais été confronté à ce problème)

Sur ce VPS, j’ai 2 utilisateurs et les applications suivantes : Nextcloud (sans OnlyOffice), Kanboard, Dokuwiki, Kresus, Ihatemoney

Depuis aujourd’hui, j’essaye de suivre ce qui se passe pour essayer d’en savoir plus.
Je vois que sur mon panel OnetSolutions il m’est indiqué que j’utilise actuellement 1,7g, de mémoire alors qu’un top ou un free me donne une utilisation de 500/600M.

L’augmentation brutale vers 6h30 est à priori liée au déclenchement de mes scripts de backup mais je trouve bizarre qu’il n’y ait qu’une descente ridicule une fois les backups terminés (Je relancerai les backups en étant présent pour voir ce qui se passe aussi sur le serveur).

Peut-être un début de piste ?

Est-ce que c’est pareil pour toi @Romain ?

7

Salut.
Merci pour ta réponse. Je me sens moins seul.
J’ai exactement les mêmes constats:

  • 2 utilisateurs pour ampache et nextcloud.
  • arrêt brutal du serveur sans explication particulière.
  • différence importante entre la mémoire utilisée par le serveur et l’outil de monitoring de onenetsolution, près du double!

J’ai contacté l’hébergeur qui m’assure qu’il n’y a aucun problème…

Peut être que nous pourrions ouvrir une demande commune chez onenetsolution ?

8

Salut @SiM.
Depuis la mise à jour de Yunohost, le problème de plantage a disparu!! et l’utilisation de la mémoire semble plus cohérente :

image
image775×300 24.1 KB

En revanche, j’ai toujours un décalage entre free -m et l’outil de monitoring :
total used free shared buff/cache available
Mem: 1955 646 334 68 975 1204
Swap: 2047 82 1965

9

J’avoue que c’est très étrange ce décalage.

Moi je vous conseille de mesurer l’ensemble des perfs:

cpu
memoire

Mais aussi regarder les performances des disques:

dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync

Si vous avez moins de 50Mo/s c’est bizarre. Si vous êtes en dessous de 10, c’est sûr que ça peut plus fonctionner sur la durée.

Idem avec “iostat” si iowait est élevé c’est que le CPU attend en permanence le disque.

En général au bout d’une minute d’attente du disque un processus meurt.

10

Effectivement, pour l’instant pas d’arrêt inopiné depuis la MAJ 3.7.

Par contre pour la mémoire j’ai toujours ce décalage comme toi.

@ljf merci pour les conseils.
Au niveau du CPU, les graphes ne montre qu’une très faible utilisation, même lorsqu’il y avait arrêt du VPS.
Le résultat de ta commande :
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 16.8566 s, 63.7 MB/s
iowait donne 0,27%.

A suivre !

11

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.