MariaDB
 sql >> Cơ Sở Dữ Liệu >  >> RDS >> MariaDB

Cách đánh giá hiệu suất của MySQL &MariaDB bằng SysBench

SysBench là gì? Nếu bạn làm việc với MySQL thường xuyên, thì có lẽ bạn đã nghe nói về nó. SysBench đã ở trong hệ sinh thái MySQL từ lâu. Ban đầu nó được viết bởi Peter Zaitsev vào năm 2004. Mục đích của nó là cung cấp một công cụ để chạy các điểm chuẩn tổng hợp của MySQL và phần cứng mà nó chạy trên đó. Nó được thiết kế để chạy các bài kiểm tra CPU, bộ nhớ và I / O. Nó cũng có một tùy chọn để thực thi khối lượng công việc OLTP trên cơ sở dữ liệu MySQL. OLTP là viết tắt của xử lý giao dịch trực tuyến, khối lượng công việc điển hình cho các ứng dụng trực tuyến như thương mại điện tử, nhập đơn hàng hoặc hệ thống giao dịch tài chính.

Trong bài đăng trên blog này, chúng tôi sẽ tập trung vào tính năng điểm chuẩn của SQL nhưng hãy nhớ rằng điểm chuẩn phần cứng cũng có thể rất hữu ích trong việc xác định các vấn đề trên máy chủ cơ sở dữ liệu. Ví dụ:điểm chuẩn I / O nhằm mục đích mô phỏng khối lượng công việc I / O của InnoDB trong khi các bài kiểm tra CPU liên quan đến việc mô phỏng môi trường đa nhịp, đồng thời cao cùng với các bài kiểm tra nội dung mutex - một cái gì đó cũng giống như một loại khối lượng công việc cơ sở dữ liệu.

Lịch sử và kiến ​​trúc SysBench

Như đã đề cập, SysBench ban đầu được tạo ra vào năm 2004 bởi Peter Zaitsev. Ngay sau đó, Alexey Kopytov đã tiếp quản sự phát triển của nó. Nó đã đạt đến phiên bản 0.4.12 và quá trình phát triển tạm dừng. Sau một thời gian dài nghỉ ngơi, Alexey bắt đầu hoạt động trở lại trên SysBench vào năm 2016. Ngay sau đó, phiên bản 0.5 đã được phát hành với điểm chuẩn OLTP được viết lại để sử dụng các tập lệnh dựa trên LUA. Sau đó, vào năm 2017, SysBench 1.0 đã được phát hành. Điều này giống như ngày và đêm so với phiên bản cũ, 0.4.12. Đầu tiên và quan trọng nhất, thay vì các tập lệnh được mã hóa cứng, giờ đây chúng tôi có khả năng tùy chỉnh các điểm chuẩn bằng LUA. Ví dụ, Percona đã tạo điểm chuẩn giống như TPCC có thể được thực thi bằng SysBench. Hãy xem nhanh kiến ​​trúc SysBench hiện tại.

SysBench là một mã nhị phân C sử dụng các tập lệnh LUA để thực thi các điểm chuẩn. Các tập lệnh đó phải:

  1. Xử lý đầu vào từ các tham số dòng lệnh
  2. Xác định tất cả các chế độ mà điểm chuẩn phải sử dụng (chuẩn bị, chạy, dọn dẹp)
  3. Chuẩn bị tất cả dữ liệu
  4. Xác định cách điểm chuẩn sẽ được thực thi (các truy vấn sẽ trông như thế nào, v.v.)

Tập lệnh có thể sử dụng nhiều kết nối đến cơ sở dữ liệu, chúng cũng có thể xử lý kết quả nếu bạn muốn tạo các điểm chuẩn phức tạp trong đó các truy vấn phụ thuộc vào tập kết quả của các truy vấn trước đó. Với SysBench 1.0, có thể tạo biểu đồ độ trễ. Các tập lệnh LUA cũng có thể bắt và xử lý lỗi thông qua các móc lỗi. Có hỗ trợ song song trong tập lệnh LUA, nhiều truy vấn có thể được thực hiện song song, chẳng hạn như việc cung cấp nhanh hơn nhiều. Cuối cùng nhưng không kém phần quan trọng, nhiều định dạng đầu ra hiện đã được hỗ trợ. Trước khi SysBench chỉ tạo ra đầu ra mà con người có thể đọc được. Giờ đây, có thể tạo nó dưới dạng CSV hoặc JSON, giúp việc xử lý hậu kỳ và tạo đồ thị dễ dàng hơn nhiều bằng cách sử dụng, ví dụ:gnuplot hoặc cung cấp dữ liệu vào Prometheus, Graphite hoặc kho dữ liệu tương tự.

Tại sao lại sử dụng SysBench?

