zram을 사용할 때 vm.swappiness의 적절한 값은 무엇입니까?

zram을 사용할 때 vm.swappiness의 적절한 값은 무엇입니까?

내 컴퓨터에서 압축된 RAM 지원 스왑으로 zram을 사용하고 있습니다. 시스템이 무언가를 교체해야 할 때 이를 zram 지원 스왑 파일로 교체하는 것은 해당 데이터를 메모리 내에서 압축하여 공간을 확보하는 것과 거의 동일합니다. 이로 인해 디스크 지원 스왑에 비해 대부분의 경우 스왑이 매우 빠르게 이루어집니다. 이 때문에 시스템이 실제로 디스크에 영향을 주지 않고 사용하지 않는 항목을 더 적극적으로 교체하도록 장려함으로써 어느 정도 성능을 얻을 수 있는지 궁금합니다.

vm.swappiness그렇다면 zram을 사용하는 동안 100으로 설정하는 등의 문제를 겪은 사람이 있습니까 ? 이것이 바람직할까요?

sysctl -w vm.swappiness=100

답변1

짧은 대답: vm.swappiness=100이다적절한 값zram의 경우(적어도 Linux 4.9가 설치된 Debian Stretch에서는 이것이 최고의 가치라고 생각합니다)

나는 이미 vm.swappiness=100나를 위해 테스트했습니다.

내 생각엔 당신이 할 수 있을 것 같아요몇 가지 간단한 테스트어떤 가치가 귀하에게 가장 적합한지 확인하세요.

또한 내가 만든또 다른 간단한 프로그램이 질문을 테스트해 보세요. x 내 컴퓨터에서 매우 낮은 vm.swappiness값(예: vm.swappiness=1)은 명백한 응답성 문제를 일으킬 것입니다.

소개 :SwapCached/proc/meminfo

먼저 vm.page-cluster=0이것을 시도해 보세요.SwapCached아마도 교체로 인해 쓸모없는 것을 줄일 수 있습니다 .

SwapCached는 zram이 아닌 스왑 장치와 동일하게 zram 속도를 높일 수 있습니다.

SwapCached필요할 때 재사용(무료)할 수 있습니다.

./linux-4.9/mm$ grep -rn delete_from_swap_cache
memory-failure.c:715:   delete_from_swap_cache(p);
shmem.c:1115:       delete_from_swap_cache(*pagep);
shmem.c:1645:            * unaccounting, now delete_from_swap_cache() will do
shmem.c:1652:               delete_from_swap_cache(page);
shmem.c:1668:       delete_from_swap_cache(page);
vmscan.c:673:       __delete_from_swap_cache(page);
swap_state.c:137:void __delete_from_swap_cache(struct page *page)
swap_state.c:218:void delete_from_swap_cache(struct page *page)
swap_state.c:227:   __delete_from_swap_cache(page);
swapfile.c:947:         delete_from_swap_cache(page);
swapfile.c:987: delete_from_swap_cache(page);
swapfile.c:1023:            delete_from_swap_cache(page);
swapfile.c:1571:            delete_from_swap_cache(page);
./linux-4.9/mm$ 

답변2

나는 교환성을 더 높게 설정하는 것을 권장하지 않습니다. 커널의 일반적인 메커니즘은 다른 실행 작업을 위해 일부 메모리를 확보하기 위해 페이지(메모리 덩어리)를 스왑에 넣는 것입니다.

커널이 n 페이지를 해제하려고 할 때 첫 번째 "문제"는 m(m < n인 경우, m은 n을 보유하는 데 필요한 압축된 페이지 수)이 RAM에 새로 생성되는 경우입니다. 이것이 커널을 방해할 수 있는지 또는 확실하지 않습니다. 아니다.

어쨌든 스왑에 페이지가 있으면 나중에 스왑에 있는 일부 페이지와 함께 애플리케이션을 사용할 수 있습니다. 커널이 하는 일은 해당 페이지를 물리적 메모리로 다시 가져오는 것이지만 스왑(표준 스왑에서는 다음과 같이 볼 수 있음)에서 제거하지는 않습니다.캐싱, 따라서 애플리케이션이 백그라운드로 돌아갈 때 커널은 해당 페이지를 느린 스왑에 다시 쓸 필요가 없습니다. 그러나 zram을 사용하면 아마도 현명한 트릭이 아닐 것입니다. 왜냐하면 zram의 m 페이지 + 다시 메모리에 있는 n 페이지를 메모리에 갖게 되기 때문입니다!

커널은 일반적으로 업무를 수행하는 데 사용할 수 있는 "총 메모리"를 가지고 있습니다. zram을 추가하면 디스크 기반 스왑과 마찬가지로 "스왑" 메모리에서만 계산되지만 실제 "총 메모리"는 줄어들고 이는 커널에서 예상/예상하지 않습니다. 때로는 이로 인해 이상하고 원치 않는 행동을 할 수도 있습니다!

zram을 사용하면 메모리가 부족할 때 커널이 이 영역으로 너무 많이 스왑하지 않는 것이 좋을 것입니다. 그리고 항상 zram 최대 크기보다 더 큰 실제 하드 디스크 스왑 파티션을 가져야 합니다. 그래야 시스템이 OOM을 얻지 못하는 동시에 free! 에서 보고한 대로 충분한 여유 공간을 볼 수 있습니다.

답변3

https://wiki.archlinux.org/title/Zram#Optimizing_swap_on_zram

이 값은Pop!_OS가 사용하는 것. That Pop!_OS GitHub 풀 요청은 다음 링크에도 연결됩니다.r/Fedora에서 사용자가 수행한 일부 테스트, 이는 vm.page-cluster = 0이 이상적이라고 결정했습니다. 그들은 또한 높은 교환성 값이 이상적이라는 것을 발견했습니다. 이는 다음에서 제안한 것과 일치합니다.커널 문서:

기본값은 60입니다. zram 또는 zswap과 같은 메모리 내 스왑과 파일 시스템보다 빠른 장치에서 스왑을 수행하는 하이브리드 설정의 경우 100을 초과하는 값을 고려할 수 있습니다. 예를 들어 스왑 장치에 대한 임의 IO가 파일 시스템의 IO보다 평균 2배 빠른 경우 스왑 성능은 133(x + 2x = 200, 2x = 133.33)이어야 합니다.

답변4

메모리가 가득 차면 페이지를 디스크로 교체해야 합니다. 메모리가 가득 찼을 때 페이지를 교환할 장소를 만들기 위해 메모리를 사용하는 경우 압축으로 인해 차이가 나는 경우를 제외하고는 목적에 부합한다고 생각할 수 있습니다. 그런 다음 압축을 거치는 대신 메모리를 직접 압축하는 것이 자연스럽습니다. 교환). 컴퓨터의 압축 및 압축 해제 속도가 메모리 속도에 비해 점점 더 빨라지고 있기 때문에 이를 벤치마킹해야 할 것 같습니다.

관련 정보