Vì một số lý do, dường như có rất nhiều giải thích sai về https://www.kernel.org/doc/Documentation/blockdev/zram.txt
Nó nêu rõ:
2) Đặt số lượng luồng nén tối đa
Bất kể giá trị được truyền cho thuộc tính này, ZRAM sẽ luôn phân bổ nhiều luồng nén - một luồng cho mỗi CPU trực tuyến - do đó cho phép một số hoạt động nén đồng thời. Số lượng luồng nén được phân bổ giảm xuống khi một số CPU trở nên ngoại tuyến. Không còn chế độ một luồng nén nữa, trừ khi bạn đang chạy hệ thống UP hoặc chỉ có 1 CPU trực tuyến.
Để tìm hiểu có bao nhiêu luồng hiện có sẵn:
cat /sys/block/zram0/max_comp_streams
Nhưng có một truyền thuyết đô thị phổ biến, dai dẳng rằng luồng tối đa là 1.
Rõ ràng là không đúng.
Hai hệ điều hành trong đó zram đã chứng minh Chrome OS và Android hiệu quả cho bạn một thiết bị duy nhất. Ngoài ra họ tinh chỉnh page-cluster
:
page-cluster
kiểm soát số lượng trang mà các trang liên tiếp được đọc từ trao đổi trong một lần thử. Đây là đối tác trao đổi để đọc bộ nhớ cache trang.
Liên tiếp được đề cập không phải là về địa chỉ ảo / vật lý, mà liên tiếp trên không gian hoán đổi - điều đó có nghĩa là chúng được hoán đổi với nhau.
Đó là một giá trị logarit - đặt nó thành 0 có nghĩa là "1 trang", đặt nó thành 1 có nghĩa là "2 trang", đặt nó thành 2 có nghĩa là "4 trang", v.v ... Không vô hiệu hóa hoàn toàn trao đổi đọc.
Giá trị mặc định là ba (tám trang cùng một lúc). Có thể có một số lợi ích nhỏ trong việc điều chỉnh giá trị này thành một giá trị khác nếu khối lượng công việc của bạn là trao đổi nhiều.
Giá trị thấp hơn có nghĩa là độ trễ thấp hơn cho các lỗi ban đầu, nhưng đồng thời các lỗi thêm và độ trễ I / O cho các lỗi sau nếu chúng là một phần của các trang liên tiếp mà readahead sẽ đưa vào.
- từ tài liệu kernel cho/proc/sys/vm/*
Vì vậy, sử dụng echo "0" > /proc/sys/vm/page-cluster
để buộc trang duy nhất.
Dường như phần lớn bắt nguồn từ zram_config gói debian / ub Ubuntu vì lý do nào đó dường như có rất ít mối tương quan với các tài liệu kernel cho zram và đã tạo ra một loạt các lời thì thầm của Trung Quốc về bản chất có thể sai hoàn toàn.
Với trao đổi tập tin, bạn có tạo một ổ đĩa trao đổi cho mỗi lõi? Có lẽ điều đó có thể trả lời câu hỏi của bạn. Ngoài ra, để sao lưu điều này, Google Googles Chrome OS và Android sử dụng thành công với cụm trang ở trên vì nó không khớp với đĩa nên độ trễ có thể được cải thiện, các thiết bị đơn lẻ.
Ngoài ra đối với một sys-admin, việc sử dụng mem thực tế hay sử dụng mem vm là gì? Hầu hết các ví dụ cho thấy việc tạo thông qua đĩa_size và hoàn toàn bỏ qua mem_limit. đĩa_size = kích thước vm không nén. mem_limit = giới hạn dấu chân mem thực tế.
Nó khiến cho sự lựa chọn của đĩa_size trở nên khó hiểu vì kích thước tối đa ảo của nó phụ thuộc vào tỷ lệ comp_ache và chi phí 0,1% kích thước của đĩa khi không sử dụng và thực sự là một dự đoán của mem_limit * (khoảng 2 - 4) so với lạc quan.
zram_config thậm chí không kiểm tra việc sử dụng dịch vụ trước đó và ghi đè trong khi kiểm tra đơn giản lớp zram sys như dưới đây.
createZramSwaps () {
totalmem=$(free|awk '/^Mem:/{print $2}')
mem=$((( totalmem * MEM_FACTOR / 100 / BIG_CORES ) * 1024))
# Check Zram Class created
ZRAM_SYS_DIR='/sys/class/zram-control'
if [ ! -d "${ZRAM_SYS_DIR}" ]; then
modprobe zram
RAM_DEV='0'
echo ${COMP_ALG_SWAP} > /sys/block/zram${RAM_DEV}/comp_algorithm
echo ${mem} > /sys/block/zram${RAM_DEV}/disksize
mkswap /dev/zram${RAM_DEV}
swapon -p ${SWAP_PRI} /dev/zram${RAM_DEV}
else
RAM_DEV=$(cat /sys/class/zram-control/hot_add)
echo ${COMP_ALG_SWAP} > /sys/block/zram${RAM_DEV}/comp_algorithm
echo ${mem} > /sys/block/zram${RAM_DEV}/disksize
mkswap /dev/zram${RAM_DEV}
swapon -p ${SWAP_PRI} /dev/zram${RAM_DEV}
fi
if [ "$BIG_CORES" -gt 1 ];then
for i in $(seq $((BIG_CORES - 1))); do
RAM_DEV=$(cat /sys/class/zram-control/hot_add)
echo ${COMP_ALG_SWAP} > /sys/block/zram${RAM_DEV}/comp_algorithm
echo ${mem} > /sys/block/zram${RAM_DEV}/disksize
mkswap /dev/zram${RAM_DEV}
swapon -p ${SWAP_PRI} /dev/zram${RAM_DEV}
done
fi
}