Lý do chính khiến SysBench trở nên phổ biến là thực tế là nó rất đơn giản để sử dụng. Ai đó không có kiến ​​thức trước có thể bắt đầu sử dụng nó trong vòng vài phút. Theo mặc định, nó cũng cung cấp các điểm chuẩn bao gồm hầu hết các trường hợp - khối lượng công việc OLTP, chỉ đọc hoặc đọc-ghi, tra cứu khóa chính và cập nhật khóa chính. Tất cả những điều đó đã gây ra hầu hết các sự cố cho MySQL, cho đến MySQL 8.0. Đây cũng là lý do tại sao SysBench rất phổ biến trong các điểm chuẩn và so sánh khác nhau được công bố trên Internet. Những bài đăng đó đã giúp quảng bá công cụ này và đưa nó trở thành tiêu chuẩn tổng hợp dành cho MySQL.

Một điều tốt nữa về SysBench là, kể từ phiên bản 0.5 và kết hợp LUA, bất kỳ ai cũng có thể chuẩn bị bất kỳ loại điểm chuẩn nào. Chúng tôi đã đề cập đến điểm chuẩn giống TPCC nhưng bất kỳ ai cũng có thể tạo ra thứ gì đó giống với khối lượng công việc sản xuất của cô ấy. Chúng tôi không nói rằng nó đơn giản, nó rất có thể sẽ là một quá trình tốn thời gian, nhưng có khả năng này sẽ có lợi nếu bạn cần chuẩn bị một điểm chuẩn tùy chỉnh.

Là một điểm chuẩn tổng hợp, SysBench không phải là một công cụ mà bạn có thể sử dụng để điều chỉnh cấu hình máy chủ MySQL của mình (trừ khi bạn đã chuẩn bị các tập lệnh LUA với khối lượng công việc tùy chỉnh hoặc khối lượng công việc của bạn rất giống với khối lượng công việc chuẩn mà SysBench đi kèm). Điều tuyệt vời là so sánh hiệu suất của các phần cứng khác nhau. Bạn có thể dễ dàng so sánh hiệu suất của, giả sử, các loại nút khác nhau do nhà cung cấp dịch vụ đám mây của bạn cung cấp và QPS (truy vấn mỗi giây) tối đa mà họ cung cấp. Biết số liệu đó và biết số tiền bạn phải trả cho một nút nhất định, sau đó bạn có thể tính toán số liệu quan trọng hơn - QP $ (truy vấn trên mỗi đô la). Điều này sẽ cho phép bạn xác định loại nút nào sẽ sử dụng khi xây dựng một môi trường tiết kiệm chi phí. Tất nhiên, SysBench cũng có thể được sử dụng để điều chỉnh ban đầu và đánh giá tính khả thi của một thiết kế nhất định. Giả sử chúng tôi xây dựng một cụm Galera trải dài trên toàn cầu - Bắc Mỹ, Liên minh Châu Âu, Châu Á. Một thiết lập như vậy có thể xử lý bao nhiêu lần chèn mỗi giây? Độ trễ cam kết sẽ như thế nào? Liệu có hợp lý không khi thực hiện một bằng chứng về khái niệm hoặc có thể độ trễ mạng đủ cao để ngay cả một khối lượng công việc đơn giản cũng không hoạt động như bạn mong đợi.

Còn về kiểm tra căng thẳng thì sao? Không phải tất cả mọi người đều đã chuyển sang đám mây, vẫn có những công ty thích xây dựng cơ sở hạ tầng của riêng họ. Mỗi máy chủ mới được mua phải trải qua một giai đoạn khởi động, trong đó bạn sẽ nhấn mạnh nó để xác định các lỗi phần cứng tiềm ẩn. Trong trường hợp này, SysBench cũng có thể giúp bạn. Bằng cách thực thi khối lượng công việc OLTP làm quá tải máy chủ hoặc bạn cũng có thể sử dụng các điểm chuẩn chuyên dụng cho CPU, đĩa và bộ nhớ.

Như bạn có thể thấy, có nhiều trường hợp mà ngay cả một điểm chuẩn tổng hợp, đơn giản cũng có thể rất hữu ích. Trong đoạn tiếp theo, chúng ta sẽ xem xét những gì chúng ta có thể làm với SysBench.

SysBench có thể làm gì cho bạn?

Bạn có thể chạy thử nghiệm nào?

Như đã đề cập ở phần đầu, chúng tôi sẽ tập trung vào các điểm chuẩn của OLTP và xin nhắc lại rằng chúng tôi sẽ nhắc lại rằng SysBench cũng có thể được sử dụng để thực hiện kiểm tra I / O, CPU và bộ nhớ. Hãy xem xét các điểm chuẩn mà SysBench 1.0 đi kèm (chúng tôi đã xóa một số tệp LUA trợ giúp và tập lệnh LUA không phải cơ sở dữ liệu khỏi danh sách này).

-rwxr-xr-x 1 root root 1.5K May 30 07:46 bulk_insert.lua
-rwxr-xr-x 1 root root 1.3K May 30 07:46 oltp_delete.lua
-rwxr-xr-x 1 root root 2.4K May 30 07:46 oltp_insert.lua
-rwxr-xr-x 1 root root 1.3K May 30 07:46 oltp_point_select.lua
-rwxr-xr-x 1 root root 1.7K May 30 07:46 oltp_read_only.lua
-rwxr-xr-x 1 root root 1.8K May 30 07:46 oltp_read_write.lua
-rwxr-xr-x 1 root root 1.1K May 30 07:46 oltp_update_index.lua
-rwxr-xr-x 1 root root 1.2K May 30 07:46 oltp_update_non_index.lua
-rwxr-xr-x 1 root root 1.5K May 30 07:46 oltp_write_only.lua
-rwxr-xr-x 1 root root 1.9K May 30 07:46 select_random_points.lua
-rwxr-xr-x 1 root root 2.1K May 30 07:46 select_random_ranges.lua

