RAM은 어디로 갔습니까?

15

참고 : 너무 빨리 뛰어 들기 전에 linuxatemyram.com을 읽 습니다 !

RAM이 64GB 인 서버가 있습니다.

free -m 내 RAM이 가득 찼으며 디스크 캐싱 때문이 아니라고 말합니다.

             total       used       free     shared    buffers     cached
Mem:         64458      64117        340        201         67        331
-/+ buffers/cache:      63719        739
Swap:         1532        383       1149

그러나 top메모리 사용 순서에 따라 최대 64GB가 추가되지는 않습니다.

KiB Mem:  66005116 total, 65652464 used,   352652 free,    67512 buffers
KiB Swap:  1569780 total,   392656 used,  1177124 free.   337464 cached Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 6258 mysql     20   0 38.665g 0.033t   4924 S   1.3 54.3 482:26.21 mysqld
 2293 root      20   0  165896 102116 101964 S   0.0  0.2   0:43.53 systemd-journal
 4909 root      20   0  377548  57840  57548 S   0.0  0.1   0:18.47 rsyslogd
26639 www       20   0  650076  53348  32968 S   0.0  0.1  11:32.27 php-fpm
26640 www       20   0  648344  51912  32984 S   0.0  0.1  11:37.43 php-fpm
26642 www       20   0  648600  51472  32580 S   0.0  0.1  11:37.16 php-fpm
26669 www       20   0  648148  50696  31988 S   0.0  0.1  11:35.24 php-fpm
26643 www       20   0  648452  50616  31628 S   0.0  0.1  11:36.19 php-fpm
26641 www       20   0  648620  50496  31340 S   0.0  0.1  11:36.51 php-fpm
28121 www       20   0  648620  48820  29660 S   0.0  0.1  11:35.75 php-fpm
27231 www       20   0  647508  48804  30760 S   0.0  0.1  11:35.61 php-fpm
28029 www       20   0  648044  48752  30172 S   0.0  0.1  11:37.20 php-fpm
28117 www       20   0  647868  48700  30296 S   0.0  0.1  11:36.45 php-fpm
28122 www       20   0  648340  48568  29676 S   0.0  0.1  11:35.73 php-fpm
 8569 www       20   0  649028  40268  20704 S   0.0  0.1  11:31.50 php-fpm
10126 www       20   0  648432  39420  20700 S   0.0  0.1   9:58.52 php-fpm
22386 www       20   0  647996  39400  20868 S   0.0  0.1  11:25.00 php-fpm
 9643 www       20   0  647976  39220  20704 S   0.0  0.1  11:29.23 php-fpm
23077 www       20   0  647852  39084  20692 S   0.0  0.1  11:11.80 php-fpm
10139 www       20   0  647580  38808  20692 S   0.0  0.1   9:59.94 php-fpm
 6326 www       20   0  647368  38396  20696 S   0.7  0.1   8:32.34 php-fpm
 4727 www       20   0  646128  37304  20692 S   0.0  0.1   8:30.20 php-fpm
 5459 www       20   0  645988  37156  20688 S   0.0  0.1   7:15.13 php-fpm
 2173 www       20   0  645240  36408  20684 S   0.0  0.1   4:39.13 php-fpm
20752 www       20   0  644536  35428  20680 S   0.0  0.1   4:29.78 php-fpm
 5396 www       20   0  644468  35324  20692 S   0.0  0.1   4:14.65 php-fpm
17558 www       20   0  642668  33816  20740 S   0.0  0.1   1:28.34 php-fpm
28133 www       20   0  642780  33636  20704 S   0.0  0.1   0:49.88 php-fpm
10925 www       20   0  479584  29264  11212 S   3.0  0.0   0:00.09 php
26632 root      20   0  552136  26072  19468 S   0.0  0.0   0:37.74 php-fpm
 4946 named     20   0  697996  18748   2104 S   0.0  0.0   3:46.96 named
15609 apache    20   0 2137056   8120   1592 S   0.0  0.0   0:56.18 httpd
 8584 root      20   0  133432   4864   3700 S   0.0  0.0   0:00.08 sshd

