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


13

컴퓨터에서 zram을 압축 RAM 백업 스왑으로 사용하고 있습니다. 시스템이 무언가를 교체해야 할 때 zram-backed swap 파일로 교체하는 것은 메모리를 비우기 위해 해당 데이터를 메모리에서 압축하는 것과 다소 비슷합니다. 이것은 디스크 백업 스왑에 비해 대부분의 시간을 매우 빠르게 스와핑합니다. 이 때문에 실제로 디스크를 쓰지 않고 사용할 수 있기 때문에 시스템에서 사용하지 않는 것들을보다 적극적으로 스왑하도록 장려하여 얻을 수있는 성능이 있는지 궁금합니다.

vm.swappinesszram을 사용하는 동안 100으로 설정 하는 사람이 있습니까? 이것이 바람직한가?

sysctl -w vm.swappiness=100

2
이것은 훌륭한 질문이며, 일부 벤치마킹은 의견을 제거하고 사실을 파악하기위한 것이라고 생각합니다.
— Geek

좋은 생각, 그리고 zram은 내가 그것을 마지막으로 사용한 2012 년 이후 개선되었을 수도 있습니다 :-)
— Huygens

작은 테스트를했는데 zram에 대한 "예약 된"메모리가 여전히 캐시로 사용된다고 말할 수 있습니다. 이것이 확인되면 CPU 사이클을 피하기 위해 swappiness를 낮게 유지하는 것이 합리적이라고 생각합니까?
— Vitor

답변:


2

나는 스왑 성을 더 높이는 것을 권장하지 않습니다. 커널의 일반적인 메커니즘은 스왑에 페이지 (메모리 청크)를 넣어 다른 실행중인 작업을 위해 일부 메모리를 해제한다는 것입니다.

커널이 n 페이지를 비우기를 원할 때 첫 번째 "문제", m (m <n, m은 n을 유지하는 데 필요한 압축 된 페이지 수)이 RAM에 새로 생성됩니다. 커널을 방해 할 수 있는지 확실하지 않습니다. 아니.

그러면 스왑에 페이지가 있으면 나중에 스왑에 일부 페이지와 함께 응용 프로그램을 사용할 수 있습니다. 커널이하는 일은 해당 페이지를 실제 메모리로 다시 가져 오는 것이지만 스왑에서 제거하지는 않습니다 (표준 스왑을 사용 하면 캐싱 으로 볼 수 있으므로 응용 프로그램이 백그라운드로 돌아갈 때 커널은 해당 페이지를 다시 쓸 필요가 없습니다) 느린 스왑으로). 그러나 zram을 사용하면 메모리에 zram의 m 페이지와 메모리에있는 n 페이지가 있기 때문에 현명한 트릭이 아닐 수도 있습니다!

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

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


zram은 RAM 블록 장치를 제공합니다. 이 블록 장치에 쓰여진 모든 것이 압축됩니다. zram 블록 장치가 스왑으로 사용되는 경우, 시스템이 스왑을 위해 메모리의 일부를 이동하려고하면 대상으로 복사되기 전에 데이터가 압축되는 것을 제외하고는 RAM의 한 부분에서 다른 부분으로 메모리를 효과적으로 이동합니다. 이는 메모리가 제한된 시스템에서 응답 성을 향상시키기위한 저렴한 메모리 압축 메커니즘으로 효과적으로 작동합니다. ... Zram은 Linux 2.6.33부터 스테이징되었습니다. 3.14에서 zram은 스테이징에서 드라이버 / 블록 / zram으로 이동했습니다.
— Geek

1
@ElderGeek 정확히! 그리고 왜 이것이 완벽하지 않은지를 설명하기 위해 예를 들겠습니다. 커널은 64MB의 RAM을 제거하려고 시도하여 zram 스왑에 넣습니다. 압축 된 64MB 청크는 이제 32MB입니다. 결과적으로 메모리는 64MB가 아닌 32MB만큼 줄어 듭니다. 이제 응용 프로그램이 64MB의 메모리를 다시 필요로 할 때, 커널 사본은 메모리에서 청크를 다시 이동시킵니다. RAM이 64MB이고 zram이 32MB입니다. 왜 복사합니까? 내가 대답에서 설명한대로 커널이 페이지를 캐시하기 때문입니다. 두 가지 행동 모두 이상적이지 않습니다. 그리고 메모리가 잘 압축되지 않으면 더 나빠집니다.
— Huygens

