Giá trị thích hợp của vm.swappiness khi sử dụng zram là gì?


13

Tôi đang sử dụng zram trên máy tính của mình dưới dạng hoán đổi dựa trên RAM được nén. Khi hệ thống cần hoán đổi thứ gì đó, việc hoán đổi nó thành tệp hoán đổi được hỗ trợ zram tương đương ít nhiều với việc nén dữ liệu đó trong bộ nhớ để giải phóng dung lượng. Điều này làm cho việc hoán đổi rất nhanh hầu hết thời gian, liên quan đến trao đổi dựa trên đĩa. Bởi vì điều này, tôi tự hỏi liệu có một số hiệu suất đạt được bằng cách khuyến khích hệ thống trao đổi những thứ không sử dụng mạnh mẽ hơn, vì nó có thể làm như vậy mà không thực sự nhấn vào đĩa?

Vì vậy, có ai đã vm.swappinessnhầm lẫn với, giả sử, cài đặt thành 100 trong khi sử dụng zram? Điều này sẽ được mong muốn?

sysctl -w vm.swappiness=100

2
Đây là một câu hỏi xuất sắc và tôi nghĩ rằng một số điểm chuẩn là để loại bỏ các ý kiến ​​và nhận được sự thật ...
Elder Geek

Ý tưởng hay và zram có thể đã được cải thiện kể từ năm 2012 khi tôi sử dụng lần cuối :-)
Huygens

Đã thực hiện một thử nghiệm nhỏ và theo như tôi có thể nói bộ nhớ "dành riêng" cho zram vẫn được sử dụng làm bộ đệm. Nếu điều này được xác nhận thì tôi nghĩ có thể có ý nghĩa để giữ cho swappiness thấp để tránh chu kỳ CPU?
Vitor

Câu trả lời:


2

Tôi thực sự sẽ không đề nghị để đưa swappiness cao hơn. Một cơ chế phổ biến trong kernel là nó sẽ đưa các trang (khối bộ nhớ) vào trao đổi để giải phóng một số bộ nhớ cho các tác vụ đang chạy khác.

"Vấn đề" đầu tiên khi kernel muốn n trang được giải phóng, m (với m <n, m là số trang được nén để giữ n) mới được tạo trong RAM, tôi không chắc điều đó có thể làm phiền kernel hay không không phải.

Dù sao đi nữa, khi bạn có các trang trong trao đổi, có thể bạn sẽ sử dụng ứng dụng này sau đó với một số trang của nó trong trao đổi. Những gì kernel làm là đưa các trang đó trở lại vào bộ nhớ vật lý nhưng không xóa chúng khỏi trao đổi (mà với hoán đổi tiêu chuẩn có thể được xem là bộ đệm , vì vậy khi ứng dụng quay lại nền, kernel không phải ghi lại các trang đó vào trao đổi chậm). Tuy nhiên với zram có lẽ không phải là một mẹo khôn ngoan, bởi vì sau đó bạn có trong bộ nhớ các trang m trong zram + n trang trở lại trong bộ nhớ!

Hạt nhân đã định mức một "tổng bộ nhớ" mà nó có thể sử dụng để thực hiện công việc của mình. Khi bạn thêm zram, nó chỉ được tính trong bộ nhớ "hoán đổi", giống như với bất kỳ trao đổi dựa trên đĩa nào, nhưng nó làm giảm "tổng bộ nhớ" thực tế và điều đó không được dự kiến ​​/ dự đoán bởi kernel. Đôi khi bạn có thể có hành vi kỳ lạ và không muốn vì điều này!

Với zram, sẽ tốt hơn khi kernel không trao đổi quá nhiều vào khu vực này khi nó chịu áp lực bộ nhớ. Và bạn phải luôn luôn có một phân vùng trao đổi đĩa cứng thực sự lớn hơn ít nhất so với kích thước tối đa zram của bạn, để hệ thống sẽ không nhận được OOM trong khi đồng thời bạn sẽ thấy nhiều không gian trống như được báo cáo bởi free!


zram cung cấp các thiết bị khối RAM. Tất cả mọi thứ được viết cho các thiết bị khối này được nén. Nếu các thiết bị khối zram được sử dụng làm trao đổi, khi hệ thống cố gắng di chuyển các phần của bộ nhớ để hoán đổi, nó sẽ chuyển bộ nhớ một cách hiệu quả từ một phần của RAM sang phần khác, ngoại trừ dữ liệu sẽ được nén trước khi được sao chép đến đích. Điều này hoạt động hiệu quả như một cơ chế nén bộ nhớ giá rẻ để cải thiện khả năng phản hồi trong các hệ thống với số lượng bộ nhớ hạn chế. ... Zram đã được dàn dựng kể từ Linux 2.6.33. Trong 3.14 zram đã được chuyển ra khỏi dàn cho trình điều khiển / khối / zram.
Anh Cả Geek

1
@ElderGeek chính xác! Và tôi sẽ lấy một ví dụ để minh họa tại sao điều đó không hoàn hảo. Nhân sẽ cố gắng loại bỏ 64 MB RAM, nó đưa chúng vào trao đổi zram. Nén đoạn 64 MB hiện là 32 MB. Kết quả là bộ nhớ giảm 32 MB chứ không phải 64 MB. Bây giờ điều gì xảy ra khi ứng dụng yêu cầu 64 MB trở lại trong bộ nhớ, sao chép kernel (và không di chuyển) chunk trở lại trong bộ nhớ. Bây giờ bạn có 64 MB RAM + 32 MB trong zram. Tại sao phải sao chép? Bởi vì kernel lưu trữ các trang như tôi đã giải thích trong câu trả lời của mình. Cả hai hành vi đều không lý tưởng. Và khi bộ nhớ không thể nén tốt, điều đó còn tồi tệ hơn.
Huygens

