답변:
여전히 스왑이 있는지 확인하는 프로세스가 있습니다. 를 줄이기 위해, 당신은 당신의 설정해야합니다 swappiness를 -
"/etc/sysctl.conf"를 루트로 편집 한 다음 변경 (또는 추가)
vm.swappiness = 0
kswapd0어떤 CPU를 복용하고 스왑이없는 시스템은 거의 RAM 부족하고 (실제로)에 의해 상황에 대처하려고 실행 파일에서 페이지를 교환한다. 올바른 수정은 작업량을 줄이고 스왑을 추가하거나 더 많은 RAM을 설치하는 것입니다. 커널 에 디스크로 스왑 할 항목에 대한 추가 옵션 이 있으므로 스왑을 추가하면 성능이 향상됩니다 . 스왑이 없으면 커널은 실제로 애플리케이션 코드를 스왑해야합니다.
kswapd0일부 CPU를 사용하고 있고 원하지 않는 경우 swappiness설정을 낮추십시오 . 그러나 쓰기에 어려움을 겪는 SSD (예 : 마모 수준 조정 알고리즘)가 스왑을 지원하지 않으면 swappiness시스템 전체 성능이 저하됩니다. 더 많은 RAM이 필요한 경우 RAM 사본 을 스왑에 보관하는 것이 좋습니다.이 경우 RAM을 사용하기 전에 스왑을 시작하지 않고 RAM 사본을 즉시 버립니다. 이 낙관적 스와핑은 시스템이 충분히 유휴 상태 인 동안에 만 수행되므로 시스템 속도가 느려지지 않아야합니다.
스왑 공간은 다른 파일이 지원하지 않는 데이터에만 사용됩니다. 스왑 장치가 없어도 디스크의 다른 파일 (예 : 실행 프로그램)에서 매핑 된 데이터는 여전히 해당 파일로 스왑됩니다.
리눅스에 메모리가 부족할 때,해야 할 일을하는 대신 스왑 루프에 들어가서 램을 해제하기 위해 프로세스를 중단시키는 것은 잘 알려진 문제입니다. 스왑 및 RAM이 가득 찬 경우에만이를 수행하는 OOM (메모리 부족) 킬러가 있습니다.
그러나 이것은 실제로 문제가되지 않아야합니다. 각각 메모리를 사용하고 캡처하는 탭이있는 Firefox 및 Chrome과 같은 많은 불쾌한 프로세스가있는 경우 이러한 프로세스로 인해 스왑 읽기가 다시 발생합니다. 그런 다음 Linux는 동일한 메모리가 메모리와 하드 드라이브간에 앞뒤로 이동하는 루프에 들어갑니다. 이로 인해 일부 프로세스를 앞뒤로 바꾸면 시스템이 응답하지 않는 우선 순위 반전 이 발생 합니다.
스왑을 비활성화하면 kswapd0에 실행 파일과 같은 매핑 된 메모리를 스왑 할 수있는 옵션이 없으므로이 문제가 악화됩니다. 실행 파일을 교체하면 훨씬 빨리 다시 교체 될 가능성이 훨씬 높습니다.
테스트를 위해 NetBSD 에서이 동작을 트리거하려고 시도했으며 OS 자체가 매우 반응이 좋았을 때 문제가되는 프로세스가 엄청나게 느려졌습니다. 교환 문제가 발생하지만 우선 순위 반전이 없음을 의미합니다. 그러나 NetBSD에는 AMDGPU 드라이버가 없으므로 당분간 Linux를 고수하고 있습니다. 아마도 NetBSD는 실행 파일을 메모리 맵에 저장하지 않기 때문에 스왑 루프에 들어 가지 않지만 왜 응답하지 않는지에 대한 구현에 대해서는 충분히 알지 못합니다.
페이스 북도이 문제를 가지고 있었고 메모리 부족 데몬 인 OOMD를 만들었습니다. 이것은 kswapd0 활동을 감지하고 프로세스 종료를 시작하는 데몬입니다. 그리고 페이스 북에 따르면 이것은 리눅스 서버가 응답하지 않는 문제를 거의 완전히 제거했다. 그러나 나는 그것을 테스트하지 않았으며 다른 서버 또는 데스크탑 / 랩톱에서 얼마나 잘 작동하는지 모르겠습니다. 매력적인 OOMD에는 시스템 프로세스와 서버 시스템의 일부를 유지하기 위해 어떤 프로세스를 먼저 종료해야하는지 결정하는 논리가 있습니다.
그러나 이것이 해결되어야하는 방법은 아닙니다. OOMD는 못생긴 해킹입니다. 실제 솔루션은 스왑 루프로 인한 우선 순위 반전을 수정하고 커널 OOM Killer를 프로세스를 강제 종료하여 메모리를 확보하는 데 더욱 적극적으로 만드는 것입니다. 수정 프로그램은 커널에 속하며, 문제가 제 시간에 감지되고 프로세스가 제대로 종료되고 있는지 확인할 수있는 유일한 곳이기 때문입니다.
swappiness = 0을 설정하면 시스템에 사용 가능한 RAM이 부족할 때 스와핑이 시작되기 때문에 해결책이 없습니다. 시스템이 스와핑을 시작하지 않도록 보장 할 수있는 옵션이 없습니다.
또한 문제가되는 응용 프로그램을 수정해도 문제가 해결되지 않습니다. 사용자가 OS를 응답하지 않게하기 위해이 버그를 악용하려는 경우 비 정기적으로는 아닙니다. 응답하는 것은 커널의 책임입니다. Firefox가 응답하지 않으면 응용 프로그램에 대한 수정입니다. 그러나 자체적으로 응답하지 않고 전체 OS가 매우 느리고 응답하지 않게됩니다. SSH에 로그인하는 데 30 분이 걸릴 수있는 수준. SSH는 아무런 관련이 없으며 실행되지 않으면 시스템의 다른 부분이 아닌 커널의 버그입니다. 그리고 그것은 버그가 아닙니다. 그것은 두 개의 버그입니다. 하나의 버그는 우선 순위 반전인데, 오프 레일 스와핑주기가 문제가되는 프로세스 이외의 다른 프로세스를 방해 할 수 있고 그 자체가 나쁘다는 것입니다. 다른 버그는 t 스왑 루프에 있는지 확인하고 HDD / SSD 또는 스왑을 지원하는 모든 스토리지에 미친 마모를 유발합니다. 실행 파일을 스왑 할 때 디스크에 다시 쓰여지지 않은 읽기 전용 메모리 맵이지만 kswapd0은 여전히 메모리에서 삭제하는 내용을 다시 읽지 못하므로 잠기지 않습니다.
아 그리고 세 번째 버그가 있습니다. 메모리가 부족한 응용 프로그램이 사용 가능한 모든 메모리를 삼킬 때 디스크 캐시를 사용하지 못하도록 보호 할 수있는 방법이 없습니다. 이것이 kswapd0이 시스템을 응답하지 않는 이유 중 하나입니다. 가장 핫 메모리 매핑 데이터는 일반적으로 디스크 캐시에 저장되지만 파이어 폭스가 해당 캐시를 먹었을 때 디스크 읽기가 발생해야 함을 의미합니다.
반드시 Firefox가 문제를 일으키는 것은 아니지만 Chrome이 아닌 기본 브라우저입니다. 그리고 둘 다 리눅스에서 "사용 가능한 메모리"로 간주되는 캐시 및 스왑 메모리를 포함하여 사용 가능한 메모리를 낭비되는 것으로 취급함에 따라이 문제를 유발하는 것으로 널리 알려져 있습니다. 따라서 "사용 가능한 메모리"를 얻지 않기 위해 캐싱 및 기타 자료에 사용합니다. DISK CACHE에 SWAP을 사용하는 것은 매우 나쁜 아이디어이지만 Firefox와 Chrome의 동료는 "사용 가능한 메모리가 낭비됩니다"라는 메시지에 응답합니다.
우리가 여기있는 것은 커널 팀이 버그를 고려하지 않는 세 가지 커널 버그입니다. 그리고 Firefox, Chrome 및 모든 파생 상품의 버그는 버그로 간주되지 않습니다. 이 문제를 조사하고 패치하기 위해 Fedora 랩톱에서 Firefox를 빌드하려고했습니다. 뭔지 맞춰봐. 4GB 램이있는 4 코어 CPU에서 GCC로 Firefox를 빌드하면 PRIORITY INVERSION의 SWAP LOOP이 트리거됩니다. 따라서 다시 작성해야하는 응용 프로그램 중 하나는 GCC입니다. NetBSD에서 발생하는 일은 4 개의 GCC 인스턴스가 하나의 인스턴스를 실행하는 것보다 느리지 만 시스템을 정지 시키지는 않습니다.
예, 이것은 약간의 난폭 한 일이지만 Linux 메모리 하위 시스템뿐만 아니라 응용 프로그램을 일으키는 응용 프로그램의 현재 문제를 분명히하기를 바랍니다.
스왑이없고 kswapd0실행중인 경우 시스템은 실제로 거의 모든 RAM을 사용하고 있습니다. 이제 메모리 사용량 (또는 시스템의 사용 가능한 / 사용 가능한 메모리)을 모니터링하는 더 나은 도구를 얻을 차례입니다.
실제 해결 방법은 메모리 사용량을 줄이거 나 (메모리 누수를 줄이면서 프로세스를 실행하거나, 프로세스를 덜 실행하고, 일부 프로세스를 전혀 실행하지 않고, 일부 서버 소프트웨어의 자식 / 작업자 프로세스 수를 제한) RAM을 늘리는 것입니다. 메모리 누수로 인해 RAM이 필요한 경우 대신 스왑을 사용하도록 선택할 수 있습니다. 리눅스는 누출 된 부분이 충분한 시간에 교체되도록하는 것이 현명해야합니다. 스왑을하는 것이 아무것도 아닌 것보다 낫지 만 적절한 양의 RAM을 대체하는 것은 아닙니다.