Hãy xem qua từng cái một.

Đầu tiên, số lượng lớn_insert.lua. Bài kiểm tra này có thể được sử dụng để đánh giá khả năng thực hiện chèn nhiều hàng của MySQL. Điều này có thể khá hữu ích khi kiểm tra, chẳng hạn như hiệu suất của bản sao hoặc cụm Galera. Trong trường hợp đầu tiên, nó có thể giúp bạn trả lời một câu hỏi:“Tôi có thể chèn nhanh bao nhiêu trước khi độ trễ nhân bản bắt đầu?”. Trong trường hợp sau, nó sẽ cho bạn biết dữ liệu có thể được chèn vào một cụm Galera nhanh như thế nào với độ trễ mạng hiện tại.

Tất cả các tập lệnh oltp_ * đều có chung một cấu trúc bảng. Hai đầu tiên trong số chúng (oltp_delete.lua và oltp_insert.lua) thực hiện các câu lệnh DELETE và INSERT đơn lẻ. Một lần nữa, đây có thể là một bài kiểm tra đối với sao chép hoặc cụm Galera - đẩy nó đến giới hạn và xem số lượng chèn hoặc xóa mà nó có thể xử lý. Chúng tôi cũng có các điểm chuẩn khác tập trung vào chức năng cụ thể - oltp_point_select, oltp_update_index và oltp_update_non_index. Những điều này sẽ thực hiện một tập hợp con các truy vấn - lựa chọn dựa trên khóa chính, cập nhật dựa trên chỉ mục và cập nhật không dựa trên chỉ mục. Nếu bạn muốn kiểm tra một số chức năng này, các bài kiểm tra ở đó. Chúng tôi cũng có các điểm chuẩn phức tạp hơn dựa trên khối lượng công việc OLTP:oltp_read_only, oltp_read_write và oltp_write_only. Bạn có thể chạy khối lượng công việc chỉ đọc, bao gồm các loại truy vấn CHỌN khác nhau, bạn có thể chạy chỉ ghi (kết hợp DELETE, INSERT và UPDATE) hoặc bạn có thể chạy kết hợp cả hai. Cuối cùng, sử dụng select_random_points và select_random_ranges, bạn có thể chạy một số CHỌN ngẫu nhiên hoặc sử dụng các điểm ngẫu nhiên trong danh sách IN () hoặc phạm vi ngẫu nhiên bằng cách sử dụng BETWEEN.

Bạn có thể định cấu hình Điểm chuẩn như thế nào?

Điều quan trọng nữa, điểm chuẩn có thể định cấu hình - bạn có thể chạy các mẫu khối lượng công việc khác nhau bằng cách sử dụng cùng một điểm chuẩn. Chúng ta hãy xem xét hai điểm chuẩn phổ biến nhất để thực thi. Chúng ta sẽ tìm hiểu sâu hơn về các điểm chuẩn đọc_lập OLTP read_only và OLTP. Trước hết, SysBench có một số tùy chọn cấu hình chung. Chúng ta sẽ chỉ thảo luận ở đây những điều quan trọng nhất, bạn có thể kiểm tra tất cả chúng bằng cách chạy:

sysbench --help

Hãy xem chúng.

  --threads=N                     number of threads to use [1]

Bạn có thể xác định loại đồng thời bạn muốn SysBench tạo. MySQL, như mọi phần mềm, có một số hạn chế về khả năng mở rộng và hiệu suất của nó sẽ đạt đỉnh ở một số mức đồng thời. Cài đặt này giúp mô phỏng các trường hợp đồng thời khác nhau cho một khối lượng công việc nhất định và kiểm tra xem nó đã vượt qua điểm hấp dẫn chưa.

  --events=N                      limit for total number of events [0]
  --time=N                        limit for total execution time in seconds [10]

Hai cài đặt đó chi phối thời gian SysBench sẽ tiếp tục chạy. Nó có thể thực thi một số truy vấn hoặc có thể tiếp tục chạy trong một thời gian xác định trước.

  --warmup-time=N                 execute events for this many seconds with statistics disabled before the actual benchmark run with statistics enabled [0]

Điều này là tự giải thích. SysBench tạo ra các kết quả thống kê từ các bài kiểm tra và những kết quả đó có thể bị ảnh hưởng nếu MySQL ở trạng thái nguội. Warmup giúp xác định thông lượng "thông thường" bằng cách thực hiện điểm chuẩn trong thời gian xác định trước, cho phép làm ấm bộ nhớ cache, vùng đệm, v.v.

  --rate=N                        average transactions rate. 0 for unlimited rate [0]

