메모리 가득 참 관련 충돌을 피하기 위해 SSD 스왑을 사용합니다. SSD에서 수행할 수 있는 삭제 횟수는 제한되어 있습니다. 메모리 관련 충돌은 중지되었지만 내 시스템은 vmstat거의 모든 기간 동안 지속적으로 스왑을 사용하고 si etc != 0을 표시합니다. 나는 /etc/sysctl.conf스왑 사용량을 줄이고 덤프 캐시에 대한 부담을 높이기 위해 접근 방식을 변경했지만 사용 가능한 메모리가 GB일 때 여전히 find swap을 사용합니다.
스왑 사용량을 줄이기 위해 몇 가지 사항을 변경했습니다.
$ cat /proc/sys/vm/swappiness
1
$ cat /proc/sys/vm/vfs_cache_pressure
200
캐시로 강제 교체하는 임시 솔루션은 다음과 같습니다.우분투에 관해 질문하기, 그러나 메모리를 적극적으로 모니터링하지 않을 때는 작동하지 않습니다.
운영 체제: Pop 20.04 포커스, 커널: x86_64 Linux 5.11.0-7612-generic
답변1
더 깊이 파고드는 것을 제안합니다잠재적인문제야, 너의 문제야진짜해결 및 기타 솔루션을 시도하십시오.저것질문. 또는 적어도 운영 체제가 스왑 공간을 활용하는 방법을 더 잘 이해하십시오.
많은 사람들은 SWAP 공간이 여유 RAM을 사용할 수 있는 경우에만 사용된다고 잘못 생각합니다.필요. 일반적으로 말하면(Linux 커널에 대해서는 잘 모르겠습니다!) 스왑 공간이 있는 운영 체제는 최근에 사용되지 않은 것으로 생각되는 RAM 블록을 교체합니다.방문했다: 스왑이 올바른지 확인하는 알고리즘이 거의 없음필요RAM이 가득 찼기 때문에 최근에 RAM을 사용하지 않은 경우에만 만료됩니다.방문했다. 따라서 일정 기간 동안 시스템을 유휴 상태로 두고 시스템이 유휴 상태이고 일부 프로그램이 메모리 공간의 일부에 액세스하지 않아 RAM에 액세스하지 못하는 경우 운영 체제는 해당 RAM이 있음에도 불구하고 여전히 해당 RAM의 일부를 교체합니다. 아직 여유 메모리가 충분합니다.
이 질문은 이것을 보여줍니다.우분투에 물어보세요, 사용자는 운영 체제가 며칠 동안 시스템을 유휴 상태로 두면서 공간을 교체하기 위해 대부분의 RAM을 교체한 후 시스템을 다시 사용하고 나서 한동안 시스템 성능이 저하되는 현상을 경험하며 운영 체제는 사용된 RAM을 복구하려고 시도합니다. /액세스된 메모리 블록 RAM은 주기적으로 다시 액세스됩니다.
한 가지 접근 방식(가능한 경우)은 SSD를 스왑 공간으로 전혀 사용하지 않는 것입니다. 내 데스크탑에는 내가 사용하는 스왑 파티션이 있는 오래된 500GB 비 SSD 하드 드라이브가 있습니다.
또 다른 접근 방식은 성능 절충입니다. 매분 실행되고 RAM 사용량을 확인하는 스크립트에 대한 cron 작업을 생성합니다. RAM 사용량이 60%를 초과하면 swapon(적절한 매개변수와 함께) 스왑을 사용합니다.문서필요한 경우. RAM 사용량이 40% 미만으로 떨어지면 swapoff스왑 파일의 사용이 비활성화되고 운영 체제가 물리적 RAM으로 스왑을 다시 "드레이닝"할 수 있습니다. 물론 활성화/비활성화하려면 이전에 생성되고 적절하게 초기화된 스왑 파일이 필요합니다. (그리고 임계값을 다르게 만듭니다. 동일한 값(예: 50%)으로 설정하면 다음과 같은 문제가 발생합니다.이기다RAM 사용량이 50% 바로 위에서 50% 바로 아래 사이를 맴돌 때. 일반적으로 시스템을 사용하는 방식에 따라 이러한 값을 미세 조정하십시오. )
나는 다른 사람들이 다른 방법과 기술을 사용했다고 확신합니다. 마찬가지로 SSD 드라이브의 사용이 증가함에 따라 꼭 필요한 경우가 아니면 SSD 기반 스왑 파티션의 사용을 줄이기 위해 커널 알고리즘이 수정될 수 있습니다.