Vẫn đang trong giai đoạn thử nghiệm. Tôi nghĩ rằng phải có một số cách để điều chỉnh thuật toán bộ đệm mà zram sử dụng để giải phóng trang nén khi nó được sao chép trở lại RAM không nén.
Anh Cả Geek

Tôi đã thử nó nhiều lần cho đến năm 2012. Lúc đó máy tính của tôi bị giới hạn ở mức 1GB RAM và trong khi duyệt internet thì nó rất chậm (tôi thường mở 10-50 tab). Nhưng kể từ đó tôi không bao giờ sử dụng nó nữa. Tôi có quá nhiều RAM mà tôi không sử dụng trao đổi nữa. Khi sử dụng zram với Firefox hồi đó, tôi nhanh chóng bắt đầu "tráo đổi" với lượng RAM nhỏ mà tôi có. Và nhanh chóng tôi có một hệ thống không phản hồi với nhiều sự cố. Không có zram, nó rất chậm nhưng ổn định. Vấn đề của tôi là có lẽ nó liên tục nén / giải nén các trang bộ nhớ.
Huygens

Có, kết quả của tôi có phần giống nhau, trên một hệ thống có 8GB, tôi đã có thể buộc OOM bằng cách khởi chạy một số VM trong công việc mã hóa. Bạn có bất kỳ kinh nghiệm với zswap? Có vẻ như một sự thay thế khả thi dựa trên những gì tôi đã đọc.
Anh Cả Geek

2

Câu trả lời ngắn: vm.swappiness=100giá trị phù hợp cho zram (Ít nhất là trên Debian Stretch với Linux 4.9, tôi tin rằng đó là giá trị tốt nhất)

Tôi đã thử nghiệm vm.swappiness=100cho tôi.

Tôi nghĩ bạn có thể làm một số thử nghiệm đơn giản để chắc chắn giá trị nào là tốt nhất cho bạn.

Ngoài ra tôi đã thực hiện một chương trình đơn giản khác để kiểm tra câu hỏi này. x Trên máy của tôi, vm.swappinessgiá trị rất thấp (chẳng hạn như vm.swappiness=1) sẽ gây ra sự cố phản hồi rõ ràng.

Về SwapCached/proc/meminfo:

Trước tiên, hãy thử vm.page-cluster=0, điều này có thể có thể làm giảm một số vô dụng SwapCachedtừ trao đổi.

SwapCached có thể tăng tốc zram giống như thiết bị trao đổi không phải zram

SwapCached có thể tái sử dụng (miễn phí) khi cần thiết:

./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

Các trang cần được hoán đổi (vào đĩa) khi bộ nhớ đầy. Nếu bạn đang sử dụng bộ nhớ để tạo nơi trao đổi các trang khi bộ nhớ đầy, người ta sẽ nghĩ rằng nó có mục đích, ngoại trừ nếu việc nén tạo ra sự khác biệt (và sau đó, việc nén trực tiếp bộ nhớ thay vì đi qua hoán đổi). Đoán người ta sẽ phải điểm chuẩn này, vì máy tính đang ngày càng nhanh hơn trong việc nén và giải nén so với tốc độ bộ nhớ.


Bản thân tôi đã tìm thấy hoán đổi được hỗ trợ zram khá hữu ích khi hệ thống hết bộ nhớ. Nó đã giúp tôi tiết kiệm một vài lần khỏi bị mắc kẹt hoàn toàn trong việc hoán đổi địa ngục và phải khởi động lại (Tôi đang phân tích các tập dữ liệu lớn, vì vậy tôi cần bộ nhớ, tất cả là 24 GB). Tôi chỉ tự hỏi liệu vm.swappinessgiá trị có được điều chỉnh cho trao đổi dựa trên đĩa hay không và liệu tôi có nên thay đổi nếu tôi chủ yếu sử dụng trao đổi dựa trên zram.
Ryan C. Thompson

1
"Ngày càng nhanh"? Quá trình nén đã hoạt động tốt hơn so với I / O đĩa trực tiếp trong hơn một thập kỷ qua (nó sẽ không bao giờ nhanh hơn truy cập bộ nhớ - đó không phải là vấn đề)
symcbean

symcbean, bạn đã quên "so với tốc độ bộ nhớ". Đâu là bất đồng?
Alexander

Tôi nghĩ rằng quan điểm của symcbean là mục tiêu của các trang được hỗ trợ bộ nhớ nén (zram) là thay thế việc hoán đổi sang phương tiện vật lý. Lý do không phải là "tự nhiên để nén bộ nhớ" là bởi vì nó sẽ gây ra nhiều phức tạp cho các ứng dụng phải xác định phần nào của bộ nhớ có thể được nén và khi nào; hệ thống con VM là một nơi dễ dàng hơn nhiều để thực hiện điều này. Khối lượng công việc được hưởng lợi từ zram có các trang không có trong bộ làm việc và có thể dễ dàng nén.
Daniel Papasian
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.