충분한 여유 메모리가 남아있을 때 스왑이 사용되는 이유는 무엇입니까?

35

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

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 명을 넘지 않습니다 ...

linux mysql php

— 사용자 1179459
소스

리눅스에서 애플리케이션이 CPU의 100 % 이상을 사용할 수 있습니까? 음 ...

— BlueRaja

5

@BlueRaja : 예. Linux에서 CPU 사용률은 시스템의 모든 CPU가 아니라 단일 CPU를 기준으로 측정되기 때문입니다. 따라서 CPU가 8 개인 시스템에서는 최대 800 %의 CPU를 사용할 수 있습니다.

— Daniel Pryden

??? 어떤 버전의 MySQL을 사용하고 있습니까 ???

— RolandoMySQLDBA

@RolandoMySQLDBA 버전 5.5

— user1179459

61

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

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

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

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

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

— 데이비드 슈워츠
소스

이 경우 때때로 스왑 공간이 전혀 사용되지 않는 이유를 설명 할 수 있습니다. MEM : 4087592k 사용 49554484k 총, 45466892k 무료, 349244k 버퍼 스왑 : 94204k 총, 0K 사용, 94204k 무료는 1113644k 캐시

— ananthan

4

@ananthan : 여러 가지 이유가있을 수 있습니다. 버퍼링 된 쓰기로 인해 시스템이 메모리를 전혀 사용하지 않았을 가능성이 높으므로 기회주의 스왑 코드가 트리거되지 않았을 수 있습니다. 또한 누군가가 어떤 스왑 사용량이 나쁜와 잘못 조정 기회 주의적으로 스왑이 아닌 시스템 (줄임으로써 그렇게 생각 일 수 있었다 swappiness를 ).

— David Schwartz

6

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

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

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

— brain99
소스

아니요-스왑 사용량이 상위 워터 마크가 아닙니다. 스왑 아웃 된 페이지가 다시 매핑되면 디스크 페이지는 사용 중이 아닌 것으로 표시됩니다 (그러나 여전히 데이터를 포함 할 수 있음).

— symcbean

스왑 사용이 가능한 시나리오 하나만 언급했지만 실제로 실제 메모리가 충분하지 않은 증상은 아닙니다. 위의 David Schwartz가 설명했듯이

— brain99

3

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

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

— 혼돈의 데몬
소스

1

이것은 캐시 / 버퍼가 재생되는 경향을 증가시킵니다. 불행히도 29.53 %의 수치에 버퍼 / 캐시가 포함되어 있는지 여부는 원래의 질문에서 명확하지 않습니다. 이 dbms가 innodb를 광범위하게 사용하고 있다면 아마도 잘못 구성되었을 것입니다 (웹 서버로 사용하기위한 단일 8 코어 16gb 상자가 시작하는 BAD deisgn 선택

— 이지만

왜 웹 서버에 대한 나쁜 선택이라고 말합니까? 난 .... 내이 70 %이다 읽고 30 %를 기록하기 때문에 많이 나는 아직도의 MyISAM을 선호 InnoDB에 사용 해달라고

— user1179459

1

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

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

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

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

— jfg956
소스