Pannes régulières

Bonsoir,

Il ne se passe pas un jour sans que mon serveur ne tombe en panne. Tous les jours, je dois le redémarrer, parfois plusieurs fois de suite pour espérer le revoir fonctionner, pour ensuite recommencer à quelques hoeres d’intervalles. Ce qui fait que quand je ne suis pas chez moi, il devient inutilisable jusqu’à ce que je revienne à mon domicile. Les pannes les plus fréquentes sont les suivantes:

  1. Plusieurs applis me retournent une erreur 500, vraisemblablement à cause de mysql vu que c’est la seule chose que ces derniers ont en commun (nextcloud, ttrss, opensondage, wallabag).
  2. Synapse me retourne une erreur 502.
  3. Mon serveur devient inaccessible depuis l’extérieur (voire inaccessible tout court).

Tout ceci met ma patience à rude épreuve. Comment puis-je investiguer l’origine de ces pannes et faire en sorte qu’elles n’arrivent plus ?

Merci d’avance.

Salut,

dans un premier temps, il faut bien comprendre que redémarrer un serveur pour fixer un problème est une relativement mauvaise pratique :sweat_smile:. Dans le meilleur des cas, il faut s’attendre à ce que ça résolve le problème temporairement mais pas de manière permanente … Maintenant c’est aussi compréhensible de tenter ça comme solution rapide si l’on a pas le temps et/ou si l’on ne sais pas où chercher …

Si cela arrive de manière récurrente et d’après les symptomes que tu décrit, mon intuition me dit naivement que ça pourrait être un système qui fini par manquer de RAM … mais il faudrait vraiment investiguer pour savoir ce qu’il en est …

Donc pour commencer : quel type de matériel utilises-tu ?

Ensuite, pour investiguer tes problèmes avec mysql, une fois que le problème se produit, il faudrait je pense regarder ce que renvoie cette commande pour savoir ce qu’il se passe :

