Hiệu suất và hiệu suất của Ext4

Tôi đã có một cụm máy chạy Carbon và Graphite mà tôi cần mở rộng để lưu trữ nhiều hơn, nhưng tôi không chắc liệu tôi có cần mở rộng quy mô hay không.

Các cụm hiện bao gồm:

• Nút chuyển tiếp 1: Nhận tất cả các số liệu và chuyển tiếp đến nút lưu trữ có liên quan
• 6 Nút lưu trữ: Nhà chứa tất cả các tệp Whisper DB

Vấn đề là có vẻ như khi các đĩa nằm trong vùng lân cận sử dụng 80%, hiệu suất rơi ra khỏi một vách đá. IOPS viết cụm đã giảm từ mức trung bình gần 13k xuống mức trung bình hỗn loạn hơn khoảng 7k và thời gian chờ đợi trung bình là 54%.

Tôi đã xem qua repo cấu hình của chúng tôi và không có thay đổi nào kể từ đầu tháng 4, vì vậy đây không phải là kết quả của thay đổi cấu hình.

Câu hỏi: Việc tăng kích thước đĩa sẽ mang lại hiệu suất IO trong tầm kiểm soát hay tôi cần thêm nhiều nút lưu trữ hơn?

Lưu ý: Không có SSD ở đây, chỉ có rất nhiều và nhiều trục chính.

Đồ thị liên quan:

Số liệu thống kê và nội dung:

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

