xfs, 20 개의 디스크 및 Ceph가있는“대형”서버에서 페이지 조각화의 원인

18

리눅스 IO 시스템에 약간의 경험이있는 사람의 통찰력이 도움이 될 것입니다. 여기 내 이야기가 있습니다 :

최근 Ceph를 통해 파일을 제공하기 위해 6 개의 Dell PowerEdge rx720xd 클러스터를 구축했습니다. 이 기계에는 2 개의 누마 영역과 70 개의 홀수 기가 바이트 메모리를 가진 2 개의 소켓에 24 개의 코어가 있습니다. 디스크는 각각 하나의 디스크를 습격하는 형식으로되어 있습니다 (그렇지 않으면 직접 노출하는 방법을 볼 수 없음). 네트워킹은 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,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는 수백 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 시간 후에 연속 페이지가 너무 세분화되어 마그네 우트 4 (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와 덴트 리가 조각화를 일으키는 경우를 대비하여 최소로 유지하기로 결정했습니다.

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

실제로 재생 / 압축에 문제가 있습니다.

현재 저는 ipoib 설정에 SG 지원을 추가하여 높은 할당량을 줄이는 것을 찾고 있습니다. 실제 문제는 vmscan과 관련된 것으로 보입니다.

이것은 흥미롭고이 질문을 참조합니다 : http://marc.info/?l=linux-mm&m=141607142529562&w=2

linux  linux-kernel  xfs  fragmentation  ceph 
— 핀구
소스
2
그래 그래 !! 우리는 이러한 좋은 질문을 많이받지 않습니다. 그래도 우리가 할 수있는 일을 볼 수 있습니다.
— ewwhite
1
/proc/buddyinfo의 결과와 결과 를 제공 할 수 free -m있습니까? blockdev 요청이 있습니다 아마 에서 버퍼로 표현 free. 아, 그리고 사용중인 배포판도 좋을 것입니다. 또한 page allocation failure메시지가 dmesg있습니까? 그렇다면 출력과 관련 컨텍스트를 제공하십시오.
— Matthew Ife
1
또한 특정 mkfs.xfs명령 줄을 사용 했습니까? Hugepages가 활성화 되었습니까?
— ewwhite
/proc/meminfo
— Matthew Ife
투명한 대형 페이지를 스스로 비활성화하여 (사용하지 않도록 설정) 시도했지만 여전히 실패했습니다. 다른 '수정'과 함께 시도하지 않았습니다.
— pingu

답변:

4

의견이 많기 때문에 관찰 한 내용에 답을하겠다고 생각했습니다.

https://gist.github.com/christian-marie/7bc845d2da7847534104 에서 출력을 기반으로합니다.

우리는 다음을 결정할 수 있습니다.

  1. 시도 된 메모리 할당에 대한 GFP_MASK는 다음을 수행 할 수 있습니다.
    • (I 비상 풀에 액세스 할 수 생각 이 수단은 영역에 대한 높은 워터 마크 아래의 데이터에 액세스)
    • 비상 준비금을 사용 하지 마십시오 (최소 워터 마크 아래의 memroy에 대한 액세스를 허용하지 않는다고 생각 합니다)
    • 일반 영역 중 하나에서 할당하십시오.
    • 공간을 확보하기 위해 교환 할 수 있습니다.
    • 공간을 확보하기 위해 캐시를 삭제할 수 있습니다.

영역 조각화는 다음 위치에 있습니다.

[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 페이지가 많으며 주문 페이지가 훨씬 적거나 없습니다. '좋은'결과는 각 주문에 따라 무료 페이지가 풍부하며, 주문이 많을수록 점차 크기가 작아집니다. 상위 페이지 5 이상이 0이면 상위 할당에 대한 단편화 및 기아 상태를 나타냅니다.

나는 현재이 기간 동안 조각화가 슬래브 캐시와 관련이 있음을 암시하는 확실한 증거를 보지 못했습니다. 결과 메모리 통계에서 다음을 볼 수 있습니다.

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

사용자 공간에서 할당 된 거대한 페이지가 없으므로 사용자 공간은 항상 차수 0 메모리를 청구합니다. 따라서 두 영역 모두에 22GiB 이상의 조각 모음 가능한 메모리가 있습니다.

내가 설명 할 수없는 행동

높은 순서의 할당이 실패하면, 높은 순서의 메모리 할당 영역이 발생하고 성공하기 위해 항상 메모리 압축이 시도 된다는 것을 이해합니다 . 왜 이런 일이 발생하지 않습니까? 만약 그렇다면, 22GiB의 메모리가 재주문 될 때 조각 모음 할 메모리를 찾을 수없는 이유는 무엇입니까?

내가 설명 할 수있는 행동

이것은 제대로 이해하기 위해 더 많은 연구가 필요하지만, 사용 가능한 여유 메모리가 많기 때문에 일부 페이지 캐시를 자동으로 스왑 / 드롭하는 할당 기능이 여기에 적용되지 않을 가능성이 높으므로 재생이 발생하지 않습니다. 높은 주문에서는 충분하지 않습니다.

사용 가능한 메모리의 프로그래머를 많이하는 동안 과 4 개 요청이 각 영역에 남아있는 몇 순서는 인 '분'워터 마크 아래 '무료 메모리'에 문제의 결과 "실제 사용 가능한 메모리에서 각 주문 및 공제에 대한 모든 사용 가능한 메모리를 총" 실제 할당 실패로 이어지는 것.

— 매튜 이프
소스
상대적으로 (총 여유 메모리) 작은 SLAB 캐시가 모든 메모리를 조각화하는 것은 이상하게 보입니다. 나는 모든 무료 퇴거 가능한 페이지로 단순히 일부를 퇴거시키고 끝낼 것이라고 기대했을 것입니다. NUMA 가이 이상한 것과 관련이 있다고 생각합니다.
— pingu
되어 numad이 시스템에서 실행?
— ewwhite
@ewwhite numad가 실행되고 있지 않습니다.
— pingu
@pingu이 동작을 재현 할 수 있으면 numad서비스를 활성화하고 의 작업을 기록하십시오 /var/log/numad.log. libcgroup이 설치되어 있어야 할 수도 있습니다.
— ewwhite
@ewwhite 자, 지금 달리고 있습니다. 나는 그것이 무엇을 기대하는지 또는 우리가 어떤 정보를 얻을 수 있는지 잘 모르겠습니다. 당신은 무슨 일이 일어나기를 바라고 있습니까?
— pingu
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.