Funktionen der InnoDB INSERT-Leistung

Hallo, ich verwende die neueste Version von Percona Server.

Serverversion: 5.5.24-55 Percona Server (GPL), Version 26.0

Ich habe eine 10-CPU-Box mit diesen Eigenschaften.

processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 16
model           : 9
model name      : AMD Opteron(tm) Processor 6128
stepping        : 1
microcode       : 0x10000d9
cpu MHz         : 800.000
cache size      : 512 KB

Es hat SSD und 64 GB RAM. Innodb ist ca. 10 GB groß, daher ist innodb_buffer_pool_size auf 10 GB festgelegt.

Ich habe eine Tabelle, die wie folgt ist:

create table TODAY
( symbol_id       integer not null
, openp           decimal(10,4)
, high            decimal(10,4)
, low             decimal(10,4)
, last            decimal(10,4) not null
, volume          int
, last_updated      datetime        -- the time of the last quote update
, prev        decimal(10,4) null
, PRIMARY KEY ( symbol_id )
)

Wenn ich mit einer leeren Tabelle beginne und 23.000 Zeilen einfüge, dauert es ungefähr 10 Sekunden. Wenn ich anschließend ein Update durchführe, bei dem jede Spalte jeder Zeile aktualisiert wird (außer natürlich symbol_id), dauert es etwas länger als 11-12 Sekunden.

Ist dies generell die Schreibleistung, die ich von Innodb erwarten sollte? Gibt es Vorschläge zur Verbesserung dieser Leistung? Das Aktualisieren von 23.000 Zeilen ist ein Extremfall, da ich normalerweise während eines Handelstages alle 5 Sekunden ca. 1000 Zeilen aktualisieren muss (das ist also die realistischere Einschränkung, mit der ich mich befasse).

Andere relevante mysql.cnf-Einstellungen, die ich geändert habe:

innodb_buffer_pool_size = 10G
innodb_log_file_size    = 64M
innodb_flush_log_at_trx_commit = 2
innodb_flush_method = O_DIRECT

Übrigens, wenn ich anstelle von Innodb die Tabelle mit ENGINE = MEMORY erstelle, dauert das Einfügen ungefähr 4 Sekunden, das Update 6 Sekunden.

Viele TIA, wenn mir jemand helfen kann, herauszufinden, was der Benchmark für diese Art von Abfrage ist, oder mir helfen, die Zeit zu verbessern.

Don

PS volle Innodb Einstellungen.

