Ý nghĩa của số liệu thống kê nhóm bộ đệm INNODB


20

Sau khi đọc trang này trong tài liệu mysql , tôi đã cố gắng hiểu ý nghĩa của việc sử dụng InnoDB hiện tại của chúng tôi. Hiện tại, chúng tôi phân bổ 6GB RAM cho vùng đệm. Kích thước cơ sở dữ liệu của chúng tôi là như nhau. Đây là đầu ra từ show engine innodb status\G(chúng tôi đang chạy v5.5)

----------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 6593445888; in additional pool allocated 0
Dictionary memory allocated 1758417
Buffer pool size   393215
Free buffers       853
Database pages     360515
Old database pages 133060
Modified db pages  300
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 7365790, not young 23099457
0.00 youngs/s, 0.00 non-youngs/s
Pages read 1094342, created 185628, written 543182148
0.00 reads/s, 0.00 creates/s, 37.32 writes/s
Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 360515, unzip_LRU len: 0
I/O sum[2571]:cur[0], unzip sum[0]:cur[0]

Tôi muốn biết chúng tôi sử dụng bộ đệm bộ đệm tốt như thế nào. Sau khi ban đầu liếc vào đầu ra, có vẻ như chúng ta thực sự đang sử dụng nó, dựa trên Pages made youngnot youngcó số trong đó và Buffer pool hit rate is 1000 / 10000(tôi thấy ở đâu đó trên web rằng điều này có nghĩa là nó được sử dụng khá nhiều. Đúng không?)

Có gì ném tôi qua một vòng lặp là lý do tại sao young-making ratenotđều tại 0/1000 và young/snon-young/struy cập đều ở 0. Những tất cả sẽ chỉ ra rằng nó không được sử dụng ở tất cả, phải không?

Bất cứ ai có thể giúp làm cho ý nghĩa của điều này?

Câu trả lời:


18
 Buffer pool hit rate is 1000 / 1000

Đây là giá trị thực sự có ý nghĩa duy nhất trong tình huống mà bạn đang ở ... và tình huống đó là bạn đủ may mắn để có một vùng đệm với tỷ lệ trúng hoàn hảo 100%. Đừng phân tích quá mức phần còn lại của nó, bởi vì không có gì bạn cần thay đổi, trừ khi hệ điều hành máy chủ thiếu bộ nhớ, gây ra sự tráo đổi.

Các giá trị trẻ / không trẻ không thú vị trong trường hợp không có áp lực lên vùng đệm. InnoDB đang sử dụng nó, nó không làm gì nếu không có nó. Nếu nhóm quá nhỏ, các trang sẽ bị trục xuất và các trang mới được đọc và các số liệu thống kê khác giúp bạn hiểu rằng ... nhưng đó là vấn đề bạn dường như không gặp phải.

Không gian "không sử dụng" miễn phí trong hồ bơi sẽ không bao giờ bị InnoDB bỏ qua hoặc nhàn rỗi nếu cần vì bất kỳ lý do gì, vì vậy thực tế là nó chỉ có nghĩa là bạn có một số phòng thở để mở rộng theo quy mô làm việc của bạn tập dữ liệu phát triển.

Tất nhiên điều đó có nghĩa là, trừ khi, gần đây, bạn đã khởi động lại máy chủ, trong trường hợp đó, nó chưa hoàn tất .. Máy chủ cần phải chạy qua toàn bộ thời gian sử dụng "bình thường" (bao gồm các bản sao lưu đầy đủ) trước khi thống kê nói lên toàn bộ câu chuyện ... cho dù đó là một giờ, một ngày, tuần, tháng hay năm, tùy thuộc vào ứng dụng của bạn.


28

The Buffer pool size 393215 Đây là trong các trang không byte.

Để xem kích thước Bộ đệm trong GB chạy này:

SELECT FORMAT(BufferPoolPages*PageSize/POWER(1024,3),2) BufferPoolDataGB FROM
(SELECT variable_value BufferPoolPages FROM information_schema.global_status
WHERE variable_name = 'Innodb_buffer_pool_pages_total') A,
(SELECT variable_value PageSize FROM information_schema.global_status
WHERE variable_name = 'Innodb_page_size') B;

Database pages 360515 Đây là số lượng trang có dữ liệu bên trong Vùng đệm

Để xem lượng dữ liệu trong kích thước Bộ đệm trong GB, hãy chạy này:

SELECT FORMAT(BufferPoolPages*PageSize/POWER(1024,3),2) BufferPoolDataGB FROM
(SELECT variable_value BufferPoolPages FROM information_schema.global_status
WHERE variable_name = 'Innodb_buffer_pool_pages_data') A,
(SELECT variable_value PageSize FROM information_schema.global_status
WHERE variable_name = 'Innodb_page_size') B;

Để xem tỷ lệ phần trăm của Bộ đệm đang sử dụng, hãy chạy phần này:

SELECT CONCAT(FORMAT(DataPages*100.0/TotalPages,2),' %') BufferPoolDataPercentage FROM
(SELECT variable_value DataPages FROM information_schema.global_status
WHERE variable_name = 'Innodb_buffer_pool_pages_data') A,
(SELECT variable_value TotalPages FROM information_schema.global_status
WHERE variable_name = 'Innodb_buffer_pool_pages_total') B;

