아래에 프로덕션 호스트가 있습니다.

이 시스템은 1GB의 스왑을 사용하는 동안 거의 40GB의 사용 가능한 여유 메모리 공간을 유지합니다. 이것에 대해 걱정해야합니까, 아니면 대부분 정상입니까?

이것은 문제가되지 않으며 정상일 수 있습니다. 많은 코드 (및 데이터)는 거의 사용되지 않으므로 시스템은 메모리를 확보하기 위해 스왑 아웃합니다.

스와핑은 메모리가 지속적으로 스왑 및 아웃되는 경우에만 문제가됩니다. 이러한 종류의 활동은 성능을 저하시키고 시스템의 다른 곳에서 문제를 시사합니다.

스왑 활동을 모니터링하려면 여러 유틸리티를 사용할 수 있지만 vmstat일반적으로 매우 유용합니다.

$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0 348256  73540 274600    0    0     1     9    9    6  2  0 98  0  0
 0  0      0 348240  73544 274620    0    0     0    16   28   26  0  0 100  0  0
 0  0      0 348240  73544 274620    0    0     0     0   29   33  0  0 100  0  0
 0  0      0 348240  73544 274620    0    0     0     0   21   23  0  0 100  0  0
 0  0      0 348240  73544 274620    0    0     0     0   24   26  0  0 100  0  0
 0  0      0 348240  73544 274620    0    0     0     0   23   23  0  0 100  0  0

시스템이 시작된 이후 첫 번째 행은 활동이므로 무시하십시오. 아래 의 si및 so열을 확인하십시오 ---swap--. 대부분의 경우 0이 아닌 경우 일반적으로 상당히 작은 숫자 여야합니다.

또한이 선점 적 스와핑은 커널 설정으로 제어 할 수 있습니다. at 파일 /proc/sys/vm/swappiness에는 0에서 100 사이의 숫자가 포함되어있어 커널에게 메모리를 얼마나 적극적으로 스왑 아웃하는지 알려줍니다. 이 설정이 무엇인지 보려면 파일을 정리하십시오. 기본적으로 대부분의 Linux 배포판은 기본적으로 이것을 60으로 설정하지만 메모리가 고갈되기 전에 스와핑을 원하지 않으면 다음과 같이 파일에 0을 에코하십시오.

echo 0 >/proc/sys/vm/swappiness

이것은 추가하여 영구적으로 만들 수 있습니다

vm.swappiness = 0

에 /etc/sysctl.conf.

Linux는 더 나은 방법이 없다면 디스크에 페이지를 미리 작성합니다. 그렇다고 메모리에서 해당 페이지를 제거한다는 의미 는 아닙니다 . 그것은 경우에 그것은 단지입니다 해야한다 그들은 이미 있기 때문에 미래에 언젠가 해당 페이지를 퇴거, 그것은 그들 디스크에 기록 할 때까지 기다릴 필요가 없습니다.

결국, 메모리가 부족한 이유는 아마도 컴퓨터가 이미 열심히 작동하고 있기 때문에 스와핑으로 인해 추가 부담을 느끼고 싶지 않기 때문일 것입니다. 기계가 아무것도하지 않을 때 스와핑을 수행하는 것이 좋습니다.

비슷한 이유로 메모리가 항상 가득 찼습니다. 메모리 페이지, 파일 시스템 캐시, 메모리에 담을 tmpfs수있는 많은 것들이 있습니다. 실제로, 당신은 당신의 기억이 비어 있는지 걱정해야합니다. 결국, 당신은 (적어도 같은 양의 디스크 공간과 비교하여) 많은 돈을 지불했기 때문에 더 잘 사용됩니다!