Chỉnh sửa: Tôi đã thay đổi kích thước một trong các nút lưu trữ, nhưng nó không có hiệu lực. Tôi cũng đã tìm thấy cachestattiện ích này trong [ https://github.com/brendangregg/perf-tools[(a bộ sưu tập các công cụ hoàn hảo) đã cho tôi xem bên trong bộ đệm VFS. Tại thời điểm này, có vẻ như tôi đã đạt đến giới hạn về thông lượng IO mà bộ lưu trữ của tôi có thể cung cấp.

Tại thời điểm này, tôi nghĩ rằng tôi sẽ phải tiếp tục mở rộng quy mô cho nhiều thành viên cụm hơn hoặc xem về việc tìm kiếm một giải pháp lưu trữ chuỗi thời gian hiệu quả hơn.

Ví dụ đầu ra từ 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

Chỉnh sửa siêu muộn: Chúng tôi đã chuyển sang nền tảng khác, nơi có sẵn SSD và, trong khi mọi thứ vẫn tốt trong một thời gian, cuối cùng chúng tôi đã thấy hiệu suất giảm mạnh như vậy khi chúng tôi thêm nhiều số liệu hơn. Mặc dù tôi không có bất kỳ bằng chứng chắc chắn nào, tôi tin rằng đây là một trường hợp góc giữa cách thức lưu trữ Carbon / Whisper và số lượng số liệu tuyệt đối mà chúng tôi lưu trữ.

Về cơ bản, miễn là hệ thống có đủ RAM để thoải mái lưu trữ các tệp Whisper để đọc thì IO gần như là ghi thuần túy và mọi thứ đều hạnh phúc. Tuy nhiên, một khi bộ nhớ cache bộ đệm FS đặt trong và các tệp Whisper cần phải được đọc liên tục trong đĩa ăn vào băng thông IO của bạn và mọi thứ bắt đầu được xử lý.

Âm thanh như bạn đang chạy SSD, có thể có một số đặc điểm hiệu suất thú vị khi chúng đầy. Thực tế là khi mức sử dụng giảm khoảng 6/1, hiệu suất không trở lại bình thường, củng cố lý thuyết đó.

Lý do đằng sau nó khá phức tạp, nhưng về cơ bản xuất phát từ nhu cầu xóa các đoạn flash được viết nhưng hiện tại chưa được sử dụng trước khi có thể viết lại. Có vẻ như bạn đang viết khá khó khăn, vì vậy quá trình xóa trống đang chạy trong ổ đĩa không có cơ hội duy trì đủ nguồn cung cấp các khối trống một khi tất cả được viết thành một lần.

Các mô hình ổ đĩa khác nhau có bộ điều khiển khác nhau và số lượng flash "dự phòng" khác nhau để sử dụng và các ổ đĩa lớn hơn rõ ràng có nhiều khối hơn để ghi trước khi chúng hết bit mới, do đó, gần như chắc chắn rằng việc nâng cấp lên ổ đĩa lớn hơn sẽ "giải quyết" vấn đề cho bạn, ít nhất là tạm thời. Các ổ đĩa cấp "Doanh nghiệp" có xu hướng làm tốt hơn trong vấn đề này, nhưng các mô hình bộ điều khiển flash mới hơn cũng vậy, do đó, có một chút tào lao, trong trường hợp không có thử nghiệm đáng tin cậy của bên thứ ba về một mô hình ổ đĩa cụ thể trong mô hình sử dụng tương tự như của riêng bạn

Bạn cũng có thể thoát khỏi việc sử dụng các ổ đĩa mà bạn có bây giờ thêm một thời gian nữa, nếu bạn vẫy một cái gì đó giống như fstrimchúng để nói với ổ đĩa "bạn chắc chắn có thể xóa sạch tất cả các khối này ngay bây giờ ", mặc dù thực hiện nó trên một hệ thống bạn cần phải làm những việc khác cùng một lúc có thể không đi xuống tốt như vậy (bạn sẽ muốn lưu ý tốt các cảnh báo hiệu suất trong fstrimtrang chủ).

Về việc bạn có cần nhiều nút hơn không, tôi không thể chắc chắn nhưng tôi không nghĩ vậy. CPU không vượt quá tầm kiểm soát và tôi nghi ngờ bạn sẽ bão hòa hệ thống I / O ở nơi khác.

Ext3 / 4 được biết là phải chịu, từ quan điểm hiệu suất, với mức sử dụng trên 80-85%. Điều này là do sự phân mảnh tăng và hiệu suất ghi giảm.

Bạn có thể cung cấp hai iostat -k -x 60 3đầu ra, một khi dưới 80% công suất và một khi trên 80%?

EDIT: từ bạn e2freefragdường như /dev/vda3có nhiều không gian trống. Bạn có thể thêm đầu ra của dfvà df -i?

Dù sao, iostatkết quả của bạn , kết hợp với biểu đồ của bạn (đặc biệt là "Đĩa IOPS"), khá thú vị. Có vẻ như khối lượng công việc của bạn là rất trung tâm; khi> 95% tổng số IOPS đã ban hành được ghi, bạn không gặp vấn đề gì. Tuy nhiên, khi hiệu suất của bạn suy giảm, các đĩa của bạn bắt đầu phục vụ nhất quán đọc IOPS. Việc đọc / ghi xen kẽ này làm gián đoạn khả năng kết hợp nhiều lần ghi nhỏ hơn của các đĩa lớn hơn (đọc thường là các hoạt động chặn), dẫn đến hiệu suất chậm hơn nhiều.

Ví dụ, hãy xem kết quả nắm đấm được hiển thị bởi iostat: khi tổng số IOPS của đĩa bị chi phối bởi ghi (như trong trường hợp này), cả hai avgqu-szvà của bạn awaitđều rất thấp.

Nhưng trong lần thứ hai và thứ ba, iostatchúng ta sẽ thấy nhiều lần đọc hơn, đó là các hoạt động chặn / đình trệ (xem rrqm/scột: nó hiển thị 0, vì vậy không có kết quả nào có thể được hợp nhất trong trường hợp của bạn), làm gián đoạn cả độ trễ ( await) và thông lượng (KB / s) .

Tôi đã thấy hành vi tương tự khi máy chủ hết bộ đệm inode, có thể do số lượng tệp nhỏ được lưu trữ. Để điều chỉnh hệ thống của bạn để thích bộ đệm inode / nha khoa với chi phí của bộ đệm dữ liệu, hãy thử phát hành echo 10 > /proc/sys/vm/vfs_cache_pressurevà chờ vài phút: nó có thay đổi gì không?