Innodb: sau 48 giờ tối ưu hóa tốc độ ghi 10mb / giây


7

Tôi chạy cái này trên máy chủ 8 lõi với bộ lưu trữ NVME (2TB) và ram 64 GB.
Các đĩa rất nhanh, seq 1,1 GB / giây và song công hoàn toàn 70-100k IOPS.

Bởi vì tôi đã có hiệu năng khủng khiếp với mysql 5.7, tôi đã cài đặt Mariadb 10.3.8 trên một container docker mỏng.

Tổng cộng tôi có các bảng để viết có kích thước 2 TB và một tỷ hàng. Nhưng hãy để tôi nói rõ: hiệu suất tốc độ này xảy ra trên đĩa trống ở vài nghìn hàng đầu tiên, nó không liên quan đến một bảng lớn.

Tôi đã đầu tư khoảng 50 giờ làm việc này trong tuần qua, ngày và đêm, tôi đọc mọi trang tài liệu tôi có thể tìm thấy và hàng trăm hướng dẫn và câu hỏi trên các nền tảng khác nhau.
Tôi đã thử nghiệm tất cả, trong hầu hết mọi kết hợp bạn có thể nghĩ ra.
Tôi đã thử nó bộ nhớ thuần bộ đệm, bộ đệm đĩa thuần, có và không có nhật ký lớn, bộ đệm nhật ký, các phương pháp xóa khác nhau, không xóa, tất cả các cài đặt bạn có thể nghĩ ra.

Tôi đã thử nghiệm nhập bằng cách sử dụng: mydumper, bảng điều khiển mysql, mysqlimport, tải dữ liệu không lưu, chèn PHP, tập lệnh PDO đa luồng tôi đã viết.

Tôi đã kiểm tra các bảng có và không có chỉ mục, chỉ lập chỉ mục chính.

Tôi đã thử nhập có và không có GIAO DỊCH, đã thử các hàng CHỌN một hàng và nhiều hàng.

Tôi đã thử các loại bảng khác nhau, thường là 20-30 cột chứa chủ yếu là varchars và một vài datetimes.

Hiệu suất trong một luồng là 3-5k hàng / giây và đa luồng (lố bịch ..) 10-25k / giây. CPU và DISK hầu như không hoạt động mọi lúc, iuler cho thấy hiệu suất ghi 3-20mb / giây, thường là khoảng 7mb-12mb. Tùy thuộc vào cài đặt nào tôi thử.

Vì vậy, chậm hơn khoảng 100 lần so với nó nên thực hiện, không có gì rõ ràng giữ nó lại.
Đó là cấu hình hiện tại:

innodb_buffer_pool_size = 14G
innodb_buffer_pool_chunk_size=1G
innodb_log_buffer_size  = 32M
innodb_file_per_table   = 1
innodb_open_files       = 600
#innodb_flush_method    = O_DIRECT
innodb_flush_method     = O_DSYNC 
innodb_log_file_size    = 512M
innodb_io_capacity=800 
innodb_io_capacity_max=3000 
innodb_flush_neighbors=0
innodb_write_io_threads=8 
innodb_read_io_threads=8 
innodb_change_buffer_max_size=70
innodb_doublewrite=0 # corruption risk

Hãy tưởng tượng hầu hết mọi sự kết hợp hầu như có thể, tôi đã thử tất cả.

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
xvda              0.50         0.00        19.00          0         76
xvdg            102.50     13120.00         0.00      52480          0
xvdh           1381.50     19708.00     30984.00      78832     123936
xvdf              0.00         0.00         0.00          0          0
nvme0n1         222.00         0.00     10957.00          0      43828

Đĩa duy nhất có liên quan ở đây là nvme0n1, bạn có thể thấy hiệu suất ghi hiện tại bằng cách sử dụng chèn đa luồng.

