Comment faire pour que le tueur Linux OOM ne tue pas mon processus?

Comment puis-je obtenir le tueur Linux OOM pour ne pas tuer mes processus lorsque la mémoire physique est faible mais qu'il y a beaucoup d'espace de swap?

J'ai désactivé la suppression de MOO et la surcharge avec sysctl vm.overcommit_memory = 2.

La machine virtuelle dispose de 3 Go de swap non fragmenté absolument gratuit et les processus qui sont tués par MOO ont une utilisation maximale de la mémoire inférieure à 200 Mo.

Je sais que l'échange à long terme sera horrible pour les performances, mais je dois l'utiliser maintenant pour faire des tests fonctionnels sous valgrind où les besoins en mémoire sont beaucoup plus importants.

Mar  7 02:43:11 myhost kernel: memcheck-amd64- invoked oom-killer: gfp_mask=0x24002c2, order=0, oom_score_adj=0
Mar  7 02:43:11 myhost kernel: memcheck-amd64- cpuset=/ mems_allowed=0
Mar  7 02:43:11 myhost kernel: CPU: 0 PID: 3841 Comm: memcheck-amd64- Not tainted 4.4.0-x86_64-linode63 #2
Mar  7 02:43:11 myhost kernel: Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
Mar  7 02:43:11 myhost kernel: 0000000000000000 0000000000000000 ffffffff8158cbcc ffff880032d7bc18
Mar  7 02:43:11 myhost kernel: ffffffff811c6a55 00000015118e701d ffffffff81044a8d 00000000000003e2
Mar  7 02:43:11 myhost kernel: ffffffff8110f5a1 0000000000000000 00000000000003e2 ffffffff81cf15cc
Mar  7 02:43:11 myhost kernel: Call Trace:
Mar  7 02:43:11 myhost kernel: [<ffffffff8158cbcc>] ? dump_stack+0x40/0x50
Mar  7 02:43:11 myhost kernel: [<ffffffff811c6a55>] ? dump_header+0x59/0x1dd
Mar  7 02:43:11 myhost kernel: [<ffffffff81044a8d>] ? kvm_clock_read+0x1b/0x1d
Mar  7 02:43:11 myhost kernel: [<ffffffff8110f5a1>] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x1e
Mar  7 02:43:11 myhost kernel: [<ffffffff81183316>] ? oom_kill_process+0xc0/0x34f
Mar  7 02:43:11 myhost kernel: [<ffffffff811839b2>] ? out_of_memory+0x3bf/0x406
Mar  7 02:43:11 myhost kernel: [<ffffffff81187bbd>] ? __alloc_pages_nodemask+0x8ba/0x9d8
Mar  7 02:43:11 myhost kernel: [<ffffffff811b82e8>] ? alloc_pages_current+0xbc/0xe0
Mar  7 02:43:11 myhost kernel: [<ffffffff811b096c>] ? __vmalloc_node_range+0x12d/0x20a
Mar  7 02:43:11 myhost kernel: [<ffffffff811e0e62>] ? alloc_fdtable+0x6a/0xd8
Mar  7 02:43:11 myhost kernel: [<ffffffff811b0a83>] ? __vmalloc_node+0x3a/0x3f
Mar  7 02:43:11 myhost kernel: [<ffffffff811e0e62>] ? alloc_fdtable+0x6a/0xd8
Mar  7 02:43:11 myhost kernel: [<ffffffff811b0ab0>] ? vmalloc+0x28/0x2a
Mar  7 02:43:11 myhost kernel: [<ffffffff811e0e62>] ? alloc_fdtable+0x6a/0xd8
Mar  7 02:43:11 myhost kernel: [<ffffffff811e1338>] ? dup_fd+0x103/0x1f0
Mar  7 02:43:11 myhost kernel: [<ffffffff810dd143>] ? copy_process+0x5aa/0x160d
Mar  7 02:43:11 myhost kernel: [<ffffffff8110f5a1>] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x1e
Mar  7 02:43:11 myhost kernel: [<ffffffff810de2fc>] ? _do_fork+0x7d/0x291
Mar  7 02:43:11 myhost kernel: [<ffffffff810ea186>] ? __set_current_blocked+0x47/0x52
Mar  7 02:43:11 myhost kernel: [<ffffffff810ea1f2>] ? sigprocmask+0x61/0x6a
Mar  7 02:43:11 myhost kernel: [<ffffffff81998eae>] ? entry_SYSCALL_64_fastpath+0x12/0x71
Mar  7 02:43:11 myhost kernel: Mem-Info:
Mar  7 02:43:11 myhost kernel: active_anon:15 inactive_anon:18 isolated_anon:0
Mar  7 02:43:11 myhost kernel: active_file:7 inactive_file:8 isolated_file:0
Mar  7 02:43:11 myhost kernel: unevictable:0 dirty:3 writeback:26 unstable:0
Mar  7 02:43:11 myhost kernel: slab_reclaimable:1798 slab_unreclaimable:3674
Mar  7 02:43:11 myhost kernel: mapped:8 shmem:1 pagetables:752 bounce:0
Mar  7 02:43:11 myhost kernel: free:1973 free_pcp:0 free_cma:0
Mar  7 02:43:11 myhost kernel: Node 0 DMA free:3944kB min:60kB low:72kB high:88kB active_anon:0kB inactive_anon:0kB active_file:28kB inactive_file:32kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15992kB managed:15908kB
 mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:72kB slab_unreclaimable:236kB kernel_stack:48kB pagetables:60kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:36
