Người dùng phàn nàn rằng hệ thống chạy chậm khi đang tiến hành mysqldump

Cơ sở dữ liệu MYSQL (ibdata1) có kích thước 73 GB và được định cấu hình để chạy như một máy chủ cơ sở dữ liệu chuyên dụng trên Windows 2008 O / S cho các bảng INNODB. Chúng tôi đang chạy bản sao lưu bằng mysqldump mysqldump --skip-opt --quick --single-giao dịch --create-Tùy chọn --extends-insert --disable-key --add-drop-table --complete-insert - set-charset - nén --log-error = Proddb0635.err -u root -pjohndoe Proddb> \ devNas \ devNas \ sqlbackup \ LIVE \ db \ Proddb0635.sql

Tệp sao lưu Proddb0635.sql được lưu trữ trên một máy chủ riêng biệt từ máy chủ cơ sở dữ liệu. RAM là 12 GB. Kích thước bể đệm của INNODB là 6 GB. Mem.pool bổ sung là 32 MB. Truy vấn Kích thước bộ đệm là 2 GB Chiều dài bộ đệm ròng tối đa 16 M. kích thước gói 1 GB.

phiên bản mysql là 5.0,67.

Khi sao lưu không chạy, người dùng hài lòng với hiệu suất.

Khi sao lưu đang chạy INNODB Buffer pool tỷ lệ trúng cao gần 100%. Không có đọc chờ hoặc viết đang chờ xử lý. innodb chờ miễn phí là 0. Sử dụng CPU không cao tối thiểu 9% đến tối đa 15% Tốc độ truy cập bộ đệm truy vấn thấp khoảng 40% có hoặc không có mysqlbackup chạy. Hiện tại Windows Task Manager đang hiển thị rằng 10GB RAM đang được sử dụng. Tôi có nên tăng Cache truy vấn chỉ với 2GB RAM không? mysqlld-nt đang chiếm 9,2 GB RAM và mysqldump đang chiếm 5 MB RAM. Alos, lưu ý rằng kích thước của tệp kết xuất là giống nhau khi có hoặc không có tùy chọn - nén.

Tôi có nên giảm kích thước nhóm đệm iNNODB không?

Cảm ơn

Có một vấn đề được biết đến trong Windows, đó là khi bạn đẩy một tệp lớn sang máy chủ khác, tất cả bộ nhớ sẽ được cấp phát vào bộ đệm Hệ thống thay vì xử lý người dùng. Bạn có thể xem trong phần Bộ nhớ vật lý (MB) của trình quản lý tác vụ để xem dung lượng bộ nhớ được phân bổ cho bộ đệm hệ thống.

Điều này có thể được giải quyết bằng cách sao lưu vào một đĩa cục bộ, sau đó nhờ máy từ xa kéo tập tin đó.

Dưới đây là một số suy nghĩ của tôi về việc cải thiện hiệu suất mysqldump, tùy theo hoàn cảnh của bạn. Đây là lệnh của bạn:

mysqldump --skip-opt --quick --single-giao dịch --create-Tùy chọn --extends-insert --disable-key --add-drop-table --complete-insert --set-charset --compress - -log-error = Proddb0635.err -u root -pjohndoe Proddb> \ devNas \ devNas \ sqlbackup \ LIVE \ db \ Proddb0635.sql

Điều đầu tiên tôi nhận thấy là bạn đang chuyển hướng đầu ra sang một hệ thống tập tin. Nó nói 'devNas' vì vậy tôi sẽ cho rằng đây là Lưu trữ được đính kèm mạng . Tôi là một fan hâm mộ của NAS để sao lưu, nhưng nó phải được kết nối trên một NIC vật lý riêng biệt với lưu lượng sản xuất . Bạn có thể không bão hòa băng thông, nhưng chúng vẫn cạnh tranh. Đây sẽ là một vấn đề nhiều hơn vì cờ --quick, vì nó xóa mọi hàng thay vì giữ nó trong bộ nhớ.

