
모니터링 시스템으로부터 메모리 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
좋아, 먼저 돌아가서 최상위 출력이 메모리 사용량( RES
ID 크기)별로 정렬되어 있는지 확인하고, 그렇지 않은 경우 다음으로 질문을 업데이트하세요.저것산출. 그러면 실제로 RAM을 씹고 있는 것이 무엇인지 확인할 수 있습니다.
둘째, %MEM
열을 잊어 버리십시오. 그 특정 케이크는 (반올림으로 인해) 거짓말입니다. 대신 프로그램의 고유 크기(그리고 교체가 걱정되는 경우 실제 크기)
에 집중하세요 . - 합계RES
VIRT
저것들열과 숫자는 현재 표시되는 내용 free
및 top
출력과 일치합니다.
귀하의 최고 출력을 살펴보면 거대한(2.6G) MySQL 프로세스와 거대한(2.0G) Java 프로세스가 있습니다. 이 두 프로세스가 모든 RAM(특정 Java 프로세스가 무엇이든 간에)을 씹어먹는 데 있어 공동 공모자가 아닐까 의심됩니다. MySQL에게 요청하는 것은 거대한 결과 세트 또는 중간 데이터를 생성하는 것입니다.
Java 프로세스의 가상 크기도 25G입니다(!!). 가비지 수집기가 해제하지 않아 내부적으로 메모리가 누출되고 있는 것이 분명합니다(또는 대규모 결과 집합을 비효율적으로 처리하고 있을 수도 있습니다).
나는 귀하의 시스템이 "평상시"에 4-5G RAM을 사용하여 순항할 것이라고 장담합니다. 그리고 이 두 프로세스가 합쳐지면 나머지 프로세스(그리고 일부)를 씹어 결국 나쁜 위치에 놓이게 됩니다.
그들이 무엇을 하는지 알아내고 고치면 문제가 사라질 것입니다.