Linux ne libérant pas de grand cache de disque lorsque la demande de mémoire monte
Courir Ubuntu sur un noyau 2.6.31-302 x86-64. Le problème global est que j'ai la mémoire dans la catégorie "mise en cache" qui continue à monter et ne sera pas libérée ni utilisée même lorsque notre application en a besoin.
Alors voici ce que je sors de la commande 'libre'. Aucun de cela ne regarde hors de l'ordinaire au premier coup d'œil.
# free
total used free shared buffers cached
Mem: 7358492 5750320 1608172 0 7848 1443820
-/+ buffers/cache: 4298652 3059840
Swap: 0 0 0
La première chose que quelqu'un va dire est "Ne t'inquiète pas, Linux gère la mémoire automatiquement." Oui, je sais comment le gestionnaire de mémoire est censé fonctionner; Le problème est que cela ne fait pas la bonne chose. Le "caché" 1,4 Go de 1,4 Go semble être réservé et inutilisable.
Ma connaissance de Linux me dit que 3 gb est "libre"; Mais le comportement du système dit le contraire. Lorsque la mémoire libre de 1,6 Go est utilisée pendant l'utilisation de crête, dès que dès que davantage de mémoire est demandée (et le "gratuit" dans les approches de la première colonne 0), le tueur OMM est invoqué, les processus sont tués et les problèmes commencent à se poser. Même si Le "Gratuit" dans la ligne tampon/cache/cache a toujours environ 1,4 Go 'Gratuit'.
J'ai accordé les valeurs OUM_ADJ sur les processus clés afin que cela ne ramène pas le système à genoux, mais même alors les processus importants seront tués et nous ne voulons jamais atteindre ce point. Surtout quand, théoriquement, 1,4 Go est toujours "libre" si cela n'allume que le cache de disque.
Est-ce que quelqu'un a une idée de ce qui se passe ici? Internet est inondé des questions muettes sur la commande "Free 'GRATUITE" Linux et "Pourquoi n'ai-je pas de mémoire libre" et je ne trouve rien à propos de cette question à cause de cela.
La première chose qui apparaît dans ma tête est que l'échange est éteint. Nous avons une sysadmin qui l'adore; Je suis ouvert aux explications si elles sont sauvegardées. Cela pourrait-il causer des problèmes?
Voici gratuitement après la course echo 3 > /proc/sys/vm/drop_caches:
# free
total used free shared buffers cached
Mem: 7358492 5731688 1626804 0 524 1406000
-/+ buffers/cache: 4325164 3033328
Swap: 0 0 0
Comme vous pouvez le constater, une quantité minuscule de cache est effectivement libérée, mais environ 1,4 Go semble être "bloquée". L'autre problème est que cette valeur semble augmenter avec le temps. Sur un autre serveur 2.0 Go est bloqué.
J'aimerais vraiment cette mémoire ... Toute aide serait la plus appréciée.
Voici cat /proc/meminfo Si cela vaut rien:
# cat /proc/meminfo
MemTotal: 7358492 kB
MemFree: 1472180 kB
Buffers: 5328 kB
Cached: 1435456 kB
SwapCached: 0 kB
Active: 5524644 kB
Inactive: 41380 kB
Active(anon): 5492108 kB
Inactive(anon): 0 kB
Active(file): 32536 kB
Inactive(file): 41380 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 320 kB
Writeback: 0 kB
AnonPages: 4125252 kB
Mapped: 42536 kB
Slab: 29432 kB
SReclaimable: 13872 kB
SUnreclaim: 15560 kB
PageTables: 0 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 3679244 kB
Committed_AS: 7223012 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 7696 kB
VmallocChunk: 34359729675 kB
DirectMap4k: 7340032 kB
DirectMap2M: 0 kB
J'ai découvert la réponse à ma propre question - grâce à l'aide de Womble (soumettre une réponse si vous aimez).
lsof -s Affiche les poignées de fichier en cours d'utilisation et s'avère que plusieurs gigaoctets de fichiers journaux MMAP'D occupent le cache.
La mise en œuvre d'un logrotate devrait résoudre complètement le problème et me permettre de tirer parti de plus de mémoire.
Je vais également réactiver l'échange afin de ne pas avoir de problèmes avec le tueur OMM à l'avenir. Merci.
Apparemment, postgres 'shared_buffers peut apparaître en cached, tout en ne faisant pas vraiment de difficulté ... voir OOM malgré la mémoire disponible (cache)