Điều tiếp theo tôi thấy là bạn đã gọi - nén. Có vẻ như bạn đang chạy mysql cục bộ vì bạn không sử dụng công tắc -h. Điều này có thể sử dụng CPU cục bộ không cần thiết trong bối cảnh này. - Máy nén có cần thiết không? Nó chỉ nén dữ liệu giữa máy khách mysqldump và máy chủ mysql chứ không phải nội dung tệp.

Tiếp theo tôi thấy bạn đang sử dụng cờ --single-giao dịch. Điều này sẽ gây ra thêm CPU khi nó thử nghiệm trên mỗi lựa chọn như một phần của mysqldump.

Điều này không liên quan gì đến hiệu suất, nhưng bạn đang sử dụng --disable-key chỉ hoạt động trên MyISAM ( thủ công ).

Bạn có thể muốn thử nghiệm chạy mysqldump từ xa từ máy chủ ngoại tuyến và di chuyển tệp kết xuất sang NAS sau khi hoàn thành để thực hiện càng nhiều thao tác này ra khỏi băng tần càng tốt.

QUAN SÁT # 1

Dưới đây là một số điều cần lưu ý khi thực hiện mysqldump đối với InnoDB.

Bất cứ trang bẩn nào tồn tại trong Bộ đệm InnoDB đều phải được xóa vào đĩa trước. Một mysqldump sẽ kích hoạt việc xóa một bảng InnoDB vẫn còn các trang bẩn trong đó.

Có một tùy chọn máy chủ được gọi là innodb_max_denty_pages_pct . Giá trị mặc định là 75 là MySQL 5.5 và 90 trong các phiên bản của MySQL trước 5.5. Trong môi trường sản xuất, bạn có thể để số này ở giá trị mặc định.

Để xem bạn có nhiều trang bẩn trong Nhóm đệm InnoDB hay không, hãy chạy nó:

SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_pages_dirty';

BTW một trang là 16K như hiển thị từ đây:

SHOW GLOBAL STATUS LIKE 'Innodb_page_size';

Khi nói đến InnoDB và mysqldump, bạn có thể hạ thấp con số này trong hai trường hợp.

CIRCUMSTANCE 1: Đặt nó vĩnh viễn thành 0

Chỉ cần thêm nó vào my.ini:

[mysqld]
innodb_max_dirty_pages_pct=0

Điều này sẽ giữ cho nhóm đệm InnoDB nạc và có ý nghĩa. Bước xóa bảng InnoDB đang bị xóa sẽ nhanh chóng vì một vài trang bẩn nhất có thể (có lẽ là 0) sẽ cần phải được xóa trước khi mysqldump hoạt động trên đó.

Hạn chế duy nhất là nếu bạn mysqldump từ một DB bị buôn bán rất nhiều, có thể có một sự gia tăng nhỏ hơn trong I / O viết vì việc xóa trang bẩn thường xuyên hơn. Bạn có thể xác định nếu điều này là như vậy mà không cần khởi động lại mysql bằng cách chạy này:

SET GLOBAL innodb_max_dirty_pages_pct = 0;

Để cài đặt trong 12-24 giờ, nếu hiệu suất ghi là chấp nhận được, bạn tốt để đi. Nếu không, hãy đặt lại bằng:

SET GLOBAL innodb_max_dirty_pages_pct = 90;

CIRCUMSTANCE 2: Đặt thành 0 khoảng 1 giờ trước khi mysqldump

SET GLOBAL innodb_max_dirty_pages_pct = 0;

Chạy mysqldump

SET GLOBAL innodb_max_dirty_pages_pct = 90;

QUAN SÁT # 2

Bạn có --complete-insert dưới dạng tùy chọn mysqldump. Điều này sẽ nhúng tên cột vào mọi quy tắc INSERT trước mệnh đề GIÁ TRỊ. Ngay cả với --extends-insert, trên mỗi lô hàng được chèn đều có tên cột được gửi vào mysqldump. Bạn có thể giảm số lượng byte được gửi đến mysqldump bằng cách xóa --complete-insert.

SỰ GIỚI THIỆU

Nếu bạn có một Windows Server khác có thể được thiết lập là Slave, hãy thực hiện mysqldumps từ nô lệ đó thay vì từ máy sản xuất.