mysql> zeige globale Variablen wie 'innodb%';
+ --------------------------------------- + ----- ------------------- +
| Variablenname | Wert |
+ --------------------------------------- + ----- ------------------- +
| innodb_adaptive_flushing | EIN |
| innodb_adaptive_flushing_method | Schätzung |
| innodb_adaptive_hash_index | EIN |
| innodb_adaptive_hash_index_partitions | 1 |
| innodb_additional_mem_pool_size | 8388608 |
| innodb_autoextend_increment | 8 |
| innodb_autoinc_lock_mode | 1 |
| innodb_blocking_buffer_pool_restore | AUS |
| innodb_buffer_pool_instances | 1 |
| innodb_buffer_pool_restore_at_startup | 0 |
| innodb_buffer_pool_shm_checksum | EIN |
| innodb_buffer_pool_shm_key | 0 |
| innodb_buffer_pool_size | 10737418240 |
| innodb_change_buffering | alle |
| innodb_checkpoint_age_target | 0 |
| innodb_checksums | EIN |
| innodb_commit_concurrency | 0 |
| innodb_concurrency_tickets | 500 |
| innodb_corrupt_table_action | behaupten |
| innodb_data_file_path | ibdata1: 10M: autoextend |
| innodb_data_home_dir | |
| innodb_dict_size_limit | 0 |
| innodb_doublewrite | EIN |
| innodb_doublewrite_file | |
| innodb_fake_changes | AUS |
| innodb_fast_checksum | AUS |
| innodb_fast_shutdown | 1 |
| innodb_file_format | Antilope |
| innodb_file_format_check | EIN |
| innodb_file_format_max | Antilope |
| innodb_file_per_table | AUS |
| innodb_flush_log_at_trx_commit | 2 |
| innodb_flush_method | O_DIRECT |
| innodb_flush_neighbor_pages | Bereich |
| innodb_force_load_corrupted | AUS |
| innodb_force_recovery | 0 |
| innodb_ibuf_accel_rate | 100 |
| innodb_ibuf_active_contract | 1 |
| innodb_ibuf_max_size | 5368692736 |
| innodb_import_table_from_xtrabackup | 0 |
| innodb_io_capacity | 200 |
| innodb_kill_idle_transaction | 0 |
| innodb_large_prefix | AUS |
| innodb_lazy_drop_table | 0 |
| innodb_lock_wait_timeout | 50 |
| innodb_locks_unsafe_for_binlog | AUS |
| innodb_log_block_size | 512 |
| innodb_log_buffer_size | 8388608 |
| innodb_log_file_size | 67108864 |
| innodb_log_files_in_group | 2 |
| innodb_log_group_home_dir | ./ |
| innodb_max_dirty_pages_pct | 75 |
| innodb_max_purge_lag | 0 |
| innodb_mirrored_log_groups | 1 |
| innodb_old_blocks_pct | 37 |
| innodb_old_blocks_time | 0 |
| innodb_open_files | 300 |
| innodb_page_size | 16384 |
| innodb_purge_batch_size | 20 |
| innodb_purge_threads | 1 |
| innodb_random_read_ahead | AUS |
| innodb_read_ahead | linear |
| innodb_read_ahead_threshold | 56 |
| innodb_read_io_threads | 4 |
| innodb_recovery_stats | AUS |
| innodb_recovery_update_relay_log | AUS |
| innodb_replication_delay | 0 |
| innodb_rollback_on_timeout | AUS |
| innodb_rollback_segments | 128 |
| innodb_show_locks_held | 10 |
| innodb_show_verbose_locks | 0 |
| innodb_spin_wait_delay | 6 |
| innodb_stats_auto_update | 1 |
| innodb_stats_method | nulls_equal |
| innodb_stats_on_metadata | EIN |
| innodb_stats_sample_pages | 8 |
| innodb_stats_update_need_lock | 1 |
| innodb_strict_mode | AUS |
| innodb_support_xa | EIN |
| innodb_sync_spin_loops | 30 |
| innodb_table_locks | EIN |
| innodb_thread_concurrency | 0 |
| innodb_thread_concurrency_timer_based | AUS |
| innodb_thread_sleep_delay | 10000 |
| innodb_use_global_flush_log_at_trx_commit | EIN |
| innodb_use_native_aio | EIN |
| innodb_use_sys_malloc | EIN |
| innodb_use_sys_stats_table | AUS |
| innodb_version | 1.1.8-rel26.0 |
| innodb_write_io_threads | 4 |
+ --------------------------------------- + ----- ------------------- +
90 Zeilen im Satz (0,00 Sek.)

Ich habe numactl --hardware ausgeführt und hier ist die Ausgabe, die ich erhalten habe. Die Kommentare meines Administrators sind unten aufgeführt (in Bezug auf die Interpretation).

root @ prog: / data / mysql # numactl --hardware
verfügbar: 4 Knoten (0-3)
Knoten 0 cpus: 0 1 2 3
Knoten 0 Größe: 32766 MB
Knoten 0 frei: 21480 MB
Knoten 1 CPU: 4 5 6 7
Knoten 1 Größe: 32768 MB
Knoten 1 frei: 25285 MB
Knoten 2 cpus: 12 13 14 15
Knoten 2 Größe: 32768 MB
Knoten 2 frei: 20376 MB
Knoten 3 cpus: 8 9 10 11
Knoten 3 Größe: 32768 MB
Knoten 3 frei: 24898 MB
Knotenabstände:
Knoten 0 1 2 3
  0: 10 16 16 16
  1: 16 10 16 16
  2: 16 16 10 16
  3: 16 16 16 10

— Don Wool
quelle

Sie müssen Ihre InnoDB-Einstellungen in den folgenden Bereichen anpassen:

