충분한 여유 메모리가 남아있을 때 스왑이 사용되는 이유는 무엇입니까? 꽤 좋은 웹 (전용)

메모리 리소스가 좋은 꽤 좋은 웹 (전용) 서버가 있습니다.

System information
Server load     2.19 (8 CPUs)
Memory Used     29.53% (4,804,144 of 16,267,652)
Swap Used   10.52% (220,612 of 2,097,136)

보시다시피, 사용 가능한 메모리가 충분할 때 서버에서 스왑을 사용하고 있습니다.

이것이 정상입니까 아니면 구성이나 코딩에 문제가 있습니까?

NB
My MySQL 프로세스가 어떤 이유로 CPU 전력의 160 % 이상을 사용하고 있습니다. 이유를 모르겠지만 동시 사용자 수가 70 명을 넘지 않습니다 …



답변

이것은 완벽하게 정상입니다.

시스템 시작시 여러 서비스가 시작됩니다. 이러한 서비스는 자체 초기화, 구성 파일 읽기, 데이터 구조 작성 등을 수행합니다. 그들은 약간의 메모리를 사용합니다. 이러한 서비스 중 상당수는 사용하지 않기 때문에 시스템이 가동되는 전체 시간 동안 다시 실행되지 않습니다. 그들 중 일부는 몇 시간, 며칠 또는 몇 주 안에 실행될 수 있습니다. 그러나이 모든 데이터는 실제 메모리에 있습니다.

물론 시스템은이 데이터를 버릴 수 없습니다. 문자 그대로 액세스 할 수 없음을 증명할 수 없습니다. 예를 들어 이러한 서비스 중 하나는 상자에 대한 원격 액세스를 제공하는 서비스 일 수 있습니다. 일주일에 사용하지 않았을 수도 있지만 사용하면 더 잘 작동합니다.

그러나 시스템은 디스크 캐시와 같은 용도로 또는 성능을 향상시키는 다른 방법으로 해당 실제 메모리를 사용할 수 있음을 알고 있습니다. 따라서 기회 교환이 이루어집니다. 더 좋은 방법이 없으면 스왑 공간을 사용하여 오랫동안 사용하지 않은 데이터를 디스크에 씁니다. 그러나 여전히 페이지를 실제 메모리에 유지합니다. 따라서 교체하지 않고도 액세스 할 수 있습니다.

이제 나중에 시스템이 다른 물리적 메모리를 필요로하면 스왑을 위해 이미 작성된 페이지를 버릴 수 있습니다. 이것은 시스템에게 두 세계의 최고를 제공합니다. 데이터는 여전히 메모리에 보관되므로 디스크에서 읽을 필요없이 액세스 할 수 있습니다. 그러나 시스템에 다른 목적으로 해당 메모리가 필요한 경우 먼저 메모리를 쓸 필요가 없습니다. 사방에서 큰 승리.


답변

과거에 언젠가 컴퓨터에 실제 RAM보다 많은 메모리가 필요한 경우에 발생할 수 있습니다. 당시 일부 데이터는 스왑 공간에 기록되었습니다.

나중에 메모리가 해제되면 스왑의 데이터는 자동으로 RAM으로 다시 읽히지 않습니다. 이는 스왑의 데이터가 실제로 일부 프로세스에 필요한 경우에만 발생합니다. 이것은 완벽하게 정상입니다.

mysql 프로세스의 경우 :이 모든 것은 실행하는 쿼리 유형에 따라 다릅니다. 이론적으로는 사용자 수에 관계없이 매우 복잡한 쿼리로 충분할 수 있습니다. 느린 쿼리 로그를 활성화하여로드가 많은 쿼리에 대한 통찰력을 얻을 수 있습니다.


답변

이 동작을로 변경하여 sysctl -w vm.swappiness=10실제로 필요할 때까지 스왑 사용을 크게 줄일 수 있습니다.

MySQL의 경우, tuning-primer.sh 스크립트를 사용하여 최소한 기본 구성 테스트를 수행 했습니까?


답변

David가 설명했듯이 이는 Linux 커널의 정상적인 동작 일 수도 있지만 MySQL의 “swap insanity”문제 일 수도 있습니다. 귀하의 경우 (8 CPU, 총 16GB RAM, 5GB 사용) 컴퓨터는 4 개의 노드 (소켓)와 4GB의 RAM 및 4 개의 MySQL InnoDB 버퍼 풀을 갖춘 NUMA 시스템이어야합니다 GB.

간단히 말해서 (자세한 내용은 위의 링크를 읽으십시오), 이것은 다음과 같습니다.

  1. 시스템이 시작되면 프로세스는 일부 메모리를 사용하여 모든 NUMA 노드에 분산됩니다.
  2. MySQL이 시작되면 InnoDB 버퍼 풀에 4GB를 할당하여 NUMA 노드의 RAM을 채우고 다른 노드의 일부 RAM을 사용합니다.
  3. 그런 다음 할당 된 RAM을 한 NUMA 노드에서 다른 NUMA 노드로 이동할 수없는 Linux 커널은 굶주린 노드에서 페이지를 교체하는 것이 좋습니다 (또는 페이지를 교체해야하므로 페이지를 교체해야 함) 고 생각합니다.

이를 피하려면 MySQL의 메모리 할당을 변경하여 모든 코어에 RAM을 할당하십시오 (자세한 내용은 위의 링크 참조).


답변