MySQL은, 혼자 54.3 %를 사용하여이 그것이 가지고로 완벽하게 정상 innodb_buffer_pool_size의 32G. 다른 프로세스의 메모리 사용량은 약 2.8 %로 총 57.1 %입니다.

32 %는 어디에 남아 있습니까?

편집 : 내용 /proc/meminfo:

MemTotal:       66005116 kB
MemFree:          353272 kB
Buffers:           66328 kB
Cached:           736620 kB
SwapCached:        11348 kB
Active:         34396680 kB
Inactive:        2651132 kB
Active(anon):   34223240 kB
Inactive(anon):  2228020 kB
Active(file):     173440 kB
Inactive(file):   423112 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:       1569780 kB
SwapFree:        1177448 kB
Dirty:               328 kB
Writeback:             0 kB
AnonPages:      36234364 kB
Mapped:           125208 kB
Shmem:            206396 kB
Slab:           28058904 kB
SReclaimable:   28010224 kB
SUnreclaim:        48680 kB
KernelStack:        2760 kB
PageTables:        94780 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    34572336 kB
Committed_AS:   38572348 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      382304 kB
VmallocChunk:   34359353572 kB
HardwareCorrupted:     0 kB
DirectMap4k:        9000 kB
DirectMap2M:     2054144 kB
DirectMap1G:    67108864 kB

출력 slabtop:

 Active / Total Objects (% used)    : 147380425 / 147413026 (100.0%)
 Active / Total Slabs (% used)      : 7005839 / 7005839 (100.0%)
 Active / Total Caches (% used)     : 71 / 144 (49.3%)
 Active / Total Size (% used)       : 27615020.12K / 27627490.91K (100.0%)
 Minimum / Average / Maximum Object : 0.01K / 0.19K / 16.12K

  OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME
146851887 146851887  12%    0.19K 6992947       21  27971788K dentry
124936 124936 100%    0.07K   2231       56      8924K Acpi-ParseExt
105144 105144 100%    0.10K   2696       39     10784K buffer_head
 49920  49172  98%    0.06K    780       64      3120K kmalloc-64
 29916  29916 100%    0.11K    831       36      3324K sysfs_dir_cache
 29856  29661  99%    0.12K    933       32      3732K kmalloc-128
 21450  21128  98%    0.18K    975       22      3900K vm_area_struct
 19328  19328 100%    0.03K    151      128       604K kmalloc-32
 18258  13383  73%    0.93K    537       34     17184K ext4_inode_cache
 17952  11651  64%    0.04K    176      102       704K ext4_extent_status
 16828   6513  38%    0.55K    601       28      9616K radix_tree_node
 14400  13996  97%    0.06K    225       64       900K anon_vma
 11645   7903  67%    0.05K    137       85       548K shared_policy_node
 10710   7006  65%    0.19K    510       21      2040K kmalloc-192
 10608  10608 100%    0.04K    104      102       416K Acpi-Namespace
  9728   9728 100%    0.01K     19      512        76K kmalloc-8
...
linux  memory  memory-usage 
— 베냐민
소스
3
linuxatemyram.com을 다시 읽으십시오. 그런 다음 kernel.org/doc/gorman/html/understand
— symcbean을
나는 그것을 다시 읽었고, 실제로 메모리 사용을 얻는 free -m방법 이라고 제안 합니다. 또한 스왑 사용량이 0이 아니라는 사실은 조금 모호합니다. 귀하의 링크를 확인했지만 읽을 수있는 데이터가 너무 많아서 두려워하는 순간 에이 모든 것을 처리 할 수 ​​없습니다.
— Benjamin
이 서버는 실제 서버입니까?
— Optichip
@Optichip 실제 서버입니다.
— Benjamin
5
@AndrewSchulman이 질문이 특정 질문과 중복된다고 생각하지 않습니다. 이 질문은 슬래브에 사용되는 메모리에 관한 것입니다. 다른 질문은 슬래브를 전혀 언급하지 않습니다.
— kasperd

답변:

23 
  OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME
146851887 146851887  12%    0.19K 6992947       21  27971788K dentry

디스크 캐싱 때문이 아니라 분명히 그렇습니다.

