☰

메모리를 많이 차지하고 "ps" 또는 이와 유사한 프로그램에서는 표시되지 않는 콘텐츠를 찾아보세요.

tag-icon • tag-icon memory out-of-memory
메모리를 많이 차지하고 "ps" 또는 이와 유사한 프로그램에서는 표시되지 않는 콘텐츠를 찾아보세요.

가상 머신에 메모리 문제가 있습니다. 실행하려는 작업 중 하나가 메모리 부족 오류로 인해 충돌합니다.

그러나 충돌이 발생했을 때 시스템은 여전히 ​​메모리 부족 상태였습니다. 이것이 제가 누락한 프로세스인지 아니면 실제 버그인지 확실하지 않습니다(이것은 hyper-v에 있으며 새로운 커널 확장으로 인해 Linux 호스트의 메모리가 부풀어오르므로 실제 커널일 가능성이 높습니다). 벌레) .

durr@sqlbox:~$ free -h
             total       used       free     shared    buffers     cached
Mem:          3.1G       2.6G       541M        88K       7.4M        39M
-/+ buffers/cache:       2.5G       588M
Swap:         1.0G       6.2M       1.0G

Free는 단지 캐시된 것이 아니라 실제로 살아있는 것처럼 보이는 무언가가 2.6G의 메모리를 차지한다고 말합니다.

그러나 가상 크기별로 정렬된 PS 출력을 보는 것은 흥미롭지 않습니다.

durr@sqlbox:~$ ps -e ax -o pid,vsz,comm | sort --numeric-sort --key=2
[ ... snip ... ]
  PID    VSZ COMMAND
   96      0 rcuob/23
   97      0 rcuob/24
   98      0 rcuob/25
   99      0 rcuob/26
 1124   4368 acpid
59863  10016 ps
 1031  15668 upstart-file-br
 1047  15820 getty
 1050  15820 getty
 1055  15820 getty
 1056  15820 getty
 1058  15820 getty
 1167  15820 getty
 1023  15920 upstart-socket-
 1076  19140 atd
 1099  19188 irqbalance
  428  19476 upstart-udev-br
59864  21860 sort
59267  22644 bash
59234  22664 bash
59280  22808 bash
 1075  23656 cron
59261  26928 screen
59279  27380 htop
59262  28472 screen
    1  33776 init
  749  39240 dbus-daemon
  816  43452 systemd-logind
  432  51348 systemd-udevd
 1090  61364 sshd
  871 255844 rsyslogd
59184 269028 sshd
59233 269028 sshd

따라서 가장 큰 메모리를 차지하는 것은 sshd... 269K를 사용하고 있다는 것인가요? 내 기억은 다 어디로 갔나요?

/proc/meminfo프로그램 개요 :

durr@sqlbox:~$ cat /proc/meminfo
MemTotal:        3266904 kB
MemFree:          554228 kB
Buffers:            7596 kB
Cached:            41104 kB
SwapCached:         3032 kB
Active:            32552 kB
Inactive:          34292 kB
Active(anon):      13224 kB
Inactive(anon):     5008 kB
Active(file):      19328 kB
Inactive(file):    29284 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:       1044476 kB
SwapFree:        1038084 kB
Dirty:                 0 kB
Writeback:             0 kB
AnonPages:         15656 kB
Mapped:             9196 kB
Shmem:                88 kB
Slab:              33488 kB
SReclaimable:      14532 kB
SUnreclaim:        18956 kB
KernelStack:        2352 kB
PageTables:         2748 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     2677928 kB
Committed_AS:      56148 kB
VmallocTotal:   34359738367 kB
VmallocUsed:       34360 kB
VmallocChunk:   34359695660 kB
HardwareCorrupted:     0 kB
AnonHugePages:         0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:       44456 kB
DirectMap2M:     3491840 kB

아무래도 메모리를 많이 차지하는 뭔가가 있는 것 같은데 Vmalloc, 관련이 있는지는 잘 모르겠습니다.

답변1

프로그램이 공유 메모리를 사용하고 있고 이를 정리하지 않을 수 있습니다.

Linux에는 공유 메모리의 세 가지 변형이 있습니다.

1.) POSIX 공유 메모리(glibc로 구현된 메모리)는 tmpfs의사 파일 시스템의 파일을 통해 액세스할 수 있으며 일반적으로 시스템에 의해 또는 /dev/shm에 /run마운트 됩니다 . 결정하는 가장 좋은 방법은 쉘 (더 이식성이 높음) 또는 (Linux에 가장 적합)에 입력하는 것입니다./run/shm/run/lockmount | grep -E '^tmpfs'grep -E '^tmpfs' /proc/mounts

프로세스는 unlink()공유 mmap()메모리에서 "ed" 파일을 호출하여 파일 이름으로 파일에 액세스할 수 없도록 렌더링할 수 있습니다(예: 계속 액세스하려면 이전에 할당된 파일 핸들이 필요함). 그러나 unlink()ed 파일은 일반적으로 해당 파일을 소유한 모든 프로세스가 종료될 때 삭제됩니다 open(). 프로그램이 종료된 경우에도 해당 파일에 대한 핸들을 여전히 보유하고 있는 다른 프로세스가 있을 수 있습니다.

2.) SysV IPC 공유 메모리는 의사 파일 시스템을 통해 표시되지 않지만 tmpfsLinux /proc/sysvipc/shm시스템 호출(해커인 경우에만), libc 래퍼 또는 최근에는 ipcs -m -p -[tclu]이 목록 중 하나에서 일치하는 프로세스 ID를 찾아야 합니다. 그런 다음 프로세스를 추가로 검토합니다.

3.) 익명으로 매핑된 공유 메모리, 이 경우 메모리는 어떤 파일에서도 지원되지 않으며 대신 프로세스와 모든 하위 프로세스 간에 초기에 메모리가 공유됩니다. 내가 아는 한, mmap()이 익명으로 매핑된 공유 메모리는 이를 편집한 프로세스가 실행될 때 해제됩니다 exit(). 따라서 프로그램이 종료되고 해당 하위 프로세스도 모두 종료되면 더 이상 메모리를 차지해서는 안 됩니다.

관련 정보