Linux에서 보이지 않는 메모리 누수-Ubuntu Server (디스크 캐시 / 버퍼 아님)

23

2015 년 8 월 요약

아직 진행 중입니다. 이것은 linuxatemyram.com과 관련 이 없습니다 . 메모리는 디스크 캐시 / 버퍼에 사용되지 않습니다. 이것은 NewRelic의 모습입니다-시스템은 모든 메모리를 누출하고 모든 스왑 공간을 사용한 다음 충돌합니다. 이 스크린 샷에서 서버가 충돌하기 전에 재부팅했습니다.

여기에 이미지 설명을 입력하십시오

일반적인 사용자 공간 도구를 사용하여 누수의 원인을 식별하는 것은 불가능합니다. 이제이 문제를 논의 할 수있는 대화방이 있습니다 : http://chat.stackexchange.com/rooms/27309/invisible-memory-leak-on-linux

"누락 된"메모리를 복구하는 방법 만이 서버를 재부팅하는 것으로 보입니다. 이것은 우분투 서버 14.04, 14.10 및 15.04에서 오랫동안 재현 된 문제였습니다.

상단

메모리 사용은 맨 위에 표시되지 않으며 커널 프로세스 및 ssh와 같은 것을 제외하고 거의 모든 프로세스를 종료 한 후에도 복구 할 수 없습니다. 상단에있는 "캐시 된 메모리", "버퍼"및 "자유"필드를 확인하십시오. 메모리를 사용하고 있지 않으며, 사용 된 메모리가 "누락"되어 재부팅 없이는 복구 할 수 없습니다.

이 "누락 된"메모리를 사용하려고하면 서버가 스왑되어 크롤링 속도가 느려지고 결국 정지됩니다.

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]

하드웨어

나는 지금까지 약 100 대 중 3 대의 서버에서 이것을 관찰했습니다 (다른 서버는 영향을받을 수 있음). 하나는 Intel Atom D525 @ 1.8ghz이고 다른 하나는 Core2Duo E4600 및 Q6600입니다. 하나는 JMicron Technology Corp.을 사용하고 있습니다. JMC250 PCI Express 기가비트 이더넷 컨트롤러, 다른 하나는 Qualcomm Atheros Attansic L1 기가비트 이더넷 (rev b0)을 사용하고 있습니다.

문제가있는 서버와 예제 OK 서버에서 lshw를 실행했습니다. 문제 서버 : http://pastie.org/10370534 http://pastie.org/10370537 및 http://pastie.org/10370541-OK 서버 : http://pastie.org/10370544

신청

이것은 전적으로 헤드리스 응용 프로그램입니다. 모니터가 연결되어 있지 않으며 실제로 XServer가 설치되어 있지 않습니다. 그래픽 드라이버 / 문제를 배제해야합니다.

서버는 live555ProxyServer, ffmpeg 및 openCV를 사용하여 RTSP 비디오를 프록시하고 분석하는 데 사용됩니다. 이 서버는 CCTV 응용 프로그램이므로 많은 트래픽을 처리합니다. http://pastie.org/9558324

나는 아주 오래된 및 최신 트렁크 버전의 live555, ffmpeg 및 openCV를 변경하지 않고 시도했습니다. 또한 python2 및 python3 모듈을 통해 opencv를 사용해 보았습니다. 변경 사항은 없습니다.

정확히 동일한 소프트웨어 / 구성이 100여 대의 서버에로드되어 지금까지 3 개가 메모리 누수를 확인했습니다. 서버는 모든 램이 사라질 때까지 시간당 xMB 주위에서 느리고 은밀하게 누출됩니다 (하나는 8MB, 하나는 느리고 하나는 더 빠름).

Meminfo

다시 말하지만, 캐시 및 버퍼가 많은 메모리를 전혀 사용하지 않는 것을 볼 수 있습니다. HugePages도 비활성화되어 있으므로 범인이 아닙니다.

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