Theo mặc định, SysBench sẽ cố gắng thực thi các truy vấn nhanh nhất có thể. Để mô phỏng lưu lượng truy cập chậm hơn, tùy chọn này có thể được sử dụng. Bạn có thể xác định ở đây có bao nhiêu giao dịch sẽ được thực hiện mỗi giây.

  --report-interval=N             periodically report intermediate statistics with a specified interval in seconds. 0 disables intermediate reports [0]

Theo mặc định, SysBench tạo một báo cáo sau khi nó chạy xong và không có tiến trình nào được báo cáo trong khi điểm chuẩn đang chạy. Sử dụng tùy chọn này, bạn có thể làm cho SysBench dài hơn trong khi điểm chuẩn vẫn chạy.

  --rand-type=STRING   random numbers distribution {uniform, gaussian, special, pareto, zipfian} to use by default [special]

SysBench cung cấp cho bạn khả năng tạo các kiểu phân phối dữ liệu khác nhau. Tất cả chúng đều có thể có mục đích riêng. Tùy chọn mặc định, 'đặc biệt', xác định một số điểm nóng (có thể định cấu hình) trong dữ liệu, một điều khá phổ biến trong các ứng dụng web. Bạn cũng có thể sử dụng các bản phân phối khác nếu dữ liệu của bạn hoạt động theo một cách khác. Bằng cách thực hiện một lựa chọn khác ở đây, bạn cũng có thể thay đổi cách cơ sở dữ liệu của bạn được căng thẳng. Ví dụ, phân phối đồng đều, trong đó tất cả các hàng có cùng khả năng được truy cập, là hoạt động tốn nhiều bộ nhớ hơn. Nó sẽ sử dụng nhiều vùng đệm hơn để lưu trữ tất cả dữ liệu và sẽ tốn nhiều ổ đĩa hơn nếu tập dữ liệu của bạn không vừa với bộ nhớ. Mặt khác, phân phối đặc biệt với một vài điểm nóng sẽ ít gây căng thẳng hơn cho đĩa vì các hàng nóng có nhiều khả năng được giữ trong vùng đệm hơn và khả năng truy cập vào các hàng được lưu trên đĩa ít hơn nhiều. Đối với một số kiểu phân phối dữ liệu, SysBench cung cấp cho bạn nhiều tinh chỉnh hơn. Bạn có thể tìm thấy thông tin này trong đầu ra ‘sysbench --help’.

  --db-ps-mode=STRING prepared statements usage mode {auto, disable} [auto]

Sử dụng cài đặt này, bạn có thể quyết định xem SysBench có nên sử dụng các câu lệnh đã chuẩn bị sẵn hay không (miễn là chúng có sẵn trong kho dữ liệu nhất định - đối với MySQL, điều đó có nghĩa là PS sẽ được bật theo mặc định) hay không. Điều này có thể tạo ra sự khác biệt khi làm việc với các proxy như ProxySQL hoặc MaxScale - chúng nên xử lý các câu lệnh đã chuẩn bị theo cách đặc biệt và tất cả chúng phải được chuyển đến một máy chủ để không thể kiểm tra khả năng mở rộng của proxy.

Ngoài các tùy chọn cấu hình chung, mỗi bài kiểm tra có thể có cấu hình riêng. Bạn có thể kiểm tra những gì khả thi bằng cách chạy:

[email protected]:~# sysbench ./sysbench/src/lua/oltp_read_write.lua  help
sysbench 1.1.0-2e6b7d5 (using bundled LuaJIT 2.1.0-beta3)

oltp_read_only.lua options:
  --distinct_ranges=N           Number of SELECT DISTINCT queries per transaction [1]
  --sum_ranges=N                Number of SELECT SUM() queries per transaction [1]
  --skip_trx[=on|off]           Don't start explicit transactions and execute all queries in the AUTOCOMMIT mode [off]
  --secondary[=on|off]          Use a secondary index in place of the PRIMARY KEY [off]
  --create_secondary[=on|off]   Create a secondary index in addition to the PRIMARY KEY [on]
  --index_updates=N             Number of UPDATE index queries per transaction [1]
  --range_size=N                Range size for range SELECT queries [100]
  --auto_inc[=on|off]           Use AUTO_INCREMENT column as Primary Key (for MySQL), or its alternatives in other DBMS. When disabled, use client-generated IDs [on]
  --delete_inserts=N            Number of DELETE/INSERT combinations per transaction [1]
  --tables=N                    Number of tables [1]
  --mysql_storage_engine=STRING Storage engine, if MySQL is used [innodb]
  --non_index_updates=N         Number of UPDATE non-index queries per transaction [1]
  --table_size=N                Number of rows per table [10000]
  --pgsql_variant=STRING        Use this PostgreSQL variant when running with the PostgreSQL driver. The only currently supported variant is 'redshift'. When enabled, create_secondary is automatically disabled, and delete_inserts is set to 0
  --simple_ranges=N             Number of simple range SELECT queries per transaction [1]
  --order_ranges=N              Number of SELECT ORDER BY queries per transaction [1]
  --range_selects[=on|off]      Enable/disable all range SELECT queries [on]
  --point_selects=N             Number of point SELECT queries per transaction [10]

