Bảng InnoDB nặng không sử dụng tất cả CPU của tôi


8

Tôi có một cơ sở dữ liệu nhật ký gói, gần như không bao giờ được truy vấn. Nó chỉ cần được nhanh chóng trên chèn. Tôi đang sử dụng InnoDB vì tôi muốn duy trì tuân thủ ACID, vì thậm chí mất một gói duy nhất có thể gây tổn hại cho khách hàng của chúng tôi. Trong kịch bản điều chỉnh hiệu suất, tôi gửi 1.000.000 gói đến máy chủ qua nhiều kết nối DB. Nhưng bất kể tôi sử dụng cài đặt nào trong my.cnf, tôi không thể có quy trình mysqld để sử dụng hơn 900% CPU trên hệ thống có 12 lõi. (Không có gì khác đang chạy trên hộp.)

Tôi đã thiết lập như sau

  • innodb_file_per_table = 1
  • innodb_write_io_threads = 64
  • innodb_read_io_threads = 64
  • innodb_thread_concurrency = 0

Nếu tôi sử dụng MyISAM, tôi có thể nhận được tất cả các gói được viết trong khoảng 6 giây. Nhưng InnoDB mất khoảng 25. Tôi có thể khiến MySQL sử dụng phần còn lại của tài nguyên hệ thống và chèn nhanh hơn không?

Chỉnh sửa: Đây là lược đồ cho bảng:

+-------+----------------------+------+-----+---------+-------+
| Field | Type                 | Null | Key | Default | Extra |
+-------+----------------------+------+-----+---------+-------+
| t     | bigint(20) unsigned  | YES  |     | NULL    |       |
| a     | char(1)              | YES  |     | NULL    |       |
| sa    | int(10) unsigned     | YES  |     | NULL    |       |
| sb    | int(10) unsigned     | YES  |     | NULL    |       |
| sc    | int(10) unsigned     | YES  |     | NULL    |       |
| sd    | int(10) unsigned     | YES  |     | NULL    |       |
| sp    | smallint(5) unsigned | YES  |     | NULL    |       |
| da    | int(10) unsigned     | YES  |     | NULL    |       |
| db    | int(10) unsigned     | YES  |     | NULL    |       |
| dc    | int(10) unsigned     | YES  |     | NULL    |       |
| dd    | int(10) unsigned     | YES  |     | NULL    |       |
| dp    | smallint(5) unsigned | YES  |     | NULL    |       |
+-------+----------------------+------+-----+---------+-------+

chỉnh sửa2: Tôi đã gộp nhiều lần chèn lại với nhau để một truy vấn duy nhất gần độ dài tối đa (khoảng 16.000.000 ký tự). Cơ sở dữ liệu bây giờ tăng vọt lên 1100% trong hai giây, sau đó giảm xuống 100% trong thời gian còn lại. Tổng thời gian bây giờ là 21 giây, hoặc nhanh hơn khoảng 16% so với khi tôi bắt đầu.

Câu trả lời:


7

Bạn cũng phải điều chỉnh innodb_io_capacity .

Mặc định là 200. Nâng nó lên 5000 cho người mới bắt đầu. Tôi sẽ đi đến 20000.

Bạn cũng có thể muốn đảm bảo ib_logfile0ib_logfile1đủ lớn. Giá trị mặc định cho innodb_log_file_size là 5M. Tôi sẽ nâng nó lên 1G cho người mới bắt đầu.

Nhóm đệm InnoDB lớn hơn cũng có thể giúp ích, có lẽ là 4G.

Để tóm tắt, sử dụng các cài đặt bổ sung sau:

[mysqld]
innodb_io_capacity=5000
innodb_buffer_pool_size=4G
innodb_log_file_size=1G

Sau khi thêm các cài đặt này vào my.cnf, để thay đổi kích thước ib_logfile0 / ib_logfile1, hãy làm như sau

service mysql stop
rm -f /var/log/mysql/ib_logfile[01]
service mysql start

Các tập tin ib_logfile0 và ib_logfile1 được tạo lại. Đừng lo lắng, tôi đã làm điều này nhiều lần .

Bạn có thể phải làm một cái gì đó khác thường cho InnoDB

Hãy thử như sau:

  • Khóa bảng đầy đủ trên bảng InnoDB
  • Thực hiện tải số lượng lớn
  • Phát hành Khóa

Nó sẽ giúp có nhiều vùng đệm? Hoặc vì nó chỉ là một bảng, nó sẽ có vấn đề?
sep32

Chỉ có một vùng đệm. Bằng cách đó, không có giới hạn ảo. Tôi có một máy khách có MySQL 5.5.9 sử dụng nhóm bộ đệm 162 GB duy nhất và nó chạy rất tốt.
RolandoMySQLDBA

Sử dụng cái này tôi có khoảng 950% CPU, nhưng dường như nó không nhanh hơn.
sep32

Hãy thử khóa bảng đầy đủ trên bảng InnoDB trước khi tải số lượng lớn.
RolandoMySQLDBA

3

Có một số yếu tố ảnh hưởng đến khả năng tối đa hóa việc sử dụng nhiều lõi.

  • Một số mutexes sẽ tác động đến nhiều CPU để lại một số chờ đợi trước khi chúng có thể tiến hành.
  • Bạn cần nhiều luồng hoạt động như bạn có CPU. Nếu khối lượng công việc của bạn dẫn đến 9 luồng song song, bạn không thể điền vào 12 lõi.
  • Dung lượng I / O phải đủ để cung cấp đủ công việc cho tất cả các CPU. Nếu bạn đang xếp hàng trên I / O trên đĩa hoặc chờ tin nhắn mạng, thì bạn sẽ không thể lấp đầy CPU.

Các công cụ như SAR sẽ cho phép bạn xác định xem có bất kỳ tắc nghẽn nào làm giảm khả năng của bạn không. Chỉ cần được cảnh báo, loại bỏ một nút cổ chai, sẽ chỉ di chuyển nút cổ chai.

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.