자유 출력

Free는 다음을 보여줍니다 (캐시 및 버퍼가 모두 낮으므로 디스크 캐시 또는 버퍼가 아닙니다!)-재부팅없이 메모리를 복구 할 수 없습니다. 

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

버퍼를 빼거나 Used and Free에 버퍼를 추가하면 다음을 볼 수 있습니다.

  • 실제로 사용 된 1,772MB (-버퍼 / 캐시) = 1,838MB 사용-1MB 버퍼-66MB 캐시
  • 220MB 실제 사용 가능 (+ 버퍼 / 캐시) = 154MB 사용 가능 + 1MB 버퍼 + 66MB 캐시

우리가 예상 한대로 :

-/+ buffers/cache:      1,772        220

따라서 사용자 공간은 약 1.7GB를 사용하지 않으며 실제로 시스템은 실제로 53.7MB를 사용하므로 커널에서 사용합니다 (아래 PS Mem 출력 참조).

1.7GB가 캐싱 / 버퍼에 사용된다고 생각하는 의견에 놀랐습니다. 이것은 기본적으로 출력을 잘못 읽습니다! -이 줄은 buffers / cache를 제외한 사용 된 메모리를 의미 합니다. 자세한 내용은 linuxatemyram.com을 참조하십시오.

PS 출력

다음은 메모리별로 정렬 된 전체 실행 프로세스 목록입니다.

# 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

실행중인 모든 프로세스의 전체 목록은 다음과 같습니다.

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]

PS Mem 출력

또한 https://github.com/pixelb/ps_mem 에서 ps_mem.py를 시도했습니다.

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
=================================

슬랩 탑 출력

나는 또한 슬라브 탑을 시도했다.

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

다른

나는 또한 rkhunter로 루트킷을 스캔하려고 시도했지만 아무것도 발견하지 못했다. 그리고 캐시를 동기화하고 덤프하려고했습니다.

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

차이도 없었습니다.

또한 다음을 사용하여 스왑을 강제 실행하거나 스왑을 비활성화하려고했습니다.

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

또한 htop을 사용하고 메모리별로 정렬하려고 시도했지만 메모리가 어디로 가고 있는지 표시하지 않습니다. 커널 버전은 Linux 3.13.0-40-generic # 69-Ubuntu SMP입니다.

Dmesg 출력 : http://pastie.org/9558255 smem 출력 : http://pastie.org/9558290

결론

무슨 일이야? -모든 기억이 어디로 가고 있습니까? -어떻게 알 수 있습니까?

linux  ubuntu  memory 
— 해커 런
소스
2
— 콜린 피커드
출력을 잘못 읽고 있습니다. IO 캐싱은 1771이 아니라 65에 불과합니다.
— Hackeron
1
@ user50300 : linuxnix.com/2013/05/find-ram-size-in-linuxunix.html Used mem- (버퍼 + 캐시) = 앱에서 사용하는 램.
— Frank Thomas
@ FrankThomas 나는 모든 것을 시도했습니다. 내 질문을 더 신중하게 읽으십시오.
— Hackeron
2
일부 프로세스가 메모리를 올바르게 해제하지 않았는지 확인하십시오.sync && sudo echo 3 > /proc/sys/vm/drop_caches
— Hastur

답변:

7

필자의 결론은 Linux 커널 어딘가에서 커널 메모리 누수이므로 사용자 공간 도구 중 어느 것도 메모리 누수 위치를 보여줄 수 없습니다. 아마이 질문과 관련이 있습니다 : /server/670423/linux-memory-usage-higher-than-sum-of-processes

커널 버전을 3.13에서 3.19로 업그레이드했는데 메모리 누수가 중단 된 것 같습니다! -다시 누출이 보이면 다시보고하겠습니다.

Linux 커널의 다른 부분에 얼마나 많은 메모리가 사용되는지 알 수있는 쉽고 쉬운 방법을 사용하는 것이 여전히 유용합니다. 3.13에서 누수를 일으킨 것은 여전히 ​​미스터리입니다.