| InnoDB |      | 
=====================================
2018-07-22 06:42:31 0x7fe7341c9700 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 39 seconds
-----------------
BACKGROUND THREAD
-----------------
srv_master_thread loops: 4883 srv_active, 0 srv_shutdown, 1061 srv_idle
srv_master_thread log flush and writes: 5944
----------
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 2215493
OS WAIT ARRAY INFO: signal count 3968391
RW-shared spins 0, rounds 6388873, OS waits 1674234
RW-excl spins 0, rounds 34932124, OS waits 431565
RW-sx spins 13782, rounds 169207, OS waits 2879
Spin rounds per wait: 6388873.00 RW-shared, 34932124.00 RW-excl, 12.28 RW-sx
------------
TRANSACTIONS
------------
Trx id counter 1036891
Purge done for trx's n:o < 1036891 undo n:o < 0 state: running but idle
History list length 53
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 422106005755512, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
---TRANSACTION 422106005754696, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
--------
FILE I/O
--------
I/O thread 0 state: waiting for completed aio requests (insert buffer thread)
I/O thread 1 state: waiting for completed aio requests (log thread)
I/O thread 2 state: waiting for completed aio requests (read thread)
I/O thread 3 state: waiting for completed aio requests (read thread)
I/O thread 4 state: waiting for completed aio requests (read thread)
I/O thread 5 state: waiting for completed aio requests (read thread)
I/O thread 6 state: waiting for completed aio requests (read thread)
I/O thread 7 state: waiting for completed aio requests (read thread)
I/O thread 8 state: waiting for completed aio requests (read thread)
I/O thread 9 state: waiting for completed aio requests (read thread)
I/O thread 10 state: waiting for completed aio requests (write thread)
I/O thread 11 state: waiting for completed aio requests (write thread)
I/O thread 12 state: waiting for completed aio requests (write thread)
I/O thread 13 state: waiting for completed aio requests (write thread)
I/O thread 14 state: waiting for completed aio requests (write thread)
I/O thread 15 state: waiting for completed aio requests (write thread)
I/O thread 16 state: waiting for completed aio requests (write thread)
I/O thread 17 state: waiting for completed aio requests (write thread)
Pending normal aio reads: [0, 0, 0, 0, 0, 0, 0, 0] , aio writes: [0, 0, 0, 0, 0, 0, 0, 0] ,
 ibuf aio reads:, log i/o's:, sync i/o's:
Pending flushes (fsync) log: 0; buffer pool: 0
263597 OS file reads, 2045302 OS file writes, 161983 OS fsyncs
0.00 reads/s, 0 avg bytes/read, 282.56 writes/s, 28.08 fsyncs/s
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 1, free list len 1134, seg size 1136, 0 merges
merged operations:
 insert 0, delete mark 0, delete 0
discarded operations:
 insert 0, delete mark 0, delete 0