0 all_unreclaimable? yes
Mar  7 02:43:11 myhost kernel: lowmem_reserve[]: 0 972 972 972
Mar  7 02:43:11 myhost kernel: Node 0 DMA32 free:3948kB min:3956kB low:4944kB high:5932kB active_anon:60kB inactive_anon:72kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:1032064kB manag
ed:999552kB mlocked:0kB dirty:12kB writeback:104kB mapped:32kB shmem:4kB slab_reclaimable:7120kB slab_unreclaimable:14460kB kernel_stack:2112kB pagetables:2948kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_t
mp:0kB pages_scanned:792 all_unreclaimable? yes
Mar  7 02:43:11 myhost kernel: lowmem_reserve[]: 0 0 0 0
Mar  7 02:43:11 myhost kernel: Node 0 DMA: 20*4kB (UM) 17*8kB (UM) 13*16kB (M) 14*32kB (UM) 8*64kB (UM) 4*128kB (M) 4*256kB (M) 0*512kB 1*1024kB (M) 0*2048kB 0*4096kB = 3944kB
Mar  7 02:43:11 myhost kernel: Node 0 DMA32: 934*4kB (UM) 28*8kB (UM) 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 3960kB
Mar  7 02:43:11 myhost kernel: 71 total pagecache pages
Mar  7 02:43:11 myhost kernel: 42 pages in swap cache
Mar  7 02:43:11 myhost kernel: Swap cache stats: add 245190, delete 245148, find 77026/136093
Mar  7 02:43:11 myhost kernel: Free swap  = 3118172kB
Mar  7 02:43:11 myhost kernel: Total swap = 3334140kB
Mar  7 02:43:11 myhost kernel: 262014 pages RAM
Mar  7 02:43:11 myhost kernel: 0 pages HighMem/MovableOnly
Mar  7 02:43:11 myhost kernel: 8149 pages reserved
Mar  7 02:43:11 myhost kernel: [ pid ]   uid  tgid total_vm      rss nr_ptes nr_pmds swapents oom_score_adj name
Mar  7 02:43:11 myhost kernel: [ 2054]     0  2054     5101        1      15       4      283             0 upstart-udev-br
Mar  7 02:43:11 myhost kernel: [ 2063]     0  2063    12362        1      28       4      184         -1000 systemd-udevd
Mar  7 02:43:11 myhost kernel: [ 3342]   102  3342     9780        1      23       3       89             0 dbus-daemon
Mar  7 02:43:11 myhost kernel: [ 3423]     0  3423    10864        1      26       3       85             0 systemd-logind
Mar  7 02:43:11 myhost kernel: [ 3441]     0  3441    15344        0      34       3      184         -1000 sshd
Mar  7 02:43:11 myhost kernel: [ 3450]     0  3450     4786        0      14       3       43             0 atd
Mar  7 02:43:11 myhost kernel: [ 3451]     0  3451     5915        0      17       4       65             0 cron
Mar  7 02:43:11 myhost kernel: [ 3457]   101  3457    63962        0      28       3      202             0 rsyslogd
Mar  7 02:43:11 myhost kernel: [ 3516]     0  3516     3919        1      13       3      156             0 upstart-file-br
Mar  7 02:43:11 myhost kernel: [ 3518]     0  3518     4014        0      13       3      265             0 upstart-socket-
Mar  7 02:43:11 myhost kernel: [ 3557]     0  3557    66396        0      32       3     1802             0 fail2ban-server
Mar  7 02:43:11 myhost kernel: [ 3600]     0  3600     3956        1      13       3       39             0 getty
Mar  7 02:43:11 myhost kernel: [ 3601]     0  3601     3198        1      12       3       37             0 getty
Mar  7 02:43:11 myhost kernel: [ 3673]     0  3673    26411        1      55       3      252             0 sshd
Mar  7 02:43:11 myhost kernel: [ 3740]  1000  3740    26411        1      52       3      253             0 sshd
Mar  7 02:43:11 myhost kernel: [ 3741]  1000  3741     5561        0      16       3      431             0 bash
Mar  7 02:43:11 myhost kernel: [ 3820]   103  3820     7863        1      21       3      152             0 ntpd
Mar  7 02:43:11 myhost kernel: [ 3837]  1000  3837    31990        0      58       4    12664             0 memcheck-amd64-
Mar  7 02:43:11 myhost kernel: [ 3841]  1000  3841    32006        0      59       4    12812             0 memcheck-amd64-
Mar  7 02:43:11 myhost kernel: [ 3844]  1000  3844    31950        0      57       4    12035             0 memcheck-amd64-
Mar  7 02:43:11 myhost kernel: [ 3849]  1000  3849    31902        0      56       4    11482             0 memcheck-amd64-
Mar  7 02:43:11 myhost kernel: [ 3853]  1000  3853     1087        0       7       3       27             0 lsof
Mar  7 02:43:11 myhost kernel: [ 3854]     0  3854    26140        5      55       3      230             0 sshd
Mar  7 02:43:11 myhost kernel: [ 3855]   104  3855    15699        0      33       3      202             0 sshd
Mar  7 02:43:11 myhost kernel: Out of memory: Kill process 3841 (memcheck-amd64-) score 11 or sacrifice child
Mar  7 02:43:11 myhost kernel: Killed process 3841 (memcheck-amd64-) total-vm:128024kB, anon-rss:0kB, file-rss:0kB