사용 된 스왑은 나쁘지 않지만 많은 스왑 활동은

  vmstat 1
  procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
  6  0 521040 114564   6688 377308    8   13   639   173    0 1100  5  4 90  0
  1  0 521040 114964   6688 377448    0    0   256     0    0 1826  3  4 94  0
  0  0 521040 115956   6688 377448    0    0     0     0    0 1182  7  3 90  0
  0  0 521036 115992   6688 377448    4    0    16     0    0 1154 10  2 88  0
  3  0 521036 114628   6696 377640    0    0   928   224    0 1503 15 17 67  1

스왑 된 열 은 전혀 문제가되지 않습니다. 컬럼에 비 제로 값은 SI 및 때문에 서버 성능에 치명적이다. 특히 RAM이 많은 것들.

몇 GB의 램이있는 머신에서 스왑 인을 비활성화하는 것이 가장 좋습니다.

sysctl -w vm.swappiness=0

이것은 스왑을 비활성화하지 않습니다. Linux는 스왑을 최후의 수단으로 사용하도록 지시합니다. 이것은 RAM에있을 필요가없는 몇 MB의 프로그램을 낭비 할 것입니다. 그러나 디스크 액세스 큐를 블로 팅하는 것보다 스왑하는 것이 좋습니다.

편집 1 : swappiness의 기본값이 최적이 아닌 이유

우리는 20 년 전에 큰 486에 32Mb RAM 만 있다는 것을 기억해야합니다. 스왑 알고리즘은 전체 RAM을 몇 초 안에 디스크로 옮길 수있을 때 개발되었습니다. 그 당시 디스크 속도가 느려도 마찬가지입니다. 이것이 기본 스왑 정책이 매우 공격적인 이유입니다. RAM은 당시 병목 현상이었습니다. 이후 RAM 크기는 10,000 배 이상 증가했으며 디스크 속도는 10 배 미만입니다. 이로 인해 병목 현상이 디스크 대역폭으로 전환되었습니다.

편집 2 : 왜 SI 활동이 서버에 치명적입니까?

시 및 그래서 RAM의 톤과 기계의 활동은 치명적입니다 의미하기 때문에 시스템 RAM을 위해 자신과 싸우고있다. RAM과 비교할 때 디스크, 심지어 큰 스토리지조차도 너무 느립니다. 적극적인 스왑은 응용 프로그램 데이터보다 커널 디스크 캐시를 선호하며 RAM에 대한 가장 일반적인 소스입니다. OS는 모든 si 에서 디스크 캐시를 비워야하기 때문에 스왑이 제공하는 여분의 캐시를 사용하는 데 걸리는 시간이 너무 짧아 어쨌든 유용하지 않습니다. 결과적으로 사용되지 않을 캐시를 저장하기 위해 디스크 대역폭을 사용하고 si 페이지를 기다리는 프로그램을 일시 중지합니다 . 이는 응용 프로그램에 거의 또는 전혀 이점이없는 많은 중요 자원을 소비한다는 의미입니다.

응답 제목은 "RAM이 많은 서버에서 많은 스왑 활동"입니다. 이것은 때때로 si 활동이있는 머신에는 적용되지 않습니다. 보다 현명한 스왑 알고리즘이 OS에서 개발 된 경우 향후에는 적용되지 않을 수 있습니다.

편집 3 : "콜드"페이지

사람들은 교환 알고리즘을 낭만적으로 만듭니다. 일부는 "RAM의 사용 된 페이지를 덜 사용합니다"라고 말하지만 이것이 커널이하는 일은 아닙니다. 스왑에 대해 이해하기 어려운 것은 커널이 "콜드 페이지"가 ​​무엇인지 모른다는 것입니다. 커널은 페이지가 가까운 장래에 사용되는지 또는 사용 될지 여부를 결정하기위한 메트릭이 없습니다. 커널이 우연히 스왑에 페이지를 무작위로 넣는 것을 피하기 위해 필요하지 않은 페이지는 그대로 남아 있습니다. 이 알고리즘의 문제점은 페이지가 응용 프로그램에 필요한지 여부를 알기 위해 스왑으로 이동해야한다는 것입니다. 그리고 이것은 많은 "핫"페이지가 스왑으로 이동한다는 것을 의미합니다. 그 문제는 디스크가 RAM에 비해 너무 느리다는 것입니다.

