Windows에서 AWS의 Linux 인스턴스로 이동한 .NET(Core 2.0) 서비스가 있습니다. 인스턴스는 1GB RAM을 갖춘 마이크로 인스턴스입니다.
Linux 인스턴스에 1GB의 스왑 공간을 추가하고 swappiness=100으로 설정했지만 물리적 메모리가 가득 차면 서버가 작동을 멈춥니다. 프로세스 자체가 느려져 거의 멈출 정도이며 bash에서 Enter 키를 눌러도 새 줄이 나타나는 데 때때로 10초가 걸립니다.
실행하면 top일반적으로 여유 메모리가 10, 20MB로 표시됩니다. 800Mb 이상의 RAM과 스왑을 사용하는 프로세스는 항상 거의 비어 있으며 최대 20MB를 사용합니다. 한 시간 동안 놓아두어도 더 이상 교환되지 않았습니다.
AWS의 디스크 및 CPU 크레딧이 거의 100%에 도달하여 리소스 사용을 제한하지 않는 것을 볼 수 있습니다. 또한 이러한 인스턴스가 약 100개 정도 있는데 여러 번 교체했는데 동작이 항상 동일하므로 별 문제가 되지 않습니다.나쁜 사례문제.
나를 괴롭히는 것은 이것이 Windows에서는 발생하지 않았고 Linux 인스턴스가 기본 시스템에 대해 약 200MB 적은 메모리를 사용한다는 것입니다.
Linux가 더 많은 메모리를 스왑으로 이동하도록 하기 위해 스왑 기능 외에 조정해야 할 설정이 있습니까?
편집하다:cloud-init를 통해 스왑이 올바르게 설정되었으며 재부팅 후에도 정상적으로 유지됩니다.
설정:
fallocate -l 1024M /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
sysctl vm.swappiness=100
free -m부팅 후:
total used free shared buffers cached
Mem: 993 232 760 0 7 152
-/+ buffers/cache: 72 921
Swap: 1023 0 1023
답변1
진짜 문제를 발견했습니다. 애플리케이션이 Docker 내부에서 실행 중이고AWS는 ECS 컨테이너 내에서 스왑 사용을 의도적으로 차단합니다.몇 가지 이유. 이전에는 ECS를 사용하여 Docker를 관리하지 않았기 때문에 이 블록은 창에 영향을 미치지 않았습니다.
지원팀에 문의한 결과 컨테이너 내 스왑을 지원하지 않으며 언제 지원하게 될지 알 수 없습니다. 그래서 저는 ECS에서 나가서 docker를 직접 관리해야 합니다.
답변2
글쎄, 당신의 오류는 실제로 아주 작을 수 있습니다. 이렇게 높은 스왑성 값은 일부 OS 구성에 문제를 일으킬 수 있습니다. 15와 같은 값을 시도해 보세요. (참고: 시스템이 스왑을 선호하도록 강제하는 것은 끔찍한 생각입니다. 시스템이 정상적으로 작동하려면 실제 RAM을 사용해야 합니다. [알지 못했거나 반전한 경우 스왑 가능성은 %입니다. 스왑이 사용되기 전에 RAM이 비어 있으므로 15는 SWAP 파티션을 사용하기 전에 RAM의 85%를 사용해야 한다는 것입니다.])
그리고 스왑 공간은 어떻게 추가하셨나요? 방금 구성을 변경하고 새 파티션을 만들지 않았거나 /etc/fstab 파일에 오류를 남긴 경우 스왑을 사용할 수 없으며 시스템이 거기에 없는 항목에 쓰려고 할 때 스왑 사용이 중단됩니다. 쓸 수 없습니다 (또는 더 흥미로운 일이 일어날 것입니다). 나는 이러한 방법을 통해 두 번 이상의 설치를 중단했습니다.