zram 사용의 가장 큰 단점은LRU 반전:
오래된 페이지는 우선순위가 더 높은 zram에 들어가서 빠르게 채우는 반면, 새로운 페이지는 더 느린 [...] 스왑 안팎으로 스왑됩니다.
그만큼zswap 문서zswap은 이 문제를 겪지 않는다고 말합니다.
Zswap은 Frontswap API를 통해 압축할 페이지를 수신하고 LRU 기반으로 자체 압축 풀에서 페이지를 제거하고 압축 풀이 가득 찬 경우 이를 백업 스왑 장치에 다시 쓸 수 있습니다.
max_pool_percent로 설정하면 zram의 모든 이점과 완전히 압축된 RAM을 얻을 수 있습니까 100?
Zswap seeks to be simple in its policies. Sysfs attributes allow for one user controlled policy: * max_pool_percent - The maximum percentage of memory that the compressed pool can occupy.
max_pool_percent여기에는 기본값이 지정되어 있지 않지만아치 위키 페이지이라고 말합니다 20.
압축 해제의 성능 영향 외에도 max_pool_percent로 설정하는 데 위험/단점이 있습니까 100?
향상된 스왑 지원 zram을 사용하는 것처럼 작동합니까?
답변1
귀하의 질문에 답하기 위해 먼저 일련의 실험을 진행했습니다. 최종 답변은 끝에 굵은 글씨로 표시되어 있습니다.
수행된 실험:
1) swap file, zswap disabled
2) swap file, zswap enabled, max_pool_percent = 20
3) swap file, zswap enabled, max_pool_percent = 70
4) swap file, zswap enabled, max_pool_percent = 100
5) zram swap, zswap disabled
6) zram swap, zswap enabled, max_pool_percent = 20
7) no swap
8) swap file, zswap enabled, max_pool_percent = 1
9) swap file (300 M), zswap enabled, max_pool_percent = 100
실험 전 설정:
- 버추얼박스 5.1.30
- 페도라 27, xfce 스핀
- 512MB RAM, 16MB 비디오 RAM, CPU 2개
- 리눅스 커널 4.13.13-300.fc27.x86_64
- 기본값
swappiness(60) - 일부 실험 중에 사용할 수 있도록 빈 512MB 스왑 파일(실험 9에서는 300MB)을 생성했지만( 사용 ) 아직
dd생성하지 않았습니다.swapon - 모든 dnf* systemd 서비스를 비활성화하고
watch "killall -9 dnf"dnf가 실험 중에 자동 업데이트를 시도하지 않고 결과를 너무 멀리 버리지 않도록 실행했습니다.
실험 전 상태:
[root@user-vm user]# free -m ; vmstat ; vmstat -d
total used free shared buff/cache available
Mem: 485 280 72 8 132 153
Swap: 511 0 511
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 0 74624 8648 127180 0 0 1377 526 275 428 3 2 94 1 0
disk- ------------reads------------ ------------writes----------- -----IO------
total merged sectors ms total merged sectors ms cur sec
sda 102430 688 3593850 67603 3351 8000 1373336 17275 0 26
sr0 0 0 0 0 0 0 0 0 0 0
실험 중 다른 설정으로 이어지는 후속 swapon 작업 등으로 인해 이 값의 약 2% 이내의 차이가 발생했습니다.
실험 작업은 다음과 같이 구성되었습니다.
- 처음으로 Firefox를 실행해 보세요
- 약 40초 동안 또는 네트워크 및 디스크 활동이 중단될 때까지(둘 중 더 긴 시간) 기다립니다.
- 실험 후 다음 상태를 기록합니다(firefox는 계속 실행 중입니다. 실험 7과 9에서 Firefox가 충돌한 경우는 제외).
실험 후 상태:
1) 스왑 파일, zswap 비활성화
[root@user-vm user]# free -m ; vmstat ; vmstat -d
total used free shared buff/cache available
Mem: 485 287 5 63 192 97
Swap: 511 249 262
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
1 0 255488 5904 1892 195428 63 237 1729 743 335 492 3 2 93 2 0
disk- ------------reads------------ ------------writes----------- -----IO------
total merged sectors ms total merged sectors ms cur sec
sda 134680 10706 4848594 95687 5127 91447 2084176 26205 0 38
sr0 0 0 0 0 0 0 0 0 0 0
2) 스왑 파일, zswap 활성화, max_pool_percent = 20
[root@user-vm user]# free -m ; vmstat ; vmstat -d
total used free shared buff/cache available
Mem: 485 330 6 33 148 73
Swap: 511 317 194
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 325376 7436 756 151144 3 110 1793 609 344 477 3 2 93 2 0
disk- ------------reads------------ ------------writes----------- -----IO------
total merged sectors ms total merged sectors ms cur sec
sda 136046 1320 5150874 117469 10024 41988 1749440 53395 0 40
sr0 0 0 0 0 0 0 0 0 0 0
3) 스왑 파일, zswap 활성화, max_pool_percent = 70
[root@user-vm user]# free -m ; vmstat ; vmstat -d
total used free shared buff/cache available
Mem: 485 342 8 32 134 58
Swap: 511 393 118
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 403208 8116 1088 137180 4 8 3538 474 467 538 3 3 91 3 0
disk- ------------reads------------ ------------writes----------- -----IO------
total merged sectors ms total merged sectors ms cur sec
sda 224321 1414 10910442 220138 7535 9571 1461088 42931 0 60
sr0 0 0 0 0 0 0 0 0 0 0
4) 스왑 파일, zswap 활성화, max_pool_percent = 100
[root@user-vm user]# free -m ; vmstat ; vmstat -d
total used free shared buff/cache available
Mem: 485 345 10 32 129 56
Swap: 511 410 101
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
1 0 420712 10916 2316 130520 1 11 3660 492 478 549 3 4 91 2 0
disk- ------------reads------------ ------------writes----------- -----IO------
total merged sectors ms total merged sectors ms cur sec
sda 221920 1214 10922082 169369 8445 9570 1468552 28488 0 56
sr0 0 0 0 0 0 0 0 0 0 0
5) zram 스왑, zswap 비활성화
[root@user-vm user]# free -m ; vmstat ; vmstat -d
total used free shared buff/cache available
Mem: 485 333 4 34 147 72
Swap: 499 314 185
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
5 0 324128 7256 1192 149444 153 365 1658 471 326 457 3 2 93 2 0
disk- ------------reads------------ ------------writes----------- -----IO------
total merged sectors ms total merged sectors ms cur sec
sda 130703 884 5047298 112889 4197 9517 1433832 21037 0 37
sr0 0 0 0 0 0 0 0 0 0 0
zram0 58673 0 469384 271 138745 0 1109960 927 0 1
6) zram 스왑, zswap 활성화, max_pool_percent = 20
[root@user-vm user]# free -m ; vmstat ; vmstat -d
total used free shared buff/cache available
Mem: 485 338 5 32 141 65
Swap: 499 355 144
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
1 0 364984 7584 904 143572 33 166 2052 437 354 457 3 3 93 2 0
disk- ------------reads------------ ------------writes----------- -----IO------
total merged sectors ms total merged sectors ms cur sec
sda 166168 998 6751610 120911 4383 9543 1436080 18916 0 42
sr0 0 0 0 0 0 0 0 0 0 0
zram0 13819 0 110552 78 68164 0 545312 398 0 0
7) 스왑 없음
이 통계를 기록하는 시점에는 이 실험에서 Firefox가 실행되고 있지 않습니다.
[root@user-vm user]# free -m ; vmstat ; vmstat -d
total used free shared buff/cache available
Mem: 485 289 68 8 127 143
Swap: 0 0 0
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
2 0 0 70108 10660 119976 0 0 13503 286 607 618 2 5 88 5 0
disk- ------------reads------------ ------------writes----------- -----IO------
total merged sectors ms total merged sectors ms cur sec
sda 748978 3511 66775042 595064 4263 9334 1413728 23421 0 164
sr0 0 0 0 0 0 0 0 0 0 0
8) 스왑 파일, zswap 활성화, max_pool_percent = 1
[root@user-vm user]# free -m ; vmstat ; vmstat -d
total used free shared buff/cache available
Mem: 485 292 7 63 186 90
Swap: 511 249 262
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
1 0 255488 7088 2156 188688 43 182 1417 606 298 432 3 2 94 2 0
disk- ------------reads------------ ------------writes----------- -----IO------
total merged sectors ms total merged sectors ms cur sec
sda 132222 9573 4796802 114450 10171 77607 2050032 137961 0 41
sr0 0 0 0 0 0 0 0 0 0 0
9) 스왑 파일(300M), zswap 활성화, max_pool_percent = 100
Firefox가 멈췄고 시스템은 여전히 디스크에서 맹렬하게 읽습니다. 이 실험의 기준은 새 스왑 파일이 작성되었기 때문에 다릅니다.
total used free shared buff/cache available
Mem: 485 280 8 8 196 153
Swap: 299 0 299
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 0 8948 3400 198064 0 0 1186 653 249 388 2 2 95 1 0
disk- ------------reads------------ ------------writes----------- -----IO------
total merged sectors ms total merged sectors ms cur sec
sda 103099 688 3610794 68253 3837 8084 1988936 20306 0 27
sr0 0 0 0 0 0 0 0 0 0 0
특히 이 변경으로 인해 추가로 649384개의 섹터가 기록되었습니다.
실험 후 상태:
[root@user-vm user]# free -m ; vmstat ; vmstat -d
total used free shared buff/cache available
Mem: 485 335 32 47 118 53
Swap: 299 277 22
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
7 1 283540 22912 2712 129132 0 0 83166 414 2387 1951 2 23 62 13 0
disk- ------------reads------------ ------------writes----------- -----IO------
total merged sectors ms total merged sectors ms cur sec
sda 3416602 26605 406297938 4710584 4670 9025 2022272 33805 0 521
sr0 0 0 0 0 0 0 0 0 0 0
2022272에서 추가로 작성된 649384개의 섹터를 빼면 1372888이 됩니다. 이는 1433000(나중에 참조)보다 작습니다. 이는 아마도 Firefox가 완전히 로드되지 않았기 때문일 것입니다.
또한 낮은 값(10과 1)으로 몇 가지 실험을 실행했는데 swappiness모두 과도한 디스크 읽기로 인해 정지 상태에 갇혀 최종 메모리 통계를 기록할 수 없었습니다.
관찰:
- 주관적으로 높은
max_pool_percent값은 부진을 초래했습니다. - 주관적으로 실험 9의 시스템은 너무 느려서 사용할 수 없었습니다.
- 값이 높으면
max_pool_percent쓰기 수가 가장 적고, 값이 매우 낮max_pool_percent으면 쓰기 수가 가장 많습니다. - 실험 5와 6(zram 스왑)에서는 Firefox가 데이터를 작성하여 약 62000개의 섹터가 디스크에 기록되었음을 시사합니다. 약 1433000보다 큰 것은 스와핑으로 인해 작성된 섹터입니다. 다음 표를 참조하세요.
- 실험 중 가장 낮은 읽기 섹터 수를 기준으로 가정하면 스와핑으로 인해 발생한 추가 읽기 섹터의 양을 기준으로 실험을 비교할 수 있습니다.
스와핑의 직접적인 결과로 작성된 섹터(대략):
650000 1) swap file, zswap disabled
320000 2) swap file, zswap enabled, max_pool_percent = 20
30000 3) swap file, zswap enabled, max_pool_percent = 70
40000 4) swap file, zswap enabled, max_pool_percent = 100
0 5) zram swap, zswap disabled
0 6) zram swap, zswap enabled, max_pool_percent = 20
-20000 7) no swap (firefox crashed)
620000 8) swap file, zswap enabled, max_pool_percent = 1
-60000 9) swap file (300 M), zswap enabled, max_pool_percent = 100 (firefox crashed)
스와핑의 직접적인 결과로 인한 추가 읽기 섹터(대략):
51792 1) swap file, zswap disabled
354072 2) swap file, zswap enabled, max_pool_percent = 20
6113640 3) swap file, zswap enabled, max_pool_percent = 70
6125280 4) swap file, zswap enabled, max_pool_percent = 100
250496 5) zram swap, zswap disabled
1954808 6) zram swap, zswap enabled, max_pool_percent = 20
61978240 7) no swap
0 (baseline) 8) swap file, zswap enabled, max_pool_percent = 1
401501136 9) swap file (300 M), zswap enabled, max_pool_percent = 100
결과 해석:
- 이는 주관적이며 현재 사용 사례에 따라 다릅니다. 다른 사용 사례에서는 동작이 달라질 수 있습니다.
- Zswap의 페이지 풀은 시스템의 페이지 캐시(파일 지원 페이지용)에서 사용할 수 있는 RAM 공간을 차지합니다. 즉, 시스템이 반복적으로 파일 지원 페이지를 버리고 필요할 때 다시 읽어 과도한 읽기를 초래합니다.
- 실험 7에서 높은 읽기 횟수는 동일한 문제로 인해 발생합니다. 즉, 시스템의 익명 페이지가 대부분의 RAM을 차지하고 파일 지원 페이지를 디스크에서 반복적으로 읽어야 했습니다.
- 특정 상황에서는 0에 가까운 스왑 디스크에 기록되는 데이터 양을 최소화하는 것이 가능할 수 있지만
zswap분명히 이 작업에는 적합하지 않습니다. - "를 가질 수는 없습니다.완전히 압축된 RAM"시스템이 작동하려면 RAM에 상주하기 위해 일정량의 비스왑 페이지가 필요하기 때문입니다.
개인적인 의견과 일화:
- 디스크 쓰기 측면에서 zswap의 주요 개선 사항은 페이지를 압축한다는 사실이 아니라 페이지 캐시를 줄이고 RAM에 더 많은 익명 페이지(압축 형식)를 효과적으로 유지하는 자체 버퍼링 및 캐싱 시스템이 있다는 사실입니다. (그러나 매일 Linux를 사용하면서 주관적인 경험에 따르면 스왑이 있고
zswap기본값이 이고swappiness항상 값이 없거나 높을 때 어떤 값max_pool_percent보다 더 잘 작동하는 시스템입니다 .)swappinesszswapzswapmax_pool_percent - 값이 낮으면
swappiness남은 페이지 캐시 양이 너무 작아서 과도한 디스크 읽기로 인해 시스템을 사용할 수 없게 될 때까지 시스템이 더 잘 작동하는 것 같습니다. 너무 높음 과 유사합니다max_pool_percent. - 스왑 만 사용
zram하고 메모리에 보관해야 하는 익명 페이지의 양을 제한하거나 및 대략적인 기본값을 사용하여 디스크 지원 스왑을 사용zswap합니다 .swappinessmax_pool_percent
zsmalloc편집: 질문의 더 자세한 요점에 대답할 수 있는 향후 작업은 특정 사용 사례에 대해 에서 사용된 할당자가 에서 사용된 할당자 zram와 압축 방식을 비교하는 방법을 찾는 것입니다 . 하지만 나는 그렇게 하지 않을 것이며 단지 문서나 인터넷에서 검색할 내용을 지적할 뿐입니다.zbudzswap
편집 2:
echo "zsmalloc" > /sys/module/zswap/parameters/zpoolzswap의 할당자를 에서 로 전환 zbud합니다 zsmalloc. 위 실험에 대한 테스트 픽스처를 계속해서 + zram와 비교해 보면, 필요한 스왑 메모리가 스왑 또는 's 와 동일한 한 디스크에 대한 읽기 및 쓰기 양은 둘 사이에서 매우 유사한 것으로 보입니다. . 사실에 근거한 내 개인적인 의견으로는 필요한 스왑 양이 RAM에 실제로 보관할 수 있는 스왑 양보다 적 다면 단독으로 사용하는 것이 가장 좋습니다 . 실제로 메모리에 보관할 수 있는 것보다 더 많은 스왑이 필요한 경우 이를 방지하기 위해 작업 부하를 변경하거나 스왑을 비활성화하고 zram이 이전에 메모리에 사용했던 것과 동일한 값으로 설정하는 것이 가장 좋습니다(크기 * 압축 비율 ) ). 하지만 현재는 이러한 추가 테스트에 대해 제대로 작성할 시간이 없습니다.zswapzsmalloczramzswapmax_pool_percentzramzramzramzramzswapzsmallocmax_pool_percentzram