tail -n 200 /var/lib/mysql/*.err

À propos de synapse, lorsque l’erreur se produitm je pense qu’il faut regarder du côté de :

systemctl synapse status | cat

OK, merci pour les tuyaux. Voici ce que donne le premier message:

root@stemy:~# tail -n 200 /var/lib/mysql/*.err
180521 18:17:56 [Note] InnoDB: Restoring possible half-written data pages from the doublewrite buffer...
180521 18:17:58 [Note] InnoDB: 128 rollback segment(s) are active.
180521 18:17:58 [Note] InnoDB: Waiting for purge to start
180521 18:17:58 [Note] InnoDB:  Percona XtraDB (http://www.percona.com) 5.6.36-82.1 started; log sequence number 943897510
180521 18:17:58 [Note] Plugin 'FEEDBACK' is disabled.
180521 18:17:58 [Note] Server socket created on IP: '::'.
180521 18:17:58 [Note] /usr/sbin/mysqld: ready for connections.
Version: '10.0.32-MariaDB-0+deb8u1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Debian)
180522 14:33:12 mysqld_safe Number of processes running now: 0
180522 14:33:12 mysqld_safe mysqld restarted
180522 14:33:14 [Note] /usr/sbin/mysqld (mysqld 10.0.32-MariaDB-0+deb8u1) starting as process 25156 ...
180522 14:33:15 [Note] InnoDB: innodb_empty_free_list_algorithm has been changed to legacy because of small buffer pool size. In order to use backoff, increase buffer pool at least up to 20MB.

180522 14:33:15 [Note] InnoDB: Using mutexes to ref count buffer pool pages
180522 14:33:15 [Note] InnoDB: The InnoDB memory heap is disabled
180522 14:33:15 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
180522 14:33:15 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
180522 14:33:15 [Note] InnoDB: Compressed tables use zlib 1.2.8
180522 14:33:15 [Note] InnoDB: Using Linux native AIO
180522 14:33:15 [Note] InnoDB: Not using CPU crc32 instructions
180522 14:33:15 [Note] InnoDB: Initializing buffer pool, size = 128.0M
180522 14:33:15 [Note] InnoDB: Completed initialization of buffer pool
180522 14:33:15 [Note] InnoDB: Highest supported file format is Barracuda.
180522 14:33:15 [Note] InnoDB: Starting crash recovery from checkpoint LSN=956425393
180522 14:33:15 [Note] InnoDB: Restoring possible half-written data pages from the doublewrite buffer...
InnoDB: 1 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 1 row operations to undo
InnoDB: Trx id counter is 17259008
180522 14:33:16 [Note] InnoDB: Starting final batch to recover 1 pages from redo log
180522 14:33:17 [Note] InnoDB: 128 rollback segment(s) are active.
180522 14:33:17 [Note] InnoDB: Starting in background the rollback of recovered transactions
2018-05-22 14:33:17 a67ff420  InnoDB: Rolling back trx with id 17258671, 1 rows to undo
180522 14:33:17 [Note] InnoDB: Waiting for purge to start
180522 14:33:17 [Note] InnoDB:  Percona XtraDB (http://www.percona.com) 5.6.36-82.1 started; log sequence number 956425516
180522 14:33:17 [Note] InnoDB: Rollback of trx with id 17258671 completed
180522 14:33:17 [Note] InnoDB: Rollback of non-prepared transactions completed
180522 14:33:17 [Note] Plugin 'FEEDBACK' is disabled.
180522 14:33:17 [Note] Server socket created on IP: '::'.
180522 14:33:17 [Note] /usr/sbin/mysqld: ready for connections.
Version: '10.0.32-MariaDB-0+deb8u1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Debian)
180522 18:00:54 mysqld_safe Number of processes running now: 0
180522 18:00:55 mysqld_safe mysqld restarted
180522 18:00:56 [Note] /usr/sbin/mysqld (mysqld 10.0.32-MariaDB-0+deb8u1) starting as process 29436 ...
180522 18:00:56 [Note] InnoDB: innodb_empty_free_list_algorithm has been changed to legacy because of small buffer pool size. In order to use backoff, increase buffer pool at least up to 20MB.

180522 18:00:56 [Note] InnoDB: Using mutexes to ref count buffer pool pages
180522 18:00:56 [Note] InnoDB: The InnoDB memory heap is disabled
180522 18:00:56 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
180522 18:00:56 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
180522 18:00:56 [Note] InnoDB: Compressed tables use zlib 1.2.8
180522 18:00:56 [Note] InnoDB: Using Linux native AIO
180522 18:00:56 [Note] InnoDB: Not using CPU crc32 instructions
180522 18:00:58 [Note] InnoDB: Initializing buffer pool, size = 128.0M
InnoDB: mmap(138149888 bytes) failed; errno 12
180522 18:00:58 [ERROR] InnoDB: Cannot allocate memory for the buffer pool
180522 18:00:58 [ERROR] Plugin 'InnoDB' init function returned error.
180522 18:00:58 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
180522 18:00:58 [ERROR] mysqld: Out of memory (Needed 130760704 bytes)
180522 18:00:58 [Note] Plugin 'FEEDBACK' is disabled.
180522 18:00:58 [ERROR] Unknown/unsupported storage engine: innodb
180522 18:00:58 [ERROR] Aborting

180522 18:00:58 [Note] /usr/sbin/mysqld: Shutdown complete

180522 18:00:59 mysqld_safe mysqld from pid file /var/lib/mysql/stemy.me.pid ended
180522 18:07:42 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
180522 18:07:42 [Note] /usr/sbin/mysqld (mysqld 10.0.32-MariaDB-0+deb8u1) starting as process 29868 ...
180522 18:07:42 [Note] InnoDB: innodb_empty_free_list_algorithm has been changed to legacy because of small buffer pool size. In order to use backoff, increase buffer pool at least up to 20MB.

180522 18:07:42 [Note] InnoDB: Using mutexes to ref count buffer pool pages
180522 18:07:42 [Note] InnoDB: The InnoDB memory heap is disabled
180522 18:07:42 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
180522 18:07:42 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
180522 18:07:42 [Note] InnoDB: Compressed tables use zlib 1.2.8
180522 18:07:42 [Note] InnoDB: Using Linux native AIO
180522 18:07:42 [Note] InnoDB: Not using CPU crc32 instructions
180522 18:07:42 [Note] InnoDB: Initializing buffer pool, size = 128.0M
InnoDB: mmap(138149888 bytes) failed; errno 12
180522 18:07:42 [ERROR] InnoDB: Cannot allocate memory for the buffer pool
180522 18:07:42 [ERROR] Plugin 'InnoDB' init function returned error.
180522 18:07:42 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
180522 18:07:42 [ERROR] mysqld: Out of memory (Needed 130760704 bytes)
180522 18:07:42 [Note] Plugin 'FEEDBACK' is disabled.
180522 18:07:42 [ERROR] Unknown/unsupported storage engine: innodb
180522 18:07:42 [ERROR] Aborting

180522 18:07:43 [Note] /usr/sbin/mysqld: Shutdown complete

180522 18:07:43 mysqld_safe mysqld from pid file /var/lib/mysql/stemy.me.pid ended
180522 18:14:17 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
180522 18:14:17 [Note] /usr/sbin/mysqld (mysqld 10.0.32-MariaDB-0+deb8u1) starting as process 30505 ...
180522 18:14:17 [Note] InnoDB: innodb_empty_free_list_algorithm has been changed to legacy because of small buffer pool size. In order to use backoff, increase buffer pool at least up to 20MB.

180522 18:14:17 [Note] InnoDB: Using mutexes to ref count buffer pool pages
180522 18:14:17 [Note] InnoDB: The InnoDB memory heap is disabled
180522 18:14:17 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
180522 18:14:17 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
180522 18:14:17 [Note] InnoDB: Compressed tables use zlib 1.2.8
180522 18:14:17 [Note] InnoDB: Using Linux native AIO
180522 18:14:17 [Note] InnoDB: Not using CPU crc32 instructions
180522 18:14:17 [Note] InnoDB: Initializing buffer pool, size = 128.0M
InnoDB: mmap(138149888 bytes) failed; errno 12
180522 18:14:17 [ERROR] InnoDB: Cannot allocate memory for the buffer pool
180522 18:14:17 [ERROR] Plugin 'InnoDB' init function returned error.
180522 18:14:17 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
180522 18:14:17 [ERROR] mysqld: Out of memory (Needed 130760704 bytes)
180522 18:14:17 [Note] Plugin 'FEEDBACK' is disabled.
180522 18:14:17 [ERROR] Unknown/unsupported storage engine: innodb
180522 18:14:17 [ERROR] Aborting

180522 18:14:17 [Note] /usr/sbin/mysqld: Shutdown complete

180522 18:14:17 mysqld_safe mysqld from pid file /var/lib/mysql/stemy.me.pid ended
180522 18:25:08 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
180522 18:25:10 [Note] /usr/sbin/mysqld (mysqld 10.0.32-MariaDB-0+deb8u1) starting as process 1113 ...
180522 18:25:10 [Note] InnoDB: innodb_empty_free_list_algorithm has been changed to legacy because of small buffer pool size. In order to use backoff, increase buffer pool at least up to 20MB.

180522 18:25:10 [Note] InnoDB: Using mutexes to ref count buffer pool pages
180522 18:25:10 [Note] InnoDB: The InnoDB memory heap is disabled
180522 18:25:10 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
180522 18:25:10 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
180522 18:25:10 [Note] InnoDB: Compressed tables use zlib 1.2.8
180522 18:25:10 [Note] InnoDB: Using Linux native AIO
180522 18:25:10 [Note] InnoDB: Not using CPU crc32 instructions
180522 18:25:10 [Note] InnoDB: Initializing buffer pool, size = 128.0M
180522 18:25:10 [Note] InnoDB: Completed initialization of buffer pool
180522 18:25:11 [Note] InnoDB: Highest supported file format is Barracuda.
180522 18:25:11 [Note] InnoDB: The log sequence numbers 943891780 and 943891780 in ibdata files do not match the log sequence number 959152345 in the ib_logfiles!
180522 18:25:12 [Note] InnoDB: Restoring possible half-written data pages from the doublewrite buffer...
180522 18:25:14 [Note] InnoDB: 128 rollback segment(s) are active.
180522 18:25:14 [Note] InnoDB: Waiting for purge to start
180522 18:25:14 [Note] InnoDB:  Percona XtraDB (http://www.percona.com) 5.6.36-82.1 started; log sequence number 959152345
180522 18:25:14 [Note] Plugin 'FEEDBACK' is disabled.
180522 18:25:14 [Note] Server socket created on IP: '::'.
180522 18:25:14 [Note] /usr/sbin/mysqld: ready for connections.
Version: '10.0.32-MariaDB-0+deb8u1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Debian)
180522 18:42:53 [Note] /usr/sbin/mysqld: Normal shutdown

180522 18:42:53 [Note] Event Scheduler: Purging the queue. 0 events
180522 18:42:56 [Note] InnoDB: FTS optimize thread exiting.
180522 18:42:56 [Note] InnoDB: Starting shutdown...
180522 18:42:57 [Note] InnoDB: Waiting for page_cleaner to finish flushing of buffer pool
180522 18:42:59 [Note] InnoDB: Shutdown completed; log sequence number 959395130
180522 18:42:59 [Note] /usr/sbin/mysqld: Shutdown complete

180522 18:42:59 mysqld_safe mysqld from pid file /var/lib/mysql/stemy.me.pid ended
180522 19:00:33 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
180522 19:00:34 [Note] /usr/sbin/mysqld (mysqld 10.0.32-MariaDB-0+deb8u1) starting as process 1092 ...
180522 19:00:35 [Note] InnoDB: innodb_empty_free_list_algorithm has been changed to legacy because of small buffer pool size. In order to use backoff, increase buffer pool at least up to 20MB.

180522 19:00:35 [Note] InnoDB: Using mutexes to ref count buffer pool pages
180522 19:00:35 [Note] InnoDB: The InnoDB memory heap is disabled
180522 19:00:35 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
180522 19:00:35 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
180522 19:00:35 [Note] InnoDB: Compressed tables use zlib 1.2.8
180522 19:00:35 [Note] InnoDB: Using Linux native AIO
180522 19:00:35 [Note] InnoDB: Not using CPU crc32 instructions
180522 19:00:35 [Note] InnoDB: Initializing buffer pool, size = 128.0M
180522 19:00:35 [Note] InnoDB: Completed initialization of buffer pool
180522 19:00:35 [Note] InnoDB: Highest supported file format is Barracuda.
180522 19:00:37 [Note] InnoDB: 128 rollback segment(s) are active.
180522 19:00:37 [Note] InnoDB: Waiting for purge to start
180522 19:00:37 [Note] InnoDB:  Percona XtraDB (http://www.percona.com) 5.6.36-82.1 started; log sequence number 959395130
180522 19:00:37 [Note] Plugin 'FEEDBACK' is disabled.
180522 19:00:37 [Note] Server socket created on IP: '::'.
180522 19:00:38 [Note] /usr/sbin/mysqld: ready for connections.
Version: '10.0.32-MariaDB-0+deb8u1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Debian)
180522 19:28:21 [Note] /usr/sbin/mysqld: Normal shutdown

180522 19:28:21 [Note] Event Scheduler: Purging the queue. 0 events
180522 19:28:21 [Note] InnoDB: FTS optimize thread exiting.
180522 19:28:21 [Note] InnoDB: Starting shutdown...
180522 19:28:22 [Note] InnoDB: Waiting for page_cleaner to finish flushing of buffer pool
180522 19:28:24 [Note] InnoDB: Shutdown completed; log sequence number 959805945
180522 19:28:24 [Note] /usr/sbin/mysqld: Shutdown complete

180522 19:28:25 mysqld_safe mysqld from pid file /var/lib/mysql/stemy.me.pid ended
180522 19:30:51 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
180522 19:30:53 [Note] /usr/sbin/mysqld (mysqld 10.0.32-MariaDB-0+deb8u1) starting as process 1087 ...
180522 19:30:53 [Note] InnoDB: innodb_empty_free_list_algorithm has been changed to legacy because of small buffer pool size. In order to use backoff, increase buffer pool at least up to 20MB.

180522 19:30:53 [Note] InnoDB: Using mutexes to ref count buffer pool pages
180522 19:30:53 [Note] InnoDB: The InnoDB memory heap is disabled
180522 19:30:53 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
180522 19:30:53 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
180522 19:30:53 [Note] InnoDB: Compressed tables use zlib 1.2.8
180522 19:30:53 [Note] InnoDB: Using Linux native AIO
180522 19:30:53 [Note] InnoDB: Not using CPU crc32 instructions
180522 19:30:53 [Note] InnoDB: Initializing buffer pool, size = 128.0M
180522 19:30:54 [Note] InnoDB: Completed initialization of buffer pool
180522 19:30:54 [Note] InnoDB: Highest supported file format is Barracuda.
180522 19:30:54 [Note] InnoDB: The log sequence numbers 959805945 and 959805945 in ibdata files do not match the log sequence number 959811700 in the ib_logfiles!
180522 19:30:56 [Note] InnoDB: Restoring possible half-written data pages from the doublewrite buffer...
180522 19:30:59 [Note] InnoDB: 128 rollback segment(s) are active.
180522 19:30:59 [Note] InnoDB: Waiting for purge to start
180522 19:30:59 [Note] InnoDB:  Percona XtraDB (http://www.percona.com) 5.6.36-82.1 started; log    sequence number 959811700
180522 19:30:59 [Note] Plugin 'FEEDBACK' is disabled.
180522 19:30:59 [Note] Server socket created on IP: '::'.
180522 19:31:00 [Note] /usr/sbin/mysqld: ready for connections.

Version: '10.0.32-MariaDB-0+deb8u1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Debian)
root@stemy:~#

Pour le deuxième, je vais attendre que l’erreur se produise.

Mon hardware est une brique Olinuxino Lime 1. Ce serait bizarre que les dysfonctionnements soient du au manque de mémoire, parce que si c’était le cas, l’association à laquelle j’ai fait appel n’aurait pas proposé d’installer YNH sur ce modèle, mais supposons que ce soit ça, y a-t-il un moyen de connaître à posteriori la quantité de mémoire vive occupée ?

Cordialement.

Est-ce que tu peux préciser si c’est une “vraie” Brique Internet, ou bien c’est une carte Olinuxino avec juste YunoHost (sans VPN ou hotspot) ?

C’est plus compliqué que ca, il se peut que ce soit d’autres programmes qui dévorent ta RAM :wink:

En regardant tes logs de mysql, je vois du coup :

180522 18:14:17 [ERROR] InnoDB: Cannot allocate memory for the buffer pool
180522 18:14:17 [ERROR] Plugin 'InnoDB' init function returned error.
180522 18:14:17 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
180522 18:14:17 [ERROR] mysqld: Out of memory (Needed 130760704 bytes)

Ce qui ressemble furieusement à un problème de manque de RAM …

Du coup, (toujours quand le probleme se produit) tu peux inspecter la quantité de RAM dispo avec : free -h

Sachant que le chiffre le plus pertinent à regarder est le free de la ligne -/+ buffers/cache

C’est bien une brique internet, avec VPN et hotspot.

Je devrais peut-être remplacer ma brique actuelle par une LIME 2, mais l’image à flasher n’est pas la même, du coup je ne sais pas si c’est possible d’y transférer facilement les données de ma brique actuelle.

C’est deux problèmes différents :wink: À priori tes données tu peux les transférer via le système de backup, qui est indépendant de la couche matériel de ton serveur…

Ceci étant, la réinstallation, c’est comme le reboot, c’est un peu la solution une fois qu’on a tout essayé … Hors là il y a encore moyen d’investiguer ce qu’il se passe - en particulier comprendre ce qui prends de la RAM.

Aussi, si tu as un hotspot mais que tu ne l’utilises pas, personellement je te conseillerais de débrancher l’antenne car il y a des problèmes matériel connu avec certaines et ça ne m’étonnerais pas que ça finisse par mettre le système en vrac au fil du temps …

La panne vient à nouveau de se produire et j’ai pu me connecter en ssh après qu’elle soit partie d’elle-même (pas pu le faire avant vu qu’elle bloquait ma connexion).

root@stemy:~# free -h
                       total       used       free     shared    buffers     cached
Mem:                    497M       479M        17M        58M        22M       145M
-/+ buffers/cache:      312M       185M
Swap:                     0B         0B         0B
root@stemy:~#

On peut voir que la RAM est au bord de la saturation bien que le buffer et le cache semblent à priori corrects. Du coup, est-ce que ça vient bien de la RAM ?

17Mo de RAM disponible et sans swap c’est bien trop peu. Il suffit qu’une application réclame ponctuellement plus de 17Mo pour que le noyau (via OOM Killer) décide de tuer un autre processus trop gourmand, comme mysql par exemple.
Pour limiter les dégâts on pourrait éventuellement définir des exclusions dans l’OOM Killer pour SSH et MySQL par exemple.

Une autre piste serait d’ajouter de la swap en sachant que ça risque de diminuer l’espérance de vie de la carde µSD.

Mais la solution que je recommanderais serait plutôt la sobriété. Il vaudrait mieux désinstaller la ou les applis trop gourmandes.

Ce n’est pas parce que yunohost propose d’installer facilement plein d’applications que c’est techniquement faisable. La brique Internet a une configuration matérielle modeste (même avec une LIME2) et est avant tout conçue pour le partage de connexion en Wifi d’une connexion Internet neutre via un VPN. Les fonctionnalités d’auto-hébergement d’applis sont un bonus apporté par yunohost et sont à utiliser avec modération.
Ce n’est pas l’avis de tout le monde mais personnellement j’ai tendance à considérer que la brique Internet est un moyen de goûter à l’auto-hébergement de façon abordable avec Yunohost et que lorsqu’on est rôdé et qu’on veut aller plus loin alors on installe Yunohost sur du matériel plus puissant.

PS : Depuis quelques temps chez Franciliens.net lorsqu’on livre des briques Internet à nos membres on fait bien attention de leur préciser ces limitations . Désolé si tu es passé aux travers des mailles de notre filet de protection.

On ne m’avait pas dit tout ça, d’autant plus que je suis le seul au sein de mon assoc à avoir ce type de problème.

Ceci dit, j’utilise déjà un SSD pour mon cloud. Du coup, est-ce que je pourrais en même temps m’en servir également pour le SWAP sans que ça ne gêne trop son espérance de vie ?

Ah oui, la swap sur le SSD ça devrait le faire.
Tapes les instructions suivantes (que j’ai adaptées de l’autre post qui parle de swap).

Remarque : remplace /ssdmountpoint par le point de montage de ton SSD.

dd if=/dev/zero of=/ssdmountpoint/swapfile bs=1024 count=1048576
mkswap /ssdmountpoint/swapfile
swapon /ssdmountpoint/swapfile
echo "/ssdmountpoint/swapfile swap swap defaults 0 0" >> /etc/fstab

Pour information systemd garantit au démarrage que le point de montage /ssdmountpoint sera créé avant le swap (cf. mon message #19).

[EDIT] comme ce message a été marqué comme solution je l’ai beaucoup allégé pour plus de lisibilité. Pour comprendre l’historique des échanges ci-dessous il faudra d’abord consulter l’historique des modifications de ce message lui-même :wink:

1 Like

Ça ne me rassure pas trop, ça. C’est pas que je ne te fais pas confiance, mais ledit SSD contient déjà des fichiers importants, et j’ai un peu peur que la manip’ ne les efface. Est-ce qu’il y a vraiment ce risque ?

Non il n’y a pas de risque de perte de données. Le risque c’est plutôt que le swap ne fonctionne pas au démarrage.
En fait j’avais écrit cette phrase avant de découvrir que mount ne respectait pas forcément l’ordre dans fstab et j’ai oublié de retirer cette formulation. Maintenant je suis sûr que c’est une mauvaise idée d’utiliser le fstab pour déclarer le fichier swap et je vais d’ailleurs éditer mon message.

Tu peux donc créer un fichier swap manuellement dès maintenant tout en gardant en tête qu’au prochain démarrage il faudra refaire la manip tant qu’on n’aura pas automatisé ça.

Il faut faire attention : le chiffre à vraiment regarder est celui de la ligne +/- buffers/cache … C’est “normal” qu’il y ai 17M de “libre” en théorie … en fait, si tu fais un free -h sur une machine qui est active depuis relativement longtemps, tu verras que + de 90% de la RAM est utilisée. Car de la RAM non utilisée, c’est de la RAM perdue …

Mais ce qu’il faut comprendre, c’est que certains morceaux sont utilisés par des buffers ou des caches qui peuvent être enlevé de la RAM si un autre programme a besoin de RAM. Ces buffers/cache sont mis en RAM pour accélérer l’execution toussa. Par exemple sur mon laptop qui a 6G de RAM, il m’indique qu’il n’y en a que 135M libre, mais si on enleve les buffers/cache, alors j’ai 3.6G de dispo…

(En tout cas c’est ma compréhension du schmilblik…)

C’est vrai, j’avais oublié ce schmilblik sous linux de la RAM consommée qui n’est pas vraiment consommée. Comme toi @Aleks je n’ai jamais bien su comment ça devait s’interpréter.

Cela dit, je pense que l’ajout du fichier swapfile sur le disque SSD devrait aider quand même pour éviter les erreurs mysqld: Out of memory.

1 Like

Pour l’instant, les erreurs ne se sont pas reproduites et le swap est déjà rempli à 10%.
Croisons les doigts.

Ok, ça fait presque une semaine et toujours pas la moindre panne, ça ne m’était plus arrivé depuis longtemps.

Dont acte: le SWAP était bien la solution.

1 Like

Merci pour le retour, c’est bon à savoir

Je vais créer un ticket pour qu’on se demande si il faudrait pas créer automatiquement du swap à l’install ou au moins prévenir l’utilisateur qu’il n’y en a pas … À voir comment on gère le cas des cartes SD… À mon avis c’est la cause d’autre problème (par exemple, j’ai vu des cas de processus Killed pendant la migration à Stretch, probablement car ca prenait beaucoup de RAM…)

Merci pour ta patience :+1: :heart:

Bonne nouvelle ! Grâce à systemd il semble possible d’automatiser la création du swap au boot avec la garantie que le point de montage sous-jacent sera créé d’abord.

cf. https://www.freedesktop.org/software/systemd/man/systemd.swap.html

Swaps listed in /etc/fstab will be converted into native units dynamically at boot
[…]
Option what=
[…] If this refers to a file, a dependency on the respective mount unit is automatically created

Tu peux donc déclarer ton fichier swap dans fstab.
je vais éditer ma réponse en conséquence

1 Like

OK, super.

Maintenant, j’ai un autre problème: mon SWAP semble se remplir indéfiniment. Est-ce que le redémarrage est le seul moyen de le vider ? Et est-ce que je serai forcé de le faire quand il sera saturé à son tour ?

Ce n’est pas forcément une mauvaise chose qu’il se remplisse. Ça veut juste dire qu’il fait son boulot et que ta Lime1 en avait vraiment besoin. Et je crois que comme pour la RAM il ne faut pas s’inquiéter de la fausse impression qu’il reste peu de mémoire.

Tant que tu n’as pas de symptômes désagréables (comme une appli qui plante faute de mémoire) alors ne touche à rien. S’il s’avère que tes applis ont besoin de plus que 1Go de SWAP alors tu peux envisager de créer un fichier SWAP plus gros.
Cela dit je ne te le conseille pas car une appli qui utilise le SWAP devient horriblement lente. Le SWAP ce n’est qu’une roue de secours pour la RAM.