Penggunaan dan kinerja Ext4

Saya memiliki sekelompok mesin yang menjalankan Karbon dan Grafit yang perlu saya skala untuk penyimpanan lebih banyak, tetapi saya tidak yakin apakah saya perlu memperbesar atau memperkecil.

Cluster saat ini terdiri dari:

• 1 Relay Node: Menerima semua metrik dan meneruskan ke simpul penyimpanan yang relevan
• 6 Node Penyimpanan: Rumah semua file DB Bisikan

Masalahnya adalah bahwa sepertinya ketika disk mendapat di lingkungan penggunaan 80% kinerja turun dari tebing. Cluster menulis IOPS turun dari hampir konstan 13k ke rata-rata lebih kacau di sekitar 7k dan IOwait waktu rata-rata 54%.

Saya sudah melihat-lihat repo konfigurasi kami dan tidak ada perubahan sejak awal April, jadi ini bukan hasil dari perubahan konfigurasi.

Pertanyaan: Apakah meningkatkan ukuran disk akan mengembalikan kinerja IO, atau apakah saya perlu menambahkan lebih banyak node penyimpanan?

Catatan: Tidak ada SSD di sini, hanya banyak dan banyak gelendong.

Grafik yang Relevan:

Stats and Stuff:

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

Sunting: Saya telah mengubah ukuran salah satu node penyimpanan, tetapi tidak berpengaruh. Saya juga menemukan cachestatutilitas di [ https://github.com/brendangregg/perf-tools[(a koleksi alat perf) yang memberi saya pandangan di dalam cache VFS. Pada titik ini sepertinya saya telah mencapai batas pada throughput IO yang dapat disediakan oleh penyimpanan saya.

Pada titik ini saya pikir saya harus terus meningkatkan skala ke lebih banyak anggota cluster, atau melihat tentang menemukan solusi penyimpanan seri waktu yang lebih efisien.

Contoh output dari 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

Sunting Super Terlambat: Kami sejak bermigrasi ke platform lain di mana SSD tersedia dan, sementara beberapa hal bagus untuk beberapa waktu, kami akhirnya melihat penurunan tajam dalam kinerja yang sama ketika kami menambahkan semakin banyak metrik. Meskipun saya tidak memiliki bukti definitif, saya percaya ini adalah kasus sudut antara cara penyimpanan Carbon / Whisper bekerja, dan banyaknya metrik yang kami simpan.

Pada dasarnya, selama sistem memiliki RAM yang cukup untuk dengan nyaman men-cache file Whisper untuk membaca IO adalah tulisan yang hampir murni dan semuanya bahagia. Namun, begitu kelaparan FS cache masuk dan file Whisper harus terus dibaca dalam disk yang memakan bandwidth IO Anda dan semuanya mulai pot.

Kedengarannya seperti Anda menjalankan SSD, yang dapat memiliki beberapa karakteristik kinerja yang funky saat sudah penuh. Fakta bahwa ketika penggunaan turun sekitar 6/1, kinerja tidak kembali normal, memperkuat teori itu.

Alasan di balik itu semua agak rumit, tetapi pada dasarnya bermuara pada kebutuhan untuk mengosongkan potongan flash yang belum digunakan sebelum dapat ditulis lagi. Sepertinya Anda menulis cukup keras, sehingga proses pengosongan yang berjalan di drive tidak memiliki kesempatan untuk menjaga persediaan potongan-potongan yang kosong begitu semuanya ditulis untuk satu kali.

Model drive yang berbeda memiliki pengontrol yang berbeda, dan jumlah potongan flash "cadangan" yang berbeda untuk digunakan, dan drive yang lebih besar jelas memiliki lebih banyak potongan untuk ditulis sebelum kehabisan bit segar, sehingga hampir pasti bahwa meng-upgrade ke drive yang lebih besar akan "menyelesaikan" masalah untuk Anda, setidaknya untuk sementara. Drive kelas "Enterprise" cenderung lebih baik dalam hal ini, tetapi begitu juga model-model baru dari pengontrol flash, jadi ini sedikit omong kosong, dengan tidak adanya pengujian pihak ketiga yang dapat diandalkan dari model drive tertentu dalam pola penggunaan yang serupa dengan milikmu.

Anda juga mungkin dapat menggunakan drive yang Anda miliki sekarang untuk beberapa waktu lagi, jika Anda melambaikan sesuatu seperti fstrimitu untuk memberi tahu drive "Anda pasti dapat menghapus semua potongan ini sekarang ", meskipun melakukannya pada sistem Anda harus melakukan hal-hal lain pada saat yang sama mungkin tidak turun dengan baik (Anda harus mencatat dengan baik peringatan kinerja di halaman fstrimmanual).

Seperti apakah Anda membutuhkan lebih banyak node, saya tidak bisa mengatakan dengan pasti tetapi saya tidak berpikir begitu. CPU tidak terlihat di luar kendali, dan saya ragu Anda akan menjenuhkan sistem I / O di tempat lain.

Ext3 / 4 diketahui menderita, dari sudut pandang kinerja, dengan pemanfaatan di atas 80-85%. Ini karena peningkatan fragmentasi dan berkurangnya kinerja penulisan kembali.

Dapatkah Anda memberikan dua iostat -k -x 60 3output, satu ketika di bawah 80% kapasitas dan satu ketika lebih dari 80%?

EDIT: dari Anda e2freefragtampaknya /dev/vda3memiliki banyak ruang bebas. Bisakah Anda menambahkan output dari dfdan df -i?

Bagaimanapun, iostathasil Anda , dikombinasikan dengan grafik Anda (terutama "Disk IOPS"), cukup menarik. Tampaknya beban kerja Anda sangat centric; ketika> 95% dari total IOPS yang diterbitkan ditulis, Anda tidak memiliki masalah. Namun, ketika kinerja Anda menurun, disk Anda mulai menyajikan IOPS baca yang konsisten. Proses baca / tulis yang terputus-putus ini mengganggu kemampuan disk untuk menggabungkan beberapa penulisan yang lebih kecil menjadi lebih besar (baca biasanya memblokir operasi), yang menyebabkan kinerja jauh lebih lambat.

Sebagai contoh, mari kita lihat hasil tinju yang ditunjukkan oleh iostat: ketika total disk IOPS didominasi oleh write (seperti dalam kasus ini), Anda avgqu-szdan awaitkeduanya sangat rendah.

Tetapi pada bagian kedua dan ketiga iostatkita melihat lebih banyak pembacaan yang, sebagai operasi pemblokiran / penghentian (lihat rrqm/skolom: ini menunjukkan 0, jadi tidak ada pembacaan yang dapat digabungkan dalam kasus Anda), mengganggu latensi ( await) dan throughput (KB / s) .

Saya telah melihat perilaku yang sama ketika host kehabisan cache inode, mungkin karena banyaknya file kecil yang disimpan. Untuk menyesuaikan sistem Anda agar memilih inode / dentry cache dengan mengorbankan cache data, cobalah mengeluarkan echo 10 > /proc/sys/vm/vfs_cache_pressuredan tunggu beberapa menit: apakah itu mengubah apa pun?