C'est / proc / meminfo

MemTotal:        1015460 kB
MemFree:          277508 kB
MemAvailable:     322032 kB
Buffers:            8336 kB
Cached:            42208 kB
SwapCached:        46088 kB
Active:            58844 kB
Inactive:         116100 kB
Active(anon):      34784 kB
Inactive(anon):    89620 kB
Active(file):      24060 kB
Inactive(file):    26480 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:       3334140 kB
SwapFree:        3215756 kB
Dirty:                16 kB
Writeback:             0 kB
AnonPages:        121128 kB
Mapped:            15072 kB
Shmem:                 4 kB
Slab:              22668 kB
SReclaimable:       8028 kB
SUnreclaim:        14640 kB
KernelStack:        2016 kB
PageTables:         2532 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     3841868 kB
Committed_AS:     380460 kB
VmallocTotal:   34359738367 kB
VmallocUsed:           0 kB
VmallocChunk:          0 kB
DirectMap4k:       14208 kB
DirectMap2M:     1034240 kB
DirectMap1G:           0 kB

Cela semble être un problème en combinaison de deux facteurs:

• Utilisation d'une machine virtuelle.
• Un bug du noyau possible.

C'est en partie l'une des lignes qui explique pourquoi cela se produit:

7 mars 02:43:11 noyau myhost: memcheck-amd64- oom-killer invoqué: gfp_mask = 0x24002c2, order = 0, oom_score_adj = 0

L'autre ligne est la suivante:

Mar  7 02:43:11 myhost kernel: 0 pages HighMem/MovableOnly

