Bonjour chères moules,
J'ai une linux mint 18, kernel 4.4.0, sur une machine i5-3337U (2 cœurs HT), 8GB, SSD..
Malgré une grande stabilité, j'ai des freezes dont je commence à cerner les circonstances: beaucoup de calcul, et beaucoup de RAM consommée, donc du swap.
Je me demande si les freezes ne viendraient pas du fait que mon swap de 8GB est sur un mapper chiffré (dm_crypt, lui même sur un LVM). Des deadlocks pourraient se produire. D'autant que les calculs s'arrêtent lors du freeze système (les ventillos s'éteignent, je n'ai plus de CTRL+ALT+Fn ou CTRL+ALT+Backspace).
fdisk donne :
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 999423 997376 487M 83 Linux
/dev/sda2 1001470 500117503 499116034 238G 5 Extended
/dev/sda5 1001472 500117503 499116032 238G 83 Linux
sda1 est le /boot
sda5 est géré par dmcrypt
sur ce mapper, il y a un vg géré par LVM pour deux lv : root et swap.
en plus visuel :
Est-ce que cela ressemble à un problème connu ? Quel serait une bonne manière de tester mon hypothèse ? Comment générer beaucoup de swap et observer le crash ?
Merci de votre aide
# Recherche ....
Posté par root_rtfm . Évalué à 1.
Hello,
Je tenterais de désactiver le swap et de pousser les calculs… si ça plante, le swap n'est pas en cause, le disques dur peut-être (stockage calculs intermédiaires ?).
Sans le swap, s'il n'y a pas assez de RAM, il y aura un OutOfMemory avec un kill du process le plus gourmant, mais pas de freeze normalement.
Bonne continuation ;-)
PS : j'utilise un configuration similaire sans problème, mais avec moins de calcul peut-être
# des pistes ?
Posté par NeoX . Évalué à 2.
ca me fait plus penser à un probleme de (sur)chauffe et à l'extinction de la machine par securité
mais il me semble aussi avoir lu quelque part (mais impossible de me souvenir d'ou)
qu'en effet, le swap chiffré c'est pas top.
pour forcer le swap, tu dois pouvoir jouer avec le parametre swapiness mais faut quand meme faire des calculs en memoire pour forcer l'usage de la memoire, et donc du swap
# avancées
Posté par steph1978 . Évalué à 2.
Suivant vos commentaires, j'ai avancé vers un scénario reproductible.
Je lance uniquement plusieurs instance d'un programme python qui consomme beaucoup de ram et beaucoup de cpu.
Les ventillos se lancent à fond.
Avec le swap, le pc finit par figer : les ventillos s'éteignent, l'écran reste allumé sur la dernière image du bureau.
Sans le swap (
sudo swapoff -a
), le pc tourne, les ventillos toujours à fond. Des instances finissent par planter en outofmemory. Je peux en relancer autant que je veux.J'en déduis que c'est bien le fait de swaper qui provoque le freeze. Est-ce parce qu'il est chiffré ? je n'ai pas encore les moyens de le vérifier.
Pour l'instant je n'ai pas d'option parfaite :
En l'état (swap chiffré) : il ne faut pas trop swapper pour éviter le freeze et donc vivre avec une épée de Damoclès. Comme je suis gros consommateurs de firefox, libreoffice, java, python, VM, ça n'est pas simple. Je ne sais pas comment diagnostiquer mieux.
Sans swap : à part que le pc ne plante pas, la menace est la même mais sur un processus quelconque. Je n'ai pas trop envie de perdre un travail en cours. Est-ce que l'on peut prioriser les processus à tuer (hors "le plus gros") ? Et puis, pas d'hibernation sans réactiver le swap.
Swap non chiffré : cela nécessite de modifier ma conf en retaillant les partitions. Et cela compromet la sécurité de mes données (le swap, surtout en hibernation, regorge de données intéressantes).
Je vais tester un peu avec le swapiness à 10 au lieu de 60. Je ne vois pas trop comment ça solutionnerait mon problème mais ça a au moins le mérite d'améliorer les perfs sur un pc avec beaucoup de ram, dixit certains articles.
[^] # Re: avancées
Posté par foobarbazz . Évalué à 1.
Tu as essayé zram ?
[^] # Re: avancées
Posté par steph1978 . Évalué à 2.
J'y songe parce que je sais que ça marche bien.
Après, swapper sur du SSD, en soit, c'est pas mal.
Par contre, de mémoire, ça ne permet pas d'activer l'hibernation.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.