Hash table size 4425293, node heap has 1 buffer(s)
Hash table size 4425293, node heap has 4113 buffer(s)
Hash table size 4425293, node heap has 1 buffer(s)
Hash table size 4425293, node heap has 41738 buffer(s)
Hash table size 4425293, node heap has 1 buffer(s)
Hash table size 4425293, node heap has 9223 buffer(s)
Hash table size 4425293, node heap has 1 buffer(s)
Hash table size 4425293, node heap has 5900 buffer(s)
7968.05 hash searches/s, 13692.47 non-hash searches/s
---
LOG
---
Log sequence number 185044128669
Log flushed up to   185044077028
Pages flushed up to 185040571130
Last checkpoint at  185017989085
0 pending log flushes, 0 pending chkp writes
37148 log i/o's done, 6.79 log i/o's/second
----------------------
BUFFER POOL AND MEMORY
----------------------
Total large memory allocated 17649631232
Dictionary memory allocated 419728
Buffer pool size   1048576
Free buffers       8032
Database pages     979545
Old database pages 361426
Modified db pages  275
Percent of dirty pages(LRU & free pages): 0.028
Max dirty pages percent: 75.000
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 817, not young 38547
0.00 youngs/s, 0.00 non-youngs/s
Pages read 263539, created 1493647, written 2008209
0.00 reads/s, 204.33 creates/s, 275.76 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: 979545, unzip_LRU len: 0
I/O sum[116336]:cur[0], unzip sum[0]:cur[0]
----------------------
INDIVIDUAL BUFFER POOL INFO
----------------------
---BUFFER POOL 0
Buffer pool size   131072
Free buffers       1025
Database pages     122400
Old database pages 45162
Modified db pages  19
Percent of dirty pages(LRU & free pages): 0.015
Max dirty pages percent: 75.000
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 70, not young 6961
0.00 youngs/s, 0.00 non-youngs/s
Pages read 33027, created 186873, written 272369
0.00 reads/s, 19.72 creates/s, 32.72 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: 122400, unzip_LRU len: 0
I/O sum[14542]:cur[0], unzip sum[0]:cur[0]
---BUFFER POOL 1
Buffer pool size   131072
Free buffers       1007
Database pages     122444
Old database pages 45179
Modified db pages  26
Percent of dirty pages(LRU & free pages): 0.021
Max dirty pages percent: 75.000
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 74, not young 9194
0.00 youngs/s, 0.00 non-youngs/s
Pages read 32952, created 187093, written 242787
0.00 reads/s, 22.49 creates/s, 28.87 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: 122444, unzip_LRU len: 0
I/O sum[14542]:cur[0], unzip sum[0]:cur[0]
---BUFFER POOL 2
Buffer pool size   131072
Free buffers       1023
Database pages     122421
Old database pages 45170
Modified db pages  14
Percent of dirty pages(LRU & free pages): 0.011
Max dirty pages percent: 75.000
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 45, not young 177
0.00 youngs/s, 0.00 non-youngs/s
Pages read 32936, created 186494, written 236773
0.00 reads/s, 23.97 creates/s, 30.69 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: 122421, unzip_LRU len: 0
I/O sum[14542]:cur[0], unzip sum[0]:cur[0]
---BUFFER POOL 3
Buffer pool size   131072
Free buffers       994
Database pages     122454
Old database pages 45182
Modified db pages  39
Percent of dirty pages(LRU & free pages): 0.032
Max dirty pages percent: 75.000
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 173, not young 254
0.00 youngs/s, 0.00 non-youngs/s
Pages read 33012, created 185887, written 258491
0.00 reads/s, 26.49 creates/s, 39.49 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: 122454, unzip_LRU len: 0
I/O sum[14542]:cur[0], unzip sum[0]:cur[0]
---BUFFER POOL 4
Buffer pool size   131072
Free buffers       1006
Database pages     122449
Old database pages 45180
Modified db pages  46
Percent of dirty pages(LRU & free pages): 0.037
Max dirty pages percent: 75.000
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 120, not young 12679
0.00 youngs/s, 0.00 non-youngs/s
Pages read 32937, created 187265, written 249442
0.00 reads/s, 29.79 creates/s, 39.18 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: 122449, unzip_LRU len: 0
I/O sum[14542]:cur[0], unzip sum[0]:cur[0]
---BUFFER POOL 5
Buffer pool size   131072
Free buffers       1012
Database pages     122452
Old database pages 45182
Modified db pages  25
Percent of dirty pages(LRU & free pages): 0.020
Max dirty pages percent: 75.000
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 202, not young 5093
0.00 youngs/s, 0.00 non-youngs/s
Pages read 32867, created 187025, written 253352
0.00 reads/s, 30.69 creates/s, 40.20 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: 122452, unzip_LRU len: 0
I/O sum[14542]:cur[0], unzip sum[0]:cur[0]
---BUFFER POOL 6
Buffer pool size   131072
Free buffers       1021
Database pages     122423
Old database pages 45171
Modified db pages  13
Percent of dirty pages(LRU & free pages): 0.011
Max dirty pages percent: 75.000
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 64, not young 2573
0.00 youngs/s, 0.00 non-youngs/s
Pages read 32909, created 187403, written 243809
0.00 reads/s, 25.82 creates/s, 31.64 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: 122423, unzip_LRU len: 0
I/O sum[14542]:cur[0], unzip sum[0]:cur[0]
---BUFFER POOL 7
Buffer pool size   131072
Free buffers       944
Database pages     122502
Old database pages 45200
Modified db pages  93
Percent of dirty pages(LRU & free pages): 0.075
Max dirty pages percent: 75.000
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 69, not young 1616
0.00 youngs/s, 0.00 non-youngs/s
Pages read 32899, created 185607, written 251186
0.00 reads/s, 25.36 creates/s, 32.97 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: 122502, unzip_LRU len: 0
I/O sum[14542]:cur[0], unzip sum[0]:cur[0]
--------------
ROW OPERATIONS
--------------
0 queries inside InnoDB, 0 queries in queue
0 read views open inside InnoDB
Process ID=21173, Main thread ID=140612953028352, state: sleeping
Number of rows inserted 68789564, updated 0, deleted 0, read 0
10659.42 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.00 reads/s
Number of system rows inserted 0, updated 0, deleted 0, read 0
0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.00 reads/s
----------------------------
END OF INNODB MONITOR OUTPUT

