Linux IO sisteminde biraz deneyime sahip birinden herhangi bir fikir yardımcı olacaktır. İşte benim hikayem:

Yakın zamanda Ceph aracılığıyla dosya sunmak için altı adet Dell PowerEdge rx720xds kümesi oluşturdu. Bu makineler, iki numa bölgesi ve 70 garip gigabayt belleğe sahip iki soket üzerinde 24 çekirdeğe sahiptir. Diskler, her biri bir diskin baskını olarak biçimlendirilmiştir (aksi takdirde doğrudan göstermenin bir yolunu göremedik). Ağ iletişimi, IB üzerinden mellanox infiniband IP ile sağlanır (IP paketleri donanım alanında değil çekirdek topraklarında IB'ye dönüştürülür).

SAS disklerimizin her biri şu şekilde monte edilmiştir:

# 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

Bu makinelerden geçen ES birkaç yüz MB / s hızda patlar, ancak çoğu zaman bir sürü küçük 'pokes' ile oldukça boştur:

# 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

Sorun:

Yaklaşık 48 saat sonra bitişik sayfalar o kadar parçalı olur ki, dört (16 sayfa, 65536 bayt) magniutde ayırma başarısız olmaya başlar ve paketleri bırakmaya başlarız (bir SLAB büyüdüğünde kalloc arızası nedeniyle).

Nispeten "sağlıklı" bir sunucu şöyle görünür:

# 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 

Parçalanma önemli ölçüde kötüleştiğinde, sistem çekirdek alanında dönmeye başlar ve her şey parçalanır. Bu hata sırasındaki bir anormallik, xfsaild'in çok fazla CPU kullanıyor gibi görünmesi ve kesintisiz uyku durumunda kalmasıdır. Yine de, toplam sistem arızası sırasında garip bir sonuç çıkarmak istemiyorum.

Geçici çözüm.

Bu tahsislerin başarısız olmamasını sağlamak için, parçalanma altında bile:

vm.min_free_kbytes = 16777216

SLAB önbelleklerinde milyonlarca blkdev_request gördükten sonra, kirli sayfaları şu şekilde azaltmaya çalıştım:

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

Bir seferde çok fazla değişkeni değiştirmek mümkün, ancak sadece inode ve dişçiliklerin parçalanmaya neden olması durumunda, bunları minimumda tutmaya karar verdim:

vm.vfs_cache_pressure = 10000

Ve bu yardımcı oldu. Parçalanma hala yüksek ve inode ve dentry sorunlarının azalması beni tuhaf bir şey fark ettiğim anlamına geliyordu ...

Benim sorum:

Neden bu kadar çok blkdev_request'im var (daha az aktif olan), önbellekleri bıraktığımda kayboluyor?

Demek istediğim şu:

# 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           

Bu blkdev_request birikimi olduğunu bana diyor değil kirli sayfalarla ilgili aslında ve aktif nesneler gerçekten etkin değildir ayrıca o? Bu nesneler aslında kullanılmıyorsa nasıl kurtarılabilir? Burada neler oluyor?

Bazı arka plan için, drop_caches ne yapıyor:

http://lxr.free-electrons.com/source/fs/drop_caches.c

Güncelleme:

Onlar blkdev_requests olmayabilir, ama bu 'başlık' altında gösterilen xfs_buf girişleri olabilir mi çalıştı? Bunun nasıl çalıştığından emin değilim:

/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/

Bunların neden 'drop_slabs' tarafından temizlendiğini veya bu parçalanmaya neyin neden olduğunu nasıl anlayacağımı hala bilmiyorum.

Bonus soru: Bu parçalanmanın kaynağına ulaşmanın daha iyi bir yolu nedir?

Şimdiye kadar okursanız, ilginiz için teşekkür ederiz!

Ekstra istenen bilgiler:

Bellek ve xfs bilgisi: https://gist.github.com/christian-marie/f417cc3134544544a8d1

Sayfa ayırma hatası: https://gist.github.com/christian-marie/7bc845d2da7847534104

Takip: mükemmel bilgi ve sıkıştırma ile ilgili şeyler

http://ponies.io/raw/compaction.png

Sıkıştırma kodu biraz verimsiz görünüyor ha? Başarısız işlemleri çoğaltmaya çalışmak için birlikte bazı kodları topladım: https://gist.github.com/christian-marie/cde7e80c5edb889da541

Bu sorunu yeniden oluşturuyor gibi görünüyor.

Ayrıca, bir olay izlemesinin, defalarca başarısız geri dönüşler olduğunu söylediğini de not edeceğim:

<...>-322 [023] .... 19509.445609: mm_vmscan_direct_reclaim_end: nr_reclaimed=1

Vmstat çıkışı da söz konusudur. Sistem bu yüksek yük durumundayken, işlemler tavandan geçer (ve çoğunlukla başarısız olur):

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

Gerçekten, geri kazanım / sıkıştırma ile ilgili bir şey var.

Şu anda ipoib kurulumumuza SG desteği ekleyerek yüksek dereceli tahsisleri azaltmaya çalışıyorum. Asıl sorun muhtemelen vmscan ile ilgili görünüyor.

Bu ilginç ve bu soruya atıfta bulunuyor: http://marc.info/?l=linux-mm&m=141607142529562&w=2

Gözlemlerime bir cevap vereceğimi düşündüm çünkü çok fazla yorum var.

Https://gist.github.com/christian-marie/7bc845d2da7847534104 adresindeki çıktınıza dayanarak

Aşağıdakileri belirleyebiliriz:

1. Denenen bellek ayırma için GFP_MASK'ın aşağıdakileri yapmasına izin verilir.
   • Acil durum havuzlarına erişebilir ( bunun bir bölge için yüksek filigranın altındaki verilere erişim anlamına geldiğini düşünüyorum )
   • Acil rezervleri kullanmayın ( Bence bu, min filigranın altındaki hafızaya erişime izin vermiyor demektir)
   • Normal bölgelerden birinden tahsis edin.
   • Oda yapmak için değişebilir.
   • Oda yapmak için önbellekleri düşürebilir.

Bölge parçalanması buradaki konumdur:

[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

Ve o zamanki bellek kullanımı burada:

[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

Sayfa ayırma hatası çıkışında her bölgenin parçalanması kötü. Daha fazla sipariş sayfası yok veya çok daha az ücretsiz sipariş 0 sayfa var. 'İyi' bir sonuç, her sipariş boyunca bol miktarda ücretsiz sayfalar olacak ve gittikçe artan boyut giderek gittikçe daha yüksek olacak. 0 üst sıra sayfa 5 ve üstü olması, yüksek sıra tahsisleri için parçalanma ve açlığı gösterir.

Şu anda bu dönemdeki parçalanmanın levha önbellekleri ile ilgili olduğunu düşündüren ikna edici bir kanıt görmüyorum. Ortaya çıkan bellek istatistiklerinde aşağıdakileri görebiliriz

Node 0 = active_anon:9694208kB inactive_anon:1054236kB
Node 1 = active anon:11371988kB inactive_anon:1172444kB

Kullanıcı alanından atanmış çok büyük sayfa yoktur ve bu nedenle kullanıcı alanı her zaman sipariş 0 belleği talep eder. Böylece her iki bölgede de 22GiB'den fazla birleştirilebilir hafıza vardır.

Açıklayamadığım davranışlar

Yüksek dereceli ayırmalar başarısız olduğunda, yüksek dereceli bellek ayırma bölgelerinin gerçekleşmesine ve başarılı olmasına izin vermek için her zaman bellek sıkıştırmaya çalışıldığını düşünüyorum. Bu neden gerçekleşmiyor? Böyle bir şey olursa, yeniden sıralama için 22GiB olgunlaştığında neden birleştirilecek bir bellek bulamıyor?

Sanırım açıklayabildiğim davranışlar

Bu düzgün anlamak için daha fazla araştırmaya ihtiyaç duyuyor, ancak başarılı olmak için bazı pagecache'i otomatik olarak değiştirme / bırakma tahsisinin muhtemelen burada geçerli olmadığı için hala geçerli olmadığına inanıyorum, çünkü hala bir sürü boş bellek var, bu yüzden hiçbir geri dönüş gerçekleşmiyor. Sadece yüksek siparişlerde yeterli değil.

Her bölgede çok fazla boş bellek ve birkaç sıra 4 istek kalırken, "her sipariş için toplam boş bellek toplamı ve gerçek boş bellekten düşme" sorunu, 'min' filigranının altında 'boş bellek' ile sonuçlanır. gerçek tahsis hatasına neden olur.