적절한 볼륨을 가진 많은 응용 프로그램에 매우 일반적인 현실적인 시나리오 인 자체 벤치 마크를 만들었습니다. 테스트에서 스왑을 사용할 때 처리량이나 대기 시간에 이점이 없었습니다. 그것과는 거리가 멀다. 스와핑이 시작되면 처리량과 대기 시간이 둘 다 느려집니다.

나는 이것에 대해 조금 더 나아 간다 : 나는 스왑이 처리를위한 것이 아니라는 것을 이해한다. 스왑은 비상시에만 사용됩니다. 너무 많은 응용 프로그램이 동시에 실행되고 메모리 스파이크가 발생하는 순간. 스왑이 없으면 메모리 부족 오류가 발생합니다. 스왑 사용은 개발 및 프로덕션 팀의 실패라고 생각합니다. 이것은 우리가 여기서 논의한 것 이상으로 진행되는 의견 일뿐입니다. 물론 내 응용 프로그램 자체로는 뛰어난 메모리 관리 기능이 있습니다.

이것은 귀하의 질문에 대한 답변이 아닙니다. 그러나 정보에 입각 한 결정을 내리는 데 도움이되는 추가 정보 만 있습니다.

어떤 프로세스가 스왑을 얼마나 많이 사용하고 있는지 알고 싶다면 다음은 약간의 쉘 스크립트입니다.

#!/bin/bash

set -o posix
set -u

OVERALL=0
for DIR in `find /proc/ -maxdepth 1 -type d -regex "^/proc/[0-9]+"` ; do
  PID=`echo $DIR | cut -d / -f 3`
  PROGNAME=`ps -p $PID -o comm --no-headers`

  SUM=0
  for SWAP in `grep Swap $DIR/smaps 2>/dev/null| awk '{ print $2 }'` ; do
    let SUM=$SUM+$SWAP
  done
  echo "PID=$PID - Swap used: $SUM - ($PROGNAME )"

  let OVERALL=$OVERALL+$SUM
done
echo "Overall swap used: $OVERALL"

또한 tmpfs도 스왑 아웃 될 것임을 추가해야합니다. 이것은 tmpfs를 사용하여 사용자 공간 / tmp 오버레이를 생성하는 systemd를 사용하는 최신 Linux 시스템에서 더 일반적입니다.

에이전트가 과도하게 교환 할 때 MySQL 클러스터 복제가 느려지거나 실패하는 것을 알았습니다. 어쩌면 일부 응용 프로그램은 일부 스와핑의 이점을 얻지 못하거나 심지어 이점을 얻을 수도 있지만 데이터베이스는 실제로 문제를 겪고있는 것 같습니다. 그러나 포럼에서 본 많은 토론은 특정 작업 부하 토론에서 비 컨텍스트 화 된 스왑에 대해 설명합니다.

DBA 세계에서 합의는 "MySQL (또는 실제로 다른 DBMS)을 실행할 때 스왑 공간에서 I / O를보고 싶지 않다는 것이 상식입니다. 캐시 크기 조정 (사용 MySQL의 경우 innodb_buffer_pool_size)는 사용 가능한 메모리가 충분하므로 스와핑이 필요하지 않은 표준 사례입니다.

그러나 실수 나 계산 오류가 발생하고 교체가 발생하면 어떻게됩니까? 실제로 성능에 얼마나 영향을 줍니까? 이것이 바로 내가 조사하기 시작한 것입니다. "

독자들이 다음 링크가 제공되기를 바랍니다.

https://www.percona.com/blog/2017/01/13/impact-of-swapping-on-mysql-performance/

https://www.percona.com/blog/2010/01/18/why-swapping-is-bad-for-mysql-performance/