Bonjour,

Depuis 2 jours, à exactement 3h du matin, mon NAS crash.
Avant cela, il a juste le temps de m'envoyer 2 ou 3 mails contenant ceci :

La mémoire de votre système est saturée. Certains services ont été arrêtés afin de garantir la stabilité du système. Si le problème persiste, nous vous recommandons d'augmenter la capacité de mémoire si votre périphérique prend en charge l'extension de mémoire, ou de désactiver les services qui ne seront pas utilisés.

Pour avoir de nouveau accès au NAS, je suis obligé de maintenir le bouton "On/Off" ce qu'il n'est absolument pas cool.
De plus, à 3 heures du matin, tous les jours, c'est exactement le moment où j'ai paramétré mon NAS pour qu'il se sauvegarde via Hyper Backup sur mon autre NAS du même LAN.

Jusqu'à avant hier et depuis environ 6 mois, pas de problème. La sauvegarde s'effectuée en 7 à 9 minutes environ.

Je vais faire redémarrer le NAS par ma femme demain matin. 
Pourriez-vous m'orienter pour savoir ce qui merde ? (un fichier de log ou un truc du genre)

Merci.

Bonne soirée et bonne nuit.

 

Modifié le 23 mai 20214 a par GrOoT64

Bonjour,

je suis un peu, tu as le plex qui ne fonctionne pas top en plus 124 utilisateurs connectés en même temps alors que tu es le seul utilisateur...

À mon avis (mais je ne suis pas docteur 🙂 ) tu as un problème assez profond au niveau de la config ou de l'utilisation du NAS.

124 utilisateurs connectés c'est pas normal et pourraient utiliser de la ram ?

 

J’ai parfois ses alertes, lors de forte sollicitude en docker mais j’en rigole dans la mesure où le nas a 70% en cache presque tout le temps.

Mais de là à avoir un crash ou problème de système, jamais…

Bonjour, 

Je viens de faire redémarrer le system par Madame.
Je vais lancer une sauvegarde manuelle de via Hyper Backup pour voir si ça plante encore. c'est peut-être lui le fautif.

Dans les journaux j'ai ça :

Video Station démarre 5 fois de suite ?

Modifié le 23 mai 20214 a par GrOoT64

Ha le problème vient peu être de lui alors… s’il lance 5 fois sont process…

Apres niveau utilisation de la ram sa dit quoi ?

Tu me conseilles de le réinstaller ?

Pour la RAm : 

Quand les problèmes sont multiples et sans raisons, que faire ?

Réinstaller DSM mais je suis en Afrique

ou bien remonter toutes les manips/optimisations/bidouilles/...

bon courage 🙂

sur un bêta DSM 🤣

 

Modifié le 24 mai 20214 a par pluton212+

il y a 32 minutes, GrOoT64 a dit :

Tu me conseilles de le réinstaller ?

Pour la RAm : 

Donc la ta ram est normale, tu dois avoir tout le reste en cache, bug a ne pas tenir compte normalement, mais bon si tu as le nas qui crash.. la chelou

Après tu cumules les bugs les plus improbables, j'ai mis sur le 916 sans aucun soucis et migré après avec un 920 sans aucun soucis ^^'

edit : tu as testé ta ram quand tu l'as mise ?

On peut pas "Réparer DSM" à distance ?

Je viens de tester sur une VM DSM7 (celle de test mise à disposition de Synology)
J'ai coupé et réactivé video station :

 

Modifié le 23 mai 20214 a par GrOoT64

il y a une heure, GrOoT64 a dit :

On peut pas "Réparer DSM" à distance ?

Je veux dire par là, Réinstaller entièrement DSM (sans perdre les données) via SSH

Je viens de pense à un truc intéressant.
Sur mon 2nd NAS, que je joins via Reverse Proxy en place sur le 1er, j'ai PLEX (sous docker)
Dans ce PLEX, j'ai uniquement des films en 4K (donc bien lourds)

Par le plus grand des hasards, est-ce que ne serait pas ça qui fait planter le 1er NAS car comme c'est le reverse proxy, tout passe par lui et donc sa RAM ?!
 

Je suis tout seul ? :x

Il y a 4 heures, GrOoT64 a dit :

Je viens de pense à un truc intéressant.
Sur mon 2nd NAS, que je joins via Reverse Proxy en place sur le 1er, j'ai PLEX (sous docker)
Dans ce PLEX, j'ai uniquement des films en 4K (donc bien lourds)

