Mariadb MySQL Tuner báo cáo khó hiểu


7

Tôi muốn yêu cầu bạn làm rõ báo cáo từ mysqltuner về cơ sở dữ liệu MariaDB. Các mysqltuner đã được gọi với cờ --nogood!

 >>  MySQLTuner 1.7.1 - Major Hayden <major@mhtx.net>
 >>  Bug reports, feature requests, and downloads at http://mysqltuner.com/
 >>  Run with '--help' for additional options and output filtering

[--] Skipped version check for MySQLTuner script
[!!] Currently running unsupported MySQL version 10.0.29-MariaDB-0ubuntu0.16.04.1

-------- Log file Recommendations ------------------------------------------------------------------
[--] Log file: (0B)
[!!] Log file  doesn't exist
[!!] Log file  isn't readable.

-------- Storage Engine Statistics -----------------------------------------------------------------
[--] Status: +ARCHIVE +Aria +BLACKHOLE +CSV +FEDERATED +InnoDB +MEMORY +MRG_MyISAM +MyISAM +PERFORMANCE_SCHEMA 
[--] Data in InnoDB tables: 380M (Tables: 417)

-------- Security Recommendations ------------------------------------------------------------------
[--] There are 605 basic passwords in the list.

-------- CVE Security Recommendations --------------------------------------------------------------
[--] Skipped due to --cvefile option undefined

-------- Performance Metrics -----------------------------------------------------------------------
[--] Up for: 15s (812 q [54.133 qps], 275 conn, TX: 258K, RX: 108K)
[--] Reads / Writes: 100% / 0%
[--] Binary logging is disabled
[--] Physical Memory     : 31.3G
[--] Max MySQL memory    : 10.0G
[--] Other process memory: 1.2G
[--] Total buffers: 8.4G global + 10.7M per thread (150 max threads)
[--] P_S Max memory usage: 34M
[--] Galera GCache Max memory usage: 0B
[!!] Slow queries: 27% (221/812)
[!!] Query cache may be disabled by default due to mutex contention.
[!!] Query cache efficiency: 0.0% (0 cached / 521 selects)

-------- Performance schema ------------------------------------------------------------------------
[--] Memory used by P_S: 35.0M
[--] Sys schema isn't installed.

-------- ThreadPool Metrics ------------------------------------------------------------------------
[--] ThreadPool stat is enabled.
[--] Thread Pool Size: 8 thread(s).
[--] Using default value is good enough for your version (10.0.29-MariaDB-0ubuntu0.16.04.1)

-------- MyISAM Metrics ----------------------------------------------------------------------------
[!!] Key buffer used: 18.2% (24M used / 134M cache)
[!!] Read Key buffer hit rate: 80.0% (10 cached / 2 reads)

-------- InnoDB Metrics ----------------------------------------------------------------------------
[--] InnoDB is enabled.
[--] InnoDB Thread Concurrency: 0
[!!] Ratio InnoDB log file size / InnoDB Buffer pool size (12.5 %): 512.0M * 2/8.0G should be equal 25%
[--] InnoDB Buffer Pool Chunk Size not used or defined in your version
[!!] InnoDB Write Log efficiency: 0% (2 hits/ 0 total)

-------- AriaDB Metrics ----------------------------------------------------------------------------
[--] AriaDB is enabled.

-------- TokuDB Metrics ----------------------------------------------------------------------------
[--] TokuDB is disabled.

-------- XtraDB Metrics ----------------------------------------------------------------------------
[--] XtraDB is disabled.

-------- RocksDB Metrics ---------------------------------------------------------------------------
[--] RocksDB is disabled.

-------- Spider Metrics ----------------------------------------------------------------------------
[--] Spider is disabled.

-------- Connect Metrics ---------------------------------------------------------------------------
[--] Connect is disabled.

-------- Galera Metrics ----------------------------------------------------------------------------
[--] Galera is disabled.

-------- Replication Metrics -----------------------------------------------------------------------
[--] Galera Synchronous replication: NO
[--] No replication slave(s) for this server.
[--] This is a standalone server.

-------- Recommendations ---------------------------------------------------------------------------
General recommendations:
    MySQL started within last 24 hours - recommendations may be inaccurate
    Consider installing Sys schema from https://github.com/mysql/mysql-sys
Variables to adjust:
    query_cache_type (=0)
    query_cache_limit (> 256K, or use smaller result sets)
    innodb_log_file_size * innodb_log_files_in_group should be equals to 1/4 of buffer pool size (=4G) if possible.

Điều khiến tôi bối rối là phần "Đề xuất tệp nhật ký". Tôi thực sự không biết phải làm gì với nó. Sau đó, dòng này:

[!!] Query cache may be disabled by default due to mutex contention.

Tôi cũng rất tò mò tại sao nó lại khuyên tôi thay đổi query_cache_type thành 0 và tăng query_cache_limit?

Tôi biết rằng nó đã không chạy trong ít nhất 24 giờ, đó là vì tôi đã điều chỉnh cấu hình và khởi động lại cơ sở dữ liệu của mình. Tôi đã điều chỉnh theo kiến ​​thức của mình về MariaDB, nhưng với vài điều này tôi cảm thấy bối rối.


Bạn nên cập nhật báo cáo của mysql Tuner với thời gian chạy lâu hơn. 15 giây là không đủ!
Philippe Delteil

Câu trả lời:


7

Tôi có thể giải thích dòng này

[!!] Query cache may be disabled by default due to mutex contention.

