Intereting Posts

Modifiez un fichier volumineux, puis pouvez annuler les modifications en le faisant (presque) en place Mise à l'échelle de vidéos avec différents filtres de chaque côté Quelle est la commande% u dans toutes les commandes de mes programmes? Comment puis-je sauvegarder un système Ubuntu et le restaurer sur un autre maching avec un matériel complètement différent? Rechercher un conflit de mots clés dans firefox Quelle est la différence entre les répertoires .ssh et .ssh2 Y a-t-il un Windows exe qui ne fait rien? La capture d'écran MS OneNote a cessé de fonctionner Comment restreindre certains sites dans IE? Comment désactiver * les redémarrages automatiques dans Windows 10? Un raccourci pour redimensionner une fenêtre à mi-haut / bas de l'écran? Touche de raccourci pour basculer entre les modes de saisie d'entrée Hangul et Latin avec Windows 7 Korean IME? Comment enregistrer le bureau dans le lecteur multimédia VLC – deuxième écran Excel 2007 transpose / combine plusieurs lignes en une seule fois Maximisation de la vitesse des clients USB 2.0 sur le concentrateur USB 3.0

Fuite de mémoire invisible sur Linux – Ubuntu Server (pas de cache de disque / tampons!)

Sommaire d'août 2015

Veuillez noter que cela se produit toujours. Ceci n'est pas lié à linuxatemyram.com – la mémoire n'est pas utilisée pour le cache de disque / les tampons. C'est ce qu'il ressemble à NewRelic – le système fuit toute la mémoire, utilise tout l'espace de swap et se bloque. Dans cette capture d'écran, j'ai redémarré le serveur avant qu'il ne soit écrasé:

Entrez la description de l'image ici

Il est impossible d'identifier la source de la fuite en utilisant des outils d'espace utilisateur communs. Il y a maintenant une salle de discussion pour discuter de ce problème: http://chat.stackexchange.com/rooms/27309/invisible-memory-leak-on-linux

Le seul moyen de récupérer la mémoire "manquante" semble redémarrer le serveur. Cela a été un problème de longue date reproduit dans Ubuntu Server 14.04, 14.10 et 15.04.

Haut