— 해커 런
소스
2

이야기

Linux에서 ZFS를 사용하여 문제를 재현 할 수 있습니다 .

여기라는 서버입니다 node51와 20GBRAM의는. ZFS ARC (Adaptive Replacement Cache)에16GiB 할당 할 수있는 RAM을 표시했습니다 .

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

그런 다음 ZFS 풀에서 파이프 뷰어 를 45GiB사용 하여 ARC를 채우는 파일을 읽었 습니다.zeltik

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

이제 여유 메모리를보십시오 :

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

보기!

51MiB버퍼에서
69MiB캐시에
120MiB모두
19688MiB버퍼 캐시를 포함하여 사용중인 RAM의
19568MiB사용의 RAM을 제외한 버퍼와 캐시

참조한 Python 스크립트는 애플리케이션이 적은 양의 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 설명되지 않은 RAM

설명

120MiB버퍼와 캐시는 데이터를 외부 장치로 전송 또는 수신을 캐시의 커널의 효율적인 동작을 위해 계정 위의 이야기에서 본 것을 사용했다.

Mem 이라는 첫 번째 행 에는 버퍼 및 캐시에 할당 된 메모리 양을 포함하여 실제 메모리 사용률이 표시됩니다. 버퍼 메모리 라고도하는 버퍼 는 일반적으로 HDD, 키보드, 프린터 또는 네트워크와 같은 외부 장치로 보내거나받는 데이터의 임시 보관 장소로 설정되는 메모리의 일부로 정의됩니다.

-/ + buffers / cache로 시작하는 두 번째 데이터 행은 현재 시스템 버퍼 캐시에 할당 된 실제 메모리의 양을 보여줍니다 . read () 및 write () 시스템 호출을 사용하여 수행되는 시스템의 파일에서 액세스 한 모든 데이터 가이 캐시를 통과 하므로 응용 프로그램과 관련하여 특히 의미가 있습니다 . 이 캐시는 HDD 또는 다른 디스크에서 읽거나 쓸 필요를 줄임으로써 데이터에 대한 액세스 속도를 크게 높일 수 있습니다.

출처 : http://www.linfo.org/free.html

이제 우리는 어떻게 누락을 설명 19431MiB합니까?

에서 free -m상기 출력의 19688MiB" 사용 에서", " - / + 버퍼 / 캐시 "이 수식에서 온다 :

