Linux에서 스왑 크기가 지속적으로 증가하고 스왑 공간이 회수되지 않습니까?


10

4 개의 Tomcat 서버가 실행되는 8GB RAM Linux 상자가 있습니다. 그중 하나는 3000MB 메모리 (jvm -Xms 및 -Xmx 설정)로 설정되고 다른 하나는 1500MB로 설정됩니다. 스왑 파티션도 8Gigs로 설정되어 있습니다. 이 서버를 시작할 때 스왑 파일 사용량이 적습니다. 그러나 일정 기간 동안 그리고 서버 중 하나 / 모든 서버가 최대 활동 상태 인 특정 시간 동안 스왑 사용량이 증가하기 시작합니다. 전형적인 sar -r 출력은 다음과 같습니다.

kbmemfree kbmemused % memused kbbuffers kbcached kbswpfree kbswpused % swpused kbswpcad

48260 8125832 99.41 196440 2761852 7197688 1190912 14.20 316044

75504 8098588 99.08 198032 2399460 7197688 1190912 14.20 316032

현재 사용 된 14.2 % 스왑을 보여줍니다. 재미있는 점은이 비율이 절대 감소하지 않는다는 것입니다 . 그것은 계속 증가하고 30-40 %까지 도달합니다 . 매주 서버를 다시 시작합니다.

최대 활동 기간 동안 % swpused 가 증가하고 활동이 적은 기간 동안 감소 한다고 가정합니다 . 또는 최소한 일정하게 유지됩니다. 이것은 OS가 스왑 공간을 다시 확보하지 못하는 것처럼 보입니다.

free 출력 : free -m 총 사용 된 free shared buffers 캐시 Mem : 7982 7937 45 0 32 2088-/ + 버퍼 / 캐시 : 5816 2166 스왑 : 8191 1163 7028

따라서 최소 2g의 무료 램이 있습니다. 문제는 왜 스왑 공간이 계속 증가하고 OS에 의해 재생되지 않는 것입니까? 또는 무엇이 문제가되는지 알아 내기 위해 이것을 디버깅하는 방법 ..

답변:


12

정보가 디스크로 스왑 아웃되고 나중에 메모리로 다시 읽 히면 스왑 공간이 부족해질 때까지 스왑 영역에 할당 된 상태로 남아있는 경우가 많습니다. 즉, 동일한 정보를 나중에 다시 교체해야하는데 변경되지 않은 경우 OS는 디스크 절약 시간에 아무것도 쓰지 않고도 할당 된 RAM에서 페이지를 삭제할 수 있습니다.

메모리로 다시 읽은 항목에 할당 된 스왑은 해제됩니다.

  1. 관련 페이지가 더 이상 필요하지 않은 경우 (즉, 응용 프로그램에서 해제)
  2. 관련 페이지가 변경 될 때 (디스크의 사본이 더 이상 최신 상태가 아님)
  3. 머신은 스왑 공간이 부족하여 이미 RAM에있는 일부 공간을 확보하여 공간을 확보합니다.

/proc/meminfo"SwapCached"라는 행을 찾으십시오 . 이 항목은 RAM 및 스왑 파티션에서 발견 된 페이지를 계산합니다. 예를 들어 작은 VM을 임의로 선택하면 /proc/meminfo내 VM 중 하나 인 가상 파일에 다음과 같이 표시됩니다.

SwapTotal:        698816 kB
SwapFree:         624520 kB
SwapCached:        17232 kB

74268K의 스왑 공간이 할당되었지만 해당 페이지의 17232K 가치도 현재 RAM에도 매핑되어 있음을 나타냅니다 (따라서 다른 공간이 필요한 경우 스왑에서 즉시 통지를 교환 할 수 있음).

또한 오래 전에 교체되어 다시는 사용 된 적이없는 페이지가있을 것입니다. 커널은 스왑에서 페이지를 다시로드하지 않습니다. 여유 RAM은 캐시 또는 버퍼에 더 잘 사용될 수 있기 때문에 다시 읽을 수있는 여유 RAM이 있기 때문에 스왑에서 페이지를 다시로드하지 않습니다. 스왑에 작성된 페이지는 일반적으로 다음에 필요할 때만 다시 읽습니다.

여유 및 / 또는 여유가 충분한 경우 (예 : free + cache + buffers (c + b 카운트에서 해제 할 수없는 RightThisInstant가없는 부분)) 스왑 상태를 지우려면 돌리십시오. 을 사용하여 껐다가 다시 켭니다 swapoff -a && swapon -a.

물론 메모리 누수가 발생할 수도 있지만 이것이 현재보고있는 동작에 대한 유일한 설명은 아닙니다.


훌륭한 답변입니다. 감사합니다. 따라서 내 시스템은 현재 SwapTotal : 8388600 kB SwapFree : 7197688 kB SwapCached : 595724 kB를 보여줍니다. 실제 스왑 무료 = 7197688 + 595724 = 7793412. Actul Swap Used = 8388600-7793412 = 595188 == 581MB. 4 개의 앱이 실행되는 8GB 시스템에 581MB의 스왑 파일 사용이 합리적이라고 생각합니다. 다음 며칠 동안 이것을 모니터링하고 swapCached 수치가 % swapUsed에 비례하여 증가하는지 확인하십시오.
Zenil

2

기본적으로, 당신은 이것에 대해 신경 쓸 필요가 없습니다. 알아야 할 중요한 것은 스왑으로가는 IO의 양입니다 ( 'vmstat'명령 참조). 스왑에 더 많은 물건이 있으면 비용이 들지 않습니다. 유일한 비용은 스왑에 물건을 넣거나 (페이지에 넣는) 것입니다. 따라서 OS가 스왑을 늘리는 것은 완벽하게 합리적입니다.


1
스왑이 증가하고 감소하지 않는 이유를 파악하는 것이 중요합니다. 서버가 몇 주 동안 계속 실행되도록하려면 어떻게해야합니까? 스왑이 제한을 초과하여 메모리 문제가 발생합니까? 스왑 인 / 스왑 아웃은 "합리적"으로 보입니다. 피크 활동 기간 동안 스왑 인 / 스왑 아웃이 높으며 (또한 % swapused 증가) 정상 기간 동안 스왑 인 / 스왑 아웃은 최소이지만 % swapused는 감소하지 않습니다
Zenil

0

사용 가능한 스왑 공간이 있으면 운영 체제에서 스왑 공간을 비울 필요가 없습니다. 남은 공간이 없으면 해제됩니다. 이 상황에 처했을 때 분명히 문제가 있습니다.


0

서버가 문제가되는지 확인하기에 충분한 시간 동안 서버를 실행하지 않는 한 이것이 결국 문제가 될 것인지 알 수있는 방법은 없습니다.

기본적으로 OS는 새로운 프로그램이 시작될 때 항상 사용 가능한 메모리를 일부 메모리를 확보하기 위해 스왑합니다. 스왑 공간은 필요할 때까지 해제되지 않으므로 100 % 스왑 공간을 사용할 수 있으며 성능 문제가 없습니다. 걱정할 것은 이것이 메모리 누수로 인한 것인지입니다. 반드시 메모리 누수는 아니지만 가능할 수 있습니다.

Java는 메모리 누수가 발생하기 쉽지 않지만 특히 복잡한 앱에서 발생할 수 있습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.