| La première ligne est le masque GFP affecté à l'allocation. Il décrit essentiellement ce que le noyau est autorisé / non autorisé à faire pour satisfaire cette demande. Le masque indique un tas de drapeaux standard. Le dernier bit, «2» indique cependant que l'allocation de mémoire doit provenir de la HighMemzone.

Si vous regardez attentivement la sortie du MOO, vous verrez qu'aucune HighMem/Normalzone n'existe réellement.

Mar  7 02:43:11 myhost kernel: Node 0 DMA: 20*4kB (UM) 17*8kB (UM) 13*16kB (M) 14*32kB (UM) 8*64kB (UM) 4*128kB (M) 4*256kB (M) 0*512kB 1*1024kB (M) 0*2048kB 0*4096kB = 3944kB
Mar  7 02:43:11 myhost kernel: Node 0 DMA32: 934*4kB (UM) 28*8kB (UM) 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 3960kB

HighMem(généralement également appelé Normalx86_64) tend à mapper la mémoire pour les zones en dehors des plages standard de 896 Mo, directement accessibles au noyau sur les systèmes 32 bits. Sur x86_64 HighMem/Normalsemble couvrir toutes les pages au-dessus de la taille 3GiB.

DMA32contient une zone utilisée pour la mémoire qui serait accessible sur les périphériques DMA 32 bits, c'est-à-dire que vous pouvez les adresser avec des pointeurs de 4 octets. Je pense que DMAc'est pour les appareils DMA 16 bits.

D'une manière générale, les systèmes à faible mémoire Normaln'existeraient pas, étant donné que cela DMA32couvre déjà toutes les adresses virtuelles disponibles.

La raison pour laquelle vous OOM tuez est parce qu'il y a une allocation de mémoire pour une HighMemzone avec 0 pages disponibles. Étant donné que le gestionnaire de mémoire insuffisante n'a absolument aucun moyen de satisfaire le fait que cette zone ait des pages à utiliser en échangeant, en tuant d'autres processus ou toute autre astuce, OOM-killer la tue.

Je crois que cela est causé par la montgolfière de la machine hôte au démarrage. Sur les systèmes KVM, vous pouvez définir deux valeurs.

• La mémoire actuelle.
• La mémoire disponible.

La façon dont cela fonctionne est que vous pouvez ajouter de la mémoire à chaud à votre serveur jusqu'à la mémoire disponible. Cependant, votre système reçoit la mémoire actuelle.

Lorsqu'une machine virtuelle KVM démarre, elle commence par l'allocation maximale de mémoire possible (la mémoire disponible). Au cours de la phase de démarrage du système, le KVM récupère progressivement cette mémoire à l'aide de sa bulle, vous laissant à la place le paramètre de mémoire actuel.

C'est ma conviction que c'est ce qui s'est passé ici. Linode vous permet d'étendre la mémoire, vous offrant beaucoup plus au démarrage du système.

Cela signifie qu'il existe une Normal/HighMemzone au début de la durée de vie du système. Lorsque l'hyperviseur la gonfle, la zone normale disparaît à juste titre du gestionnaire de mémoire. Mais, je soupçonne que le drapeau définissant si ladite zone est disponible pour l'attribution n'est pas effacé quand il le devrait. Cela conduit le noyau à tenter d'allouer à partir d'une zone qui n'existe pas.

Pour résoudre ce problème, vous avez deux options.

1. Apportez cela sur les listes de diffusion du noyau pour voir si c'est vraiment un bug, un comportement attendu ou rien à voir avec ce que je dis.

2. Demandez à ce que Linode définisse la «mémoire disponible» sur le système comme la même affectation de 1 Go que la «mémoire actuelle». Ainsi, le système ne monte jamais en ballon et n'obtient jamais de zone normale au démarrage, gardant le drapeau dégagé. Bonne chance pour les faire faire ça!

Vous devriez être en mesure de tester que c'est le cas en configurant votre propre machine virtuelle dans le paramètre KVM disponible pour 6 Go, actuel à 1 Go et en exécutant votre test en utilisant le même noyau pour voir si ce problème que vous voyez ci-dessus se produit. Si tel est le cas, modifiez le paramètre «disponible» pour qu'il soit égal au courant 1 Go et répétez le test.

Je fais un tas de suppositions éclairées ici et je lis un peu entre les lignes pour trouver cette réponse, mais ce que je dis semble correspondre aux faits déjà décrits.