Một lần nữa, chúng tôi sẽ thảo luận về các tùy chọn quan trọng nhất từ ​​đây. Trước hết, bạn có quyền kiểm soát xem chính xác một giao dịch sẽ như thế nào. Nói chung, nó bao gồm các loại truy vấn khác nhau - INSERT, DELETE, các loại SELECT khác nhau (tra cứu điểm, phạm vi, tổng hợp) và UPDATE (được lập chỉ mục, không được lập chỉ mục). Sử dụng các biến như:

  --distinct_ranges=N           Number of SELECT DISTINCT queries per transaction [1]
  --sum_ranges=N                Number of SELECT SUM() queries per transaction [1]
  --index_updates=N             Number of UPDATE index queries per transaction [1]
  --delete_inserts=N            Number of DELETE/INSERT combinations per transaction [1]
  --non_index_updates=N         Number of UPDATE non-index queries per transaction [1]
  --simple_ranges=N             Number of simple range SELECT queries per transaction [1]
  --order_ranges=N              Number of SELECT ORDER BY queries per transaction [1]
  --point_selects=N             Number of point SELECT queries per transaction [10]
  --range_selects[=on|off]      Enable/disable all range SELECT queries [on]

Bạn có thể xác định giao dịch trông như thế nào. Như bạn có thể thấy bằng cách xem xét các giá trị mặc định, phần lớn các truy vấn là CHỌN - chủ yếu là lựa chọn điểm nhưng cũng có các loại CHỌN dải ô khác nhau (bạn có thể tắt tất cả chúng bằng cách đặt range_selects thành tắt). Bạn có thể điều chỉnh khối lượng công việc theo hướng khối lượng công việc nhiều ghi hơn bằng cách tăng số lượng bản cập nhật hoặc các truy vấn CHÈN / XÓA. Cũng có thể tinh chỉnh các cài đặt liên quan đến chỉ mục phụ, tăng tự động nhưng cũng có thể kích thước tập dữ liệu (số lượng bảng và số hàng mỗi bảng nên chứa). Điều này cho phép bạn tùy chỉnh khá tốt khối lượng công việc của mình.

  --skip_trx[=on|off]           Don't start explicit transactions and execute all queries in the AUTOCOMMIT mode [off]

Đây là một cài đặt khác, khá quan trọng khi làm việc với proxy. Theo mặc định, SysBench sẽ cố gắng thực hiện các truy vấn trong giao dịch rõ ràng. Bằng cách này, tập dữ liệu sẽ luôn nhất quán và không bị ảnh hưởng:Ví dụ:SysBench sẽ thực thi CHÈN và XÓA trên cùng một hàng, đảm bảo rằng tập dữ liệu sẽ không phát triển (ảnh hưởng đến khả năng tái tạo kết quả của bạn). Tuy nhiên, proxy sẽ xử lý các giao dịch rõ ràng theo cách khác - tất cả các truy vấn được thực hiện trong một giao dịch phải được thực hiện trên cùng một máy chủ, do đó loại bỏ khả năng mở rộng khối lượng công việc. Xin lưu ý rằng việc vô hiệu hóa các giao dịch sẽ dẫn đến việc tập dữ liệu khác biệt so với thời điểm ban đầu. Nó cũng có thể gây ra một số vấn đề như lỗi khóa trùng lặp hoặc tương tự. Để có thể vô hiệu hóa các giao dịch, bạn cũng có thể muốn xem xét:

  --mysql-ignore-errors=[LIST,...] list of errors to ignore, or "all" [1213,1020,1205]

Cài đặt này cho phép bạn chỉ định mã lỗi từ MySQL mà SysBench nên bỏ qua (và không ngắt kết nối). Ví dụ:để bỏ qua các lỗi như:lỗi 1062 (Mục nhập trùng lặp '6' cho khóa 'CHÍNH'), bạn nên chuyển mã lỗi này:--mysql-ignore-error =1062

Điều quan trọng nữa, mỗi điểm chuẩn phải trình bày một cách để cung cấp một tập dữ liệu cho các bài kiểm tra, chạy chúng và sau đó dọn dẹp nó sau khi các bài kiểm tra hoàn tất. Điều này được thực hiện bằng cách sử dụng các lệnh ‘chuẩn bị’, ‘chạy’ và ‘dọn dẹp’. Chúng tôi sẽ chỉ ra cách thực hiện điều này trong phần tiếp theo.

Ví dụ

Trong phần này, chúng ta sẽ xem xét một số ví dụ về những gì SysBench có thể được sử dụng. Như đã đề cập trước đó, chúng tôi sẽ tập trung vào hai điểm chuẩn phổ biến nhất - chỉ đọc OLTP và đọc / ghi OLTP. Đôi khi, việc sử dụng các điểm chuẩn khác có thể hợp lý, nhưng ít nhất chúng tôi sẽ có thể cho bạn biết cách tùy chỉnh hai điểm chuẩn đó.

Tra cứu Khóa chính

Trước hết, chúng tôi phải quyết định điểm chuẩn nào chúng tôi sẽ chạy, chỉ đọc hay đọc-ghi. Về mặt kỹ thuật, nó không tạo ra sự khác biệt vì chúng ta có thể loại bỏ các ghi từ điểm chuẩn R / W. Hãy tập trung vào trang chỉ đọc.

