En casi todos los servidores de producción, es aconsejable desactivar la caché de consultas. Cada la modificación de una tabla provoca la depuración de todos Entradas de control de calidad para esa tabla. Cuanto más grande sea la mesa, más tiempo llevará. 128M es peligrosamente alto.
Normalmente, es aconsejable configurar innodb_buffer_pool_size a alrededor del 70 % de los disponibles RAM. Lo tiene configurado en un valor mucho más bajo, incluso menor que el tamaño del conjunto de datos. 3G probablemente ayudaría. 20G ya no ayudaría (hasta que su conjunto de datos crezca significativamente).
Asegúrese de que tanto el sistema operativo como MySQL sean versiones de 64 bits.
Para un análisis más completo, proporcione
- Tamaño de RAM (32G)
SHOW VARIABLES;SHOW GLOBAL STATUS;(después de funcionar al menos 24 horas)
Análisis de VARIABLES y ESTADO:
Los asuntos más importantes
Dado que solo (?) usa InnoDB y solo 2 GB de datos, no es crítico responder a los comentarios sobre innodb_buffer_pool_size y key_buffer_size
Proporcione más detalles sobre su uso intensivo de DELETE .
Utilice el registro lento para encontrar las "peores" consultas. Más detalles aquí . Eso debería identificar los problemas de escaneo de tablas y tmp_table que se mencionan a continuación.
No se moleste en usar OPTIMIZE TABLE .
¿Cómo estás haciendo "transacciones"? A veces con confirmación automática, a veces con COMMIT ?
Detalles y otras observaciones
( Key_blocks_used * 1024 / key_buffer_size ) = 4,710 * 1024 / 128M = 3.6% -- Porcentaje de key_buffer utilizado. High-water-mark.-- Key_buffer_size más bajo para evitar el uso innecesario de la memoria.
( innodb_buffer_pool_size / _ram ) = 4096M / 32768M = 12.5% -- % de RAM utilizada para InnoDB buffer_pool
( (key_buffer_size / 0.20 + innodb_buffer_pool_size / 0.70) / _ram ) = (128M / 0.20 + 4096M / 0.70) / 32768M = 19.8% -- La mayor parte de la RAM disponible debe estar disponible para el almacenamiento en caché.-- http://mysql. rjweb.org/doc.php/memoria
( Innodb_buffer_pool_pages_free * 16384 / innodb_buffer_pool_size ) = 187,813 * 16384 / 4096M = 71.6% -- buffer pool free -- buffer_pool_size es más grande que el conjunto de trabajo; podría disminuirlo
( Innodb_pages_written / Innodb_buffer_pool_write_requests ) = 7,144,121 / 29935426 = 23.9% -- Escribir solicitudes que tenían que llegar al disco -- Comprobar innodb_buffer_pool_size
( Innodb_buffer_pool_bytes_data / innodb_buffer_pool_size ) = 1,199,046,656 / 4096M = 27.9% -- Porcentaje del grupo de búfer ocupado por los datos-- Un pequeño porcentaje puede indica que buffer_pool es innecesariamente grande.
( Uptime / 60 * innodb_log_file_size / Innodb_os_log_written ) = 533,153 / 60 * 512M / 20356473344 = 234 -- Minutos entre rotaciones de registro de InnoDB A partir de 5.6.8, esto se puede cambiar dinámicamente; asegúrese de cambiar también my.cnf.-- (La recomendación de 60 minutos entre rotaciones es algo arbitraria). Ajuste innodb_log_file_size. (No se puede cambiar en AWS).
( Innodb_rows_deleted / Innodb_rows_inserted ) = 364,605 / 414950 = 0.879 -- Churn-- "No hagas cola, solo hazlo". (Si se utiliza MySQL como cola).
( Created_tmp_disk_tables / (Created_tmp_disk_tables + Created_tmp_tables) ) = 247,373 / (247373 + 446152) = 35.7% -- Porcentaje de tablas temporales que se derramaron en el disco -- tal vez aumentar tmp_table_size y max_heap_table_size; evitar manchas, etc.
( Select_scan ) = 871,872 / 533153 = 1.6 /sec -- escaneos completos de tablas -- Agregar índices/optimizar consultas (a menos que sean tablas pequeñas)
( Select_scan / Com_select ) = 871,872 / 12593904 = 6.9% -- % de selecciones que realizan un escaneo completo de la tabla. (Puede dejarse engañar por las rutinas almacenadas).-- Agregar índices/optimizar consultas
( Com_optimize ) = 216 / 533153 = 1.5 /HR -- Con qué frecuencia se realiza OPTIMIZE TABLE.-- OPTIMIZE TABLE rara vez es útil, ciertamente no a alta frecuencia.
( long_query_time ) = 10.000000 = 10 -- Límite (segundos) para definir una consulta "lenta".-- Sugerir 2
Extremos (sin comentarios):
Anormalmente pequeño:
Com_commit = 2.5 /HR
Innodb_buffer_pool_pages_made_not_young = 0.15 /sec
Innodb_ibuf_merged_delete_marks = 27 /HR
Innodb_row_lock_time = 8
Innodb_row_lock_time_max = 1
interactive_timeout = 360
Anormalmente grande:
Com_rollback_to_savepoint = 14 /HR
Handler_savepoint_rollback = 14 /HR
join_cache_level = 8 (This may be unused? It was removed in 5.6.3, but possibly left in MariaDB 10.1?)
Cadenas anormales:
Innodb_buffer_pool_dump_status = Dumping buffer pool(s) not yet started
Innodb_buffer_pool_load_status = Loading buffer pool(s) not yet started
innodb_checksum_algorithm = INNODB
innodb_cleaner_lsn_age_factor = HIGH_CHECKPOINT
innodb_empty_free_list_algorithm = BACKOFF
innodb_force_load_corrupted = OFF
innodb_foreground_preflush = EXPONENTIAL_BACKOFF
innodb_log_checksum_algorithm = INNODB
myisam_stats_method = NULLS_UNEQUAL
opt_s__engine_condition_pushdown = off
opt_s__mrr = off
opt_s__mrr_cost_based = off
Caché de consultas
Como se apagó, no se configuró ninguno de los valores de estado de Qcache. Así que no puedo abordar la pregunta original. Si desea activar el control de calidad y reiniciar el servidor y esperar unos días, podría volver a analizar con él activado. Varias métricas sobre aciertos, ciruelas pasas, etc. pueden abordar la pregunta original.
