뭔가가 내 서버의 메모리를 모두 잡아먹고 있지만 fs 캐시는 아닙니다.

뭔가가 내 서버의 메모리를 모두 잡아먹고 있지만 fs 캐시는 아닙니다.

모니터링 시스템으로부터 메모리 98%에 대한 알림을 여러 번 받았습니다. 나는 실행하여 top합산하면 약 60%의 메모리만 사용된 것으로 계산했습니다.메모리열. 몇 시간 후에 메모리 사용량이 정상(~70%)으로 돌아왔습니다. fs 캐시를 의심했지만 free -m이를 증명하지는 않습니다.

어떤 아이디어가 있나요? 서버: x86-64, 우분투 12.04, 8GB RAM

# free -m

             total       used       free     shared    buffers     cached
Mem:          7958       7835        123          0          8         39
-/+ buffers/cache:       7787        171
Swap:          975        975          0

#top

top - 10:11:48 up 179 days, 14:25,  1 user,  load average: 1.99, 1.81, 1.59
Tasks: 143 total,   1 running, 142 sleeping,   0 stopped,   0 zombie
Cpu(s):  2.8%us,  0.6%sy,  0.0%ni, 82.8%id, 13.6%wa,  0.0%hi,  0.2%si,  0.0%st
Mem:   8149424k total,  8017556k used,   131868k free,     6708k buffers
Swap:   999420k total,   999372k used,       48k free,    37952k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND        
30562 mysql     20   0 6033m 2.6g 3160 S   14 32.9  74:37.56 mysqld         
10898 www-data  20   0 25.3g 2.0g 1560 S   16 25.6  19:44.10 java           
 9570 rabbitmq  20   0 2611m 166m 1540 S    6  2.1 628:08.96 beam.smp       
13166 redis     20   0 94276  72m  584 S    0  0.9  23:24.47 redis-server   
 3798 root      20   0  348m  29m  988 S    0  0.4 167:36.37 cimprovagt     
 7614 root      20   0 51468  28m 1256 S    0  0.4   0:02.59 bash           
 3677 root      20   0 4706m  26m    0 S    0  0.3 110:47.59 java           
 3458 bind      20   0  668m 5328 1488 S    0  0.1   0:23.38 named          
 7595 root      20   0 85380 2956  880 S    0  0.0   0:00.25 sshd           
 2061 root      10 -10  4996 2948 2104 S    0  0.0  13:39.72 iscsid         
  632 syslog    20   0  244m 2404  360 S    0  0.0   7:12.39 rsyslogd       
 5855 newrelic  20   0  107m 1852 1248 S    0  0.0 128:23.28 nrsysmond      
    1 root      20   0 24340 1516  736 S    0  0.0   0:29.96 init           
 2741 root      20   0 17340 1308  944 R    0  0.0   0:00.04 top            
 4214 root      20   0 45336 1264 1020 S    0  0.0   6:12.72 cdm            
 4235 root      20   0 12428 1108  908 S    0  0.0  10:55.38 processes      
 4178 root      20   0 19124 1064  856 S    0  0.0   7:20.07 controller     
 5853 ntp       20   0 37772 1036  872 S    0  0.0   7:40.35 ntpd           
 4179 root      20   0 86044 1024  848 S    0  0.0   9:55.54 spooler        
 4008 root      20   0 4090m  980  756 S    0  0.0   0:08.70 console-kit-dae
 3790 root      20   0  422m  952  668 S    0  0.0  89:21.80 cimprovagt     
 3629 root      20   0 50032  868  752 S    0  0.0   1:17.44 sshd           
 4075 root      20   0  182m  844  408 S    0  0.0   0:02.90 polkitd        
27661 root      20   0  101m  776  772 S    0  0.0   0:00.02 mysql          
18465 root      20   0  101m  732  732 S    0  0.0   0:00.04 mysql          
 3436 root      20   0 19112  716  636 S    0  0.0   0:11.25 cron           
 3783 root      20   0 1009m  716  432 S    0  0.0   0:04.83 cimserver      
