Đôi khi có vẻ như bộ nhớ trống của máy chủ sắp hết vì MySQL đang sử dụng nhiều bộ nhớ hơn mức bạn muốn
Viết bởi Thomas Fiorelli
Chà, người ta không chỉ đơn giản nói cho MySQL biết nó nên sử dụng bao nhiêu bộ nhớ
Mức sử dụng bộ nhớ tối đa đến từ nhiều cài đặt khác nhau, chủ yếu là kích thước bộ đệm nhưng có vẻ như tài liệu không nêu rõ cách tìm hoặc đặt giá trị này.
Bạn sẽ phải đọc bài đăng của họ về việc sử dụng bộ nhớ, dù sao thì tôi cũng rất khuyến khích điều này.
Hy vọng rằng, một người đàn ông tốt bụng đã đăng một tập lệnh shell rất hữu ích dưới dạng nhận xét về bài đăng này [mà bạn sẽ tìm thấy ở cuối tài liệu này]
Tập lệnh này in xấp xỉ mức sử dụng bộ nhớ tiềm năng của MySQL dựa trên phân bổ bộ nhớ đệm và bộ đệm
Chúng ta đừng chờ đợi lâu hơn
+------------------------------------------+--------------------+
| TOTAL [MIN] | 194.719 MB |
| TOTAL [MAX] | 3002.531 MB |
+------------------------------------------+--------------------+Đây là kết quả của script khi test trên môi trường của mình [chỉ là một phần của nó, phần còn lại sẽ xem sau]
TOTAL [MAX] là bộ nhớ tối đa mà MySQL có thể sử dụng với cấu hình hiện tại.
Với cấu hình mặc định, MySQL có thể sử dụng 3GB bộ nhớ máy chủ của tôi.
Nhưng nếu tôi chỉ có 500 MB để cho phép thì sao?
Chúng ta sẽ xem 3 bước để giảm mức sử dụng bộ nhớ tiềm ẩn xuống mức thực tế hơn.
Trong trường hợp của tôi, mục tiêu là khoảng 350 MB, tương ứng với 70% tổng bộ nhớ máy chủ của tôi.
Hãy làm bẩn tay chúng ta
1] Xác định các tham số bạn sẽ muốn sửa đổi để hạn chế sử dụng bộ nhớ MySQL
Khởi chạy tập lệnh mà bạn có thể tìm thấy ở cuối hướng dẫn này.
Đây là một ví dụ về hiển thị.
+------------------------------------------+--------------------+
| key_buffer_size | 16.000 MB |
| query_cache_size | 16.000 MB |
| innodb_buffer_pool_size | 128.000 MB |
| innodb_additional_mem_pool_size | 8.000 MB |
| innodb_log_buffer_size | 8.000 MB |
+------------------------------------------+--------------------+
| BASE MEMORY | 176.000 MB |
+------------------------------------------+--------------------+
| sort_buffer_size | 2.000 MB |
| read_buffer_size | 0.125 MB |
| read_rnd_buffer_size | 0.250 MB |
| join_buffer_size | 0.125 MB |
| thread_stack | 0.188 MB |
| binlog_cache_size | 0.031 MB |
| tmp_table_size | 16.000 MB |
+------------------------------------------+--------------------+
| MEMORY PER CONNECTION | 18.719 MB |
+------------------------------------------+--------------------+
| Max_used_connections | 1 |
| max_connections | 151 |
+------------------------------------------+--------------------+
| TOTAL [MIN] | 194.719 MB |
| TOTAL [MAX] | 3002.531 MB |
+------------------------------------------+--------------------+Hai điều chúng ta có thể tác động trực tiếp hoặc gián tiếp là.
- bộ nhớ trên mỗi kết nối — số lượng kết nối đồng thời tối đa
Bạn sẽ muốn đọc một chút về chức năng của từng cài đặt để điều chỉnh các thay đổi theo nhu cầu của bạn
Giống như một gợi ý, đây là những giá trị tôi đã cân nhắc kỹ lưỡng nhất.
- innodbbufferpoolsize — sortbuffersize — readbuffersize — tmptablesize — maxconnections
Khi bạn tìm ra những gì bạn có thể đạt được bộ nhớ, hãy chuyển sang bước tiếp theo
2] Xác định vị trí của bạn. tập tin cnf
Đây là tệp mà bạn sẽ ghi đè lên các tùy chọn mysql. Nó thường nằm trong thư mục /etc/mysql
Khi MySQL lấy bộ nhớ, nó có xu hướng không trả lại. Điều đó không có nghĩa là MySQL đang tích cực “sử dụng” tất cả bộ nhớ; . Nếu MySQL là ứng dụng duy nhất chạy trên máy chủ, thì bạn sẽ không sao vì MySQL sẽ quản lý bộ nhớ và thực hiện với nó khi thấy phù hợp. Tuy nhiên, nếu MySQL cuối cùng sử dụng nhiều bộ nhớ trống hơn mà bạn có, thì bạn có thể gặp sự cố, vì vậy bạn cần xem “mức nước cao” của mình là gì và giảm mức sử dụng bộ nhớ nếu cần để ngăn hệ thống bị quá tải
Nếu bạn đang chạy một ứng dụng ngốn bộ nhớ khác trên cùng một máy chủ thì bạn có thể gặp rắc rối. Nếu đúng như vậy, thì lý tưởng nhất là bạn nên đặt MySQL trên máy chủ của chính nó, nếu không, bạn sẽ cần giảm dung lượng bộ nhớ của MySQL [rất có thể là giảm kích thước nhóm bộ đệm InnoDB] để ngăn tranh chấp bộ nhớ giữa các ứng dụng
Theo như innodb_max_dirty_pages_pct, tôi không tin rằng điều đó sẽ làm giảm dung lượng bộ nhớ hiện đang sử dụng của MySQL. Tất cả những gì làm là ghi các thay đổi từ nhóm bộ đệm InnoDB vào đĩa. Đặt biến này thành 0 thường chỉ được thực hiện khi bạn định tắt máy chủ và muốn có ít thay đổi hơn để ghi vào đĩa sau khi bạn thực sự tắt máy để quá trình này diễn ra nhanh hơn. Điều này là “an toàn” để thực hiện trong quá trình sản xuất, miễn là bạn hiểu ý nghĩa hiệu suất của nó vì bạn đang ghi nhiều hơn vào đĩa vào thời điểm đó. Nếu hệ thống của bạn không bận lắm và bạn có thời gian I/O rảnh rỗi thì có khả năng nó sẽ không gây ra sự cố. Tuy nhiên, nếu bạn chạy một hệ thống bận rộn, bạn có thể nhận thấy hiệu suất bị ảnh hưởng khi đặt biến đó thành 0
Vì vậy, để trả lời cụ thể câu hỏi của bạn, tôi không biết cách nào để giải phóng một lượng bộ nhớ đáng kể khỏi MySQL mà không cần khởi động lại nó. Điều duy nhất hầu như không đáng kể mà tôi thấy là đặt lại bộ đệm truy vấn, nhưng hầu hết mọi người thậm chí không sử dụng bộ đệm truy vấn ngày nay
-Scott
Xin chào ssksan;
Bản thân tôi chưa bao giờ sử dụng drop_caches nên tôi không thể nói, nhưng theo những gì tôi hiểu về nó thì tôi không khuyên dùng nó
vấn đề thực sự trong tầm tay là gì?
Nếu máy chủ của bạn thực sự hết bộ nhớ và các ứng dụng đang bị tắt, thì bạn cần giảm dung lượng bộ nhớ tiềm năng của MySQL bằng cách sửa đổi các cài đặt như kích thước innodb_buffer_pool và tmp_table_size / max_heap_table_size [trong số nhiều cài đặt khác mà bạn có thể điều chỉnh nếu cần]
Nếu máy chủ của bạn không thực sự hết bộ nhớ thì có thể bạn không gặp sự cố. Nếu tại thời điểm đó bạn vẫn không thoải mái khi thấy MySQL sử dụng quá nhiều bộ nhớ, thì chỉ cần thực hiện tương tự như trên và giảm dung lượng bộ nhớ có thể có của MySQL bằng cách sửa đổi các cài đặt khác nhau để hạn chế sử dụng bộ nhớ
MySQL [và hầu hết các máy chủ cơ sở dữ liệu] là những động vật đói bộ nhớ sẽ lấy và giữ càng nhiều bộ nhớ càng tốt. Vì vậy, điều quan trọng là cung cấp cho MySQL càng nhiều bộ nhớ càng tốt một cách an toàn mà không đi đến điểm mà hệ thống đang hoán đổi và/hoặc giết chết MySQL hoặc các ứng dụng khác do bộ nhớ thấp
-Scott
Xin chào ssksan;
Bạn đang tập trung vào triệu chứng [tăng mức sử dụng bộ nhớ] thay vì vấn đề. Vì MySQL đột nhiên bắt đầu sử dụng nhiều bộ nhớ hơn và có vẻ như nó vẫn đang tăng lên, nên bạn cần xác định nguyên nhân gây ra thay đổi và sửa nó nếu nó bị hỏng hoặc điều chỉnh cấu hình MySQL của bạn để đối phó với nó [giả sử mức sử dụng
Bạn đã phát hành mã cho ứng dụng sử dụng MySQL làm phụ trợ chưa? . e. quy trình ETL cho kho dữ liệu]?
Tôi sẽ bắt đầu bằng cách chạy nhật ký truy vấn chậm và xem những truy vấn nào đang hiển thị. Một nguyên nhân có thể là do bạn có các truy vấn làm việc với các tập hợp kết quả lớn đang chiếm dụng bộ nhớ. Cùng với đó, tôi sẽ theo dõi việc sử dụng bảng tạm thời của bạn, vì bạn cũng có thể thấy rất nhiều bảng tmp được tạo nếu vấn đề là truy vấn lớn/xấu. Nếu đúng như vậy, việc tối ưu hóa các truy vấn có thể giúp bạn rất nhiều hoặc giảm các biến tmp_table_size / max_heap_table_size nếu cần để giảm bộ nhớ đã sử dụng