Công cụ lưu trữ InnoDB và Cache truy vấn luôn ở trạng thái chiến tranh liên tục (Xem bài đăng 1,5 năm của tôi Tại sao query_cache_type bị tắt theo mặc định bắt đầu từ MySQL 5.6? )

mysqltuner đang khuyên bạn nên đặt query_cache_type thành 0 để bạn vô hiệu hóa bộ đệm truy vấn. Xin đừng quên đặt query_cache_size thành 0. Nếu không, hành vi gây đột biến sẽ bị động xảy ra bằng mọi cách.

Như tôi đã nói trong bài viết cũ của tôi , bạn không nhất thiết phải vô hiệu hóa bộ đệm truy vấn nếu bạn biết rõ kích thước của các tập kết quả phổ biến nhất của bạn. Nếu bạn có thể tìm ra kích thước đó, thì bạn có thể truy vấn_cache_limitquery_cache_min_res_unit làm giới hạn trên và dưới của kích thước tập kết quả. Chỉ sau đó, bạn có thể đặt query_cache_type thành 1.

Đối với các khuyến nghị về tệp nhật ký của bạn

[--] Log file: (0B)
[!!] Log file  doesn't exist
[!!] Log file  isn't readable.

Có lẽ điều này có thể giải thích nó

[!!] Currently running unsupported MySQL version 10.0.29-MariaDB-0ubuntu0.16.04.1

Có thể mysqltuner không thể liên quan đến các tệp nhật ký trong phiên bản MariaDB này giống như với các phiên bản được hỗ trợ.


tuyên bố của bạn về Bộ đệm truy vấn cũng hợp lệ cho MariaDB 10.xx?
Ivanov

điều đó có nghĩa là bạn khuyên bạn nên tắt bộ đệm? Điều đó sẽ có tác động đến hiệu suất? Nếu vậy, tôi sẵn sàng thực hiện bất kỳ phép đo nào để đặt query_cache_limit và query_cache_min_res_unit chính xác và chạy query_cache. Mặc dù tôi cũng có thể sử dụng Redis để lưu trữ kết quả truy vấn nếu điều đó dễ dàng hơn (nhưng tôi cho rằng MariaDb sẽ xử lý việc vô hiệu hóa bộ đệm trên mà không cần làm thêm?). Tôi thực sự không phải là DBA, có mẹo nào để đo kích thước đó không? Tôi đang sử dụng ORM, vì vậy không thể thực sự đo nó từ trong ứng dụng của mình.
pzaj

3

Không tin tưởng (chỉ dựa vào nó) - đối với mysqltunner, tất cả các cài đặt phải được điều chỉnh dựa trên giám sát và tải thực tế.

Đăng nhập Kích thước tệp từ một phía - kích thước 0,5-1Hr của tất cả các giao dịch trong khoảng thời gian này

nhưng từ phía khác - nếu khởi động lại nhiều hơn 1-2Gb sau sự cố có thể mất nhiều thời gian. Khi nhật ký lớn hơn - khi bắt đầu lâu hơn.

Vì vậy, nó luôn luôn cân bằng giữa.

Bắt đầu từ 512M mỗi tệp (Tổng 1G), sau đó nếu tải cao - tăng lên tới 1024Gb

tốt hơn để kiểm tra những gì bên trong:

Slow queries: 27% (221/812)
  • truy vấn nào?
  • tại sao chậm
  • Là bởi kích thước dữ liệu? hoặc do chỉ số sai?

điều này có thể cung cấp nhiều hơn cho hiệu suất


1
Cảm ơn bạn đã bình luận của bạn. Tôi sẽ xem kích thước tệp nhật ký và áp dụng các khuyến nghị của bạn. Đối với các truy vấn chậm, bạn nói đúng, đó là điều tôi sẽ xem xét, không hỏi về điều đó trong câu hỏi của tôi, vì tôi biết cách xử lý vấn đề đó. Bây giờ tôi chỉ có thể nói với bạn rằng tất cả họ đều dưới 20ms, chỉ thực hiện quét toàn bộ và một số trong số họ sử dụng tmp_table và tmp_disk_table do các mệnh đề mà tôi cho là. Đây là điều tôi sẽ cố gắng tối ưu hóa khi tôi tìm thấy các công cụ giúp tôi xác định các chỉ mục có khả năng bị thiếu
pzaj

2

Đầu ra hầu như vô dụng vì hệ thống chỉ chạy 15 giây. Đợi ít nhất một ngày.

Tuy nhiên, phần trăm truy vấn "chậm" là khủng khiếp. Bật Slowlog, đợi một ngày, sử dụng pt-query-digest để tìm cặp truy vấn tồi tệ nhất. Sau đó, hãy thảo luận về chúng.

Tôi không nghĩ rằng InnoDB có thể chạy mà không cần tệp nhật ký! (Hoặc có thể nó đang đề cập đến một tệp nhật ký khác ??) Tuy nhiên, sau đó nó nói innodb_log_file_sizelà 512M. Đó nên là một kích thước khá cho bây giờ. (Bạn có các vấn đề khác cần tập trung vào bây giờ.)

Đối với các hệ thống sản xuất có nhiều ghi, đây là cài đặt QC tốt nhất:

query_cache_type = OFF
query_cache_size = 0

Nếu bạn muốn đánh giá khác, vui lòng cung cấp SHOW VARIABLES;SHOW GLOBAL STATUS;(sau khi thức dậy ít nhất một ngày).


Có, 15 giây nó không đủ thời gian.
Philippe Delteil
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.