iBug @ USTC
2024 年 8 月 17 日
南京大学 开源软件论坛
zfs_arc_max
)硬盘 I/O 日常 > 90%,校内下载 iso 不足 50 MB/s
USTC 镜像站两台服务器在 2024 年 5 月期间的磁盘负载
重要学习资料:
好像给什么奇怪的东西加入了 Grafana
2024 年 8 月 USTC 镜像仓库内的文件大小分布
其中中位数为 9.83 KiB,平均大小为 1.60 MiB
recordsize=1M
:反正都是全文件顺序读compression=zstd
:至少可以压掉 > 1M 文件的 padding
xattr=off
:谁家镜像需要 xattr?atime=off
, setuid=off
, exec=off
, devices=off
:开着干啥?secondarycache=metadata
:Rsync 就别来消耗固态寿命了sync=disabled
:囤到 zfs_txg_timeout
再写盘redundant_metadata=some
:偶尔坏个文件也没事
# Set ARC size to 160-200 GiB, keep 16 GiB free for OS
options zfs zfs_arc_max=214748364800
options zfs zfs_arc_min=171798691840
options zfs zfs_arc_sys_free=17179869184
# Favor metadata to data by 20x (OpenZFS 2.2+)
options zfs zfs_arc_meta_balance=2000
# Allow up to 80% of ARC to be used for dnodes
options zfs zfs_arc_dnode_limit_percent=80
# See man page section "ZFS I/O Scheduler"
options zfs zfs_vdev_async_read_max_active=8
options zfs zfs_vdev_async_read_min_active=2
options zfs zfs_vdev_scrub_max_active=5
options zfs zfs_vdev_max_active=20000
zfs list -po name,logicalused,used
重建前后 Rsync 服务器的磁盘负载与空闲空间比较
重建前 HTTP 服务器采用的 LVMcache 方案的命中率
6.8.8-3-pve
(无需 DKMS 哦)secondarycache=all
(放着不动)compression=zstd-8
zfs send -Lcp
:36 小时倒完 50+ TiB 仓库重建前后两台服务器的磁盘负载比较
左边为重建前,中间为仅 Rsync 服务器重建后,右边为两台服务器均重建后的负载
两台服务器的 ZFS ARC 命中率
两台服务器重建后稳定的磁盘利用率
NAME | LUSED | USED | RATIO |
---|---|---|---|
pool0/repo/crates.io-index | 2.19G | 1.65G | 3.01x |
pool0/repo/elpa | 3.35G | 2.32G | 1.67x |
pool0/repo/rfc | 4.37G | 3.01G | 1.56x |
pool0/repo/debian-cdimage | 1.58T | 1.04T | 1.54x |
pool0/repo/tldp | 4.89G | 3.78G | 1.48x | pool0/repo/loongnix | 438G | 332G | 1.34x |
pool0/repo/rosdistro | 32.2M | 26.6M | 1.31x |
我数学不好: openzfs/zfs#7639
NAME | LUSED | USED | DIFF |
---|---|---|---|
pool0/repo | 58.3T | 56.1T | 2.2T |
pool0/repo/debian-cdimage | 1.6T | 1.0T | 549.6G |
pool0/repo/opensuse | 2.5T | 2.3T | 279.7G |
pool0/repo/turnkeylinux | 1.2T | 1.0T | 155.2G |
pool0/repo/loongnix | 438.2G | 331.9G | 106.3G |
pool0/repo/alpine | 3.0T | 2.9T | 103.9G |
pool0/repo/openwrt | 1.8T | 1.7T | 70.0G |
SELECT
non_negative_derivative(sum("reads"), 1s) AS "read",
non_negative_derivative(sum("writes"), 1s) AS "write"
FROM (
SELECT
first("reads") AS "reads",
first("writes") AS "writes"
FROM "zfs_pool"
WHERE ("host" = 'taokystrong' AND "pool" = 'pool0') AND $timeFilter
GROUP BY time($interval), "host"::tag, "pool"::tag, "dataset"::tag fill(null)
)
WHERE $timeFilter
GROUP BY time($interval), "pool"::tag fill(linear)
跑得有点慢(毕竟要先 GROUP BY
每个 ZFS dataset 再一起 sum
)
I/O 带宽:把里层的 reads
和 writes
换成 nread
和 nwritten
即可
security/apparmor/af_unix.c
???
dpkg-divert --package lxc-pve --rename --divert /usr/share/apparmor-features/features.stock --add /usr/share/apparmor-features/features
wget -O /usr/share/apparmor-features/features https://github.com/proxmox/lxc/raw/master/debian/features
ZeroTier 仓库中一眼重复的内容
zfs create -o dedup=on pool0/repo/zerotier
# zdb -DDD pool0
dedup = 4.93, compress = 1.23, copies = 1.00, dedup * compress / copies = 6.04
效果倒是不错,但是不想像 ZFS dedup 这么灵怎么办?
# post-sync.sh
# Do file-level deduplication for select repos
case "$NAME" in
docker-ce|influxdata|nginx|openresty|proxmox|salt|tailscale|zerotier)
jdupes -L -Q -r -q "$DIR" ;;
esac
Name | Orig | Dedup | Diff | Ratio |
---|---|---|---|---|
proxmox | 395.4G | 162.6G | 232.9G | 2.43x |
docker-ce | 539.6G | 318.2G | 221.4G | 1.70x |
influxdata | 248.4G | 54.8G | 193.6G | 4.54x |
salt | 139.0G | 87.2G | 51.9G | 1.59x |
nginx | 94.9G | 59.7G | 35.2G | 1.59x |
zerotier | 29.8G | 6.1G | 23.7G | 4.88x |
mysql-repo | 647.8G | 632.5G | 15.2G | 1.02x |
openresty | 65.1G | 53.4G | 11.7G | 1.22x |
tailscale | 17.9G | 9.0G | 9.0G | 2.00x |
本页面的链接: ibug.io/p/72
友情链接:2023 年南京大学报告: ibug.io/p/59