Причина фрагментации страницы на “большом” сервере с xfs, 20 дисками и Ceph
Любое понимание от кого-то с небольшим количеством опыта в системе IO Linux было бы полезно. Вот моя история:
Недавно поднятый кластер шести Dell PowerEdge rx720xds для обслуживания файлов через Ceph. Эти машины имеют 24 ядра более чем два сокета с двумя numa зонами и 70 нечетными гигабайтами памяти. Диски отформатированы как набеги одного диска каждый (мы не видели способ выставить их непосредственно иначе). Сети обеспечиваются mellanox infiniband IP по 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,noatime,attr2,inode64,noquota 0 0
/dev/sdu1 /var/lib/ceph/osd/ceph-99 xfs rw,noatime,attr2,inode64,noquota 0 0
/dev/sdd1 /var/lib/ceph/osd/ceph-82 xfs rw,noatime,attr2,inode64,noquota 0 0
/dev/sdk1 /var/lib/ceph/osd/ceph-88 xfs rw,noatime,attr2,inode64,noquota 0 0
/dev/sdl1 /var/lib/ceph/osd/ceph-89 xfs rw,noatime,attr2,inode64,noquota 0 0
/dev/sdh1 /var/lib/ceph/osd/ceph-86 xfs rw,noatime,attr2,inode64,noquota 0 0
/dev/sdo1 /var/lib/ceph/osd/ceph-97 xfs rw,noatime,attr2,inode64,noquota 0 0
/dev/sdc1 /var/lib/ceph/osd/ceph-81 xfs rw,noatime,attr2,inode64,noquota 0 0
/dev/sdb1 /var/lib/ceph/osd/ceph-80 xfs rw,noatime,attr2,inode64,noquota 0 0
/dev/sds1 /var/lib/ceph/osd/ceph-98 xfs rw,noatime,attr2,inode64,noquota 0 0
/dev/sdn1 /var/lib/ceph/osd/ceph-91 xfs rw,noatime,attr2,inode64,noquota 0 0
/dev/sde1 /var/lib/ceph/osd/ceph-83 xfs rw,noatime,attr2,inode64,noquota 0 0
/dev/sdq1 /var/lib/ceph/osd/ceph-93 xfs rw,noatime,attr2,inode64,noquota 0 0
/dev/sdg1 /var/lib/ceph/osd/ceph-85 xfs rw,noatime,attr2,inode64,noquota 0 0
/dev/sdt1 /var/lib/ceph/osd/ceph-95 xfs rw,noatime,attr2,inode64,noquota 0 0
/dev/sdf1 /var/lib/ceph/osd/ceph-84 xfs rw,noatime,attr2,inode64,noquota 0 0
/dev/sdr1 /var/lib/ceph/osd/ceph-94 xfs rw,noatime,attr2,inode64,noquota 0 0
/dev/sdi1 /var/lib/ceph/osd/ceph-96 xfs rw,noatime,attr2,inode64,noquota 0 0
/dev/sdp1 /var/lib/ceph/osd/ceph-92 xfs rw,noatime,attr2,inode64,noquota 0 0
Прохождение через IO этих пакетов машин на уровне нескольких сотен МБ/с, но большая часть времени довольно неактивно с большим количеством малого, 'вводит по абсолютному адресу':
# 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 часов спустя, непрерывные страницы так фрагментируются, что magniutde четыре (16 страниц, 65 536 байтов) выделения начинают перестать работать, и мы начинаем отбрасывать пакеты (из-за сбоя 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, кажется, использует много ЦП и застревает в бесперебойном состоянии сна. Я не хочу переходить к любым заключениям со странностью во время общего системного отказа, все же.
Обходное решение к настоящему времени.
Чтобы удостовериться, чтобы эти выделения не перестали работать, даже при фрагментации, я установил:
vm.min_free_kbytes = 16777216
После видения миллионов blkdev_requests в кэшах ПЛИТЫ я пытался уменьшить грязные страницы через:
vm.dirty_ratio = 1
vm.dirty_background_ratio = 1
vm.min_slab_ratio = 1
vm.zone_reclaim_mode = 3
Возможно заменяя слишком много переменных сразу, но на всякий случай inodes и 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
Обновление:
Разработанный, что они не могли бы быть blkdev_requests, но могут быть xfs_buf записями, обнаруживающимися в соответствии с тем 'заголовком'? Не уверенный, как это работает:
/sys/kernel/slab # ls -l blkdev_requests(
lrwxrwxrwx 1 root root 0 Nov 7 23:18 blkdev_requests -> :t-0000384/
/sys/kernel/slab # ls -l | grep 384
lrwxrwxrwx 1 root root 0 Nov 7 23:18 blkdev_requests -> :t-0000384/
lrwxrwxrwx 1 root root 0 Nov 7 23:19 ip6_dst_cache -> :t-0000384/
drwxr-xr-x 2 root root 0 Nov 7 23:18 :t-0000384/
lrwxrwxrwx 1 root root 0 Nov 7 23:19 xfs_buf -> :t-0000384/
Я все еще не знаю, почему они очищены 'drop_slabs', или как разработать то, что вызывает эту фрагментацию.
Вопрос о премии: что лучший путь состоит в том, чтобы получить к источнику этой фрагментации?
Если Вы читаете настолько далеко, спасибо за Ваше внимание!
Дополнительная запрошенная информация:
Память и xfs информация: https://gist.github.com/christian-marie/f417cc3134544544a8d1
Отказ выделения страницы: https://gist.github.com/christian-marie/7bc845d2da7847534104
Продолжите: информация о перфекте и связанные с уплотнением вещи
http://ponies.io/raw/compaction.png
Код уплотнения кажется немного неэффективным ха? Я починил некоторый код, чтобы попытаться копировать неудавшиеся уплотнения: https://gist.github.com/christian-marie/cde7e80c5edb889da541
Это, кажется, воспроизводит проблему.
Я отмечу также, что трассировка события говорит мне, что существует много неудавшихся, исправляет, много раз и:
<...>-322 [023] .... 19509.445609: mm_vmscan_direct_reclaim_end: nr_reclaimed=1
Vmstat производят, касается также. Пока система находится в этой высокой загрузке, указывают, что уплотнения проходят крышу (и главным образом провальные):
pgmigrate_success 38760827 pgmigrate_fail 350700119 compact_migrate_scanned 301784730 compact_free_scanned 204838172846 compact_isolated 18711615 compact_stall 270115 compact_fail 244488 compact_success 25212
Существует действительно, что-то криво с исправляет/уплотнение.
В данный момент я смотрю на сокращение высокого уровня выделений путем добавления поддержки SG нашей установке ipoib. Реальная проблема появляется вероятный связанный vmscan.
Это интересно, и ссылается на этот вопрос: http://marc.info/?l=linux-mm&m=141607142529562&w=2
Я решил ответить своими наблюдениями, потому что комментариев много.
На основании вашего вывода по адресу https://gist.github.com/christian-marie/7bc845d2da7847534104
мы можем определить следующее:
- GFP_MASK при попытке выделения памяти разрешено сделать следующее.
- Может получить доступ к аварийным бассейнам (I думаю это означает доступ к данным под высоким водяным знаком для зоны)
- Не использовать аварийные резервы (I думаю это означает не разрешать доступ к памяти под минимальным водяным знаком)
- Распределить от одной из нормальных зон.
- Может обмениваться, чтобы освободить место.
- Может сбрасывать кэш, чтобы освободить место.
Фрагментация зоны находится здесь:
[3443189.780792] Node 0 Normal: 3300*4kB (UEM) 8396*8kB (UEM) 4218*16kB (UEM) 76*32kB (UEM) 12*64kB (M) 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 151056kB
[3443189.780801] Node 1 Normal: 26667*4kB (UEM) 6084*8kB (UEM) 2040*16kB (UEM) 96*32kB (UEM) 22*64kB (UEM) 4*128kB (U) 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 192972kB
И использование памяти в то время находится здесь:
[3443189.780759] Node 0 Normal free:149520kB min:40952kB low:51188kB high:61428kB active_anon:9694208kB inactive_anon:1054236kB active_file:7065912kB inactive_file:7172412kB unevictable:0kB isolated(anon):5452kB isolated(file):3616kB present:30408704kB managed:29881160kB mlocked:0kB dirty:0kB writeback:0kB mapped:25440kB shmem:743788kB slab_reclaimable:1362240kB slab_unreclaimable:783096kB kernel_stack:29488kB pagetables:43748kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
[3443189.780766] Node 1 Normal free:191444kB min:45264kB low:56580kB high:67896kB active_anon:11371988kB inactive_anon:1172444kB active_file:8084140kB inactive_file:8556980kB unevictable:0kB isolated(anon):4388kB isolated(file):4676kB present:33554432kB managed:33026648kB mlocked:0kB dirty:0kB writeback:0kB mapped:45400kB shmem:2263296kB slab_reclaimable:1606604kB slab_unreclaimable:438220kB kernel_stack:55936kB pagetables:44944kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
Фрагментация каждой зоны плохо отражается в выводе ошибки распределения страниц. Есть много свободного порядка 0 страниц с гораздо меньшим количеством или вообще не выше страниц порядка. Хорошим" результатом будет большое количество бесплатных страниц при каждом заказе, постепенно уменьшаясь в размерах, чем выше заказ. Наличие 0 страниц высокого порядка 5 и выше указывает на фрагментацию и голод для распределения высокого порядка.
Я в настоящее время не вижу убедительных доказательств того, что фрагментация в течение этого периода имеет какое-либо отношение к кэш-памяти слябов. В результирующей статистике памяти мы видим следующее
Node 0 = active_anon:9694208kB inactive_anon:1054236kB
Node 1 = active anon:11371988kB inactive_anon:1172444kB
Нет никаких огромных страниц, назначенных из пользовательского пространства, и пользовательское пространство, таким образом, всегда будет претендовать на память порядка 0. Таким образом, в обеих зонах в общей сложности имеется более 22 гигабайт дефрагментируемой памяти.
Поведения, которые я не могу объяснить
Когда распределение по порядку высокого порядка не удается, я понимаю, что уплотнение памяти - это всегда попытка, чтобы позволить выполнить и успешно распределить области высокого порядка памяти. Почему этого не происходит? Если это действительно происходит, то почему она не может найти память для дефрагментации, когда 22 гигабайта уже созрели для переупорядочивания?
Поведения, которые, я думаю, я могу объяснить
Для их правильного понимания необходимо больше исследований, но я считаю, что возможность автоматического выделения подкачки/удаления некоторых страниц, чтобы добиться успеха, вероятно, здесь не применима, так как свободной памяти все еще много, так что никаких переупорядочиваний не происходит. Просто не хватает в высших порядках.
В то время как в и осталось несколько запросов 4 порядка в каждой зоне, выпуск "total all free memory for each order and deduct from the real free memory" приводит к появлению "свободной памяти" под водяным знаком "min", что и приводит к фактическому срыву выделения.
.У нас была такая же проблема с отбрасыванием пакетов TX с Ceph на IP через IB. В нашем случае проблема была из-за большого размера MTU (64 КБ). Кто-то выбрал большой размер MTU (64 КБ) для увеличения пропускной способности. Однако, когда мы запускали Ceph долгое время и при больших нагрузках, пропускная способность и задержка osd ухудшались из-за большого количества отбрасываемых пакетов tx. А когда мы меняем размер MTU на 9К и пропускная способность и задержка становятся стабильными. Мы также рассматриваем возможность уменьшения размера MTU до 8 КБ в соответствии со следующей статьей. https://www.ibm.com/support/knowledgecenter/en/linuxonibm/liaag/wehs/l0wehs00_otherconfigurationconsiderationoptimalmtusize.htm