L'utilisation de la mémoire ne s'affiche pas en haut et ne peut être récupérée même après avoir tué à peu près tous les processus (à l'exception des processus tels que kernel et ssh). Regardez les "Mémo mis en cache", "tampons" et "libres" en haut, ils n'utilisent pas la mémoire, la mémoire utilisée est "manquante" et non récupérable sans redémarrage.

Si vous tentez d'utiliser cette mémoire "manquante", le serveur échangera, ralentira et finira par figer.

root@XanBox:~# top -o +%MEM top - 12:12:13 up 15 days, 20:39, 3 users, load average: 0.00, 0.06, 0.77 Tasks: 126 total, 1 running, 125 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.1 us, 0.2 sy, 0.0 ni, 99.7 id, 0.0 wa, 0.1 hi, 0.0 si, 0.0 st KiB Mem: 2,040,256 total, 1,881,228 used, 159,028 free, 1,348 buffers KiB Swap: 1,999,868 total, 27,436 used, 1,972,432 free. 67,228 cached Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 11502 root 20 0 107692 4252 3240 S 0.0 0.2 0:00.06 sshd: deployer [priv] 11336 root 20 0 107692 4248 3240 S 0.0 0.2 0:00.06 sshd: deployer [priv] 11841 root 20 0 107692 4248 3240 S 0.0 0.2 0:00.06 sshd: deployer [priv] 11301 root 20 0 26772 3436 2688 S 0.7 0.2 0:01.30 /usr/sbin/openvpn --writepid /var/run/openvpn.zanview.com.pid --status /var/run/openvpn.zanview.com.status 10 --cd /etc/openvpn --config /etc/openvpn/z+ 11385 deployer 20 0 19972 2392 1708 S 0.0 0.1 0:00.03 -bash 11553 deployer 20 0 19972 2388 1708 S 0.0 0.1 0:00.03 -bash 11890 deployer 20 0 19972 2388 1708 S 0.0 0.1 0:00.02 -bash 11889 deployer 20 0 108008 2280 944 S 0.0 0.1 0:00.25 sshd: deployer@pts/3 12009 root 20 0 18308 2228 1608 S 0.0 0.1 0:00.09 -su 12114 root 20 0 18308 2192 1564 S 0.0 0.1 0:00.04 -su 12007 root 20 0 67796 2136 1644 S 0.0 0.1 0:00.01 sudo su - 12112 root 20 0 67796 2136 1644 S 0.0 0.1 0:00.01 sudo su - 12008 root 20 0 67376 2016 1528 S 0.0 0.1 0:00.01 su - 12113 root 20 0 67376 2012 1528 S 0.0 0.1 0:00.01 su - 1 root 20 0 33644 1988 764 S 0.0 0.1 2:29.77 /sbin/init 11552 deployer 20 0 107692 1952 936 S 0.0 0.1 0:00.07 sshd: deployer@pts/2 11384 deployer 20 0 107692 1948 936 S 0.0 0.1 0:00.06 sshd: deployer@pts/0 12182 root 20 0 20012 1516 1012 R 0.7 0.1 0:00.08 top -o +%MEM 1152 message+ 20 0 39508 1448 920 S 0.0 0.1 1:40.01 dbus-daemon --system --fork 1791 root 20 0 279832 1312 816 S 0.0 0.1 1:16.18 /usr/lib/policykit-1/polkitd --no-debug 1186 root 20 0 43736 984 796 S 0.0 0.0 1:13.07 /lib/systemd/systemd-logind 1212 syslog 20 0 256228 688 184 S 0.0 0.0 1:41.29 rsyslogd 5077 root 20 0 25324 648 520 S 0.0 0.0 0:34.35 /usr/sbin/hostapd -B -P /var/run/hostapd.pid /etc/hostapd/hostapd.conf 336 root 20 0 19476 512 376 S 0.0 0.0 0:07.40 upstart-udev-bridge --daemon 342 root 20 0 51228 468 344 S 0.0 0.0 0:00.85 /lib/systemd/systemd-udevd --daemon 1097 root 20 0 15276 364 256 S 0.0 0.0 0:06.39 upstart-file-bridge --daemon 4921 root 20 0 61364 364 240 S 0.0 0.0 0:00.05 /usr/sbin/sshd -D 745 root 20 0 15364 252 180 S 0.0 0.0 0:06.51 upstart-socket-bridge --daemon 4947 root 20 0 23656 168 100 S 0.0 0.0 0:14.70 cron 11290 daemon 20 0 19140 164 0 S 0.0 0.0 0:00.00 atd 850 root 20 0 23420 80 16 S 0.0 0.0 0:11.00 rpcbind 872 statd 20 0 21544 8 4 S 0.0 0.0 0:00.00 rpc.statd -L 4880 root 20 0 14540 4 0 S 0.0 0.0 0:00.00 /sbin/getty -8 38400 tty4 4883 root 20 0 14540 4 0 S 0.0 0.0 0:00.00 /sbin/getty -8 38400 tty5 4890 root 20 0 14540 4 0 S 0.0 0.0 0:00.00 /sbin/getty -8 38400 tty2 4891 root 20 0 14540 4 0 S 0.0 0.0 0:00.00 /sbin/getty -8 38400 tty3 4894 root 20 0 14540 4 0 S 0.0 0.0 0:00.00 /sbin/getty -8 38400 tty6 4919 root 20 0 4368 4 0 S 0.0 0.0 0:00.00 acpid -c /etc/acpi/events -s /var/run/acpid.socket 5224 root 20 0 24048 4 0 S 0.0 0.0 0:00.00 /usr/sbin/rpc.mountd --manage-gids 6160 root 20 0 14540 4 0 S 0.0 0.0 0:00.00 /sbin/getty -8 38400 tty1 2 root 20 0 0 0 0 S 0.0 0.0 0:03.44 [kthreadd] 3 root 20 0 0 0 0 S 0.0 0.0 1:04.63 [ksoftirqd/0] 5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 [kworker/0:0H] 7 root 20 0 0 0 0 S 0.0 0.0 16:03.32 [rcu_sched] 8 root 20 0 0 0 0 S 0.0 0.0 4:08.79 [rcuos/0] 9 root 20 0 0 0 0 S 0.0 0.0 4:10.42 [rcuos/1] 10 root 20 0 0 0 0 S 0.0 0.0 4:30.71 [rcuos/2]

Matériel

J'ai observé cela sur 3 serveurs sur environ 100 jusqu'à présent (bien que d'autres soient affectés). L'un est un Intel Atom D525 @ 1.8ghz et les 2 autres sont Core2Duo E4600 et Q6600. L'un utilise un contrôleur Gigabit Ethernet JMC250 JMicron Technology Corp. Les autres utilisent Qualcomm Atheros Attansic L1 Gigabit Ethernet (rev b0).

J'ai couru lshw sur les serveurs de problèmes ainsi que sur un exemple de serveur OK. Serveurs à problèmes: http://pastie.org/10370534 http://pastie.org/10370537 et http://pastie.org/10370541 – OK Serveur: http://pastie.org/10370544

Application

Il s'agit d'une application entièrement sans tête. Aucun moniteur n'est connecté et, en fait, aucun serveur XS n'a été installé. Cela devrait exclure les conducteurs / problèmes graphiques.

Le serveur est utilisé pour proxy et analyse de la vidéo RTSP en utilisant live555ProxyServer, ffmpeg et openCV. Ces serveurs réduisent beaucoup de trafic car il s'agit d'une application CCTV: http://pastie.org/9558324

J'ai essayé à la fois les très anciennes et les dernières versions de live555, ffmpeg et openCV sans changement. J'ai également essayé d'utiliser opencv à travers les modules python2 et python3, pas de changement.

Le même logiciel / configuration exacte a été chargé sur près de 100 serveurs, jusqu'à ce jour 3 sont confirmés dans la mémoire de fuite. Les serveurs se propagent lentement et furtivement autour de xMB (un fuites de 8 Mo, l'un est plus lent, l'un est plus rapide) par heure jusqu'à ce que tous les RAM aient disparu, les serveurs commencent à échanger fortement, ralentissent et nécessitent un redémarrage.

Meminfo

Encore une fois, vous pouvez voir les Cached et Buffers ne pas utiliser beaucoup de mémoire du tout. HugePages est également désactivé, donc ce n'est pas le coupable.

 root@XanBox:~# cat /proc/meminfo MemTotal: 2,040,256 kB MemFree: 159,004 kB Buffers: 1,348 kB Cached: 67,228 kB SwapCached: 9,940 kB Active: 10,788 kB Inactive: 81,120 kB Active(anon): 1,900 kB Inactive(anon): 21,512 kB Active(file): 8,888 kB Inactive(file): 59,608 kB Unevictable: 0 kB Mlocked: 0 kB SwapTotal: 1,999,868 kB SwapFree: 1,972,432 kB Dirty: 0 kB Writeback: 0 kB AnonPages: 14,496 kB Mapped: 8,160 kB Shmem: 80 kB Slab: 33,472 kB SReclaimable: 17,660 kB SUnreclaim: 15,812 kB KernelStack: 1,064 kB PageTables: 3,992 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 3,019,996 kB Committed_AS: 94,520 kB VmallocTotal: 34,359,738,367 kB VmallocUsed: 535,936 kB VmallocChunk: 34,359,147,772 kB HardwareCorrupted: 0 kB AnonHugePages: 0 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2,048 kB DirectMap4k: 62,144 kB DirectMap2M: 2,025,472 kB

Sortie gratuite

Free affiche les éléments suivants (note en cache et les tampons sont à la fois bas, donc ce n'est pas un cache de disque ou des tampons!) – la mémoire n'est pas récupérable sans redémarrage:

 root@XanBox:~# free -m total used free shared buffers cached Mem: 1,992 1,838 153 0 1 66

Si nous soustrayons / ajoutons les buffers / cache à Used and Free, nous voyons:

1,772MB Really Used (- Buffers / Cache) = 1,838MB utilisé – 1 Mo de tampons – 66 Mo de cache
220MB vraiment gratuit (+ Buffers / Cache) = 154MB gratuit + 1 Mo de tampons + 66 Mo de cache

Exactement comme nous nous attendons:

 -/+ buffers/cache: 1,772 220

Ainsi, environ 1,7 Go n'est pas utilisé par l'espace utilisateur et en fait utilisé par le noyau car le système utilise en fait 53,7 Mo (voir la sortie de PS Mem inférieur).

Je suis surpris par la quantité de commentaires qui pensent que 1.7GB est utilisé pour la mise en cache / les tampons – ceci est fondamentalement mal interprété la sortie! – cette ligne signifie mémoire utilisée, à l' exception des buffers / cache , voir linuxatemyram.com pour plus de détails.

Sortie PS

Voici une liste complète des processus en cours triés par mémoire:

 # ps -e -o pid,vsz,comm= | sort -n -k 2 2 0 kthreadd 3 0 ksoftirqd/0 5 0 kworker/0:0H 7 0 rcu_sched 8 0 rcuos/0 9 0 rcuos/1 10 0 rcuos/2 11 0 rcuos/3 12 0 rcu_bh 13 0 rcuob/0 14 0 rcuob/1 15 0 rcuob/2 16 0 rcuob/3 17 0 migration/0 18 0 watchdog/0 19 0 watchdog/1 20 0 migration/1 21 0 ksoftirqd/1 23 0 kworker/1:0H 24 0 watchdog/2 25 0 migration/2 26 0 ksoftirqd/2 28 0 kworker/2:0H 29 0 watchdog/3 30 0 migration/3 31 0 ksoftirqd/3 32 0 kworker/3:0 33 0 kworker/3:0H 34 0 khelper 35 0 kdevtmpfs 36 0 netns 37 0 writeback 38 0 kintegrityd 39 0 bioset 41 0 kblockd 42 0 ata_sff 43 0 khubd 44 0 md 45 0 devfreq_wq 46 0 kworker/0:1 47 0 kworker/1:1 48 0 kworker/2:1 50 0 khungtaskd 51 0 kswapd0 52 0 ksmd 53 0 khugepaged 54 0 fsnotify_mark 55 0 ecryptfs-kthrea 56 0 crypto 68 0 kthrotld 70 0 scsi_eh_0 71 0 scsi_eh_1 92 0 deferwq 93 0 charger_manager 94 0 kworker/1:2 95 0 kworker/3:2 149 0 kpsmoused 155 0 jbd2/sda1-8 156 0 ext4-rsv-conver 316 0 jbd2/sda3-8 317 0 ext4-rsv-conver 565 0 kmemstick 770 0 cfg80211 818 0 hd-audio0 853 0 kworker/2:2 953 0 rpciod PID VSZ 1714 0 kauditd 11335 0 kworker/0:2 12202 0 kworker/u8:2 20228 0 kworker/u8:0 25529 0 kworker/u9:1 28305 0 kworker/u9:2 29822 0 lockd 4919 4368 acpid 4074 7136 ps 6681 10232 dhclient 4880 14540 getty 4883 14540 getty 4890 14540 getty 4891 14540 getty 4894 14540 getty 6160 14540 getty 14486 15260 upstart-socket- 14489 15276 upstart-file-br 12009 18308 bash 12114 18308 bash 12289 18308 bash 4075 19008 sort 11290 19140 atd 14483 19476 upstart-udev-br 11385 19972 bash 11553 19972 bash 11890 19972 bash 29503 21544 rpc.statd 2847 23384 htop 850 23420 rpcbind 29588 23480 rpc.idmapd 4947 23656 cron 29833 24048 rpc.mountd 5077 25324 hostapd 11301 26912 openvpn 1 37356 init 1152 39508 dbus-daemon 14673 43452 systemd-logind 14450 51204 systemd-udevd 4921 61364 sshd 12008 67376 su 12113 67376 su 12288 67376 su 12007 67796 sudo 12112 67796 sudo 12287 67796 sudo 11336 107692 sshd 11384 107692 sshd 11502 107692 sshd 11841 107692 sshd 11552 108008 sshd 11889 108008 sshd 1212 256228 rsyslogd 1791 279832 polkitd 4064 335684 whoopsie

Voici une liste complète de tous les processus en cours d'exécution:

 root@XanBox:~# ps aux USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.0 33644 1988 ? Ss Jul21 2:29 /sbin/init root 2 0.0 0.0 0 0 ? S Jul21 0:03 [kthreadd] root 3 0.0 0.0 0 0 ? S Jul21 1:04 [ksoftirqd/0] root 5 0.0 0.0 0 0 ? S< Jul21 0:00 [kworker/0:0H] root 7 0.0 0.0 0 0 ? S Jul21 16:03 [rcu_sched] root 8 0.0 0.0 0 0 ? S Jul21 4:08 [rcuos/0] root 9 0.0 0.0 0 0 ? S Jul21 4:10 [rcuos/1] root 10 0.0 0.0 0 0 ? S Jul21 4:30 [rcuos/2] root 11 0.0 0.0 0 0 ? S Jul21 4:28 [rcuos/3] root 12 0.0 0.0 0 0 ? S Jul21 0:00 [rcu_bh] root 13 0.0 0.0 0 0 ? S Jul21 0:00 [rcuob/0] root 14 0.0 0.0 0 0 ? S Jul21 0:00 [rcuob/1] root 15 0.0 0.0 0 0 ? S Jul21 0:00 [rcuob/2] root 16 0.0 0.0 0 0 ? S Jul21 0:00 [rcuob/3] root 17 0.0 0.0 0 0 ? S Jul21 0:13 [migration/0] root 18 0.0 0.0 0 0 ? S Jul21 0:08 [watchdog/0] root 19 0.0 0.0 0 0 ? S Jul21 0:07 [watchdog/1] root 20 0.0 0.0 0 0 ? S Jul21 0:13 [migration/1] root 21 0.0 0.0 0 0 ? S Jul21 1:03 [ksoftirqd/1] root 23 0.0 0.0 0 0 ? S< Jul21 0:00 [kworker/1:0H] root 24 0.0 0.0 0 0 ? S Jul21 0:07 [watchdog/2] root 25 0.0 0.0 0 0 ? S Jul21 0:23 [migration/2] root 26 0.0 0.0 0 0 ? S Jul21 1:01 [ksoftirqd/2] root 28 0.0 0.0 0 0 ? S< Jul21 0:00 [kworker/2:0H] root 29 0.0 0.0 0 0 ? S Jul21 0:07 [watchdog/3] root 30 0.0 0.0 0 0 ? S Jul21 0:23 [migration/3] root 31 0.0 0.0 0 0 ? S Jul21 1:03 [ksoftirqd/3] root 32 0.0 0.0 0 0 ? S Jul21 0:00 [kworker/3:0] root 33 0.0 0.0 0 0 ? S< Jul21 0:00 [kworker/3:0H] root 34 0.0 0.0 0 0 ? S< Jul21 0:00 [khelper] root 35 0.0 0.0 0 0 ? S Jul21 0:00 [kdevtmpfs] root 36 0.0 0.0 0 0 ? S< Jul21 0:00 [netns] root 37 0.0 0.0 0 0 ? S< Jul21 0:00 [writeback] root 38 0.0 0.0 0 0 ? S< Jul21 0:00 [kintegrityd] root 39 0.0 0.0 0 0 ? S< Jul21 0:00 [bioset] root 41 0.0 0.0 0 0 ? S< Jul21 0:00 [kblockd] root 42 0.0 0.0 0 0 ? S< Jul21 0:00 [ata_sff] root 43 0.0 0.0 0 0 ? S Jul21 0:00 [khubd] root 44 0.0 0.0 0 0 ? S< Jul21 0:00 [md] root 45 0.0 0.0 0 0 ? S< Jul21 0:00 [devfreq_wq] root 46 0.0 0.0 0 0 ? S Jul21 18:51 [kworker/0:1] root 47 0.0 0.0 0 0 ? S Jul21 0:00 [kworker/1:1] root 48 0.0 0.0 0 0 ? S Jul21 1:14 [kworker/2:1] root 50 0.0 0.0 0 0 ? S Jul21 0:01 [khungtaskd] root 51 0.4 0.0 0 0 ? S Jul21 95:51 [kswapd0] root 52 0.0 0.0 0 0 ? SN Jul21 0:00 [ksmd] root 53 0.0 0.0 0 0 ? SN Jul21 0:28 [khugepaged] root 54 0.0 0.0 0 0 ? S Jul21 0:00 [fsnotify_mark] root 55 0.0 0.0 0 0 ? S Jul21 0:00 [ecryptfs-kthrea] root 56 0.0 0.0 0 0 ? S< Jul21 0:00 [crypto] root 68 0.0 0.0 0 0 ? S< Jul21 0:00 [kthrotld] root 70 0.0 0.0 0 0 ? S Jul21 0:00 [scsi_eh_0] root 71 0.0 0.0 0 0 ? S Jul21 0:00 [scsi_eh_1] root 92 0.0 0.0 0 0 ? S< Jul21 0:00 [deferwq] root 93 0.0 0.0 0 0 ? S< Jul21 0:00 [charger_manager] root 94 0.0 0.0 0 0 ? S Jul21 1:05 [kworker/1:2] root 95 0.0 0.0 0 0 ? S Jul21 1:08 [kworker/3:2] root 149 0.0 0.0 0 0 ? S< Jul21 0:00 [kpsmoused] root 155 0.0 0.0 0 0 ? S Jul21 3:39 [jbd2/sda1-8] root 156 0.0 0.0 0 0 ? S< Jul21 0:00 [ext4-rsv-conver] root 316 0.0 0.0 0 0 ? S Jul21 1:28 [jbd2/sda3-8] root 317 0.0 0.0 0 0 ? S< Jul21 0:00 [ext4-rsv-conver] root 336 0.0 0.0 19476 512 ? S Jul21 0:07 upstart-udev-bridge --daemon root 342 0.0 0.0 51228 468 ? Ss Jul21 0:00 /lib/systemd/systemd-udevd --daemon root 565 0.0 0.0 0 0 ? S< Jul21 0:00 [kmemstick] root 745 0.0 0.0 15364 252 ? S Jul21 0:06 upstart-socket-bridge --daemon root 770 0.0 0.0 0 0 ? S< Jul21 0:00 [cfg80211] root 818 0.0 0.0 0 0 ? S< Jul21 0:00 [hd-audio0] root 850 0.0 0.0 23420 80 ? Ss Jul21 0:11 rpcbind root 853 0.0 0.0 0 0 ? S Jul21 0:00 [kworker/2:2] statd 872 0.0 0.0 21544 8 ? Ss Jul21 0:00 rpc.statd -L root 953 0.0 0.0 0 0 ? S< Jul21 0:00 [rpciod] root 1097 0.0 0.0 15276 364 ? S Jul21 0:06 upstart-file-bridge --daemon message+ 1152 0.0 0.0 39508 1448 ? Ss Jul21 1:40 dbus-daemon --system --fork root 1157 0.0 0.0 23480 0 ? Ss Jul21 0:00 rpc.idmapd root 1186 0.0 0.0 43736 984 ? Ss Jul21 1:13 /lib/systemd/systemd-logind syslog 1212 0.0 0.0 256228 688 ? Ssl Jul21 1:41 rsyslogd root 1714 0.0 0.0 0 0 ? S Jul21 0:00 [kauditd] root 1791 0.0 0.0 279832 1312 ? Sl Jul21 1:16 /usr/lib/policykit-1/polkitd --no-debug root 4880 0.0 0.0 14540 4 tty4 Ss+ Jul21 0:00 /sbin/getty -8 38400 tty4 root 4883 0.0 0.0 14540 4 tty5 Ss+ Jul21 0:00 /sbin/getty -8 38400 tty5 root 4890 0.0 0.0 14540 4 tty2 Ss+ Jul21 0:00 /sbin/getty -8 38400 tty2 root 4891 0.0 0.0 14540 4 tty3 Ss+ Jul21 0:00 /sbin/getty -8 38400 tty3 root 4894 0.0 0.0 14540 4 tty6 Ss+ Jul21 0:00 /sbin/getty -8 38400 tty6 root 4919 0.0 0.0 4368 4 ? Ss Jul21 0:00 acpid -c /etc/acpi/events -s /var/run/acpid.socket root 4921 0.0 0.0 61364 364 ? Ss Jul21 0:00 /usr/sbin/sshd -D root 4947 0.0 0.0 23656 168 ? Ss Jul21 0:14 cron root 5077 0.0 0.0 25324 648 ? Ss Jul21 0:34 /usr/sbin/hostapd -B -P /var/run/hostapd.pid /etc/hostapd/hostapd.conf root 5192 0.0 0.0 0 0 ? S Jul21 0:00 [lockd] root 5224 0.0 0.0 24048 4 ? Ss Jul21 0:00 /usr/sbin/rpc.mountd --manage-gids root 6160 0.0 0.0 14540 4 tty1 Ss+ Jul21 0:00 /sbin/getty -8 38400 tty1 root 6681 0.0 0.0 10232 0 ? Ss 11:07 0:00 dhclient -1 -v -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases eth0 root 9452 0.0 0.0 0 0 ? S 11:28 0:00 [kworker/u8:1] root 9943 0.0 0.0 0 0 ? S 11:42 0:00 [kworker/u8:0] daemon 11290 0.0 0.0 19140 164 ? Ss 11:59 0:00 atd root 11301 0.2 0.1 26772 3436 ? Ss 12:00 0:01 /usr/sbin/openvpn --writepid /var/run/openvpn.zanview.com.pid --status /var/run/openvpn.zanview.com.status 10 --cd /etc/openvpn --config /etc/openvpn/zanvie root 11335 0.0 0.0 0 0 ? S 12:01 0:00 [kworker/0:2] root 11336 0.0 0.2 107692 4248 ? Ss 12:01 0:00 sshd: deployer [priv] deployer 11384 0.0 0.0 107692 1948 ? S 12:01 0:00 sshd: deployer@pts/0 deployer 11385 0.0 0.1 19972 2392 pts/0 Ss+ 12:01 0:00 -bash root 11502 0.0 0.2 107692 4252 ? Ss 12:01 0:00 sshd: deployer [priv] deployer 11552 0.0 0.0 107692 1952 ? S 12:01 0:00 sshd: deployer@pts/2 deployer 11553 0.0 0.1 19972 2388 pts/2 Ss 12:01 0:00 -bash root 11841 0.0 0.2 107692 4248 ? Ss 12:02 0:00 sshd: deployer [priv] deployer 11889 0.0 0.1 108008 2280 ? S 12:02 0:00 sshd: deployer@pts/3 deployer 11890 0.0 0.1 19972 2388 pts/3 Ss 12:02 0:00 -bash root 12007 0.0 0.1 67796 2136 pts/3 S 12:02 0:00 sudo su - root 12008 0.0 0.0 67376 2016 pts/3 S 12:02 0:00 su - root 12009 0.0 0.1 18308 2228 pts/3 S+ 12:02 0:00 -su root 12112 0.0 0.1 67796 2136 pts/2 S 12:08 0:00 sudo su - root 12113 0.0 0.0 67376 2012 pts/2 S 12:08 0:00 su - root 12114 0.0 0.1 18308 2192 pts/2 S 12:08 0:00 -su root 12180 0.0 0.0 15568 1160 pts/2 R+ 12:09 0:00 ps aux root 25529 0.0 0.0 0 0 ? S< Jul28 0:09 [kworker/u9:1] root 28305 0.0 0.0 0 0 ? S< Aug05 0:00 [kworker/u9:2]

Sortie PS Mem

J'ai également essayé le ps_mem.py à partir de https://github.com/pixelb/ps_mem

 root@XanBox:~/ps_mem# python ps_mem.py Private + Shared = RAM used Program 144.0 KiB + 9.5 KiB = 153.5 KiB acpid 172.0 KiB + 29.5 KiB = 201.5 KiB atd 248.0 KiB + 35.0 KiB = 283.0 KiB cron 272.0 KiB + 84.0 KiB = 356.0 KiB upstart-file-bridge 276.0 KiB + 84.5 KiB = 360.5 KiB upstart-socket-bridge 280.0 KiB + 102.5 KiB = 382.5 KiB upstart-udev-bridge 332.0 KiB + 54.5 KiB = 386.5 KiB rpc.idmapd 368.0 KiB + 91.5 KiB = 459.5 KiB rpcbind 388.0 KiB + 251.5 KiB = 639.5 KiB systemd-logind 668.0 KiB + 43.5 KiB = 711.5 KiB hostapd 576.0 KiB + 157.5 KiB = 733.5 KiB systemd-udevd 676.0 KiB + 65.5 KiB = 741.5 KiB rpc.mountd 604.0 KiB + 163.0 KiB = 767.0 KiB rpc.statd 908.0 KiB + 62.5 KiB = 970.5 KiB dbus-daemon [updated] 932.0 KiB + 117.0 KiB = 1.0 MiB getty [updated] (6) 1.0 MiB + 69.5 KiB = 1.1 MiB openvpn 1.0 MiB + 137.0 KiB = 1.2 MiB polkitd 1.5 MiB + 202.0 KiB = 1.7 MiB htop 1.4 MiB + 306.5 KiB = 1.7 MiB whoopsie 1.4 MiB + 279.0 KiB = 1.7 MiB su (3) 1.5 MiB + 268.5 KiB = 1.8 MiB sudo (3) 2.2 MiB + 11.5 KiB = 2.3 MiB dhclient 3.9 MiB + 741.0 KiB = 4.6 MiB bash (6) 5.3 MiB + 254.5 KiB = 5.5 MiB init 2.7 MiB + 3.3 MiB = 6.1 MiB sshd (7) 18.1 MiB + 56.5 KiB = 18.2 MiB rsyslogd --------------------------------- 53.7 MiB =================================

Sortie en plaques

J'ai également essayé de poser:

 root@XanBox:~# slabtop -sc Active / Total Objects (% used) : 131306 / 137558 (95.5%) Active / Total Slabs (% used) : 3888 / 3888 (100.0%) Active / Total Caches (% used) : 63 / 105 (60.0%) Active / Total Size (% used) : 27419.31K / 29580.53K (92.7%) Minimum / Average / Maximum Object : 0.01K / 0.21K / 8.00K OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME 8288 7975 96% 0.57K 296 28 4736K inode_cache 14259 12858 90% 0.19K 679 21 2716K dentry 2384 1943 81% 0.96K 149 16 2384K ext4_inode_cache 20916 20494 97% 0.11K 581 36 2324K sysfs_dir_cache 624 554 88% 2.00K 39 16 1248K kmalloc-2048 195 176 90% 5.98K 39 5 1248K task_struct 6447 6387 99% 0.19K 307 21 1228K kmalloc-192 2128 1207 56% 0.55K 76 28 1216K radix_tree_node 768 761 99% 1.00K 48 16 768K kmalloc-1024 176 155 88% 4.00K 22 8 704K kmalloc-4096 1100 1100 100% 0.63K 44 25 704K proc_inode_cache 1008 1008 100% 0.66K 42 24 672K shmem_inode_cache 2640 2262 85% 0.25K 165 16 660K kmalloc-256 300 300 100% 2.06K 20 15 640K sighand_cache 5967 5967 100% 0.10K 153 39 612K buffer_head 1152 1053 91% 0.50K 72 16 576K kmalloc-512 3810 3810 100% 0.13K 127 30 508K ext4_allocation_context 60 60 100% 8.00K 15 4 480K kmalloc-8192 225 225 100% 2.06K 15 15 480K idr_layer_cache 7616 7324 96% 0.06K 119 64 476K kmalloc-64 700 700 100% 0.62K 28 25 448K sock_inode_cache 252 252 100% 1.75K 14 18 448K TCP 8925 8544 95% 0.05K 105 85 420K shared_policy_node 3072 2351 76% 0.12K 96 32 384K kmalloc-128 360 360 100% 1.06K 12 30 384K signal_cache 432 337 78% 0.88K 24 18 384K mm_struct

Autre

J'ai également essayé de scanner un rootkit avec rkhunter – il n'a rien trouvé. Et j'ai essayé de synchroniser et de supprimer le cache avec:

 sync; sync; sync; echo 3 > /proc/sys/vm/drop_caches

Cela n'a pas non plus changé.

J'ai également essayé de forcer le swap ou le désactiver avec:

 sudo sysctl -w vm.swappiness=100 sudo swapoff /dev/sda2

J'ai également essayé d'utiliser htop et de trier par mémoire et il ne montre pas où la mémoire va non plus. La version du noyau est Linux 3.13.0-40-generic # 69-Ubuntu SMP.

Sortie Dmesg: http://pastie.org/9558255 sortie smem: http://pastie.org/9558290

Conclusion

Que se passe-t-il? – Où se passe la mémoire? – Comment savoir?

Ma conclusion est que c'est une fuite de mémoire du noyau quelque part dans le noyau de Linux, c'est pourquoi aucun des outils de l'espace utilisateur ne peut montrer où la mémoire est vidée. Peut-être est-il lié à cette question: https://serverfault.com/questions/670423/linux-memory-usage-higher-than-sum-of-processes

J'ai mis à niveau la version du noyau de 3.13 à 3.19 et cela semble que la fuite de la mémoire s'est arrêtée! – Je reviendrai si je vois encore une fuite.

Il serait toujours utile d'avoir une manière facile / plus facile de voir la quantité de mémoire utilisée pour différentes parties du noyau Linux. C'est encore un mystère ce qui causait la fuite en 3.13.

Récit

Je peux reproduire votre problème en utilisant ZFS sous Linux .

Voici un serveur appelé node51 avec 20GB de RAM. J'ai marqué 16GiB de RAM pour être attribuable au cache de remplacement adaptatif ZFS (ARC) :

 root@node51 [~]# echo 17179869184 > /sys/module/zfs/parameters/zfs_arc_max root@node51 [~]# grep c_max /proc/spl/kstat/zfs/arcstats c_max 4 17179869184

Ensuite, j'ai lu un fichier 45GiB à l'aide de Pipe Viewer dans mon ZFS pool zeltik pour compléter l'ARC:

 root@node51 [~]# pv /zeltik/backup-backups/2014.04.11.squashfs > /dev/zero 45GB 0:01:20 [ 575MB/s] [==================================>] 100%

Maintenant, regardez la mémoire libre:

 root@node51 [~]# free -m total used free shared buffers cached Mem: 20013 19810 203 1 51 69 -/+ buffers/cache: 19688 324 Swap: 7557 0 7556

Regardez!

51MiB dans les tampons
69MiB dans le cache
120MiB dans les deux
19688MiB de RAM en cours d'utilisation, y compris les tampons et le cache
19568MiB de RAM en cours d'utilisation, à l'exception des tampons et du cache

Le script Python auquel vous parlez rapporte que les applications utilisent uniquement une petite quantité de RAM:

 root@node51 [~]# python ps_mem.py Private + Shared = RAM used Program 148.0 KiB + 54.0 KiB = 202.0 KiB acpid 176.0 KiB + 47.0 KiB = 223.0 KiB swapspace 184.0 KiB + 51.0 KiB = 235.0 KiB atd 220.0 KiB + 57.0 KiB = 277.0 KiB rpc.idmapd 304.0 KiB + 62.0 KiB = 366.0 KiB irqbalance 312.0 KiB + 64.0 KiB = 376.0 KiB sftp-server 308.0 KiB + 89.0 KiB = 397.0 KiB rpcbind 300.0 KiB + 104.5 KiB = 404.5 KiB cron 368.0 KiB + 99.0 KiB = 467.0 KiB upstart-socket-bridge 560.0 KiB + 180.0 KiB = 740.0 KiB systemd-logind 724.0 KiB + 93.0 KiB = 817.0 KiB dbus-daemon 720.0 KiB + 136.0 KiB = 856.0 KiB systemd-udevd 912.0 KiB + 118.5 KiB = 1.0 MiB upstart-udev-bridge 920.0 KiB + 180.0 KiB = 1.1 MiB rpc.statd (2) 1.0 MiB + 129.5 KiB = 1.1 MiB screen 1.1 MiB + 84.5 KiB = 1.2 MiB upstart-file-bridge 960.0 KiB + 452.0 KiB = 1.4 MiB getty (6) 1.6 MiB + 143.0 KiB = 1.7 MiB init 5.1 MiB + 1.5 MiB = 6.5 MiB bash (3) 5.7 MiB + 5.2 MiB = 10.9 MiB sshd (8) 11.7 MiB + 322.0 KiB = 12.0 MiB glusterd 27.3 MiB + 99.0 KiB = 27.4 MiB rsyslogd 67.4 MiB + 453.0 KiB = 67.8 MiB glusterfsd (2) --------------------------------- 137.4 MiB =================================

19568MiB - 137.4MiB ≈ 19431MiB de RAM non comptabilisée

Explication

Le 120MiB de buffers et de cache utilisé que vous avez vu dans l'histoire ci-dessus explique le comportement efficace du noyau des données de mise en cache envoyées ou reçues à partir d'un périphérique externe.

La première ligne, intitulée Mem , affiche l'utilisation de la mémoire physique, y compris la quantité de mémoire attribuée aux tampons et aux caches. Une mémoire tampon, également appelée mémoire tampon , est généralement définie comme une partie de la mémoire qui est mise de côté comme lieu de détention temporaire pour les données envoyées ou reçues à partir d'un périphérique externe tel qu'un disque dur, un clavier, une imprimante ou un réseau.

La deuxième ligne de données, qui commence par – / + buffers / cache , montre la quantité de mémoire physique actuellement consacrée au cache du buffer système. Ceci est particulièrement significatif en ce qui concerne les programmes d'application, car toutes les données accessibles à partir des fichiers sur le système effectués par l'utilisation des appels système read () et write () passent par ce cache. Ce cache peut accélérer considérablement l'accès aux données en réduisant ou en éliminant le besoin de lire ou d'écrire sur le disque dur ou sur un autre disque.

^{_{Source: http://www.linfo.org/free.html}}

Maintenant, comment 19431MiB -nous le 19431MiB manquant?

Dans la sortie free -m ci-dessus, le 19688MiB " utilisé " dans " – / + buffers / cache " provient de cette formule:

 (kb_main_used) - (buffers_plus_cached) = (kb_main_total - kb_main_free) - (kb_main_buffers + kb_main_cached) kb_main_total: MemTotal from /proc/meminfo kb_main_free: MemFree from /proc/meminfo kb_main_buffers: Buffers from /proc/meminfo kb_main_cached: Cached from /proc/meminfo

^{_{Source: procps / free.c et procps / proc / sysinfo.c}}

(Si vous faites les chiffres en fonction de ma sortie free -m , vous remarquerez que 2MiB ne sont pas pris en compte, mais en raison des erreurs d'arrondissement introduites par ce code: #define S(X) ( ((unsigned long long)(X) << 10) >> shift) )

Les nombres ne s'ajoutent pas dans /proc/meminfo , soit (je n'ai pas enregistré /proc/meminfo lorsque j'ai fonctionné free -m , mais on peut voir à partir de votre question que /proc/meminfo ne montre pas où le manque La RAM est), donc nous pouvons conclure de ce qui précède que /proc/meminfo ne raconte pas toute l'histoire.

Dans mes conditions de test, je sais comme un contrôle que ZFS sur Linux est responsable de l'utilisation élevée de RAM. J'ai dit à son ARC qu'il pouvait utiliser jusqu'à 16GiB de la RAM du serveur.

ZFS sur Linux n'est pas un processus. C'est un module kernel.

À partir de ce que j'ai trouvé jusqu'ici, l'utilisation de RAM d'un module noyau ne se manifestera pas à l'aide d'outils d'information de processus car le module n'est pas un processus.

Dépannage

Malheureusement, je ne connais pas assez de Linux pour vous offrir un moyen de créer une liste de la quantité de composants RAM non process (comme le noyau et ses modules) utilisent.

À ce stade, nous pouvons spéculer, deviner et vérifier.

Vous avez fourni une sortie dmesg . Des modules de noyau bien conçus enregistrent certains de leurs détails sur dmesg .

Après avoir parcouru le dmesg , un élément s'est distingué pour moi: FS-Cache

FS-Cache fait partie du module kernel cachefiles et se rapporte aux cachefilesd du package sur Debian et Red Hat Enterprise Linux.

Il y a quelque temps, vous avez configuré FS-Cache sur un disque RAM pour réduire l'impact des E / S réseau car votre serveur analyse les données vidéo.

Essayez de désactiver tous les modules de noyés suspects qui pourraient consommer de la RAM. Ils peuvent probablement être désactivés avec une blacklist dans /etc/modprobe.d/ , suivie d'une sudo update-initramfs -u (les commandes et les emplacements peuvent varier selon la distribution Linux).

Conclusion

Une fuite de mémoire gagne 8MB/hr de votre RAM et ne libère pas la RAM, apparemment, peu importe ce que vous faites. Je n'ai pas été en mesure de déterminer la source de votre fuite de mémoire en fonction des informations que vous avez fournies, et je n'ai pas non plus été en mesure de trouver une solution pour trouver cette fuite de mémoire.

Quelqu'un qui a plus d'expérience avec Linux que je devrais fournir des informations sur la façon dont nous pouvons déterminer où l'utilisation de la RAM autre fonctionne.

J'ai commencé une générosité sur cette question pour voir si nous pouvons obtenir une meilleure réponse que «spéculer, deviner et vérifier».

Modifiez -vous le Swapiness de votre Kernel manualy ou désactivez-le?

Vous pouvez voir ce que vous avez en ce moment

 cat /proc/sys/vm/swappiness

Vous pourriez essayer de forcer votre noyau à échanger agressivement avec

 sudo sysctl -w vm.swappiness=100

Si cette diminution, vos problèmes trouvent une bonne valeur comprise entre 1 et 100, répondant à vos besoins.

Vous n'êtes pas tout à fait correct, oui, votre commande free -m affiche 220 Mo, mais elle montre également que 1771 Mo sont utilisés comme tampons. Buffers et cache est la mémoire utilisée par le noyau pour optimiser l'accès aux données d'accès lent, généralement des disques. Donc, vous devriez considérer toute la mémoire marquée comme des tampons comme mémoire libre car le noyau peut le récupérer chaque fois qu'il le faut.

Voir: https://serverfault.com/questions/23433/in-linux-what-is-the-difference-between-buffers-and-cache-reported-by-theff