Mysql hoạt động như thể nó có giới hạn IO nội bộ khoảng 25 MB ghi / giây.

Tôi biết tôi đã không thêm điểm chuẩn, tôi đã thức được 20 giờ liên tục và không có kết quả trong tay. Xin vui lòng chỉ tin tôi các đĩa là cực kỳ nhanh chóng. Bộ nhớ được phân bổ cho mysql không đóng vai trò gì, tôi đã tăng từ 1 GB lên 50 .. không có gì khác biệt.

Tôi đã dành nửa tuần và 16 giờ để thực hiện việc này, tôi đang ở cuối trí thông minh của mình.
Điều cuối cùng tôi có thể nghĩ đến là mua một cơ sở dữ liệu thương mại như Oracle nhưng đó là một cơn ác mộng khác phải trải qua.

Chỉ có một lần tôi có tốc độ chấp nhận được: Khi nhập tệp IBD "RAW" sau đó sử dụng NHẬP TABLESPACE. Nhưng điều đó đòi hỏi nhiều giờ LOCK trên cơ sở dữ liệu nguồn để có được ảnh chụp nhanh nhị phân, sau đó sao chép nó (mất thời gian qua mạng) và sau đó nhập lại tất cả.
Hiệu suất NHẬP KHẨU TABLESPACE đã ổn, khoảng 600 MB / giây
Nhìn chung, đây là tốc độ nhanh nhất nhưng không thể sử dụng được cho sự nghiệp của tôi.