(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

출처 : procps / free.c 및 procps / proc / sysinfo.c

(내 free -m출력을 기반으로 숫자를 수행하면 2MiB계산되지 않았지만이 코드에서 발생하는 반올림 오류 때문입니다. #define S(X) ( ((unsigned long long)(X) << 10) >> shift))

숫자는에 추가하지 마십시오 /proc/meminfo중 하나 (I는 기록하지 않았다, /proc/meminfo내가 달릴 때 free -m, 그러나 우리는 당신의 질문에서 볼 수있는 /proc/meminfo우리가 결론을 내릴 수 있도록 그 위가에서 누락 된 RAM이 어디에 표시되지 않습니다) /proc/meminfo하지 않습니다 전체 이야기를 들려주세요.

테스트 조건에서 Linux의 ZFS가 높은 RAM 사용량을 담당한다는 것을 알고 있습니다. 16GiB서버의 RAM 을 사용할 수 있다고 ARC에 알 렸습니다.

Linux의 ZFS는 프로세스가 아닙니다. 커널 모듈입니다.

지금까지 내가 찾은 것에서 커널 모듈의 RAM 사용량은 모듈이 프로세스가 아니기 때문에 프로세스 정보 도구를 사용하여 표시되지 않습니다.

문제 해결

불행히도, 나는 리눅스에 대해 충분히 알지 못해서 커널과 모듈과 같은 RAM 비 프로세스 구성 요소가 얼마나 많은 메모리를 사용하는지 목록을 작성하는 방법을 제공합니다.

이 시점에서 우리는 추측하고 추측하고 확인할 수 있습니다.

dmesg출력을 제공했습니다 . 잘 설계된 커널 모듈은 일부 세부 사항을로 기록 dmesg합니다.

를 살펴본 후 dmesg하나의 항목이 나에게 두드러졌습니다.FS-Cache

FS-Cachecachefiles커널 모듈의 일부이며 cachefilesdDebian 및 Red Hat Enterprise Linux 의 패키지와 관련이 있습니다.

아마도 얼마 전에 FS-Cache서버가 비디오 데이터를 분석 할 때 네트워크 I / O의 영향을 줄이기 위해 RAM 디스크에 구성 했을 수 있습니다.

RAM을 소모 할 수있는 의심스러운 커널 모듈을 비활성화하십시오. blacklist에서 로 비활성화되어있을 수 있으며 /etc/modprobe.d/그 뒤에는 sudo update-initramfs -u(명령 및 위치는 Linux 배포판에 따라 다를 수 있음).

결론

메모리 누수로 8MB/hr인해 RAM이 부족해 보이지만 RAM이 해제되지는 않습니다. 귀하가 제공 한 정보를 바탕으로 메모리 누수의 원인을 파악할 수 없었으며 해당 메모리 누수를 찾는 방법을 제공 할 수도 없었습니다.

내가 리눅스보다 더 경험이있는 사람은 "다른"RAM 사용이 어디로 가는지를 결정하는 방법에 대한 정보를 제공해야합니다.

나는이 질문에 대해 현상을 시작하여 "추측, 추측 및 확인"보다 더 나은 답변을 얻을 수 있는지 확인했다.

— 델틱
소스
감사합니다. 현상금에 감사드립니다! 참고로 캐싱을 활성화하지 않고 비디오 스트림을 실시간으로 분석하고 네트워크 스토리지가 전혀 없습니다 (NFS, SMB, FS_Cache가 사용되지 않고 캐시 파일이 설치되어 있지 않음). 나는로드 된 모든 커널 모듈을보고 이미 사용하지 않은 모든 것을 언로드하려고 시도했지만 도움이되지 않았습니다. (-아마도 누수가 네트워킹 드라이버 또는 무언가에 의심되는 것 같습니다. .
— Hackeron
1

커널 매뉴얼 의 Swapiness 를 변경 하거나 비활성화합니까?

당신은 당신이 현재 swappyness 수준을 whatch 할 수 있습니다

cat /proc/sys/vm/swappiness

커널을 적극적으로 교환하도록 시도 할 수 있습니다.

sudo sysctl -w vm.swappiness=100

이렇게 줄이면 문제가 1에서 100 사이의 좋은 값을 찾아서 요구 사항을 충족시킵니다.

— 크리스
소스
swappiness는 관련이 없습니다. 스왑을 완전히 해제하더라도 모든 사용자 프로세스를 종료하고 여전히 모든 메모리가 사용되는 상황이 있습니다.
— Hackeron
-2

당신은 옳지 않습니다 – 예, free –m 명령은 220MB의 여유 공간을 보여 주지만 1771MB가 버퍼로 사용됨을 보여줍니다. 버퍼 및 캐시는 커널이 저속 액세스 데이터 (일반적으로 디스크)에 대한 액세스를 최적화하기 위해 사용하는 메모리입니다. 따라서 커널은 필요할 때마다 다시 사용할 수 있으므로 버퍼로 표시된 모든 메모리를 사용 가능한 메모리로 간주해야합니다.

참조 : /server/23433/in-linux-what-is-the-difference-between-buffers-and-cache-reported-by-the-f

— 폴
소스
이것을 고려하여 답변을 업데이트했습니다. "무료"명령의 출력을 근본적으로 오해한다고 유감입니다.
— Hackeron
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.