내 베팅은 존재하지 않는 파일을 많이 가져 오는 코드가 있고 많은 부정적인 캐싱을 얻는 것입니다. 리눅스는 메모리 부족 상태에서 이러한 항목을 제거하므로 걱정할 필요가 없습니다. 예를 들어이 NSS 문제 와 같이 .

— 데이비드 슈워츠
소스
5
아, 그건 설명 할 수 있습니다. 내 무지를 용서해주세요 free -m. 디스크 캐싱으로 인해 메모리를 먹었는지 여부 만 알 수 있다고 생각했습니다 . "네거티브 캐싱"에 대해서도 몰랐습니다. 존재하지 않는 파일을 찾으려고하는 것이 무엇인지 이해하는 것이 정말 흥미로울 것입니다. 호기심으로 어떻게 이것을 조사 할 수 있습니까? 이것은 데이터베이스 + 웹 응용 프로그램을 사용한 최근 설치 이므로이 동작을 보게되어 정말 놀랍습니다.
— Benjamin
@ Benjamin 어떻게 이런 일이 일어날 수 있는지에 대한 예를 보려면 내 링크를 따르십시오. 또한 웹 응용 프로그램이 실제로 수행하는 작업을 살펴보십시오.
— David Schwartz
10
사실, 나는 libcurl을 더 정확하게, 더 정확하게는 PHP 바인딩을 사용합니다. 내 웹 서버는 많은 이미지를 다운로드하여 처리합니다. 이미지는 메모리에 다운로드되어 처리 된 다음 S3에 업로드되어 파일 시스템에 절대로 영향을 미치지 않습니다. 그러므로 내가 너무 나에게 영향을 첫눈에 지역화 된 고려, 귀하의 링크를 간과 것을 인정해야하지만, 그것은 아주 잘이 정확한 문제가 될 수 있습니다 나도 같은 실행 strace curl남자가 그랬던 것처럼, 발견이 생성 된 것을 7421을 ENOENT (No such file or directory) 단일위한 질문! 그게 다야. 정말 고마워요!
— Benjamin
2
당신은 참조 할 수 있습니다 linux-mm.org/Drop_Caches을 하고 할 echo 2 > /proc/sys/vm/drop_caches비파괴 dentry와 아이 노드 캐시를 삭제하고 당신의 RAM을 반환 있는지. 조용한 시간에 가장 잘 수행됩니다.
— abligh
1
압력이 가해지면 Linux가 해당 항목을 삭제한다는 추가 확인은 활성 슬래브의 대량 ( Slabin /proc/meminfo)이 아래에 있다는 사실에서 비롯 됩니다 SReclaimable(이름에서 설명한대로 필요에 따라 회수 할 수 있음).
— Marco Leogrande
4

여전히 내부 커널 구조와 파일 시스템 / 디렉토리 관련 항목 일 수 있습니다. 혼란 스럽지만 완벽하게 정상입니다. slabtop및 의 출력 결과를 확인하십시오 cat /proc/meminfo.

— 잔 피카 레인
소스
이 명령의 출력을 내 질문에 추가했습니다. 좀 봐 주시겠습니까?
— Benjamin
1
약 27 기가 바이트의 RAM이 커널에 의해 소비되는 것으로 보이며, 대부분은 dentry디렉토리 항목으로 이동 합니다. 파일 시스템에 많은 파일이 있다고 생각합니다. 실제로는 캐시 된 것입니다. 일부 프로세스에 실제로 메모리가 필요한 경우 최상위 출력에서 ​​보려는 일반 버퍼 / 캐시와 동일한 방식으로 해제됩니다.
— Janne Pikkarainen
알아두면 좋습니다. 감사합니다. : 난 그냥 내가 많은 파일 시스템에 주변에 파일이없는 것처럼하지만 놀랍군요 find / | wc -l반환 134578하지 수백만로이 dentry제안 할 수있다. 이 작업을 수행 할 수있는 방법이 있습니까?
— Benjamin
위 의 David Schwartz의 답변 덕분에 이러한 정크 디렉토리 항목을 생성하는 것을 발견했을 것 입니다. 어쨌든 도움을 주셔서 감사합니다!
— Benjamin
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.