Lassen Sie InnoDB auf alle Ihre Kerne zugreifen
Erhöhen Sie innodb_buffer_pool_size bis 12G
Erhöhen Sie innodb_buffer_pool_instances bis 2 (Erster Lauf numactl --hardwaredie Anzahl der physischen CPUs zu bestimmen. Was jeder Anzahl von CPUs es berichtet, verwenden diese Zahl. Ich dies vor kurzem in gelernt Jeremy Cole Blog )
Erhöhen Sie die Größe der Protokolldatei ( innodb_log_file_size ) auf 2047M
unterstützt separate Tablespace-Dateien für einzelne InnoDB-Tabellen (enaled innodb_file_per_table )
Unterstützung entweder hoher Leistung oder hoher Haltbarkeit (ACID-Konformität)
- Hohe Leistung: innodb_flush_log_at_trx_commit auf 0 oder 2 gesetzt
- Hohe Haltbarkeit: innodb_flush_log_at_trx_commit auf 1 gesetzt (Standard)
- Erhöhen Sie die Größe von innodb_log_buffer_size in Verbindung mit der Anzahl der Transaktionen pro Sekunde (möglicherweise 32 Millionen ).
- Ihre aktuelle Einstellung für innodb_flush_log_at_trx_commit ist gut
- Ihre aktuelle Einstellung für innodb_flush_method ist gut
Erhöhen Sie innodb_read_io_threads bis 64
Erhöhen Sie innodb_write_io_threads bis 64
Erhöhen Sie innodb_io_capactity bis 10000

Hier sind meine früheren Beiträge zum Optimieren der InnoDB-Speicher-Engine

Ist die CPU-Leistung für einen Datenbankserver relevant? (26. April 2012)
Warum speichert InnoDB alle Datenbanken in einer Datei? (25. März 2012)
Multi Cores und MySQL Performance (20. September 2011)
Kann MySQL mehr als einen Kern verwenden? (12. September 2011)
Informationen zur Leistung von Single-Threaded- und Multithread-Datenbanken (26. Mai 2011)
Wie kann ich die MySQL-Innodb-Variable 'innodb_log_file_size' sicher ändern? (16. Februar 2011)
Wie können Sie MySQL auf eine hohe InnoDB-Arbeitslast einstellen? (12. Februar 2011)
Howto: Reinigen Sie eine MySQL-InnoDB-Speicher-Engine? (29. Oktober 2010)

— RolandoMySQLDBA
quelle

Danke für diese unglaublich nützliche Antwort !! Ich grüße dich. Muss ich mir Sorgen machen, dass das Protokoll zu groß wird? Mein Anliegen ist etwas, das Tkachenko über mysqlperformanceblog.com/2011/09/18/disaster-mysql-5-5-flushing geschrieben hat . Mir ist klar, dass ich auf Percona bin, also ist das vielleicht kein Problem. Aber ich möchte sicher sein, dass ich nicht auf ein Stall-Szenario stoße. Ich beschäftige mich mit dem Rest Ihrer Antwort ...

— Don Wool

In Bezug auf innodb_buffer_pool_instances habe ich eine 16-CPU-Box (ich hatte gedacht, es wäre 10). In Bezug auf numactl sagt mein Administrator: "Sie haben insgesamt 16 CPUs und vier RAM-Blöcke mit jeweils 32 GB. Jeder RAM-Block wird von vier CPUs als lokaler Speicher behandelt."

— Don Wool

Bitte führen Sie numactl --hardwaredie Ausgabe aus und veröffentlichen Sie sie in der Frage. Ich versuche, physische CPUs herauszufinden, und ich möchte sicherstellen, dass der Administrator keine CPUs sagt, wenn er Kerne meint.

— RolandoMySQLDBA

Ok, ich habe die Ausgabe von 'numactl' in der Frage gepostet.

— Don Wool

Für mich sieht die Ausgabe wie ein Quad-Quad-Core (16 Kerne) mit 4 CPUs aus. Stellen Sie daher ein innodb_buffer_pool_instances=4. Noch eine Anfrage: Bitte überprüfen Sie noch einmal, ob der DB-Server 64 GB oder 128 GB hat.

— RolandoMySQLDBA