Trong một trong các môi trường sản xuất của tôi, chúng tôi có hai phiên bản chạy trên cụm RedHat, với một phiên bản sản xuất được liên kết với cụm.
Chúng tôi có bộ nhớ chính 125G với nhóm bộ đệm InnoDB 24G bị chiếm bởi instance1 & 12G bị chiếm bởi instance2, không liên kết với cụm RedHat. Cả dữ liệu và nhật ký giao dịch đều nằm trên phân vùng đĩa LVM với hệ thống tệp ext3.
Để tăng hiệu suất và thông lượng I / O tốt hơn, tôi đã quyết định đổi innodb_flush_methodsang O_DIRECT.
Với tài liệu tham khảo về tài liệu MySQL:
Trong trường hợp dữ liệu InnoDB và file log được đặt trên một SAN, người ta đã phát hiện ra rằng việc thiết
innodb_flush_methodđểO_DIRECTcó thể làm suy giảm hiệu suất của đơn giảnSELECTtuyên bố bởi một yếu tố của ba.
Đề cập đến MySQL Ver 2 và 3 hiệu suất cao, có tuyên bố rằng các nhà phát triển InnoDB đã tìm thấy lỗi khi sử dụng innodb_flush_method=O_DSYNC. O_SYNCvà O_DSYNCtương tự fsync()và fdatasync(): O_SYNCđồng bộ hóa cả dữ liệu và siêu dữ liệu, trong khi chỉ O_DSYNCđồng bộ hóa dữ liệu.
Nếu tất cả dường như rất nhiều lời giải thích mà không có lời khuyên, thì đây là lời khuyên:
nếu bạn sử dụng hệ điều hành giống Unix và bộ điều khiển RAID của bạn có bộ ghi dữ liệu dựa trên pin, chúng tôi khuyên bạn nên sử dụng
O_DIRECT. Nếu không, mặc định hoặcO_DIRECTcó thể sẽ là lựa chọn tốt nhất, tùy thuộc vào ứng dụng của bạn.
Bằng cách googling, tôi đã nhận được báo cáo điểm chuẩn này : trên O_DSYNCvsO_DIRECT
Báo cáo điểm chuẩn: =================== Kiểm tra giao dịch phức tạp 1B Row, 64 chủ đề * SAN O_DIRECT: yêu cầu đọc / ghi: 31560140 (8766.61 mỗi giây) * SAN O_DSYNC: yêu cầu đọc / ghi: 5179457 (1438,52 mỗi giây.) * SAN fdatasync: yêu cầu đọc / ghi: 9445774 (2623,66 mỗi giây.) * O_DIRECT đĩa cục bộ: yêu cầu đọc / ghi: 3258595 (905,06 mỗi giây) * O_DSYNC đĩa cục bộ: yêu cầu đọc / ghi: 3494632 (970,65 mỗi giây.) * Fdatasync đĩa cục bộ: yêu cầu đọc / ghi: 4223757 (1173,04 mỗi giây.
Tuy nhiên, O_DIRECTvô hiệu hóa bộ đệm cấp hệ điều hành, trong đó bộ đệm kép có thể bị vô hiệu hóa cho thấy thông lượng I / O tốt hơn.
Có tốt để đi với O_DIRECThơn là O_DSYNC? Hai tùy chọn này hơi khó hiểu. Tùy chọn nào có thể hiển thị một số thông lượng I / O tốt hơn và nâng cao hiệu suất mà không có bất kỳ tác động nào đến dữ liệu, đọc / ghi đặc biệt là trong sản xuất? Bất kỳ đề xuất tốt hơn dựa trên kinh nghiệm cá nhân của bạn?
Tôi có thể thấy Rolando Update trong bài viết :
Vẫn có một chút nhầm lẫn về cả hai tham số này. Nơi tôi có thể thấy hầu hết các mẫu cấu hình sản xuất bằng cách sử dụng
O_DIRECT, tôi không thấy bất kỳ nơi nào đề xuấtO_DSYNC.
Hệ thống
- MySQL 5.1.51-Enterprise-gpl-pro-log
- Red Hat Enterprise Linux Server phát hành 5.5
- DELL DRAC với Bộ điều khiển Raid có pin ghi lại bộ nhớ cache 512MB
- Bộ điều khiển Dell PERC H700 với bộ phận dự phòng pin (BBU).
Thông tin thêm
mysql hiển thị các biến như 'innodb_thread_concurrency'; + --------------------------- + ------- + | Biến_ame | Giá trị | + --------------------------- + ------- + | innodb_thread_concurrency | 96 | + --------------------------- + ------- + 1 hàng trong bộ (0,00 giây) mysql hiển thị các biến như 'innodb_read_io_threads'; Tập rỗng (0,00 giây) mysql hiển thị các biến như 'innodb_write_io_threads'; Tập rỗng (0,00 giây)
Chúng tôi đang sử dụng plugin mặc định, vì vậy tôi đã đăng thông tin từ trạng thái InnoDB:
mysql CHỌN * TỪ các plugin Ở đâu PLUGIN_NAME THÍCH '% innodb%' VÀ PLUGIN_TYPE THÍCH 'CÔNG CỤ BẢO QUẢN' \ G
****** / TÌM KIẾM ******
PLUGIN_NAME: InnoDB
PLUGIN_VERSION: 1.0
PLUGIN_STATUS: HOẠT ĐỘNG
PLUGIN_TYPE: KỸ THUẬT BẢO QUẢN
PLUGIN_TYPE_VERSION: 50151.0
PLUGIN_LIBRary: NULL
PLUGIN_LIBRARY_VERSION: NULL
PLUGIN_AUTHOR: Innobase OY
PLUGIN_DESCRIPTION: Hỗ trợ giao dịch, khóa cấp hàng và khóa ngoại
PLUGIN_LICENSE: GPL
1 hàng trong bộ (0,00 giây)