Ext4 사용법 및 성능

더 많은 스토리지를 위해 확장해야하는 Carbon 및 Graphite를 실행하는 시스템 클러스터가 있지만 확장 또는 축소가 필요한지 확실하지 않습니다.

클러스터는 현재 다음으로 구성됩니다.

• 1 릴레이 노드 : 모든 메트릭을 수신하고 관련 스토리지 노드로 전달
• 스토리지 노드 6 개 : 모든 Whisper DB 파일 보관

문제는 디스크 사용량이 80 % 정도가되면 성능이 절벽에서 떨어 졌다는 것입니다. 클러스터 쓰기 IOPS는 거의 일정한 13k에서 약 7k의 혼란스러운 평균으로, IOwait 시간은 평균 54 %로 떨어졌습니다.

구성 저장소를 살펴본 결과 4 월 초 이후에는 변경 사항이 없으므로 구성 변경의 결과가 아닙니다.

질문 : 디스크 크기를 늘리면 IO 성능을 다시 제어 할 수 있습니까, 아니면 스토리지 노드를 더 추가해야합니까?

참고 : 여기에는 SSD가 없으며 많은 스핀들 만 있습니다.

관련 그래프 :

통계 및 물건 :

e2freefrag:

[root@graphite-storage-01 ~]# e2freefrag /dev/vda3
Device: /dev/vda3
Blocksize: 4096 bytes
Total blocks: 9961176
Free blocks: 4781849 (48.0%)

Min. free extent: 4 KB
Max. free extent: 81308 KB
Avg. free extent: 284 KB
Num. free extent: 19071

HISTOGRAM OF FREE EXTENT SIZES:
Extent Size Range :  Free extents   Free Blocks  Percent
    4K...    8K-  :          4008          4008    0.08%
    8K...   16K-  :          1723          3992    0.08%
   16K...   32K-  :           703          3495    0.07%
   32K...   64K-  :           637          7400    0.15%
   64K...  128K-  :          1590         29273    0.61%
  128K...  256K-  :          4711        236839    4.95%
  256K...  512K-  :          2664        265691    5.56%
  512K... 1024K-  :          2359        434427    9.08%
    1M...    2M-  :           595        213173    4.46%
    2M...    4M-  :            75         49182    1.03%
   64M...  128M-  :             6        118890    2.49%

e4defrag:

[root@graphite-storage-01 ~]# e4defrag -c /dev/vda3
<Fragmented files>                             now/best       size/ext
1. /opt/graphite/storage/graphite.db            17/1              4 KB
2. /var/log/cron                                13/1              4 KB
3. /var/log/wtmp                                16/1              4 KB
4. /root/.bash_history                           4/1              4 KB
5. /var/lib/rpm/Sha1header                      10/1              4 KB

 Total/best extents                             182256/159981
 Average size per extent                        183 KB
 Fragmentation score                            2
 [0-30 no problem: 31-55 a little bit fragmented: 56- needs defrag]
 This device (/dev/vda3) does not need defragmentation.
 Done.

iostat:

[root@graphite-storage-01 ~]# iostat -k -x 60 3
Linux 3.10.0-229.7.2.el7.x86_64 (graphite-storage-01)     07/05/2016      _x86_64_        (2 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           7.99    0.00    2.54   29.66    0.35   59.46

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00   100.34  177.48 1808.94  2715.66  7659.19    10.45     0.26    0.13    0.65    0.08   0.23  46.14

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           6.17    0.00    7.00   73.21    0.58   13.04

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00    23.87  672.40  656.47  8729.87  2752.27    17.28     7.36    5.50    2.72    8.35   0.73  96.83

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           7.06    0.00    7.31   73.03    0.59   12.01

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00    42.68  677.67  614.88  8634.93  2647.53    17.46     6.66    5.15    2.72    7.83   0.74  96.08

df:

[root@graphite-storage-01 ~]# df
Filesystem     1K-blocks     Used Available Use% Mounted on
/dev/vda3       39153856 33689468   3822852  90% /
devtmpfs         1933092        0   1933092   0% /dev
tmpfs            1941380        0   1941380   0% /dev/shm
tmpfs            1941380   188700   1752680  10% /run
tmpfs            1941380        0   1941380   0% /sys/fs/cgroup
/dev/vda2         999320     2584    980352   1% /tmp
[root@graphite-storage-01 ~]# df -i
Filesystem      Inodes  IUsed   IFree IUse% Mounted on
/dev/vda3      2490368 239389 2250979   10% /
devtmpfs        483273    304  482969    1% /dev
tmpfs           485345      1  485344    1% /dev/shm
tmpfs           485345    322  485023    1% /run
tmpfs           485345     13  485332    1% /sys/fs/cgroup
/dev/vda2        65536     22   65514    1% /tmp

편집 : 스토리지 노드 중 하나의 크기를 조정했지만 효과가 없습니다. 또한 cachestat[ https://github.com/brendangregg/perf-tools](perf 도구 모음)에서 VFS 캐시 내부를 살펴 보는 유틸리티를 찾았습니다 . 이 시점에서 스토리지가 제공 할 수있는 IO 처리량의 한계에 도달 한 것 같습니다.

이 시점에서 나는 더 많은 클러스터 멤버로 계속 확장하거나 쓰기 효율적인 시계열 스토리지 솔루션을 찾는 것에 대해 생각할 것입니다.

의 출력 예 cachestat:

storage-01 [resized disk]
    HITS   MISSES  DIRTIES    RATIO   BUFFERS_MB   CACHE_MB
    9691    14566     7821    40.0%          160       2628
   36181    14689     7802    71.1%          160       2631
    8649    13617     7003    38.8%          159       2628
   15567    13399     6857    53.7%          160       2627
    9045    14002     7049    39.2%          160       2627
    7533    12503     6153    37.6%          159       2620

storage-02 [not resized]
    HITS   MISSES  DIRTIES    RATIO   BUFFERS_MB   CACHE_MB
    5097    11629     4740    30.5%          143       2365
    5977    11045     4843    35.1%          142       2344
    4356    10479     4199    29.4%          143       2364
    6611    11188     4946    37.1%          143       2348
   33734    14511     5930    69.9%          143       2347
    7885    16353     7090    32.5%          143       2358

Super Late Edit : SSD를 사용할 수있는 다른 플랫폼으로 마이그레이션 한 후 일정 기간 동안 성능이 향상되었지만 더 많은 메트릭을 추가 할 때 성능이 크게 저하되었습니다. 확실한 증거는 없지만 이것이 카본 / 위스퍼 스토리지의 작동 방식과 우리가 저장하는 수많은 지표 사이의 모퉁이 사례라고 생각합니다.

기본적으로 시스템에 충분한 RAM이있어 읽기 용 Whisper 파일을 편안하게 캐시 할 수 있다면 IO는 거의 순수한 쓰기이며 모든 것이 행복합니다. 그러나 일단 FS 캐시 기아 상태가 설정되고 Whisper 파일은 IO 대역폭을 차지하는 디스크에서 지속적으로 읽어야하며 모든 것이 작동하기 시작합니다.

SSD를 사용하는 것처럼 들립니다. SSD가 가득 차면 약간의 성능 특성이있을 수 있습니다. 사용량이 6/1로 떨어졌을 때 성능이 정상으로 돌아 가지 않았다는 사실은 그 이론을 강화합니다.

그 이유는 모두 복잡하지만 기본적으로 현재 사용되지 않는 플래시 덩어리를 비워야 다시 작성할 수 있기 때문입니다. 꽤 열심히 쓰는 것처럼 보이므로 드라이브에서 실행되는 블랭킹 프로세스는 일단 블랭킹 된 청크를 모두 한 번만 기록하면 충분한 공급량을 유지할 수 없습니다.

드라이브마다 모델마다 컨트롤러가 다르고 사용할 "예비"플래시 청크의 양이 다르며, 더 큰 드라이브에는 새 비트가 떨어지기 전에 더 많은 청크를 쓸 수 있으므로 더 큰 드라이브로 업그레이드하면 "해결"될 것입니다. 적어도 일시적으로 당신을위한 문제. "엔터프라이즈"등급 드라이브는 이와 관련하여 더 나은 경향이 있지만 최신 플래시 컨트롤러 모델도 마찬가지이므로 사용 패턴과 유사한 사용 패턴으로 특정 드라이브 모델에 대한 신뢰할 수있는 타사 테스트가없는 경우 약간의 문제입니다. 너 스스로.

당신은 또한 당신이 좋아하는 뭔가를 흔들 경우, 좀 더 시간이 지금 당신이 가지고있는 드라이브를 사용하여 멀리 얻을 수 있습니다 fstrim드라이브 "당신은 확실히 바로이 덩어리를 모두 닦아 수 말해 그들에 지금을 시스템에 그 일을하지만," 동시에 다른 작업을 수행해야합니다. 제대로 작동하지 않을 수 있습니다 ( fstrim맨 페이지 의 성능 경고에 유의하십시오 ).

더 많은 노드가 필요한지 여부에 대해서는 확실하게 말할 수 없지만 그렇게 생각하지는 않습니다. CPU가 통제력을 상실하지 않으므로 다른 곳에서 I / O 시스템을 포화 상태로 만들지 의심됩니다.

Ext3 / 4는 80-85 % 이상의 사용률로 성능 관점에서 어려움을 겪는 것으로 잘 알려져 있습니다. 조각화가 증가하고 쓰기 저장 성능이 저하 되었기 때문입니다.

iostat -k -x 60 3용량이 80 % 미만인 경우와 80 % 이상인 경우 두 가지 출력 을 제공 할 수 있습니까 ?

편집 : 당신 의 여유 공간이 많이있는 e2freefrag것 같습니다 /dev/vda3. df및 의 출력을 추가 할 수 있습니까 df -i?

어쨌든 iostat결과는 그래프 (특히 "디스크 IOPS")와 결합되어 매우 흥미 롭습니다. 워크로드가 쓰기 중심적인 것 같습니다. 총 발행 IOPS의> 95 %가 쓰기 인 경우 아무런 문제가 없습니다. 그러나 성능이 저하되면 디스크가 일관된 읽기 IOPS를 제공하기 시작합니다. 이 혼합 된 읽기 / 쓰기는 디스크에서 여러 개의 작은 쓰기를 더 큰 쓰기 (일반적으로 읽기가 작업을 차단 함)로 결합하는 기능을 방해하여 성능이 훨씬 느려집니다.

예를 들어, 주먹으로 표시 및 결과 보자 iostat: 총 디스크 IOPS가 (이 경우로) 쓰기 지배, 귀하의 경우 avgqu-sz와 await모두 매우 낮다.

그러나 두 번째와 세 번째에는 iostat더 많은 읽기가 있으며, 이는 읽기 / 차단 작업 ( rrqm/s열 참조 : 0을 표시하므로 읽기를 병합 할 수 없음), 대기 시간 ( await) 및 처리량 (KB / s)을 모두 방해합니다. .

호스트에 inode 캐시가 부족한 경우 비슷한 수의 작은 파일이 저장되어 있기 때문에 비슷한 동작을 보았습니다. 데이터 캐시를 희생하여 inode / dentry 캐시를 선호하도록 시스템을 조정하려면 발행을 시도 echo 10 > /proc/sys/vm/vfs_cache_pressure하고 몇 분 정도 기다리십시오. 변경 사항이 있습니까?