Ext4 kullanımı ve performansı

Daha fazla depolama için ölçeklemem gereken Carbon ve Graphite çalıştıran bir makine kümem var, ancak ölçeklendirip ölçeklendirmem gerekmediğinden emin değilim.

Küme şu anda şunlardan oluşmaktadır:

• 1 Röle Düğümü: Tüm metrikleri alır ve ilgili depolama düğümüne iletir
• 6 Depolama Düğümü: Tüm Whisper DB dosyalarını barındırır

Sorun şu ki, diskler% 80 kullanım mahallesine girdiğinde performans bir uçurumdan düştü. Küme yazma IOPS, yaklaşık sabit bir 13k'den yaklaşık 7k daha kaotik bir ortalamaya düştü ve IOwait zaman ortalamaları% 54'tür.

Yapılandırma depomuza bir göz attım ve Nisan ayının başından beri hiçbir değişiklik yok, bu yüzden bu bir yapılandırma değişikliğinin sonucu değil.

Soru: Disk boyutunu artırmak GÇ performansını kontrol altına alır mı yoksa daha fazla depolama düğümü eklemem gerekir mi?

Not: Burada SSD yok, sadece çok fazla mil var.

İlgili Grafikler:

İstatistikler ve Sayfalar:

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

Düzenleme: Depolama düğümlerinden birini yeniden boyutlandırdım, ancak bunun bir etkisi olmadı. Ayrıca cachestatyardımcı programı , VFS önbelleğinin içine bir görünüm veren [ https://github.com/brendangregg/perf-tools Genişletilmiş(a mükemmel araçlar koleksiyonu) içinde buldum . Bu noktada, depolama alanımın sağlayabileceği G / Ç verimi sınırına ulaşmışım gibi görünüyor.

Bu noktada ya daha fazla küme üyesine ölçeklenmeye devam edeceğim ya da daha verimli bir zaman serisi depolama çözümü bulacağımı düşünüyorum.

Örnek çıktı 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

Süper Geç Düzenleme: O zamandan beri SSD'lerin mevcut olduğu başka bir platforma taşındık ve işler bir süre daha iyi olsa da, sonunda daha fazla metrik eklediğimizde performansta aynı keskin düşüşü gördük. Kesin bir kanıtım olmasa da, bunun Carbon / Whisper depolamasının nasıl çalıştığı ile sakladığımız çok sayıda metrik arasında bir köşe örneği olduğuna inanıyorum.

Temel olarak, sistem, Whisper dosyalarını okumak için rahatça önbelleğe almak için yeterli RAM'e sahip olduğu sürece, IO neredeyse saf yazma ve her şey mutlu. Bununla birlikte, FS önbellek açlığı başladığında ve Whisper dosyalarının IO bant genişliğinize giren diskten sürekli olarak okunması gerekir ve her şey çöpe gitmeye başlar.

SSD'leri çalıştırıyor gibi görünüyorsunuz, bu da dolu olduklarında bazı eğlenceli performans özelliklerine sahip olabilir. Kullanım 6/1 civarında düştüğünde, performans normale dönmemiştir, bu teoriyi güçlendirir.

Bunun arkasındaki neden oldukça karmaşıktır, ancak temel olarak tekrar yazılmadan önce yazılı ama şu anda kullanılmayan flaş parçalarını boşaltma ihtiyacına gelir. Oldukça sert yazdığınız anlaşılıyor, bu nedenle sürücüde çalışan körleme işleminin, hepsi bir kez yazıldıktan sonra yeterli miktarda boş parça tedarik etme şansı yok.

Farklı sürücü modellerinin farklı denetleyicileri ve farklı miktarda "yedek" flaş parçaları vardır ve daha büyük sürücüler, yeni bitler bitmeden önce yazmak için daha fazla parçaya sahiptir, bu nedenle daha büyük sürücülere yükseltmenin "çözeceği" neredeyse kesindir. sorun, en azından geçici olarak. "Kurumsal" sınıf sürücüler bu konuda daha iyi performans gösterme eğilimindedir, ancak daha yeni flaş denetleyici modelleri de geçerlidir, bu nedenle, benzer bir kullanım modelinde belirli bir sürücü modelinin güvenilir bir üçüncü taraf testinin olmaması durumunda, biraz crapshoot'dur. kendi.

Ayrıca böyle bir şey dalga halinde bir süre daha şimdi sahip olduğunuz sürücüleri kullanarak kurtulmak mümkün olabilir fstrimsürücü "kesinlikle doğru bu parçalar tüm silebilir anlatmak için üzerlerinden artık bir sistemde yapıyor rağmen," aynı anda başka şeyler yapmak zorunda değilsiniz o kadar da iyi gitmeyebilir ( fstrimman sayfasındaki performans uyarılarını iyi not etmek istersiniz ).

Daha fazla düğüme ihtiyacınız olup olmadığı konusunda kesin olarak söyleyemem ama öyle düşünmüyorum. CPU kontrolden çıkmıyor ve başka bir yerde G / Ç sistemini doyuracağınızdan şüpheliyim.

Ext3 / 4'ün performans açısından% 80-85'in üzerinde kullanımı olduğu bilinmektedir. Bunun nedeni, artan parçalanma ve geri yazma performansının azalmasıdır.

iostat -k -x 60 3Biri% 80 kapasitenin altında ve diğeri% 80'in üzerinde olduğunda iki çıktı sağlayabilir misiniz ?

DÜZENLEME: senin dan e2freefraggörünüyor /dev/vda3boş alan bol vardır. Eğer çıktısını ekleyebilir dfve df -i?

Her neyse, iostatsonuçlarınız grafiklerinizle birleştiğinde (özellikle "Disk IOPS") oldukça ilginçtir. İş yükünüz çok yazma merkezli görünüyor; yayınlanan toplam IOPS'un% 95'inden fazlası yazıldığında, sorun yaşamazsınız. Ancak, performansınız düştüğünde, diskleriniz tutarlı bir okuma IOPS sunmaya başlar. Bu karışık okuma / yazma disklerin birden çok küçük yazıyı daha büyük olanlarla birleştirme yeteneğini bozar (okumalar genellikle engelleme işlemidir) ve çok daha yavaş performansa yol açar.

Örneğin, aşağıdaki gibi gösterilen yumruk sonucuna bakalım iostat: toplam disk IOPS'una yazmalar hâkim olduğunda (bu durumda olduğu gibi) avgqu-szve awaithem çok düşüktür.

Ancak ikinci ve üçüncü olarak iostat, engelleme / durdurma işlemlerini ( rrqm/ssütuna bakın : 0 gösterir, böylece sizin durumunuzda hiçbir okuma birleştirilemez), hem gecikmeyi ( await) hem de iş hacmini (KB / s) bozan çok daha fazla okuma görüyoruz. .

Ana bilgisayar inode önbellek bittiğinde, belki de saklanan küçük dosyaların sayısı nedeniyle benzer davranış gördüm. Sisteminizi veri önbelleği pahasına inode / dentry önbelleğini tercih edecek şekilde ayarlamak için, yayınlamayı deneyin echo 10 > /proc/sys/vm/vfs_cache_pressureve birkaç dakika bekleyin: bir şey değiştiriyor mu?