26239 root      20   0 22092  700  696 S    0  0.0   0:00.03 bash           
 4181 root      20   0 13196  696  596 S    0  0.0   4:18.57 hdb            
 3406 root      20   0 14744  664  660 S    0  0.0   0:00.00 getty          
 3410 root      20   0 14744  664  660 S    0  0.0   0:00.00 getty          
 3428 root      20   0 14744  664  660 S    0  0.0   0:00.00 getty          
 3429 root      20   0 14744  664  660 S    0  0.0   0:00.00 getty          
 3432 root      20   0 14744  664  660 S    0  0.0   0:00.00 getty          
 3972 root      20   0 14744  664  660 S    0  0.0   0:00.00 getty          
18452 root      20   0 22076  620  620 S    0  0.0   0:00.00 bash           
  361 root      20   0 22104  568  568 S    0  0.0   0:00.04 udevd          
 3441 root      20   0 15980  560  464 S    0  0.0  26:28.16 irqbalance     
  654 messageb  20   0 23948  516  324 S    0  0.0   0:01.98 dbus-daemon    
  676 root      20   0 21188  504  504 S    0  0.0   0:00.00 bluetoothd     
 3665 root      20   0  4400  492  488 S    0  0.0   0:00.00 sh             
 5546 rabbitmq  20   0  7672  488  308 S    0  0.0   1:04.49 epmd           
26238 root      20   0 26092  476  476 S    0  0.0   0:00.24 screen         
 2060 root      20   0  4504  440  400 S    0  0.0   3:18.60 iscsid         

답변1

버퍼~이다FS 캐시.

버퍼는 특정 블록 장치와 연관되어 있으며 파일 시스템 메타데이터 캐싱은 물론 진행 중인 페이지 추적도 담당합니다. 캐시에는 보관된 파일 데이터만 포함됩니다. 즉, 버퍼는 디렉터리에 있는 내용, 파일 권한이 무엇인지 기억하고 특정 블록 장치에 대해 어떤 메모리에서 쓰거나 읽고 있는지 추적합니다. 캐시에는 파일 자체의 내용만 포함됩니다.

https://stackoverflow.com/a/12547130/636573

Top은 또한 귀하가 제공한 스냅샷에 IOWAIT의 13%를 표시합니다. 나에게 이것은 OLTP 데이터베이스가 필요한 디스크 IOPS를 거의 얻지 못하는 것처럼 보입니다. 스토리지 하위 시스템을 업그레이드하세요.

답변2

좋아, 먼저 돌아가서 최상위 출력이 메모리 사용량( RESID 크기)별로 정렬되어 있는지 확인하고, 그렇지 않은 경우 다음으로 질문을 업데이트하세요.저것산출. 그러면 실제로 RAM을 씹고 있는 것이 무엇인지 확인할 수 있습니다.

둘째, %MEM열을 잊어 버리십시오. 그 특정 케이크는 (반올림으로 인해) 거짓말입니다. 대신 프로그램의 고유 크기(그리고 교체가 걱정되는 경우 실제 크기)
에 집중하세요 . - 합계RESVIRT저것들열과 숫자는 현재 표시되는 내용 freetop출력과 일치합니다.


귀하의 최고 출력을 살펴보면 거대한(2.6G) MySQL 프로세스와 거대한(2.0G) Java 프로세스가 있습니다. 이 두 프로세스가 모든 RAM(특정 Java 프로세스가 무엇이든 간에)을 씹어먹는 데 있어 공동 공모자가 아닐까 의심됩니다. MySQL에게 요청하는 것은 거대한 결과 세트 또는 중간 데이터를 생성하는 것입니다.
Java 프로세스의 가상 크기도 25G입니다(!!). 가비지 수집기가 해제하지 않아 내부적으로 메모리가 누출되고 있는 것이 분명합니다(또는 대규모 결과 집합을 비효율적으로 처리하고 있을 수도 있습니다).

나는 귀하의 시스템이 "평상시"에 4-5G RAM을 사용하여 순항할 것이라고 장담합니다. 그리고 이 두 프로세스가 합쳐지면 나머지 프로세스(그리고 일부)를 씹어 결국 나쁜 위치에 놓이게 됩니다.
그들이 무엇을 하는지 알아내고 고치면 문제가 사라질 것입니다.

관련 정보