Đây là bảng:

    CREATE TABLE `eval` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `intern_id` varchar(256) COLLATE utf8_bin DEFAULT NULL,
  `first_name` varchar(64) COLLATE utf8_bin DEFAULT NULL,
  `last_name` varchar(64) COLLATE utf8_bin DEFAULT NULL,
  `middle_name` varchar(64) COLLATE utf8_bin DEFAULT NULL,
  `location` varchar(196) COLLATE utf8_bin DEFAULT NULL,
  `i` varchar(128) COLLATE utf8_bin DEFAULT NULL,
  `e` varchar(256) COLLATE utf8_bin DEFAULT NULL,
  `country_code` varchar(4) COLLATE utf8_bin DEFAULT NULL,
  `country_name` varchar(64) COLLATE utf8_bin DEFAULT NULL,
  `state_name` varchar(64) COLLATE utf8_bin DEFAULT NULL,
  `city_name` varchar(64) COLLATE utf8_bin DEFAULT NULL,
  `education` varchar(256) COLLATE utf8_bin DEFAULT NULL,
  `num_c` smallint(6) DEFAULT NULL,
  `num_j` smallint(6) DEFAULT NULL,
  `j_t` varchar(256) COLLATE utf8_bin DEFAULT NULL,
  `c_name` varchar(256) COLLATE utf8_bin DEFAULT NULL,
  `e_a` varchar(256) COLLATE utf8_bin DEFAULT NULL,
  `flag_existent` tinyint(4) DEFAULT NULL COMMENT '1/0',
  `public_p_u` varchar(256) COLLATE utf8_bin DEFAULT NULL,
  `c_intern_id` varchar(256) COLLATE utf8_bin DEFAULT NULL,
  `unmatched_facts` varchar(2048) COLLATE utf8_bin DEFAULT NULL,
  `dt_snapshot` datetime DEFAULT NULL,
  `change_small` tinyint(4) DEFAULT NULL,
  `change_significant` tinyint(4) DEFAULT NULL,
  `j_t_auth` varchar(256) COLLATE utf8_bin DEFAULT NULL COMMENT 'sure about it',
  `c_name_auth` varchar(256) COLLATE utf8_bin DEFAULT NULL COMMENT 'sure about it',
  `c_intern_id_guess` varchar(256) COLLATE utf8_bin DEFAULT NULL,
  `ut_created` int(11) DEFAULT NULL,
  `reserve_int_2` int(11) DEFAULT NULL,
  `reserve_vc1` varchar(256) COLLATE utf8_bin DEFAULT NULL,
  `reserve_vc2` varchar(256) COLLATE utf8_bin DEFAULT NULL,
  `reserve_vc_3` varchar(256) COLLATE utf8_bin DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `intern_id` (`intern_id`),
  KEY `location` (`location`),
  KEY `country_name` (`country_name`),
  KEY `country_name_location_notnull` (`country_name`(1),`location`(1)),
  KEY `location_country_name` (`location`,`country_name`(1)),
  KEY `location_null_country_name` (`location`(1),`country_name`),
  KEY `dt_snapshot` (`dt_snapshot`),
  KEY `state_name` (`state_name`),
  KEY `city_name` (`city_name`),
  KEY `c_name` (`c_name`),
  KEY `c_name_auth` (`c_name_auth`),
  KEY `j_t` (`j_t`)
) ENGINE=InnoDB AUTO_INCREMENT=19883676 DEFAULT CHARSET=utf8 COLLATE=utf8_bin |

Tôi đã thử nghiệm nhập mà không có chỉ mục, chỉ có khóa chính và chỉ mục đầy đủ. Về cơ bản tốc độ luôn giống nhau. Sự khác biệt duy nhất là tốc độ IO của đĩa tăng với nhiều chỉ mục hơn, nhưng các hàng / giây vẫn giữ nguyên.

Cập nhật
Nhập bảng bằng cách sử dụng "NHẬP TABLESPACE" hoạt động nhanh (phương pháp khủng khiếp, yêu cầu xóa các tệp IBD và bất kỳ gián đoạn nào sẽ làm hỏng bảng cộng với tôi phải khóa cơ sở dữ liệu nguồn chính trong một giờ)
Phương pháp này cho phép khoảng 350k hàng / giây.

Bây giờ tôi đang chơi với cơ sở dữ liệu được tải trên máy chủ, sử dụng các CHỌN đơn giản cần quét toàn bộ. (tính (*) trong đó xxx không phải là null)
Cơ sở dữ liệu thực hiện quét toàn bộ ở tốc độ 100mb / giây!
Có một nút cổ chai giới hạn 90% tốc độ có thể.

Cập nhật:
Tôi đã cố gắng khắc phục nút cổ chai hiệu năng QUERY bằng cách thực hiện 5 phiên cơ sở dữ liệu, thực hiện truy vấn CHỌN trên cùng một bảng cơ sở dữ liệu nhưng phân tách các truy vấn bằng ID. 1-10000000, 1000000-2000000, 300000-4000000, v.v ... Mỗi phiên duy nhất tăng tải đĩa lên 100mb / giây.
Vì vậy, cơ sở dữ liệu nhanh hơn 5 lần khi sử dụng 5 truy vấn / phiên chọn đồng thời so với một truy vấn.
Nhưng thực sự điều này nên SLOWER nhiều. Điều đó có nghĩa là rất nhiều IO ngẫu nhiên được yêu cầu, IO ít tuần tự hơn có thể vì 5 luồng truy cập cùng một tệp ở các vị trí khác nhau một cách nhanh chóng.

