Một trong những yếu tố quan trọng của một máy chủ cơ sở dữ liệu MySQL hoạt động hiệu quả là có khả năng phân bổ và sử dụng bộ nhớ tốt, đặc biệt là khi chạy nó trong môi trường sản xuất. Nhưng làm thế nào bạn có thể xác định xem việc sử dụng MySQL có được tối ưu hóa hay không? Nó có hợp lý để sử dụng bộ nhớ cao hay nó yêu cầu tinh chỉnh? Điều gì sẽ xảy ra nếu tôi gặp lỗi rò rỉ bộ nhớ?
Hãy đề cập đến các chủ đề này và chỉ ra những thứ bạn có thể kiểm tra trong MySQL để xác định dấu vết của việc sử dụng bộ nhớ cao.
Phân bổ Bộ nhớ trong MySQL
Trước khi chúng ta đi sâu vào tiêu đề chủ đề cụ thể, tôi sẽ chỉ cung cấp một thông tin ngắn gọn về cách MySQL sử dụng bộ nhớ. Bộ nhớ đóng vai trò quan trọng đối với tốc độ và hiệu quả khi xử lý các giao dịch đồng thời và chạy các truy vấn lớn. Mỗi luồng trong MySQL yêu cầu bộ nhớ được sử dụng để quản lý các kết nối máy khách và các luồng này chia sẻ cùng một bộ nhớ cơ sở. Các biến như thread_stack (ngăn xếp cho luồng), net_buffer_length (cho bộ đệm kết nối và bộ đệm kết quả) hoặc với max_allowed_packet trong đó kết nối và kết quả sẽ tự động phóng to đến giá trị này khi cần, là các biến ảnh hưởng đến việc sử dụng bộ nhớ. Khi một luồng không còn cần thiết nữa, bộ nhớ được cấp cho nó sẽ được giải phóng và trả về hệ thống trừ khi luồng đó quay trở lại bộ đệm ẩn của luồng. Trong trường hợp đó, bộ nhớ vẫn được cấp phát. Các phép nối truy vấn, bộ nhớ đệm truy vấn, sắp xếp, bộ đệm bảng, định nghĩa bảng yêu cầu bộ nhớ trong MySQL nhưng chúng được gán với các biến hệ thống mà bạn có thể định cấu hình và đặt.
Trong hầu hết các trường hợp, các biến bộ nhớ cụ thể được đặt cho cấu hình được nhắm mục tiêu trên cấu hình cụ thể dựa trên bộ nhớ như MyISAM hoặc InnoDB. Khi một cá thể mysqld sinh ra trong hệ thống máy chủ, MySQL phân bổ bộ đệm và bộ đệm để cải thiện hiệu suất của các hoạt động cơ sở dữ liệu dựa trên các giá trị đã đặt được đặt trên một cấu hình cụ thể. Ví dụ:các biến phổ biến nhất mà mọi DBA sẽ đặt trong InnoDB là các biến innodb_buffer_pool_size và innodb_buffer_pool_instances đều liên quan đến phân bổ bộ nhớ vùng đệm chứa dữ liệu được lưu trong bộ nhớ cache cho các bảng InnoDB. Điều mong muốn nếu bạn có bộ nhớ lớn và đang mong đợi xử lý các giao dịch lớn bằng cách đặt innodb_buffer_pool_instances để cải thiện tính đồng thời bằng cách chia vùng đệm thành nhiều trường hợp vùng đệm.
Trong khi đối với MyISAM, bạn phải xử lý key_buffer_size để xử lý lượng bộ nhớ mà bộ đệm phím sẽ xử lý. MyISAM cũng cấp phát bộ đệm cho mọi luồng đồng thời chứa cấu trúc bảng, cấu trúc cột cho mỗi cột và bộ đệm có kích thước 3 * N được cấp phát (trong đó N là độ dài hàng tối đa, không tính cột BLOB). MyISAM cũng duy trì một bộ đệm hàng bổ sung để sử dụng nội bộ.
MySQL cũng cấp phát bộ nhớ cho các bảng tạm thời trừ khi nó trở nên quá lớn (được xác định bởi tmp_table_size và max_heap_table_size). Nếu bạn đang sử dụng bảng MEMORY và biến max_heap_table_size được đặt rất cao, điều này cũng có thể chiếm bộ nhớ lớn vì biến hệ thống max_heap_table_size xác định mức độ lớn của bảng và không có chuyển đổi sang định dạng trên đĩa.
MySQL cũng có Biểu đồ hiệu suất là một tính năng để giám sát các hoạt động của MySQL ở mức thấp. Khi tính năng này được bật, nó sẽ tự động phân bổ bộ nhớ tăng dần, mở rộng mức sử dụng bộ nhớ của nó thành tải thực tế của máy chủ, thay vì cấp phát bộ nhớ cần thiết trong quá trình khởi động máy chủ. Khi bộ nhớ được cấp phát, nó sẽ không được giải phóng cho đến khi máy chủ được khởi động lại.
MySQL cũng có thể được định cấu hình để phân bổ các vùng bộ nhớ lớn cho vùng đệm của nó nếu sử dụng Linux và nếu hạt nhân được bật để hỗ trợ trang lớn, tức là sử dụng HugePages.
Những gì cần kiểm tra khi bộ nhớ MySQL cao
Kiểm tra các Truy vấn Đang chạy
Rất phổ biến đối với các DBA MySQL trước tiên phải chạm vào cơ sở những gì đang xảy ra với máy chủ MySQL đang chạy. Các thủ tục cơ bản nhất là kiểm tra danh sách quy trình, kiểm tra trạng thái máy chủ và kiểm tra trạng thái công cụ lưu trữ. Để thực hiện những điều này, về cơ bản, bạn chỉ cần chạy một loạt các truy vấn bằng cách đăng nhập vào MySQL. Xem bên dưới:
Để xem các truy vấn đang chạy,
mysql> SHOW [FULL] PROCESSLIST;Việc xem danh sách xử lý hiện tại sẽ hiển thị các truy vấn đang chạy tích cực hoặc thậm chí là các quy trình không hoạt động hoặc ngủ. Việc có một bản ghi các truy vấn đang chạy là rất quan trọng và là một thói quen quan trọng. Như đã lưu ý về cách MySQL phân bổ bộ nhớ, các truy vấn đang chạy sẽ sử dụng phân bổ bộ nhớ và có thể gây ra các vấn đề về hiệu suất nghiêm trọng nếu không được theo dõi.
Xem các biến trạng thái máy chủ MySQL,
mysql> SHOW SERVER STATUS\Ghoặc lọc các biến cụ thể như
mysql> SHOW SERVER STATUS WHERE variable_name IN ('<var1>', 'var2'...);Các biến trạng thái của MySQL đóng vai trò là thông tin thống kê của bạn để lấy dữ liệu số liệu để xác định MySQL của bạn hoạt động như thế nào bằng cách quan sát các bộ đếm được cung cấp bởi các giá trị trạng thái. Có một số giá trị nhất định ở đây cho bạn cái nhìn sơ lược về tác động của việc sử dụng bộ nhớ. Ví dụ:kiểm tra số luồng, số lượng bộ nhớ đệm của bảng hoặc việc sử dụng vùng đệm,
...
| Created_tmp_disk_tables | 24240 |
| Created_tmp_tables | 334999 |
…
| Innodb_buffer_pool_pages_data | 754 |
| Innodb_buffer_pool_bytes_data | 12353536 |
...
| Innodb_buffer_pool_pages_dirty | 6 |
| Innodb_buffer_pool_bytes_dirty | 98304 |
| Innodb_buffer_pool_pages_flushed | 30383 |
| Innodb_buffer_pool_pages_free | 130289 |
…
| Open_table_definitions | 540 |
| Open_tables | 1024 |
| Opened_table_definitions | 540 |
| Opened_tables | 700887 |
...
| Threads_connected | 5 |
...
| Threads_cached | 2 |
| Threads_connected | 5 |
| Threads_created | 7 |
| Threads_running | 1 |Xem trạng thái màn hình của động cơ, ví dụ:trạng thái InnoDB
mysql> SHOW ENGINE INNODB STATUS\GTrạng thái InnoDB cũng cho biết trạng thái hiện tại của các giao dịch mà công cụ lưu trữ đang xử lý. Nó cung cấp cho bạn kích thước heap của một giao dịch, các chỉ mục băm thích ứng tiết lộ việc sử dụng bộ đệm của nó hoặc hiển thị cho bạn thông tin vùng đệm innodb giống như ví dụ bên dưới:
---TRANSACTION 10798819, ACTIVE 0 sec inserting, thread declared inside InnoDB 1201
mysql tables in use 1, locked 1
1 lock struct(s), heap size 1136, 0 row lock(s), undo log entries 8801
MySQL thread id 68481, OS thread handle 139953970235136, query id 681821 localhost root copy to tmp table
ALTER TABLE NewAddressCode2_2 ENGINE=INNODB
…
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 528, free list len 43894, seg size 44423, 1773 merges
merged operations:
insert 63140, delete mark 0, delete 0
discarded operations:
insert 0, delete mark 0, delete 0
Hash table size 553193, node heap has 1 buffer(s)
Hash table size 553193, node heap has 637 buffer(s)
Hash table size 553193, node heap has 772 buffer(s)
Hash table size 553193, node heap has 1239 buffer(s)
Hash table size 553193, node heap has 2 buffer(s)
Hash table size 553193, node heap has 0 buffer(s)
Hash table size 553193, node heap has 1 buffer(s)
Hash table size 553193, node heap has 1 buffer(s)
115320.41 hash searches/s, 10292.51 non-hash searches/s
...
----------------------
BUFFER POOL AND MEMORY
----------------------
Total large memory allocated 2235564032
Dictionary memory allocated 3227698
Internal hash tables (constant factor + variable factor)
Adaptive hash index 78904768 (35404352 + 43500416)
Page hash 277384 (buffer pool 0 only)
Dictionary cache 12078786 (8851088 + 3227698)
File system 1091824 (812272 + 279552)
Lock system 5322504 (5313416 + 9088)
Recovery system 0 (0 + 0)
Buffer pool size 131056
Buffer pool size, bytes 2147221504
Free buffers 8303
Database pages 120100
Old database pages 44172
Modified db pages 108784
Pending reads 0
Pending writes: LRU 2, flush list 342, single page 0
Pages made young 533709, not young 181962
3823.06 youngs/s, 1706.01 non-youngs/s
Pages read 4104, created 236572, written 441223
38.09 reads/s, 339.46 creates/s, 1805.87 writes/s
Buffer pool hit rate 1000 / 1000, young-making rate 12 / 1000 not 5 / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 120100, unzip_LRU len: 0
I/O sum[754560]:cur[8096], unzip sum[0]:cur[0]
…Một điều khác cần bổ sung, bạn cũng có thể sử dụng Lược đồ Hiệu suất và lược đồ sys để theo dõi mức tiêu thụ và sử dụng bộ nhớ của máy chủ MySQL của bạn. Theo mặc định, hầu hết các thiết bị bị vô hiệu hóa theo mặc định, vì vậy bạn phải làm những việc thủ công để sử dụng nó.
Kiểm tra Swappiness
Dù bằng cách nào, có khả năng MySQL đang hoán đổi bộ nhớ của nó sang đĩa. Đây thường là một tình huống rất phổ biến, đặc biệt là khi máy chủ MySQL và phần cứng bên dưới không được thiết lập tối ưu song song với các yêu cầu mong đợi. Có một số trường hợp không lường trước được nhu cầu lưu lượng, bộ nhớ có thể ngày càng tăng, đặc biệt nếu các truy vấn xấu được chạy gây tiêu tốn hoặc sử dụng nhiều dung lượng bộ nhớ gây giảm hiệu suất do dữ liệu được chọn trên đĩa thay vì trên bộ đệm. Để kiểm tra tính swappiness, chỉ cần chạy lệnh freemem hoặc vmstat giống như bên dưới,
[[email protected] ~]# free -m
total used free shared buff/cache available
Mem: 3790 2754 121 202 915 584
Swap: 1535 39 1496
[[email protected] ~]# vmstat 5 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
2 0 40232 124100 0 937072 2 3 194 1029 477 313 7 2 91 1 0
0 0 40232 123912 0 937228 0 0 0 49 1247 704 13 3 84 0 0
1 0 40232 124184 0 937212 0 0 0 35 751 478 6 1 93 0 0
0 0 40232 123688 0 937228 0 0 0 15 736 487 5 1 94 0 0
0 0 40232 123912 0 937220 0 0 3 74 1065 729 8 2 89 0 0Bạn cũng có thể kiểm tra bằng cách sử dụng procfs và thu thập thông tin như truy cập / proc / vmstat hoặc / proc / meminfo.
Sử dụng Perf, gdb và Valgrind với Massif
Sử dụng các công cụ như perf, gdb và valgrind giúp bạn tìm hiểu phương pháp nâng cao hơn để xác định mức sử dụng bộ nhớ MySQL. Đôi khi, một kết quả thú vị trở thành một bí ẩn trong việc giải quyết việc tiêu thụ bộ nhớ dẫn đến sự hoang mang của bạn trong MySQL. Điều này khiến nhu cầu phải có nhiều hoài nghi hơn và việc sử dụng các công cụ này giúp bạn điều tra cách MySQL đang sử dụng xử lý bộ nhớ từ việc cấp phát cho đến sử dụng bộ nhớ để xử lý các giao dịch hoặc quy trình. Điều này rất hữu ích, chẳng hạn như nếu bạn quan sát thấy MySQL đang hoạt động bất thường có thể gây ra cấu hình xấu hoặc có thể dẫn đến phát hiện rò rỉ bộ nhớ.
Ví dụ:sử dụng perf trong MySQL sẽ hiển thị nhiều thông tin hơn trong báo cáo cấp hệ thống:
[[email protected] ~]# perf report --input perf.data --stdio
# To display the perf.data header info, please use --header/--header-only options.
#
#
# Total Lost Samples: 0
#
# Samples: 54K of event 'cpu-clock'
# Event count (approx.): 13702000000
#
# Overhead Command Shared Object Symbol
# ........ ....... ................... ...................................................................................................................................................................................................
#
60.66% mysqld [kernel.kallsyms] [k] _raw_spin_unlock_irqrestore
2.79% mysqld libc-2.17.so [.] __memcpy_ssse3
2.54% mysqld mysqld [.] ha_key_cmp
1.89% mysqld [vdso] [.] __vdso_clock_gettime
1.05% mysqld mysqld [.] rec_get_offsets_func
1.03% mysqld mysqld [.] row_sel_field_store_in_mysql_format_func
0.92% mysqld mysqld [.] _mi_rec_pack
0.91% mysqld [kernel.kallsyms] [k] finish_task_switch
0.90% mysqld mysqld [.] row_search_mvcc
0.86% mysqld mysqld [.] decimal2bin
0.83% mysqld mysqld [.] _mi_rec_check
….Vì đây có thể là một chủ đề đặc biệt để tìm hiểu, chúng tôi khuyên bạn nên xem các blog bên ngoài thực sự tốt này làm tài liệu tham khảo của bạn, Kiến thức cơ bản về Cấu hình MySQL, Tìm các Vấn đề về Quy mô MySQL Sử dụng perf hoặc tìm hiểu cách gỡ lỗi bằng cách sử dụng valgrind với massif.
Cách hiệu quả để kiểm tra việc sử dụng bộ nhớ MySQL
Việc sử dụng ClusterControl giúp giải quyết mọi quy trình rắc rối như xem qua sổ tay của bạn hoặc thậm chí tạo sách vở của riêng bạn để cung cấp báo cáo cho bạn. Trong ClusterControl, bạn có Trang tổng quan (sử dụng SCUMM) nơi bạn có thể có cái nhìn tổng quan nhanh về (các) nút MySQL của mình. Ví dụ:xem MySQL General dashboard,
bạn có thể xác định cách nút MySQL hoạt động,
Bạn thấy rằng các hình ảnh ở trên tiết lộ các biến ảnh hưởng đến việc sử dụng bộ nhớ MySQL. Bạn có thể kiểm tra cách các chỉ số để sắp xếp bộ đệm, bảng tạm thời, chuỗi được kết nối, bộ đệm truy vấn hoặc công cụ lưu trữ vùng đệm innodb hoặc bộ đệm khóa của MyISAM.
Sử dụng ClusterControl cung cấp cho bạn một công cụ tiện ích một cửa, nơi bạn cũng có thể kiểm tra các truy vấn đang chạy để xác định các quy trình (truy vấn) có thể ảnh hưởng đến việc sử dụng bộ nhớ cao. Xem ví dụ bên dưới,
Xem các biến trạng thái của MySQL rất dễ dàng,
Bạn thậm chí có thể đi tới Hiệu suất -> Trạng thái Innodb để hiển thị trạng thái InnoDB hiện tại của các nút cơ sở dữ liệu của bạn. Ngoài ra, trong ClusterControl, một sự cố được phát hiện, nó sẽ cố gắng thu thập sự cố và hiển thị lịch sử dưới dạng báo cáo cung cấp cho bạn trạng thái InnoDB như được hiển thị trong blog trước của chúng tôi về MySQL Freeze Frame.
Tóm tắt
Khắc phục sự cố và chẩn đoán cơ sở dữ liệu MySQL của bạn khi nghi ngờ sử dụng bộ nhớ cao không quá khó miễn là bạn biết các quy trình và công cụ để sử dụng. Sử dụng đúng công cụ mang lại cho bạn sự linh hoạt hơn và năng suất nhanh hơn để cung cấp các bản sửa lỗi hoặc giải pháp với cơ hội đạt được kết quả cao hơn.
