Bạn có thể chống phân mảnh bộ đệm truy vấn để sử dụng tốt hơn bộ nhớ của nó bằng câu lệnh FLUSH QUERY CACHE. Câu lệnh không xóa bất kỳ truy vấn nào khỏi bộ đệm
Câu lệnh RESET QUERY CACHE xóa tất cả các kết quả truy vấn khỏi bộ đệm truy vấn. Câu lệnh FLUSH TABLES cũng thực hiện điều này
Bình luận
Nội dung được sao chép trên trang web này là tài sản của chủ sở hữu tương ứng và nội dung này không được MariaDB xem xét trước. Quan điểm, thông tin và ý kiến được thể hiện bởi nội dung này không nhất thiết đại diện cho quan điểm của MariaDB hoặc bất kỳ bên nào khác
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 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 an toàn càng tốt 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