Modified db pages 300Đây là số lượng trang trong Vùng đệm phải được ghi lại vào cơ sở dữ liệu. Chúng cũng được gọi là các trang bẩn.

Để xem Space Taken Up by Dirty Pages, hãy chạy nó:

SELECT FORMAT(DirtyPages*PageSize/POWER(1024,3),2) BufferPoolDirtyGB FROM
(SELECT variable_value DirtyPages FROM information_schema.global_status
WHERE variable_name = 'Innodb_buffer_pool_pages_dirty') A,
(SELECT variable_value PageSize FROM information_schema.global_status
WHERE variable_name = 'Innodb_page_size') B;

Để xem Tỷ lệ trang bẩn, hãy chạy này:

SELECT CONCAT(FORMAT(DirtyPages*100.0/TotalPages,2),' %') BufferPoolDirtyPercentage FROM
(SELECT variable_value DirtyPages FROM information_schema.global_status
WHERE variable_name = 'Innodb_buffer_pool_pages_dirty') A,
(SELECT variable_value TotalPages FROM information_schema.global_status
WHERE variable_name = 'Innodb_buffer_pool_pages_total') B;

Đối với những thứ khác trong màn hình, hãy chạy này:

SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool%';

Bạn sẽ thấy tất cả các biến trạng thái cho Vùng đệm. ou có thể áp dụng các truy vấn tương tự đối với bất cứ điều gì bạn cần kiểm tra.


Cảm ơn bạn! Vì vậy, từ điều này, tôi thu thập được rằng bộ đệm bộ đệm của chúng tôi thực sự đang được sử dụng, nhưng điều tôi muốn biết là nếu chúng tôi HIỆU QUẢ sử dụng nó. Nếu tôi hiểu khái niệm về trang trẻ và trang cũ, tôi đoán rằng một chỉ báo tốt cho thấy bộ đệm bộ đệm đang được sử dụng hết mức sẽ nằm trong số trang được tạo trẻ và truy cập vào trang trẻ, đúng không? Chúng tôi sử dụng mysqldump để thực hiện sao lưu cứ sau 3 giờ, điều này sẽ giải thích tại sao nó đầy. Nhưng với young-making rate 0 / 10000.00 youngs/s, điều đó cho chúng ta biết chúng ta không thực sự sử dụng nó. Tôi đang đọc cái này phải không?
Safado

2
Tỷ lệ tạo 0/1000 cho bạn biết rằng các trang dữ liệu cho các truy vấn bạn đang chạy không chỉ phù hợp với bộ đệm, chúng phù hợp với kích thước nhỏ hơn (3/8) của bộ đệm trẻ. Đó là, các truy vấn không sử dụng đủ dữ liệu để đưa một số trang vào bộ đệm lớn không trẻ.
Thomas Jones-Low

Một lời giải thích ngắn về các biến trạng thái innodb_buffer_pool còn lại sẽ rất hữu ích. Bạn có thể vui lòng thêm nó vào câu trả lời của bạn không
vidyadhar

5

Tôi sẽ không đồng ý với đánh giá rằng "bạn đủ may mắn để có một vùng đệm với tỷ lệ trúng 100% hoàn hảo"

Ở đầu ra (được băm nhỏ), là một dòng giống như:

Per second averages calculated from the last 16 seconds

Điều này nói với tôi rằng không có lần đọc nào xảy ra trong 16 giây qua, do đó (một cách giả tạo) mang lại cho bạn điểm số '1000/1000' hoàn hảo.

0.00 reads/s, 0.00 creates/s, 37.32 writes/s
Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000

Trong khi đó đã có một số viết. Chúng có thể được hoãn viết cho việc xóa các trang 'bẩn' hoặc làm sạch các chỉ mục từ 'bộ đệm thay đổi'.

Có lẽ không có hoạt động nào trong khu vực trẻ / nóng trong 16 giây qua.


Chà, chúng tôi trung bình từ 6k-10k CHỌN một giây và đồng thời tôi có thể thấy gần như 0 hoạt động đọc đĩa trên máy chủ, vì vậy tôi không nghĩ đây là trường hợp
Safado

Là "Bộ đệm truy vấn" có đáp ứng hầu hết các truy vấn không? SHOW VARIABLES LIKE 'query%';SHOW GLOBAL STATUS LIKE 'Qc%';SHOW GLOBAL VARIABLES LIKE 'Com_SELECT';.
Rick James

0

Nhóm bộ đệm được chia thành hai phần, một danh sách trẻ và một danh sách không trẻ. Tỷ lệ tạo cho thấy có bao nhiêu trang trong vùng đệm đang được xáo trộn giữa hai danh sách.

Các trang được tạo ra không phải là các trang không trẻ được tạo ra (tức là được đọc ra khỏi bộ đệm. Các trang không còn trẻ là các trang được chuyển từ danh sách trẻ vì chúng quá cũ hoặc do danh sách trẻ đã đầy.

Tốc độ tại các trang được di chuyển giữa hai tùy thuộc vào mức độ của vùng đệm hiện đang được sử dụng so với kích thước của nhóm trẻ. Đặt ở mức 0 có nghĩa là bộ hoạt động của bạn (các trang bạn đang sử dụng) nhỏ hơn nhóm trẻ.

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.