Будь-яка інформація про когось, хто має трохи досвіду роботи в системі вводу-виводу linux. Ось моя історія:

Нещодавно виведено кластер із шести Dell PowerEdge rx720xds для обслуговування файлів через Ceph. Ці машини мають 24 ядра над двома розетками з двома зонами numa та 70 непарних гігабайт пам'яті. Диски відформатовані як набіги одного диска кожен (ми не могли побачити спосіб їх викриття безпосередньо інакше). Мережі забезпечуються mellanox infiniband IP через IB (IP-пакети перетворюються на ІБ у землі ядра, а не в апаратне забезпечення).

У кожного з наших приводів 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 годин суміжні сторінки настільки роздроблені, що виділення магнітуд чотирьох (16 сторінок, 65536 байт) починають виходити з ладу, і ми починаємо скидати пакети (через збій каллока при вирощуванні SLAB).

Ось як виглядає відносно «здоровий» сервер:

# 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 в кешах SLAB, я спробував зменшити брудні сторінки за допомогою:

vm.dirty_ratio = 1
vm.dirty_background_ratio = 1
vm.min_slab_ratio = 1
vm.zone_reclaim_mode = 3

Можливо, змінити занадто багато змінних одразу, але про всяк випадок, якщо вкладиші та зубні ряди викликають фрагментацію, я вирішив звести їх до мінімуму:

vm.vfs_cache_pressure = 10000

І це ніби допомогло. Фрагментація все ще залишається великою, і зменшення проблем з дією та зубами означало, що я помітив щось дивне, що призводить мене до ...

Моє запитання:

Чому ж у мене так багато 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

Ми можемо визначити наступне:

1. GFP_MASK для випробуваного розподілу пам'яті дозволено робити наступне.
   • Можливий доступ до аварійних басейнів (я думаю, це означає доступ до даних під високим водним знаком для зони)
   • Не використовуйте аварійні резерви (я думаю, це означає, що не дозволяють отримати доступ до пам’яті нижче мінімальної водної марки)
   • Виділяють з однієї з нормальних зон.
   • Можна поміняти місцями, щоб звільнити місце.
   • Можна скидати кеші, щоб звільнити місце.

Фрагментація зони розташована тут:

[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 Гбітів дефрагментаційної пам'яті.

Поведінки, які я не можу пояснити

Коли розподіл високих замовлень не вдається, я розумію, що ущільнення пам’яті завжди намагається зробити так, щоб забезпечити можливість і успіх розподілу пам’яті високого порядку. Чому цього не відбувається? Якщо це трапляється, чому він не може знайти жодної пам'яті для дефрагментації, коли 22GiB вже дозріла для переупорядкування?

Поведінки, які я думаю, можу пояснити

Для цього потрібні додаткові дослідження, щоб правильно зрозуміти, але я вважаю, що можливість розподілу / автоматичного розміщення певного веб-кеша, щоб досягти успіху, ймовірно, тут не застосовується, тому що ще багато вільної пам’яті. Просто не вистачає у вищих порядках.

Незважаючи на те, що в кожній зоні залишилося багато вільної пам'яті та кілька замовлень, 4 запити, "загальна вся вільна пам'ять на кожне замовлення та відрахування від реальної вільної пам'яті" видає "вільну пам'ять" нижче "min" водяного знака, який є що призводить до фактичного збою розподілу.