Tengo una base de datos ocupada con únicamente tablas InnoDB que tiene un tamaño de aproximadamente 5 GB. La base de datos se ejecuta en un servidor Debian usando discos SSD y he establecido conexiones máximas = 800 que a veces saturan y muelen el servidor para detenerlo. La consulta promedio por segundo es de aproximadamente 2.5K. Por lo tanto, necesito optimizar el uso de memoria para hacer espacio para las conexiones máximas posibles.
He visto sugerencias de que innodb_buffer_pool_size debería ser hasta el 80% de la memoria total. Por otro lado, recibo esta advertencia del script tuning-primer:
Max Memory Ever Allocated : 91.97 G
Configured Max Per-thread Buffers : 72.02 G
Configured Max Global Buffers : 19.86 G
Configured Max Memory Limit : 91.88 G
Physical Memory : 94.58 G
Aquí están mis variables innodb actuales:
| innodb_adaptive_flushing | ON |
| innodb_adaptive_hash_index | ON |
| innodb_additional_mem_pool_size | 20971520 |
| innodb_autoextend_increment | 8 |
| innodb_autoinc_lock_mode | 1 |
| innodb_buffer_pool_instances | 1 |
| innodb_buffer_pool_size | 20971520000 |
| innodb_change_buffering | all |
| innodb_checksums | ON |
| innodb_commit_concurrency | 0 |
| innodb_concurrency_tickets | 500 |
| innodb_data_file_path | ibdata1:10M:autoextend |
| innodb_data_home_dir | |
| innodb_doublewrite | ON |
| innodb_fast_shutdown | 1 |
| innodb_file_format | Antelope |
| innodb_file_format_check | ON |
| innodb_file_format_max | Antelope |
| innodb_file_per_table | ON |
| innodb_flush_log_at_trx_commit | 2 |
| innodb_flush_method | O_DIRECT |
| innodb_force_load_corrupted | OFF |
| innodb_force_recovery | 0 |
| innodb_io_capacity | 200 |
| innodb_large_prefix | OFF |
| innodb_lock_wait_timeout | 50 |
| innodb_locks_unsafe_for_binlog | OFF |
| innodb_log_buffer_size | 4194304 |
| innodb_log_file_size | 524288000 |
| 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_purge_batch_size | 20 |
| innodb_purge_threads | 0 |
| innodb_random_read_ahead | OFF |
| innodb_read_ahead_threshold | 56 |
| innodb_read_io_threads | 4 |
| innodb_replication_delay | 0 |
| innodb_rollback_on_timeout | OFF |
| innodb_rollback_segments | 128 |
| innodb_spin_wait_delay | 6 |
| innodb_stats_method | nulls_equal |
| innodb_stats_on_metadata | ON |
| innodb_stats_sample_pages | 8 |
| innodb_strict_mode | OFF |
| innodb_support_xa | ON |
| innodb_sync_spin_loops | 30 |
| innodb_table_locks | ON |
| innodb_thread_concurrency | 4 |
| innodb_thread_sleep_delay | 10000 |
| innodb_use_native_aio | ON |
| innodb_use_sys_malloc | ON |
| innodb_version | 1.1.8 |
| innodb_write_io_threads | 4 |
Una nota al margen que podría ser relevante: veo que cuando trato de insertar una publicación grande (por ejemplo, más de 10 KB) de Drupal (que se encuentra en un servidor web separado) a la base de datos, dura para siempre y la página no vuelve correctamente.
Con respecto a esto, me pregunto cuál debería ser mi innodb_buffer_pool_size para un rendimiento óptimo. Agradezco sus sugerencias para establecer este y otros parámetros de manera óptima para este escenario.
SELECT (PagesData*PageSize)/POWER(1024,3) DataGB FROM...genera el siguiente error en MySQL 5.7: " La función 'INFORMATION_SCHEMA.GLOBAL_STATUS' está deshabilitada; consulte la documentación de 'show_compatibility_56' ". ¿Tendrías una versión actualizada por casualidad?¿Algo como esto? Usando
SHOW VARIABLESySHOW GLOBAL STATUS:Expresión:
innodb_buffer_pool_size / _ramSignificado: % de RAM utilizada para InnoDB buffer_pool
Rango recomendado: 60 ~ 80%
Expresión:
Innodb_buffer_pool_reads / Innodb_buffer_pool_read_requestsSignificado: Leer solicitudes que tuvieron que llegar al disco
Rango recomendado: 0-2%
Qué hacer si está fuera de rango: Aumente innodb_buffer_pool_size si tiene suficiente RAM.
Expresión:
Innodb_pages_read / Innodb_buffer_pool_read_requestsSignificado: Leer las solicitudes que tuvieron que llegar al disco
Rango recomendado: 0-2%
Qué hacer si está fuera de rango: Aumente innodb_buffer_pool_size si tiene suficiente RAM.
Expresión:
Innodb_pages_written / Innodb_buffer_pool_write_requestsSignificado: Escribir solicitudes que tuvieron que llegar al disco
Rango recomendado: 0-15%
Qué hacer si está fuera del rango: Compruebe innodb_buffer_pool_size
Expresión:
Innodb_buffer_pool_reads / UptimeSignificado: Lecturas
Rango recomendado: 0-100 / seg.
¿Qué hacer si está fuera de rango: aumentar innodb_buffer_pool_size?
Expresión:
(Innodb_buffer_pool_reads + Innodb_buffer_pool_pages_flushed) / UptimeSignificado: InnoDB I / O
Rango recomendado: 0-100 / seg.
¿Qué hacer si está fuera de rango: aumentar innodb_buffer_pool_size?
Expresión:
Innodb_buffer_pool_pages_flushed / UptimeSignificado: Escrituras (enjuagues)
Rango recomendado: 0-100 / seg.
¿Qué hacer si está fuera de rango: aumentar innodb_buffer_pool_size?
Expresión:
Innodb_buffer_pool_wait_free / UptimeSignificado: Contador para cuando no hay páginas libres en buffer_pool. Es decir, todas las páginas están sucias.
Rango recomendado: 0-1 / seg.
Qué hacer si está fuera de rango: Primero asegúrese de que innodb_buffer_pool_size esté configurado razonablemente; si aún tiene problemas, disminuya innodb_max_dirty_pages_pct
fuente
innodb_buffer_pool_sizevalor especifica? ¿Tamaño real o configurado?innodb_buffer_pool_sizeindica el tamaño máximo. En un servidor típico, el "grupo de búferes" comienza pequeño, pero rápidamente crece hasta ese tamaño máximo y permanece allí. Nota: Si eso es más grande que RAM (o incluso cercano), entonces eso lleva a un intercambio, lo cual es terrible para el rendimiento.Su título pregunta sobre innodb_buffer_pool_size, pero sospecho que ese no es el verdadero problema. (Rolando comentó por qué lo ha configurado lo suficientemente grande, incluso demasiado grande).
Eso no está claro. 800 usuarios en modo "Suspender" tienen prácticamente cero impacto en el sistema. 800 hilos activos serían un desastre. ¿Cuántos hilos se están "ejecutando"?
¿Se están bloqueando los hilos entre sí? Ver SHOW ENGINE INNODB STATUS para obtener algunas pistas sobre puntos muertos, etc.
¿Aparecen consultas en el registro lento? Optimicémoslos.
Qué versión estás usando? XtraDB (un reemplazo directo para InnoDB) hace un mejor trabajo al usar múltiples núcleos. 5.6.7 hace un trabajo aún mejor.
innodb_buffer_pool_instances: cambie esto a 8 (suponiendo un 20G buffer_pool); reducirá ligeramente la contención de Mutex.
¿Está vinculado a E / S o está vinculado a la CPU? Las soluciones son radicalmente diferentes, dependiendo de su respuesta.
SSD: podría ser mejor si todos los archivos de registro estuvieran en unidades que no sean SSD.
fuente
Más memoria siempre es mejor, pero en mi experiencia la mayoría de las veces el tamaño de la agrupación de almacenamiento intermedio no debería ajustarse al tamaño de sus datos. Muchas tablas están inactivas la mayoría de las veces, como las tablas de respaldo, por lo que el tamaño del grupo de búferes innodb debería ajustarse al tamaño de datos activo.
El período de tiempo que especifique para las páginas activas influye en el rendimiento, pero hay un punto óptimo, donde no obtendrá ese mayor rendimiento para un tamaño de búfer más grande. Podrías estimar / calcular / medir eso por
show engine innodb statusfuente