Bước đầu tiên, chúng ta phải chuẩn bị một tập dữ liệu. Chúng ta cần quyết định xem nó phải lớn đến mức nào. Đối với điểm chuẩn cụ thể này, sử dụng cài đặt mặc định (do đó, chỉ mục phụ được tạo), 1 triệu hàng sẽ dẫn đến ~ 240 MB dữ liệu. Mười bảng, 1000 000 hàng mỗi bảng tương đương với 2,4GB:

[email protected]:~# du -sh /var/lib/mysql/sbtest/
2.4G    /var/lib/mysql/sbtest/
[email protected]:~# ls -alh /var/lib/mysql/sbtest/
total 2.4G
drwxr-x--- 2 mysql mysql 4.0K Jun  1 12:12 .
drwxr-xr-x 6 mysql mysql 4.0K Jun  1 12:10 ..
-rw-r----- 1 mysql mysql   65 Jun  1 12:08 db.opt
-rw-r----- 1 mysql mysql 8.5K Jun  1 12:12 sbtest10.frm
-rw-r----- 1 mysql mysql 240M Jun  1 12:12 sbtest10.ibd
-rw-r----- 1 mysql mysql 8.5K Jun  1 12:10 sbtest1.frm
-rw-r----- 1 mysql mysql 240M Jun  1 12:10 sbtest1.ibd
-rw-r----- 1 mysql mysql 8.5K Jun  1 12:10 sbtest2.frm
-rw-r----- 1 mysql mysql 240M Jun  1 12:10 sbtest2.ibd
-rw-r----- 1 mysql mysql 8.5K Jun  1 12:10 sbtest3.frm
-rw-r----- 1 mysql mysql 240M Jun  1 12:10 sbtest3.ibd
-rw-r----- 1 mysql mysql 8.5K Jun  1 12:10 sbtest4.frm
-rw-r----- 1 mysql mysql 240M Jun  1 12:10 sbtest4.ibd
-rw-r----- 1 mysql mysql 8.5K Jun  1 12:11 sbtest5.frm
-rw-r----- 1 mysql mysql 240M Jun  1 12:11 sbtest5.ibd
-rw-r----- 1 mysql mysql 8.5K Jun  1 12:11 sbtest6.frm
-rw-r----- 1 mysql mysql 240M Jun  1 12:11 sbtest6.ibd
-rw-r----- 1 mysql mysql 8.5K Jun  1 12:11 sbtest7.frm
-rw-r----- 1 mysql mysql 240M Jun  1 12:11 sbtest7.ibd
-rw-r----- 1 mysql mysql 8.5K Jun  1 12:11 sbtest8.frm
-rw-r----- 1 mysql mysql 240M Jun  1 12:11 sbtest8.ibd
-rw-r----- 1 mysql mysql 8.5K Jun  1 12:12 sbtest9.frm
-rw-r----- 1 mysql mysql 240M Jun  1 12:12 sbtest9.ibd

Điều này sẽ cung cấp cho bạn ý tưởng về số lượng bàn bạn muốn và chúng phải lớn như thế nào. Giả sử chúng tôi muốn kiểm tra khối lượng công việc trong bộ nhớ, vì vậy chúng tôi muốn tạo các bảng phù hợp với vùng đệm InnoDB. Mặt khác, chúng tôi cũng muốn đảm bảo có đủ số lượng bảng để không trở thành nút cổ chai (hoặc số lượng bảng phù hợp với những gì bạn mong đợi trong thiết lập sản xuất của mình). Hãy chuẩn bị tập dữ liệu của chúng tôi. Xin lưu ý rằng, theo mặc định, SysBench tìm kiếm lược đồ ‘sbtest’ phải tồn tại trước khi bạn chuẩn bị tập dữ liệu. Bạn có thể phải tạo nó theo cách thủ công.

[email protected]:~# sysbench /root/sysbench/src/lua/oltp_read_only.lua --threads=4 --mysql-host=10.0.0.126 --mysql-user=sbtest --mysql-password=pass --mysql-port=3306 --tables=10 --table-size=1000000 prepare
sysbench 1.1.0-2e6b7d5 (using bundled LuaJIT 2.1.0-beta3)

Initializing worker threads...

Creating table 'sbtest2'...
Creating table 'sbtest3'...
Creating table 'sbtest4'...
Creating table 'sbtest1'...
Inserting 1000000 records into 'sbtest2'
Inserting 1000000 records into 'sbtest4'
Inserting 1000000 records into 'sbtest3'
Inserting 1000000 records into 'sbtest1'
Creating a secondary index on 'sbtest2'...
Creating a secondary index on 'sbtest3'...
Creating a secondary index on 'sbtest1'...
Creating a secondary index on 'sbtest4'...
Creating table 'sbtest6'...
Inserting 1000000 records into 'sbtest6'
Creating table 'sbtest7'...
Inserting 1000000 records into 'sbtest7'
Creating table 'sbtest5'...
Inserting 1000000 records into 'sbtest5'
Creating table 'sbtest8'...
Inserting 1000000 records into 'sbtest8'
Creating a secondary index on 'sbtest6'...
Creating a secondary index on 'sbtest7'...
Creating a secondary index on 'sbtest5'...
Creating a secondary index on 'sbtest8'...
Creating table 'sbtest10'...
Inserting 1000000 records into 'sbtest10'
Creating table 'sbtest9'...
Inserting 1000000 records into 'sbtest9'
Creating a secondary index on 'sbtest10'...
Creating a secondary index on 'sbtest9'...