Tôi gặp vấn đề tương tự với WRITE, viết 5 lần vào cơ sở dữ liệu SAME nhanh hơn 5 lần so với viết 1 lần cho nó, tuy nhiên nó đã bão hòa ở tốc độ rất chậm (1-5% topspeed)

1 Chọn tại bàn:

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1.21    0.00    0.35   10.66    0.26   87.52

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
xvda              0.67         0.00        21.33          0         64
xvdg              0.00         0.00         0.00          0          0
xvdh            134.33         5.33       721.33         16       2164
xvdf              4.67         0.00        25.33          0         76
nvme0n1        7032.00    112512.00         0.00     337536          0

5 Chọn trên bảng CÙNG tại các vị trí khóa chính khác nhau:

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1.98    0.00    0.63   43.35    0.77   53.28
    Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
    xvda              0.67         0.00        22.67          0         68
    xvdg              0.00         0.00         0.00          0          0
    xvdh            111.33        13.33       598.67         40       1796
    xvdf              0.00         0.00         0.00          0          0
    nvme0n1       30051.33    480821.33         0.00    1442464          0

Kết luận mới nhất Có vẻ như vấn đề này là một lỗ hổng bên trong MySQL cũng như MariaDB và có lẽ là do thiết kế luồng đơn.
Dường như với số lượng cột tăng lên, hiệu suất tối đa bị giảm, mỗi cột gây ra một số chi phí trì hoãn.
InnoDb / XtraDb dường như không phải là vấn đề. Đó hiện là lời giải thích duy nhất tôi có thể tìm thấy, không có giải pháp nào khả thi ngoại trừ việc viết mã tùy chỉnh đa luồng.

tất cả các biến toàn cục và hiển thị trạng thái:
https://paste.ee/p/Yk1Le

Ở đây toàn bộ tập tin cấu hình (biến thể hiện tại, tôi đã thử tất cả những gì tôi nghĩ)

[client]
port            = 3316
socket          = /maincache/share/mysqld.sock


[mysqld_safe]
socket          = /maincache/share/mysqld.sock
nice            = 0

[mysqld]
pid-file        = /var/run/mysqld/mysqld.pid
socket          = /maincache/share/mysqld.sock
port            = 3316
basedir         = /usr
datadir         = /var/lib/mysql
tmpdir          = /instance_store/tmp
lc_messages_dir = /usr/share/mysql
lc_messages     = en_US
skip-external-locking
bind-address            = 127.0.0.1
max_connections         = 100
connect_timeout         = 5
wait_timeout            = 600
max_allowed_packet      = 160M
thread_cache_size       = 128
sort_buffer_size        = 4M
bulk_insert_buffer_size = 16M
tmp_table_size          = 16M
max_heap_table_size     = 16M
join_buffer_size=32k
sort_buffer_size=32k
myisam_recover_options = BACKUP
key_buffer_size         = 6M
table_open_cache        = 1000
table_open_cache_instances = 8
myisam_sort_buffer_size = 16M
concurrent_insert       = 2
read_buffer_size        = 2M
read_rnd_buffer_size    = 1M
query_cache_limit               = 16M
query_cache_size                = 256M
log_error = /maincache/share/cluster/mysql_error.log
slow_query_log_file     = /var/log/mysql/mariadb-slow.log
long_query_time = 10

expire_logs_days        = 10
max_binlog_size         = 100M
default_storage_engine  = InnoDB
innodb_force_recovery=1
innodb_buffer_pool_size = 10G
innodb_buffer_pool_chunk_size=512M
innodb_file_per_table   = 1
innodb_open_files       = 600
innodb_flush_method     = O_DIRECT_NO_FSYNC
innodb_log_file_size    = 512M
innodb_io_capacity=5000
innodb_io_capacity_max=80000
innodb_flush_neighbors=0
innodb_write_io_threads=64
innodb_read_io_threads=64
innodb_change_buffer_max_size=70
innodb_buffer_pool_instances=128
innodb_thread_concurrency=144

[galera]

[mysqldump]
quick
quote-names
max_allowed_packet      = 16M

[mysql]

[isamchk]
key_buffer              = 16M

