linux – 使用xfs,20个磁盘和Ceph的“大型”服务器上的页面碎片的原因
发布时间：2020-05-23 16:20:03 所属栏目：Linux 来源：互联网
导读：来自具有 linux IO系统经验的人的任何见解都会有所帮助.这是我的故事： 最近推出了六个Dell PowerEdge rx720xds集群,通过Ceph提供文件服务.这些机器有24个核心,两个插座,两个numa区域和70奇数千兆字节的内存.磁盘被格式化为每个磁盘的raid(我们无法看到直接暴
|
来自具有 linux IO系统经验的人的任何见解都会有所帮助.这是我的故事： 最近推出了六个Dell PowerEdge rx720xds集群,通过Ceph提供文件服务.这些机器有24个核心,两个插座,两个numa区域和70奇数千兆字节的内存.磁盘被格式化为每个磁盘的raid(我们无法看到直接暴露它们的方式).网络由mellanox infiniband IP over IB提供(IP数据包在内核域而不是硬件中转换为IB). 我们安装了每个SAS驱动器,如下所示： # cat /proc/mounts | grep osd /dev/sdm1 /var/lib/ceph/osd/ceph-90 xfs rw,noatime,attr2,inode64,noquota 0 0 /dev/sdj1 /var/lib/ceph/osd/ceph-87 xfs rw,noquota 0 0 /dev/sdu1 /var/lib/ceph/osd/ceph-99 xfs rw,noquota 0 0 /dev/sdd1 /var/lib/ceph/osd/ceph-82 xfs rw,noquota 0 0 /dev/sdk1 /var/lib/ceph/osd/ceph-88 xfs rw,noquota 0 0 /dev/sdl1 /var/lib/ceph/osd/ceph-89 xfs rw,noquota 0 0 /dev/sdh1 /var/lib/ceph/osd/ceph-86 xfs rw,noquota 0 0 /dev/sdo1 /var/lib/ceph/osd/ceph-97 xfs rw,noquota 0 0 /dev/sdc1 /var/lib/ceph/osd/ceph-81 xfs rw,noquota 0 0 /dev/sdb1 /var/lib/ceph/osd/ceph-80 xfs rw,noquota 0 0 /dev/sds1 /var/lib/ceph/osd/ceph-98 xfs rw,noquota 0 0 /dev/sdn1 /var/lib/ceph/osd/ceph-91 xfs rw,noquota 0 0 /dev/sde1 /var/lib/ceph/osd/ceph-83 xfs rw,noquota 0 0 /dev/sdq1 /var/lib/ceph/osd/ceph-93 xfs rw,noquota 0 0 /dev/sdg1 /var/lib/ceph/osd/ceph-85 xfs rw,noquota 0 0 /dev/sdt1 /var/lib/ceph/osd/ceph-95 xfs rw,noquota 0 0 /dev/sdf1 /var/lib/ceph/osd/ceph-84 xfs rw,noquota 0 0 /dev/sdr1 /var/lib/ceph/osd/ceph-94 xfs rw,noquota 0 0 /dev/sdi1 /var/lib/ceph/osd/ceph-96 xfs rw,noquota 0 0 /dev/sdp1 /var/lib/ceph/osd/ceph-92 xfs rw,noquota 0 0 通过这些机器的IO以几百MB / s的速度突发,但大部分时间都很闲置,有很多小“捅”： # iostat -x -m
Linux 3.10.0-123.el7.x86_64 (xxx) 07/11/14 _x86_64_ (24 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
1.82 0.00 1.05 0.11 0.00 97.02
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.11 0.25 0.23 0.00 0.00 27.00 0.00 2.07 3.84 0.12 0.61 0.03
sdb 0.02 0.57 3.49 2.28 0.08 0.14 77.18 0.01 2.27 2.99 1.18 1.75 1.01
sdd 0.03 0.65 3.93 3.39 0.10 0.16 70.39 0.01 1.97 2.99 0.79 1.57 1.15
sdc 0.03 0.60 3.76 2.86 0.09 0.13 65.57 0.01 2.10 3.02 0.88 1.68 1.11
sdf 0.03 0.63 4.19 2.96 0.10 0.15 73.51 0.02 2.16 3.03 0.94 1.73 1.24
sdg 0.03 0.62 3.93 3.01 0.09 0.15 70.44 0.01 2.06 3.01 0.81 1.66 1.15
sde 0.03 0.56 4.35 2.61 0.10 0.14 69.53 0.02 2.26 3.00 1.02 1.82 1.26
sdj 0.02 0.73 3.67 4.74 0.10 0.37 116.06 0.02 1.84 3.01 0.93 1.31 1.10
sdh 0.03 0.62 4.31 3.04 0.10 0.15 67.83 0.02 2.15 3.04 0.89 1.75 1.29
sdi 0.02 0.59 3.82 2.47 0.09 0.13 74.35 0.01 2.20 2.96 1.03 1.76 1.10
sdl 0.03 0.59 4.75 2.46 0.11 0.14 70.19 0.02 2.33 3.02 1.00 1.93 1.39
sdk 0.02 0.57 3.66 2.41 0.09 0.13 73.57 0.01 2.20 3.00 0.97 1.76 1.07
sdm 0.03 0.66 4.03 3.17 0.09 0.14 66.13 0.01 2.02 3.00 0.78 1.64 1.18
sdn 0.03 0.62 4.70 3.00 0.11 0.16 71.63 0.02 2.25 3.01 1.05 1.79 1.38
sdo 0.02 0.62 3.75 2.48 0.10 0.13 76.01 0.01 2.16 2.94 0.99 1.70 1.06
sdp 0.03 0.62 5.03 2.50 0.11 0.15 68.65 0.02 2.39 3.08 0.99 1.99 1.50
sdq 0.03 0.53 4.46 2.08 0.09 0.12 67.74 0.02 2.42 3.04 1.09 2.01 1.32
sdr 0.03 0.57 4.21 2.31 0.09 0.14 72.05 0.02 2.35 3.00 1.16 1.89 1.23
sdt 0.03 0.66 4.78 5.13 0.10 0.20 61.78 0.02 1.90 3.10 0.79 1.49 1.47
sdu 0.03 0.55 3.93 2.42 0.09 0.13 70.77 0.01 2.17 2.97 0.85 1.79 1.14
sds 0.03 0.60 4.11 2.70 0.10 0.15 74.77 0.02 2.25 3.01 1.10 1.76 1.20
sdw 1.53 0.00 0.23 38.90 0.00 1.66 87.01 0.01 0.22 0.11 0.22 0.05 0.20
sdv 0.88 0.00 0.16 28.75 0.00 1.19 84.55 0.01 0.24 0.10 0.24 0.05 0.14
dm-0 0.00 0.00 0.00 0.00 0.00 0.00 8.00 0.00 1.84 1.84 0.00 1.15 0.00
dm-1 0.00 0.00 0.23 0.29 0.00 0.00 23.78 0.00 1.87 4.06 0.12 0.55 0.03
dm-2 0.00 0.00 0.01 0.00 0.00 0.00 8.00 0.00 0.47 0.47 0.00 0.45 0.00
问题： 大约48小时后,连续页面碎片化,以至于四个(16页,65536字节)分配开始失败,我们开始丢弃数据包(由于在生成SLAB时kalloc失败). 这是一个相对“健康”的服务器看起来像： # cat /sys/kernel/debug/extfrag/unusable_index Node 0,zone DMA 0.000 0.000 0.000 0.001 0.003 0.007 0.015 0.031 0.031 0.096 0.225 Node 0,zone DMA32 0.000 0.009 0.015 0.296 0.733 0.996 0.997 0.998 0.998 1.000 1.000 Node 0,zone Normal 0.000 0.000 0.019 0.212 0.454 0.667 0.804 0.903 0.986 1.000 1.000 Node 1,zone Normal 0.000 0.027 0.040 0.044 0.071 0.270 0.506 0.772 1.000 1.000 1.000 当碎片变得更糟时,系统似乎开始在内核空间中旋转,一切都崩溃了.在这次失败期间,一个异常现象是xfsaild似乎使用了大量的CPU并陷入了不间断的睡眠状态.但是,我不想在整个系统故障期间以奇怪的方式得出任何结论. 迄今为止的解决方法. 为了确保这些分配不会失败,即使在碎片化的情况下,我设置： vm.min_free_kbytes = 16777216 在SLAB缓存中看到数百万个blkdev_requests之后,我尝试通过以下方式减少脏页： vm.dirty_ratio = 1 vm.dirty_background_ratio = 1 vm.min_slab_ratio = 1 vm.zone_reclaim_mode = 3 可能会同时更改太多变量,但是为了防止inode和dentries导致碎片化,我决定将它们保持在最低限度： vm.vfs_cache_pressure = 10000 这似乎有所帮助.碎片仍然很高,减少的inode和dentry问题意味着我注意到一些奇怪的东西导致我…… 我的问题： 为什么我有这么多blkdev_requests(活动不少),当我丢弃缓存时它会消失？ 这就是我的意思： # slabtop -o -s c | head -20 Active / Total Objects (% used) : 19362505 / 19431176 (99.6%) Active / Total Slabs (% used) : 452161 / 452161 (100.0%) Active / Total Caches (% used) : 72 / 100 (72.0%) Active / Total Size (% used) : 5897855.81K / 5925572.61K (99.5%) Minimum / Average / Maximum Object : 0.01K / 0.30K / 15.69K OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME 2565024 2565017 99% 1.00K 80157 32 2565024K xfs_inode 3295194 3295194 100% 0.38K 78457 42 1255312K blkdev_requests 3428838 3399527 99% 0.19K 81639 42 653112K dentry 5681088 5680492 99% 0.06K 88767 64 355068K kmalloc-64 2901366 2897861 99% 0.10K 74394 39 297576K buffer_head 34148 34111 99% 8.00K 8537 4 273184K kmalloc-8192 334768 334711 99% 0.57K 11956 28 191296K radix_tree_node 614959 614959 100% 0.15K 11603 53 92824K xfs_ili 21263 19538 91% 2.84K 1933 11 61856K task_struct 18720 18636 99% 2.00K 1170 16 37440K kmalloc-2048 32032 25326 79% 1.00K 1001 32 32032K kmalloc-1024 10234 9202 89% 1.88K 602 17 19264K TCP 22152 19765 89% 0.81K 568 39 18176K task_xstate # echo 2 > /proc/sys/vm/drop_caches :( # slabtop -o -s c | head -20 Active / Total Objects (% used) : 965742 / 2593182 (37.2%) Active / Total Slabs (% used) : 69451 / 69451 (100.0%) Active / Total Caches (% used) : 72 / 100 (72.0%) Active / Total Size (% used) : 551271.96K / 855029.41K (64.5%) Minimum / Average / Maximum Object : 0.01K / 0.33K / 15.69K OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME 34140 34115 99% 8.00K 8535 4 273120K kmalloc-8192 143444 20166 14% 0.57K 5123 28 81968K radix_tree_node 768729 224574 29% 0.10K 19711 39 78844K buffer_head 73280 8287 11% 1.00K 2290 32 73280K xfs_inode 21263 19529 91% 2.84K 1933 11 61856K task_struct 686848 97798 14% 0.06K 10732 64 42928K kmalloc-64 223902 41010 18% 0.19K 5331 42 42648K dentry 32032 23282 72% 1.00K 1001 32 32032K kmalloc-1024 10234 9211 90% 1.88K 602 17 19264K TCP 22152 19924 89% 0.81K 568 39 18176K task_xstate 69216 59714 86% 0.25K 2163 32 17304K kmalloc-256 98421 23541 23% 0.15K 1857 53 14856K xfs_ili 5600 2915 52% 2.00K 350 16 11200K kmalloc-2048 这告诉我blkdev_request构建实际上并不与脏页有关,而且活动对象实际上并不活跃？如果这些对象实际上没有被使用,它们如何被释放？这里发生了什么？ 对于某些背景,这是drop_caches正在做的事情： http://lxr.free-electrons.com/source/fs/drop_caches.c 更新： （编辑：安卓应用网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |