리눅스 스왑을 사용하거나 스왑에 무엇이 있는지 찾는 방법은 무엇입니까?


12

28GB RAM과 2GB 스왑이있는 가상 Linux (Fedora 17) 서버가 있습니다. 서버에서 대부분의 RAM을 사용하도록 설정된 MySQL DB를 실행 중입니다.

일정 시간이 지나면 서버는 스왑을 사용하여 사용되지 않은 페이지를 스왑합니다. 내 스왑이 기본적으로 60이고 예상되는 동작이므로 괜찮습니다.

이상한 점은 top / meminfo의 숫자가 프로세스의 정보와 일치하지 않는다는 것입니다. 즉, 서버가 다음 번호를보고합니다.

/proc/meminfo:
SwapCached:        24588 kB
SwapTotal:       2097148 kB
SwapFree:         865912 kB

top:
Mem:  28189800k total, 27583776k used,   606024k free,   163452k buffers
Swap:  2097148k total,  1231512k used,   865636k free,  6554356k cached

/server//a/423603/98204 의 스크립트를 사용하면 합리적인 수 (bash와 systemd 등으로 스왑 된 MB가 거의 없음)와 MySQL에서 하나의 큰 할당이 표시됩니다 (많은 출력 행을 생략했습니다) ) :

892        [2442] qmgr -l -t fifo -u
896        [2412] /usr/libexec/postfix/master
904        [28382] mysql -u root
976        [27559] -bash
984        [27637] -bash
992        [27931] SCREEN
1000       [27932] /bin/bash
1192       [27558] sshd: admin@pts/0
1196       [27556] sshd: admin [priv]
1244       [1] /usr/lib/systemd/systemd
9444       [26626] /usr/bin/perl /bin/innotop
413852     [31039] /usr/libexec/mysqld --basedir=/usr --datadir=/data/mysql --plugin-dir=/usr/lib64/mysql/plugin --log-error=/data/mysql/err --open-files-limit=8192 --pid-file=/data/mysql/pid --socket=/data/mysql/mysql.sock --port=3306
449264   Total Swap Used

따라서 스크립트 출력을 올바르게 받으면 총 스왑 사용량은 449264K = ca입니다. ca를 사용하는 mysql의 경우 440MB 스왑의 90 %

문제는 이것이 왜 최상위 숫자와 meminfo 숫자와 크게 다른가? 모든 프로세스에서 스왑 사용량을 합산하는 대신 스왑 정보를 "덤프"하여 실제로 무엇이 있는지 확인하는 방법이 있습니까?

문제를 분석 할 때 다른 아이디어를 생각해 냈지만 모두 잘못된 것 같습니다.

  1. 스크립트 출력이 KB가 아닙니다. 512 또는 4KB 단위 일지라도 일치하지 않습니다. 실제로 비율 (1200 : 440)은 "이상한"숫자 인 약 3 : 1입니다.
  2. /server//a/477664/98204에 언급 된대로 프로세스간에 공유되는 일부 페이지가 스왑에 있습니다 . 이것이 사실이라면 이와 같이 사용 된 실제 메모리 수를 어떻게 찾을 수 있습니까? cca 800MB의 차이를 만들어야한다는 것을 의미합니다. 그리고이 시나리오에서는 제대로 들리지 않습니다.
  3. 이미 완료된 프로세스에서 사용 된 스왑에 "이전"페이지가 있습니다. 나는이 "자유로운"스왑이 얼마인지 알아낼 수 있다면 괜찮을 것입니다.
  4. 스왑의 페이지가 메모리로 다시 스왑되고 RAM에서 변경되지 않고 /server//a/100636/98204에 언급 된대로 다시 스왑해야하는 경우를 대비하여 스왑중인 페이지가 있습니다 . 그러나 SwapCached 값은 24MB에 불과합니다.

이상한 점은 스왑 사용량이 천천히 증가하는 반면 스크립트의 합계 출력은 거의 같습니다. 지난 3 일 동안 사용 된 스왑은 1100MB에서 현재 1230MB로 증가한 반면 합계는 430MB에서 현재 449MB (ca)로 증가했습니다.

서버에 사용 가능한 RAM이 충분하므로 스왑을 껐다가 다시 켤 수 있습니다. 또는 swappiness를 0으로 설정하여 스왑이 다른 방법이 아닌 경우에만 사용되도록 할 수 있습니다. 그러나 문제를 해결하거나 적어도 원인의 원인을 찾고 싶습니다.


당신이 말했듯이 vm.swappiness = 0 (또는 1)과 swapoff && swapon
HTTP500

그러나 그것은 문제를 해결하지 못할 것입니다. 스왑 파인을 다시 60으로 설정하면 스왑이 다시 증가하기 시작하거나 0 또는 1로 유지하면 전혀 사용되지 않습니다 (서버의 메모리가 부족하지 않은 경우)
Radek Hladík