Máy chủ có 64GB ram nhưng tôi đã giới hạn máy chủ mysql ở mức 10 GB trong biến thể này. Nó cho thấy hoàn toàn không có sự khác biệt trong hiệu suất, bất kể bộ đệm innodb. Máy chủ không hoạt động, trong khi chèn, nó không hoạt động 80-90% (IO / cpu) và tất nhiên không được hoán đổi.


Thảo luận về câu hỏi này đã được chuyển sang trò chuyện .
Paul White 9

Câu trả lời:


2

Các đề xuất để xem xét cho phần my.cnf [mysqld] của bạn dựa trên thông tin hiển thị được cung cấp. Toàn bộ khối sẽ đi vào KẾT THÚC của [mysqld] và XÓA bất kỳ BIẾN ĐỔI CÙNG NÀO xuất hiện cao hơn trong phần để tránh xung đột về các yêu cầu.

innodb_io_capacity=40000  # from 5000 to open the door for NVME speed
read_rnd_buffer_size=256K  # from 1M to reduce handler_read_rnd_next RPS
innodb_lru_scan_depth=128  # from 1024 to conserve CPU every second
innodb_adaptive_max_sleep_delay=10000 # from 150000 for 1 sec sleep delay
innodb_flushing_avg_loops=4  # from 30 for reduce the loop delay
innodb_thread_concurrency=0  # from 144 see dba.stackexhange Question 5666
max_seeks_for_key=32  # to limit optimizer to nn vs ~ 4 Billion possible
max_write_locks_count=16  # to allow RD after nn lcks vs up to 4 Billion lcks
thread_concurrency=30  # from 10 for additional conc - may be DEPR
innodb_buffer_pool_instances=8  # from 64 see REFMAN for innodb_lru_scan_depth details
innodb_log_file_size=6G  # from ~ 512M to reduce log rotation
innodb_log_buffer_size=3G  # from 16M for ~ 30 minutes buffering
query_cache_type=OFF  # from ON no need to waste CPU for mgmt
query_cache_size=0  # from ~256M to conserve RAM and CPU cycles
slow_query_log=ON  # from OFF always good to have ON

Chiến lược sử dụng RAM trong khi bạn đang tải hơn 10.000 hàng mỗi giây

Tổng RAM = 64GB, cho phép mysqld lên tới 48GB (~ 75%)

Trong khi bạn đang tải khối lượng lớn này,

innodb_buffer_pool_size=30G  # for 62.5% of your 48G
innodb_change_buffer_max_size=50  # for 50% to have best insert rate per second

khi tải xong

SET GLOBAL innodb_change_buffer_max_size = 15 # cho 15% dành riêng cho các yêu cầu bảo trì thường xuyên;

và bạn sẽ giải quyết dữ liệu điển hình cần thiết có sẵn trong nhóm bộ đệm innodb với thời gian hoạt động hợp lý.

Để có thêm đề xuất, hãy xem hồ sơ của tôi, Hồ sơ mạng để biết thông tin liên hệ, bao gồm ID SKYPE để liên lạc, XIN VUI LÒNG. Cảm ơn


@john Cảm ơn bạn đã upvote của bạn, bạn vẫn có thể Chấp nhận câu trả lời của tôi nếu bạn muốn. Xin hãy giúp tôi và xem hồ sơ của tôi, hồ sơ mạng để biết thông tin liên hệ, truy cập trang web của tôi và đăng bài đánh giá miễn phí TOP 10 đề xuất biến toàn cầu của tôi. Bạn KHÔNG cần phải tạo tài khoản hoặc Đăng nhập để đăng bài Đánh giá cho chúng tôi. Cảm ơn
Wilson Hauck

@john Ví dụ MySQL của bạn hoạt động như thế nào trong những ngày này? Đã được một thời gian kể từ khi đề xuất được đưa ra. Vui lòng xem hồ sơ của tôi, hồ sơ mạng để biết thông tin liên hệ và liên lạc bằng Skype hoặc email, xin vui lòng. Cảm ơn
Wilson Hauck
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.