Par le plus grand des hasards, est-ce que ne serait pas ça qui fait planter le 1er NAS car comme c'est le reverse proxy, tout passe par lui et donc sa RAM ?!
 

Si tu as mis une limite à plex non... après hormis quand il y a indexation ou transcodage, la ram c'est peau de zob avec plex

Pour le transcodage, je ne peux pas le mettre en service je n'ai pas les lignes à modifier dans le fichier de conf

Modifié le 23 mai 20214 a par GrOoT64

@GrOoT64 non tu n'es pas seul !!

Petit historique :

• tout d'abord, en passant en DSM7 Preview puis Beta, je reconnais en assumer les risques .... et l'avoir fait en toute connaissance de cause
• depuis des mois j'avais des blocages aléatoires de mon ds918+. Parmi les symptômes, des messages indiquant un manque de mémoire (j'avais 16Go et aucun symptôme sur les graphes de mémoire ...),
• Jusqu'à ce que courant mars un blocage de trop, mettant en cause le cache NVME (j'étais en R/w à l'époque) et une mauvaise manipulation de ma part qui m'a fait perdre toutes mes données 🙂 . J'ai alors expérimenté, un brin stressé, la restauration des datas .... et au final re-installation complète DSM7 et restauration des données (ok ... sauf .... perte de toute la configuration Synology Photo (albums, regroupement facial, ... 😞 )).
• et depuis, blocage du NAS tous les 5 à 10 jours, redémarrage au bouton face avant (appui long 10 sec), sans jamais rien perdre certes .... (mais j'ai migré les hébergements WordPress sur une autre machine). Le cache NVME (RO cette fois ci !) remis à zéro systématiquement, blocage des accès DSM et ssh ....

Et donc depuis mi avril tentatives d'investigation avec le support Synology. Leur hypothèse est toujours "un manque de mémoire système", m'expliquant que dans ce cas DSM7 se défend en stoppant certains services. Mais lesquels ? comment ? pas de procédure de reprise ?? Et donc "essayer de désinstaller quelques services" LOL !

On a fini par configurer un accès console RS232 pour voir ce qui se passe en cas de blocage. Le support ne m'a remonté que "manque de mémoire" comme diagnostic, ... ce qui n'apparait sur aucun graphe d'observation.

Néanmoins ces traces, que je n'ai pas pu m’empêcher d'aller un peu regarder, m'ont permises de trouver dans le log des taches bloquées (toujours prise via la console RS232) des milliers et des milliers de messages concernant un container docker en particulier : il s'agissait d'un container telegraf lui-même faisant appel un un shell via la section [[inputs.exec]]. Mon hypothèse est qu'ici j'ai eu une saturation quelconque (espace mémoire particulier, nb de process, ???? ) Même si rien de visible extérieurement sur les graphes.

J'ai donc stoppé ce container Docker sans autre forme de procès pour le moment ....   et j'en suis à un uptime de 5 jours (Youpi !) sachant que l'intervalle moyen de blocage était de l'ordre de 4 à 8 jours. Donc encore quelques jours de patience pour savoir si cela a été salvateur ou pas (si ce n'est pas le cas, je ne sais pas où chercher ailleurs pour le moment)

Si je résume :

• DSM7 semble consommer un peu plus de mémoire
• DSM7 semble tenter de se protéger en cas de manque de mémoire en bloquant des tâches (lesquelles ? pourquoi ? comment en sortir ... ???  configurable ?)
• l'appui long (10sec) au bouton face avant a jusqu'à présent toujours permis de redémarrer sans bobo (on est d'accord, on continue à bien faire des backup externes !)
• pour le moment, je soupçonne le problème chez moi d'être causé par un shell "foireux" lancé toutes les minutes par un container Docker telegraf
  • manque de mémoire : peut-être, mais en tout cas cela ne se voit pas dans les graphes récoltés ?
  • autres types de saturation ????
    • nb de process ?
    • autre ressource système ???

Comme tu le vois, j'ai des symptômes qui semblent assez proches des tiens, sans pouvoir garantir cependant que l'origine soit la même. De même, je ne suis pas encore sûr que mon problème soit résolu. D'ici quelques jours peut-être je pourrai confirmer ....

Par contre, je crois qu'Einsteinium l'a dit, il faudrait vérifier toutes les bidouilles / personnalisations  que tu as pû apporter.

Bon courage,

bruno78

(ps : histoire de rester dans des configs officiellement supportées, je suis repassé de 16 à 8Go de RAM (Syno d'origine) .... ça n'a rien changé ... heureusement . Évidemment la RAM a été testée et est OK).

(ps2 : je vais regarder si je peux retrouver les messages d'erreurs dans le logs "classique", sans être obligé de connecter une console RS232..... )

@bruno78 c'est étrange car Telegraf a plutôt tendance à bouffer du CPU plutôt que la RAM.

Est-ce que ça concernerait l'image classique ou ta version pour le monitoring de la Freebox ?

@.Shad. bonjour,

oui en fait je pense que telegraf n'entre dans l'histoire que parce qu'il lançait un shell pas forcement bien taillé ! Si ça se trouve, telegraf ou docker n'y sont pour rien .

Si le ds918 tient encore quelques jours, alors je relancerai le docker telegraf mais sans le shell en question dans la partie [[inputs.exec]]. Etape par étape, mais à moins que ça ne plante tout de suite, il me faut a minima 10 j de stabilité avant de pouvoir dire "ok c'est bon", .... donc je n'avance pas vite.

Et comme je précise, à aucun moment je ne vois mes graphes de mémoire tendre vers 0 de façon anormale. Mais il y a bien des "rares" messages "Out of memory" sont bien là, mais pas forcement au moment des blocages, d'où mon impression qu'il y a autre chose.

Si je reprends le log des taches "bloquées" /!\ le log est tronqué /!\  , mais j'y ai quand même environ 25000 occurrences du motif suivant (1 ping et 4 sed):

[396262.776686] runnable tasks:
[396262.776686]             task   PID         tree-key  switches  prio     wait-time             sum-exec        sum-sleep
[396262.776686] ----------------------------------------------------------------------------------------------------------
....
[396268.663971]             ping 23411      2605.590422         3   120         0.116067         2.204579         0.007442 /docker/63f9fb605f3c641a99f0d919bd495a0ac0e8c34a3c1fc071ab325f5c835c8f7d
[396268.683114]              sed 23413      2608.353497         4   120         8.173924         1.846712         0.007161 /docker/63f9fb605f3c641a99f0d919bd495a0ac0e8c34a3c1fc071ab325f5c835c8f7d
[396268.702257]              sed 23414      2606.541389        20   120         4.310145         1.975794         3.932512 /docker/63f9fb605f3c641a99f0d919bd495a0ac0e8c34a3c1fc071ab325f5c835c8f7d
[396268.721400]              sed 23415      2606.927045         9   120         7.840717         2.005334         3.817247 /docker/63f9fb605f3c641a99f0d919bd495a0ac0e8c34a3c1fc071ab325f5c835c8f7d
[396268.740540]              sed 26062      2662.195674         3   120         0.799128         1.801373         0.005948 /docker/63f9fb605f3c641a99f0d919bd495a0ac0e8c34a3c1fc071ab325f5c835c8f7d
.....

La dernière partie m'a permis d'identifier le container "coupable" => telegraf., et que le shell en question est un "ping" suivi de 4 'sed' pour mise en forme du résultat. On teste la réponse au ping d'un autre containter, et on envoie le résultat vers influxdb via telegraf. Voir ci-dessous. Comme ça je ne vois pas ce qui peut le mettre de travers, mais bon ....

#!/bin/bash
IP=xxx.xxx.xxx.xxx
ping -q -c1 -w1 $IP | sed "/PING/d" | sed "/statistics/d"  | sed "/transmitted/d" | sed "/rtt/d"  &>/dev/null;
#ping -q -c1 -w1 $IP ;
if [ $? -eq 0 ] ; then
res=1
else
res=0
fi
echo "pihole_docker_cnx,endpoint=pihole cnx_status_float=$res"

A chaque fois le PID augmente de "environ" 100 à "environ" 31xxx, jamais les mêmes, ça tourne en permanence. Du coup j'ai vérifié  la valeur max du PID sur notre environnement, => 32768

root@ds918blam:~# cat /proc/sys/kernel/pid_max
32768

D'où l'interrogation ( mais là je suis vraiment en eaux troubles et inconnues ) que peut-être si pour une raison ou une autre le shell n'est pas bon, des ressources ne sont pas libérées comme il faut, et on sature quelque chose ? la table de PID ? (je ne sais même pas si c'est possible) ... .

Mais je ne veux pas trop spéculer dans le vide au risque de raconter n'importe quoi.  C'est peut-être déjà trop tard ?

La si je regarde le nombre total de process  : 553. Ce qui semble raisonnable ?

root@ds918blam:~# ps -e | wc -l
553

Et du coup pour répondre à la question : il s'agit du telegraf "classique", monitorant le NAS lui-même, pas celui de la fbox.

Modifié le 23 mai 20214 a par bruno78

Il y a 10 heures, Einsteinium a dit :

edit : tu as testé ta ram quand tu l'as mise ?

La RAM a plus d'un an

@bruno78 : ça c'est du post ! et de l'investigation 😄

@GrOoT64 .... heu ... c'est à dire qu'au bout d'un moment, un NAS qui se bloque tous les 5 à 8 jours, même en version Beta, ça lasse .... !! Donc faut trouver d'où ça vient : vraisemblablement d'une bidouille customisation ratée de ma part, peut-être, mais je veux comprendre, ...et surtout régler le problème.  Après, s'agissant d'une Beta, on ne peut pas exclure le bug, ... mais si le DSM7 "propre" se bloquait chez tout le monde tous les 5 à 8 jours , ça se saurait. Ça peut aussi être un bug mis en évidence par une configuration particulière chez moi, un ensemble de facteurs .... .

Mais de toute façon il faut que je sorte, et vire, de cette situation. Même pour un usage non professionnel, ça commence à être pénible !

il y a 20 minutes, GrOoT64 a dit :

La RAM a plus d'un an

@bruno78 : ça c'est du post ! et de l'investigation 😄

Et cela ne change rien, si tu ne l’as jamais plafonné, là si tu as remplissage de cette dernière, comme les disques durs.. une mauvaise écriture, dans le mauvais bloc… et paf 🙂

@bruno78 Sur mon 916 avant j’avais déjà ses alertes à l’époque avec de la ram d’origine.

Par contre maintenant que j’y repense, j’ai fait quelques investigations y quelques semaines, j’ai vue que j’avais de l’écriture dans le swap qui provoqué cette alerte et beaucoup de ram en cache… J’ai remarqué que j’avais ses alertes en rapport avec docker et l’utilisation intensive que j’avais, j’ai appris quelque chose d’intéressant, on règle la mémoire limite des docker (--memory=xxxx), c’est en faites la limite de mémoire en ram, une fois atteint cela passe en swap, pour empêcher cela il faut rajouter une variable avec la valeur identique (formule swap-memory qui s’applique, --memory-swap=xxxx), en faites j’ai plus eu d’alerte depuis…

Par contre contrairement à vous, quand j’avais les alertes, aucun problème ou crash derrière…

@bruno78 Je pense que je suis loin de maîtriser le bash comme toi, mais quand tu utilises un pipe, tu déclares un nouveau process. Tu pourrais essayer de faire un sed en une ligne : https://unix.stackexchange.com/questions/414459/sed-how-to-minimize-sed-pipe-line-and-do-the-sed-in-one-shoot, tu dois pouvoir également traiter le résultat de la commande de ping dans le sed directement sans passer par un pipe entre les deux.

Peut-être aussi voir si tu n'aurais pas un comportement différent en te servant de /tmp à la place de /dev/null.

@Einsteinium bonjour,

oui je connais et j'utilise  le --memory-swap . Mais je ne comprends pas ton raisonnement : où est le problème à allouer de l'espace de swap à un docker ? Intuitivement j'aurai eu le raisonnement inverse : afin de limiter la RAM allouée à un docker, la solution de diminuer sa mémoire allouée (--memory) pour en contre partie lui allouer du swap ( --memory-swap) en cas de besoin me paraissait une bonne idée ?

On est bien d'accord : le swap c'est de l'espace disque utilisée par un process en cas de besoin de mémoire RAM supplémentaire à ce qui lui est alloué ? Il faut que je fasse des tests sur une VPS OVH de 4GB de RAM et sur laquelle le container Influxdb me mange toute la RAM allouée et tombe régulièrement en Out of Memory malgré 3GB alloués

@.Shad. bonjour,

non je suis loin de maitriser le bash justement ! mais oui il y a surement un loup autour de cette ligne ping / sed .... . Dés que j'aurai confirmation que c'est bien la source de mon problème, je ferai les essais que tu me conseilles, ... et je ferais quelques recherches à ce propos 🙂