DB 서버 인 경우 비상시 스왑 만 사용해야하므로 항상 0 (또는 1)으로 설정해야합니다.
HTTP500

그 사실과 그 문제는 아마도이 문제의 원인을 찾지 못하면 아마도 내가 할 것입니다 ... 반면에 서버에 아주 작은 DB가 많고 산발적으로 사용되는 아이디어가 마음에 들었습니다. 그들이 사용하지 않을 때 시스템에 의해 스왑 아웃 ... 그러나 MySQL은 자체적으로 그것을 처리 할 수 ​​있다고 생각합니다 ...
Radek Hladík

Mysql은 자체 캐시를 관리하는 데 매우 효과적이지만 실제로 메모리에 무엇이 있고 무엇이 아닌지에 대한 가정을 기반으로합니다. 스왑 메모리를 사용하여 메모리를 두 번 추측하려고하면 캐시해야 할 것과 그렇지 않은 것을 결정하는 mysql의 기능이 손상됩니다. 스왑을 끕니다. 스왑을 수행하면 튜닝 실패입니다. 스왑이 발생하지 않도록 캐시 크기를 조정하지만 부족한 경우 사용 가능한 모든 실제 메모리를 사용하려고합니다.
mc0e

답변:


9

Fedora 18 이상 smem은 repos에 있습니다. 파이썬 스크립트를 다운로드하고 source 에서 설치할 수 있습니다 .

내 컴퓨터의 샘플 출력 (약간 스니핑 및 익명 처리)은 다음과 같습니다.

# smem -s swap -t -k -n
  PID User     Command                         Swap      USS      PSS      RSS 
20917 1001     bash                               0     1.1M     1.1M     1.9M 
28329 0        python /bin/smem -s swap -t        0     6.3M     6.5M     7.4M 
 2719 1001     gnome-pty-helper               16.0K    72.0K    73.0K   516.0K 
  619 0        @sbin/mdadm --monitor --sca    28.0K    72.0K    73.0K   248.0K 

[big snip]

32079 42       gnome-shell --mode=gdm         41.9M     1.9M     2.0M     5.0M 
32403 1001     /opt/google/chrome/chrome -    43.1M   118.5M   119.4M   132.3M 
 4844 1002     /opt/google/chrome/chrome      48.1M    38.1M    41.9M    51.9M 
 5411 1002     /opt/google/chrome/chrome -    54.6M    33.4M    33.5M    36.8M 
 5624 1002     /opt/google/chrome/chrome -    72.4M    54.9M    55.5M    65.7M 
24328 1002     /opt/Adobe/Reader9/Reader/i    77.5M     1.9M     2.0M     5.2M 
 4921 1002     /opt/google/chrome/chrome -   147.2M   258.4M   259.4M   272.0M 
-------------------------------------------------------------------------------
  214 14                                       1.1G     1.1G     1.2G     1.7G 

소스는 또한 smemcapsmem을 나중에 실행할 수 있도록 모든 관련 데이터를 저장하는 기능 을 제공 합니다.

   To  capture  memory statistics on resource-constrained systems, the the
   smem source includes a utility named  smemcap.   smemcap  captures  all
   /proc entries required by smem and outputs them as an uncompressed .tar
   file to STDOUT.  smem can analyze the output using the --source option.
   smemcap is small and does not require Python.

1
F17의 REPO에서 Smem 일 (빈리스트했다)하지 않았다하지만 소스의 하나 일과 최고의 쇼를 사용 1191224k 동안, 다른 사람 :-) 392.6M 총 중 mysql을 358.1M과 거의 같은 숫자를 보여주는
라덱 Hladík

4

내 시스템에 올바른 스왑 사용량이 표시되므로 다른 컴퓨터에서이 스크립트를 확인해야합니다.

# Your_script.sh
111280   Total Swap Used
# free
Swap:     33551716     120368   33431348

매우 가까이 111280 ~ = 120368.

또한이 스크립트를보십시오 :

/ proc / *의 proc; cat $ proc / smaps 2> / dev / null | awk '/ Swap / {swap + = $ 2} END {print swap "\ t' readlink $proc/exe'"}'; 완료 | 정렬 -n | awk '{total + = $ 1} / [0-9] /; END {인쇄 총 "\ tTotal"}'

이 스레드에서 :

/unix/71714/linux-total-swap-used-swap-used-by-processes


언급 된 스크립트는 동일한 결과를 반환 ... 364920는 / usr / libexec 디렉토리 / mysqld를 400,372 총
라덱 Hladík

나는 매우 낮은 스왑 사용량 (50메가바이트)와 다른 서버에서 스크립트를했을 때 그것은 총 CCA의 72메가바이트을보고 :-) 나중에 어떤 프로덕션 서버가 아닌 서버에 시뮬레이션 할 필요가 ...
라덱 Hladík
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.