아직 테스트 단계에 있습니다. 압축되지 않은 RAM으로 압축 된 페이지를 다시 복사 할 때 zram이 압축 페이지를 해제하는 데 사용하는 캐싱 알고리즘을 조정하는 방법이 있어야한다고 생각합니다.
— Geek

나는 2012 년까지 여러 번 시도했다. 그 당시 내 컴퓨터는 1GB의 RAM으로 제한되어 있었고 인터넷을 탐색하는 동안 고통이 느렸다 (일반적으로 10-50 개의 탭이 열려 있음). 그러나 그 이후로 나는 그것을 다시 사용하지 않았습니다. 스왑을 더 이상 사용하지 않는 RAM이 충분합니다. 당시 Firefox에서 zram을 사용할 때, 내가 가진 작은 RAM이 있으면 "스왑"을 빨리 시작했습니다. 그리고 빠르게 충돌이 많은 시스템이 응답하지 않았습니다. zram이 없으면 고통스럽게 느리지 만 적어도 안정적이었습니다. 내 문제는 아마도 메모리 페이지를 지속적으로 압축 / 압축 해제하는 것이 었습니다.
— Huygens

예, 8GB 시스템에서 인코딩 작업 중에 여러 VM을 시작하여 OOM을 강제 실행할 수있었습니다. zswap에 대한 경험이 있습니까? 내가 읽은 것을 기반으로 실행 가능한 대안으로 보입니다.
— Geek

2

짧은 대답은 : vm.swappiness=100입니다 적절한 값 zram를 들어 (리눅스 4.9와 데비안 스트레치에 적어도, 나는 그 최고의 가치라고 생각)

나는 이미 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$ 

0

메모리가 가득 차면 페이지를 디스크로 교체해야합니다. 메모리가 가득 찼을 때 메모리를 사용하여 페이지를 스왑 할 장소를 만드는 경우 압축에 차이가있는 경우를 제외하고는 메모리가 목적을 능가한다고 생각할 것입니다. 교환). 컴퓨터가 메모리 속도에 비해 압축 및 압축 해제 속도가 빨라짐에 따라이를 벤치마킹해야 할 것 같습니다.


시스템에 메모리가 부족할 때 zram 기반 스왑 자체가 매우 유용하다는 것을 알았습니다. 그것은 지옥을 완전히 바꾸고 다시 시작 해야하는 몇 번의 시간을 절약했습니다 (큰 데이터 세트를 분석하고 있으므로 24GB의 메모리가 필요합니다). vm.swappiness디스크 백업 스왑에 대해 값을 조정 했는지 여부 와 zram-backed 스왑을 주로 사용하는 경우 값을 변경 해야하는지 궁금합니다.
— Ryan C. Thompson

1
"정말 빠르다"? 온 디맨드 압축은 지난 10 년 이상 직접 디스크 I / O보다 성능이 우수했습니다 (메모리 액세스보다 빠를 수는 없습니다
— symcbean

symcbean에서는 "메모리 속도와 비교하여"를 잊었습니다. 의견 불일치는 어디에 있습니까?
— Alexander

symcbean의 요점은 압축 메모리 백업 페이지 (zram)의 목표는 물리적 매체로의 교체를 대체하는 것입니다. "메모리를 직접 압축하는 것이 자연스럽지 않은"이유는 응용 프로그램이 메모리의 어느 부분을 압축 할 수 있고 언제 압축해야하는지 결정해야하기 때문에 복잡하기 때문입니다. VM 하위 시스템은이를 구현하기가 훨씬 쉬운 곳입니다. zram의 이점이있는 작업 부하에는 작업 세트에없고 쉽게 압축 할 수있는 페이지가 있습니다.
— Daniel Papasian 2016 년
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.