Sau khi chúng tôi có dữ liệu của mình, hãy chuẩn bị lệnh để chạy thử nghiệm. Chúng tôi muốn kiểm tra tra cứu Khóa chính, do đó chúng tôi sẽ tắt tất cả các loại SELECT khác. Chúng tôi cũng sẽ tắt các câu lệnh đã chuẩn bị sẵn vì chúng tôi muốn kiểm tra các truy vấn thông thường. Chúng tôi sẽ kiểm tra tính đồng thời thấp, giả sử 16 luồng. Lệnh của chúng tôi có thể giống như sau:

sysbench /root/sysbench/src/lua/oltp_read_only.lua --threads=16 --events=0 --time=300 --mysql-host=10.0.0.126 --mysql-user=sbtest --mysql-password=pass --mysql-port=3306 --tables=10 --table-size=1000000 --range_selects=off --db-ps-mode=disable --report-interval=1 run

Chúng tôi đã làm gì ở đây? Chúng tôi đặt số luồng là 16. Chúng tôi quyết định rằng chúng tôi muốn điểm chuẩn của chúng tôi chạy trong 300 giây, không có giới hạn của các truy vấn được thực thi. Chúng tôi đã xác định kết nối với cơ sở dữ liệu, số lượng bảng và kích thước của chúng. Chúng tôi cũng đã tắt tất cả các SELECT trong phạm vi, chúng tôi cũng đã tắt các câu lệnh đã chuẩn bị. Cuối cùng, chúng tôi đặt khoảng thời gian báo cáo thành một giây. Đây là cách đầu ra mẫu có thể trông như thế nào:

[ 297s ] thds: 16 tps: 97.21 qps: 1127.43 (r/w/o: 935.01/0.00/192.41) lat (ms,95%): 253.35 err/s: 0.00 reconn/s: 0.00
[ 298s ] thds: 16 tps: 195.32 qps: 2378.77 (r/w/o: 1985.13/0.00/393.64) lat (ms,95%): 189.93 err/s: 0.00 reconn/s: 0.00
[ 299s ] thds: 16 tps: 178.02 qps: 2115.22 (r/w/o: 1762.18/0.00/353.04) lat (ms,95%): 155.80 err/s: 0.00 reconn/s: 0.00
[ 300s ] thds: 16 tps: 217.82 qps: 2640.92 (r/w/o: 2202.27/0.00/438.65) lat (ms,95%): 125.52 err/s: 0.00 reconn/s: 0.00

Mỗi giây, chúng tôi thấy một ảnh chụp nhanh về số liệu thống kê khối lượng công việc. Điều này khá hữu ích để theo dõi và lập biểu đồ - báo cáo cuối cùng sẽ chỉ cung cấp cho bạn mức trung bình. Kết quả trung gian sẽ giúp bạn có thể theo dõi hiệu suất trên cơ sở từng giây. Báo cáo cuối cùng có thể giống như sau:

SQL statistics:
    queries performed:
        read:                            614660
        write:                           0
        other:                           122932
        total:                           737592
    transactions:                        61466  (204.84 per sec.)
    queries:                             737592 (2458.08 per sec.)
    ignored errors:                      0      (0.00 per sec.)
    reconnects:                          0      (0.00 per sec.)

Throughput:
    events/s (eps):                      204.8403
    time elapsed:                        300.0679s
    total number of events:              61466

Latency (ms):
         min:                                   24.91
         avg:                                   78.10
         max:                                  331.91
         95th percentile:                      137.35
         sum:                              4800234.60

Threads fairness:
    events (avg/stddev):           3841.6250/20.87
    execution time (avg/stddev):   300.0147/0.02

Bạn sẽ tìm thấy ở đây thông tin về các truy vấn đã thực thi và các câu lệnh (BEGIN / COMMIT) khác. Bạn sẽ tìm hiểu có bao nhiêu giao dịch đã được thực hiện, bao nhiêu lỗi đã xảy ra, thông lượng và tổng thời gian đã trôi qua là bao nhiêu. Bạn cũng có thể kiểm tra số liệu độ trễ và phân phối truy vấn trên các chuỗi.

Nếu quan tâm đến phân phối độ trễ, chúng tôi cũng có thể chuyển đối số ‘--histogram’ cho SysBench. Điều này dẫn đến một đầu ra bổ sung như sau:

Giá trị
Latency histogram (values are in milliseconds)
       value  ------------- distribution ------------- count
      29.194 |******                                   1
      30.815 |******                                   1
      31.945 |***********                              2
      33.718 |******                                   1
      34.954 |***********                              2
      35.589 |******                                   1
      37.565 |***********************                  4
      38.247 |******                                   1
      38.942 |******                                   1
      39.650 |***********                              2
      40.370 |***********                              2
      41.104 |*****************                        3
      41.851 |*****************************            5
      42.611 |*****************                        3
      43.385 |*****************                        3
      44.173 |***********                              2
      44.976 |**************************************** 7
      45.793 |***********************                  4
      46.625 |***********                              2
      47.472 |*****************************            5
      48.335 |**************************************** 7
      49.213 |***********                              2
      50.107 |**********************************       6
      51.018 |***********************                  4
      51.945 |**************************************** 7
      52.889 |*****************                        3
      53.850 |*****************                        3
      54.828 |***********************                  4
      55.824 |***********                              2
      57.871 |***********                              2
      58.923 |***********                              2
      59.993 |******                                   1
      61.083 |******                                   1
      63.323 |***********                              2
      66.838 |******                                   1
      71.830 |******                                   1

Khi chúng tôi hài lòng với kết quả của mình, chúng tôi có thể xóa dữ liệu:

sysbench /root/sysbench/src/lua/oltp_read_only.lua --threads=16 --events=0 --time=300 --mysql-host=10.0.0.126 --mysql-user=sbtest --mysql-password=pass --mysql-port=3306 --tables=10 --table-size=1000000 --range_selects=off --db-ps-mode=disable --report-interval=1 cleanup

Mật độ giao thông cao

Ở đây, hãy tưởng tượng rằng chúng ta muốn thực thi khối lượng công việc nhiều ghi (nhưng không chỉ ghi) và ví dụ:kiểm tra hiệu suất của hệ thống con I / O. Trước hết, chúng ta phải quyết định tập dữ liệu phải lớn như thế nào. Chúng tôi sẽ giả định khoảng 48GB dữ liệu (20 bảng, mỗi bảng 10 000 000 hàng). Chúng ta cần chuẩn bị nó. Lần này, chúng tôi sẽ sử dụng điểm chuẩn đọc-ghi.

[email protected]:~# sysbench /root/sysbench/src/lua/oltp_read_write.lua --threads=4 --mysql-host=10.0.0.126 --mysql-user=sbtest --mysql-password=pass --mysql-port=3306 --tables=20 --table-size=10000000 prepare

Khi việc này được thực hiện, chúng tôi có thể điều chỉnh các giá trị mặc định để buộc nhiều lần ghi hơn vào hỗn hợp truy vấn:

[email protected]:~# sysbench /root/sysbench/src/lua/oltp_read_write.lua --threads=16 --events=0 --time=300 --mysql-host=10.0.0.126 --mysql-user=sbtest --mysql-password=pass --mysql-port=3306 --tables=20 --delete_inserts=10 --index_updates=10 --non_index_updates=10 --table-size=10000000 --db-ps-mode=disable --report-interval=1 run

Như bạn có thể thấy từ các kết quả trung gian, các giao dịch hiện đang ở khía cạnh nặng nề:

[ 5s ] thds: 16 tps: 16.99 qps: 946.31 (r/w/o: 231.83/680.50/33.98) lat (ms,95%): 1258.08 err/s: 0.00 reconn/s: 0.00
[ 6s ] thds: 16 tps: 17.01 qps: 955.81 (r/w/o: 223.19/698.59/34.03) lat (ms,95%): 1032.01 err/s: 0.00 reconn/s: 0.00
[ 7s ] thds: 16 tps: 12.00 qps: 698.91 (r/w/o: 191.97/482.93/24.00) lat (ms,95%): 1235.62 err/s: 0.00 reconn/s: 0.00
[ 8s ] thds: 16 tps: 14.01 qps: 683.43 (r/w/o: 195.12/460.29/28.02) lat (ms,95%): 1533.66 err/s: 0.00 reconn/s: 0.00

Hiểu kết quả

Như chúng tôi đã trình bày ở trên, SysBench là một công cụ tuyệt vời có thể giúp xác định một số vấn đề về hiệu suất của MySQL hoặc MariaDB. Nó cũng có thể được sử dụng để điều chỉnh ban đầu cấu hình cơ sở dữ liệu của bạn. Tất nhiên, bạn phải nhớ rằng, để tận dụng tốt nhất các điểm chuẩn của mình, bạn phải hiểu tại sao kết quả lại giống như vậy. Điều này sẽ yêu cầu thông tin chi tiết về các chỉ số nội bộ của MySQL bằng cách sử dụng các công cụ giám sát, chẳng hạn như ClusterControl. Điều này khá quan trọng cần nhớ - nếu bạn không hiểu tại sao hiệu suất lại như vậy, bạn có thể đưa ra kết luận không chính xác từ các điểm chuẩn. Luôn có một nút thắt cổ chai và SysBench có thể giúp đưa ra các vấn đề về hiệu suất mà sau đó bạn phải xác định.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Cách DAYOFMONTH () hoạt động trong MariaDB

  2. Cách hoạt động của nhà điều hành Modulo trong MariaDB

  3. Hiểu các chỉ mục trong MySQL:Phần một

  4. Cách QUOTE () hoạt động trong MariaDB

  5. Cách LEAST () hoạt động trong MariaDB