Ich führe dies auf einem 8-Core-Server mit NVME-Speicher (2 TB) und 64 GB RAM aus.
Die Festplatten sind höllisch schnell, 1,1 GB / s seq und 70-100 k IOPS Vollduplex.
Weil ich mit MySQL 5.7 eine so schreckliche Leistung hatte, habe ich Mariadb 10.3.8 auf einem schlanken Docker-Container installiert.
Insgesamt habe ich Tabellen zu schreiben, die 2 TB und eine Milliarde Zeilen groß sind. Aber lassen Sie mich klarstellen: Diese Geschwindigkeitsleistung tritt auf einer leeren Festplatte in den ersten paar tausend Zeilen auf, sie hängt nicht mit einer großen Tabelle zusammen.
Ich habe in der vergangenen Woche Tag und Nacht ungefähr 50 Stunden Arbeit investiert , jede Dokumentationsseite gelesen, die ich finden konnte, und Hunderte von Leitfäden und Fragen auf verschiedenen Plattformen.
Ich habe alles ausprobiert, in fast jeder Kombination, die man sich vorstellen kann.
Ich habe es versucht, reinen Speicher gepuffert, reine Festplatte gepuffert, mit und ohne große Protokolle, Protokollpuffer, verschiedene Löschmethoden, kein Löschen, all diese Einstellungen, die Sie sich vorstellen können.
Ich habe den Import getestet mit: mydumper, mysql console, mysqlimport, load data infile, PHP-Einfügungen, Multithread-PDO-Skripten, die ich geschrieben habe.
Ich habe Tabellen mit und ohne Index getestet , nur primär indiziert.
Ich habe versucht, mit und ohne TRANSAKTIONEN zu importieren , habe einzeilige und mehrzeilige INSERTs ausprobiert.
Ich habe verschiedene Tabellentypen ausprobiert, normalerweise 20 bis 30 Spalten, die hauptsächlich Varchare und einige Datumsangaben enthalten.
Die Leistung in einem einzelnen Thread beträgt 3-5k Zeilen / Sekunde und Multithread (lächerlich ..) 10-25k / Sekunde. Die CPU und die Festplatte sind meistens die ganze Zeit im Leerlauf. Iostat zeigt eine Schreibleistung von 3 bis 20 MB / s, normalerweise zwischen 7 und 12 MB. Je nachdem welche Einstellungen ich versuche.
Etwa 100-mal langsamer als es funktionieren sollte, ist nichts offensichtlich, was es zurückhält.
Das ist die aktuelle Konfiguration:
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 riskStellen Sie sich fast jede praktisch mögliche Kombination vor, ich habe alles versucht.
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 43828Die einzige relevante Festplatte hier ist nvme0n1. Sie können die aktuelle Schreibleistung mithilfe der Multithread-Einfügung anzeigen.
| 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 OUTPUTMySQL verhält sich so, als hätte es ein internes E / A-Limit von ca. 25 MB Schreib- / Sekunde.
Ich weiß, dass ich keine Benchmarks hinzugefügt habe. Ich bin jetzt seit 20 Stunden in Folge auf und habe keine Ergebnisse zur Hand. Bitte glauben Sie mir einfach, die Festplatten sind extrem schnell. Der MySQL zugewiesene Speicher spielt keine Rolle, ich bin von 1 GB auf 50 gestiegen. Kein Unterschied.
Ich habe eine halbe Woche und 16 Stunden Schichten verbracht, um dies zum Laufen zu bringen. Ich bin am Ende meines Verstandes.
Das Letzte, woran ich denken kann, ist, eine kommerzielle Datenbank wie Oracle zu kaufen, aber das ist ein weiterer Albtraum.
Nur einmal hatte ich eine akzeptable Geschwindigkeit:
Beim Importieren einer IBD-Datei "RAW" dann mit IMPORT TABLESPACE. Dies erfordert jedoch viele Stunden LOCK in der Quellendatenbank, um einen binären Snapshot zu erhalten, ihn dann zu kopieren (dauert über das Netzwerk) und dann erneut zu importieren.
Die Leistung von IMPORT TABLESPACE selbst war in Ordnung, ungefähr 600 MB / s.
Insgesamt war dies die schnellste, aber für meine Sache unbrauchbar.
Hier die Tabelle:
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 |Ich habe den Import ohne Indizes getestet, nur mit Primärschlüssel und vollständigen Indizes. Grundsätzlich ist die Geschwindigkeit immer gleich. Der einzige Unterschied besteht darin, dass die E / A-Geschwindigkeit der Festplatte mit mehr Indizes zunimmt, die Zeilen / Sekunde jedoch gleich bleiben.
Update Das
Importieren der Tabelle mit "IMPORT TABLESPACE" hat schnell funktioniert (schreckliche Methode, erfordert das Löschen von IBD-Dateien und jede Unterbrechung wird die Tabelle beschädigen und ich muss die primäre Quellendatenbank für eine Stunde sperren)
Diese Methode erlaubte ungefähr 350.000 Zeilen / Sekunde.
Jetzt spielte ich mit der geladenen Datenbank auf dem Server und verwendete einfache SELECTS, die einen Fulltable-Scan benötigen. (count (*) wobei xxx nicht null ist)
Die Datenbank führt den Fulltable-Scan nur mit 100 MB / Sekunde durch!
Es gibt einen Engpass, der 90% der möglichen Geschwindigkeit einschränkt.
Update:
Ich habe versucht, den QUERY-Leistungsengpass zu umgehen, indem ich 5 Datenbanksitzungen durchgeführt habe, eine SELECT-Abfrage für dieselbe Datenbanktabelle durchgeführt und die Abfragen durch die ID getrennt habe. 1-10000000, 1000000-2000000, 300000-4000000 usw. Jede einzelne Sitzung erhöhte die Festplattenlast um 100 MB / s.
Daher war die Datenbank mit 5 gleichzeitigen Auswahlabfragen / -sitzungen fünfmal schneller als mit einer Abfrage.
Aber eigentlich sollte das viel langsamer sein. Dies bedeutet, dass viele zufällige E / A erforderlich sind und weniger sequentielle E / A möglich sind, da die 5 Threads schnell an verschiedenen Positionen auf dieselbe Datei zugreifen.
Ich hatte ähnliche Probleme mit WRITE. Das 5-fache Schreiben in die gleiche Datenbankdatei war 5-mal schneller als das 1-fache Schreiben, jedoch mit einer sehr langsamen Geschwindigkeit (1-5% der Höchstgeschwindigkeit) gesättigt.
1 Wählen Sie am Tisch:
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 05 Wählen Sie in der Tabelle SAME an verschiedenen Primärschlüsselpositionen Folgendes aus:
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 0Neueste Schlussfolgerung
Es scheint, dass dieses Problem sowohl in MySQL als auch in MariaDB ein Fehler ist und wahrscheinlich durch Single-Threaded-Design verursacht wird.
Es scheint, dass mit zunehmender Anzahl von Spalten die maximale Leistung verringert wird und jede Spalte einen gewissen Verzögerungsaufwand verursacht.
InnoDb / XtraDb scheint nicht das Problem zu sein. Dies ist derzeit die einzige Erklärung, die ich finden konnte. Es ist keine Lösung möglich, außer das Schreiben von benutzerdefiniertem Multithread-Code.
alle globalen Variablen und Status anzeigen :
https://paste.ee/p/Yk1Le
Hier die ganze Konfigurationsdatei (die aktuelle Variante habe ich alles versucht was ich denke)
[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 = 16MDer Server hat 64 GB RAM, aber ich habe den MySQL-Server in dieser Variante auf 10 GB beschränkt. Es zeigte absolut keinen Unterschied in der Leistung, unabhängig vom Innodb-Puffer. Der Server ist inaktiv, auch während des Einfügens ist er zu 80-90% inaktiv (IO / CPU) und wird natürlich nicht ausgetauscht.
Antworten:
Vorschläge, die Sie für Ihren Abschnitt my.cnf [mysqld] basierend auf den bereitgestellten sichtbaren Informationen berücksichtigen sollten. Gesamter Block, um am Ende von [mysqld] zu gehen und alle gleichnamigen Variablen zu entfernen, die höher im Abschnitt erscheinen, um Konflikte bei Anforderungen zu vermeiden.
RAM verwendet Strategie, während Sie mehr als 10.000 Zeilen pro Sekunde laden
Gesamt-RAM = 64 GB, erlauben Sie mysqld bis zu 48 GB (~ 75%)
Während Sie dieses hohe Volumen laden,
wenn das Laden abgeschlossen ist,
SET GLOBAL innodb_change_buffer_max_size = 15 # für 15% für routinemäßige Wartungsanforderungen;
und Sie werden sich in einer angemessenen Betriebszeit mit den typischen Daten befassen, die im innodb-Pufferpool verfügbar sind.
Weitere Vorschläge finden Sie in meinem Profil, Netzwerkprofil für Kontaktinformationen, einschließlich SKYPE-ID, um Kontakt aufzunehmen. BITTE. Vielen Dank
quelle