Je suggère de tester mon hypothèse et de nous faire connaître le résultat.

Pour répondre à votre question de titre, utilisez oom_score_adj(noyau> = 2.6.36) ou pour les noyaux antérieurs (> = 2.6.11) oom_adj, voir man proc

/ proc / [pid] / oom_score_adj (depuis Linux 2.6.36) Ce fichier peut être utilisé pour ajuster l'heuristique de méchanceté utilisée pour sélectionner le processus qui sera tué dans des conditions de mémoire insuffisante ...

/ proc / [pid] / oom_adj (depuis Linux 2.6.11) Ce fichier peut être utilisé pour ajuster le score utilisé pour sélectionner le processus à tuer dans une situation de mémoire insuffisante (MOO) ...

Il y a beaucoup plus à lire, mais définir oom_score_adj sur -1000 ou oom_adj sur -17 va réaliser ce que vous voulez.

Le problème est que quelque chose d'autre sera tué. Il serait peut-être préférable de déterminer pourquoi le MOO est invoqué et de traiter cela.

Plusieurs réflexions (à partir de mes commentaires ci-dessus) et des liens vers des lectures intéressantes sur votre situation:

• Je vous recommande de vérifier que 1) vous pouvez adresser plus de 3Gb avec votre noyau et configuration actuels (& cpu) [parce que si 3Gb est une limite pour votre système et os, vous la dépassez]. 2) que vous autorisez l'échange et que le sous-système d'échange est en place et fonctionne. bonne chance (je n'expliquerai pas comment, car cela dépend de vos paramètres et de vos spécificités. Les moteurs de recherche vous aideront). ET que vous ne débordez pas d'une table du noyau (nb de pids? Ou autre chose (certains peuvent être définis au moment de la compilation du noyau).

• Vérifiez que le tout (matériel, ou matériel simulé de VM, etc.) est de 64 bits. (voir par exemple: /ubuntu/313379/i-installed-a-64-bit-os-in-a-32-bit-processor/313381 ). Le cpu et l'hôte OS et le sous-système vm et le système d'exploitation vm doivent tous être activés en 64 bits, sinon vous n'aurez pas de véritable vm 64 bits

• Quelques bonnes lectures:

  • Comment diagnostiquer les causes des processus de destruction des tueurs : sur ce site même. Donne un joli lien, http://linux-mm.org/OOM_Killer , et un autre utilisateur présente l'outil au sommet, qui pourrait aider à diagnostiquer ce qui se passe
  • https://www.kernel.org/doc/gorman/html/understand/understand016.html : 3.12 montre l'arbre de décision pour le MOO (d'une ancienne version, donc ymmv. Lisez la source ^^)
  • https://lwn.net/Articles/317814/ : "Taming the OOM killer" montre, entre autres, comment créer un groupe "invicible" et y mettre votre processus
  • http://eloquence.marxmeier.com/sdb/html/linux_limits.html : affiche quelques limites communes du noyau
  • http://win.tue.nl/~aeb/linux/lk/lk-9.html : est une bonne lecture (espace perdu avec certaines méthodes d'allocation, etc.) même s'il est vraiment daté (et ne s'adresse donc qu'à 32- architectures de bits ...)
  • http://bl0rg.krunch.be/oom-frag.html montre quelques raisons pour lesquelles "le tueur OOM peut être appelé même s'il y a encore beaucoup de mémoire disponible"
  • /programming/17935873/malloc-fails-when-there-is-still-plenty-of-swap-left : donne un moyen de vérifier comment votre système alloue de la mémoire
  • /server//a/724518/146493 : excellente réponse donnant un moyen détaillé de savoir vraiment ce qui s'est passé (mais ... ciblé une question 32 bits, donc ymmv. Encore une lecture et une réponse incroyables, cependant).

• et enfin: http://www.oracle.com/technetwork/articles/servers-storage-dev/oom-killer-1911807.html montre un moyen d'empêcher votre processus d'être ciblé par le tueur oom! ( echo -17 > /proc/PROCESSPID/oom_adj). Cela pourrait être sujet à des changements et pourrait être une mauvaise chose (provoquer d'autres types d'échecs car le système ne peut plus simplement tuer le principal délinquant ...) À utiliser avec prudence. @iain notez que "oom_adj" est pour les noyaux plus anciens et devrait être remplacé par "oom_score_adj" dans les plus récents. Merci, Iain)

à côté de l' oom_score_adjaugmentation mentionnée pour le processus en question (ce qui n'aidera probablement pas beaucoup - il serait moins probable que ce processus soit tué en PREMIER, mais comme il ne s'agit que d'un système de processus gourmand en mémoire, il ne récupérera probablement pas avant d'être finalement tués), voici quelques idées à modifier:

• si vous définissez vm.overcommit_memory=2, ajustez également vm.overcommit_ratioà peut-être 90 (alternativement, définissez vm.overcommit_memory=0- voir les documents de surcharge du noyau )
• augmenter vm.min_free_kbytesafin de garder toujours de la RAM physique libre et ainsi réduire les chances que le MOO ait besoin de tuer quelque chose (mais n'en faites pas trop, car il le fera instantanément).
• passer vm.swappinessà 100 (pour faciliter l' échange de noyau )

Notez que si vous avez trop peu de mémoire pour accomplir la tâche à accomplir, même si vous ne faites pas de MOO, cela peut (ou peut ne pas) devenir EXTRÊMEMENT lent - un travail d'une demi-heure (sur un système avec suffisamment de RAM) peut facilement prendre plusieurs semaines ( lorsque la RAM est remplacée par swap) pour terminer dans les cas extrêmes, ou même bloquer toute la machine virtuelle. C'est particulièrement le cas si le swap se fait sur des disques de rotation classiques (par opposition aux SSD) en raison de lectures / écritures aléatoires massives qui leur coûtent très cher.

J'essaierais d'activer la surcharge et de voir si cela aide. Votre processus semble échouer dans un forkappel, ce qui nécessite autant de mémoire virtuelle que le processus initial. overcommit_memory=2ne rend pas votre processus immunitaire contre OOM killer, il empêche simplement votre processus de le déclencher en allouant trop. D'autres processus peuvent produire des erreurs d'allocation non liées (par exemple, obtenir un bloc de mémoire contigu), qui déclenchent toujours le tueur OOM et éliminent votre processus.

Alternativement (et plus précisément), comme le suggèrent plusieurs commentaires, achetez plus de RAM.

Petite histoire - essayez une autre version du noyau. J'ai un système qui a montré des erreurs OOM avec les noyaux 4.2.0-x et 4.4.0-x, mais pas avec 3.19.0-x.

Longue histoire: (pas trop longtemps!) J'ai un Compaq DC5000 toujours en service ici - actuellement avec 512 Mo de RAM (et une partie de cela, comme 32-128 Mo, étant donnée à la vidéo intégrée ..) Servant principalement NFS, j'ai un moniteur connecté, donc parfois je me connecte (Ubuntu Classic, no Unity.)

Via Ubuntu HWE, j'utilisais le noyau 3.19.x pendant un bon moment; cela finirait par s'échanger comme 200-300 Mo de trucs, mais apparemment, c'était des trucs inutilisés, il n'y aurait aucune activité de swap à devoir l'échanger plus tard pour autant que je sache.

Le noyau 4.2.0-x et maintenant le noyau 4.4.0-x, je peux commencer une écriture NFS volumineuse, seulement 220 Mo dans le swap (c'est-à-dire 1,3 Go gratuit), et cela commencera à tuer des choses par MOO. Je ne dirai pas s'il s'agit d'un bug du noyau ou d'un "problème de réglage" (comme une réserve de 64 Mo qui est normalement bien, mais trop élevée sur un système d'environ 400 Mo?)

Pas de manque de respect envers ceux qui disent que cela se brise en quelque sorte simplement parce qu'il s'attend à utiliser le swap; avec tout le respect que je vous dois, vous vous trompez. Ce ne sera pas rapide, mais j'avais l'habitude de passer de 1 ou 2 Go au swap sur quelques systèmes de 512 Mo à 1 Go. Bien sûr, certains types de logiciels sont un tas de RAM, mais dans mon cas (puisque j'utilise le même logiciel uniquement sur un noyau différent), ce n'est clairement pas le cas.