Post on 22-Jul-2015
transcript
Rendimiento y optimización de MySQL
@davidboluferchicisimo.com 1
presentación
• CTO en CHICISIMO• Fundador ONESTIC• NO SOY NINGÚN GURÚ!!!
2
Lecturas recomendadas
• High Performance MySQL, 3º edición• MySQL 5.0 Certification Study Guide. AMAZON• http://www.mysqlperformanceblog.com/• http://www.xaprb.com/blog/ Baron Schwartz• http://miguelangelnieto.net/• http://hackmysql.com/
3
ABOUT CHICISIMO
• Chicisimo ‐> 10M páginas vistas al mes
• Reads / Writes: 98% / 2%
• Total 876.27M 661.8/s• QC Hits 557.59M 421.1/s 63.63%• DMS 235.06M 177.5/s 26.83%
4
1. Arquitectura mysql
• 1º Nivel. Gestor de conexiones, autentificación y seguridad
• 2ª Nivel. Cache, parser de queries, optimizador de consultas, funciones (storedprocedures, triggers, views,..)
• 3º Nivel. Storage Engines, MyISAM, InnoDB, Achive, custom, …
5
storage engines - Myisam
• Default storage engine, el más veterano• Lock a nivel de tabla• Soporta índices FULL TEXT SEARCH• No índices entre tablas (JOINS)• No integridad referencial, no es transaccional • Rápido DUMPS & IMPORTS• Recomendado si tienes una tasa muy alta de lecturas & inserts• Se corrompe con más facilidad, recovery más lento• MyISAMMerge: MySQL 5.1 se puede particionar tablas grandes > rendimiento SELECT
6
storage engines - innodb
• Storage engine transaccional & entidad referencial• Lock a nivel de fila + MVCC (row snapshots)• Pueden producirse DEADLOCKS• COUNT(*) no es real debido a multiversiones• COMMIT es lento, OJO!• Muy lento DUMPS & IMPORTS• Más robusto que MyISAM & más rápido reparando• Recomendado si:
• Necesitas transacciones• Alto nivel UPDATES & DELETES
7
storage engines - MEMORY
• Todos los datos se guardan en memoria• Muy rápida para hacer queries• Podemos usar para mapear datos• Reinicio… adiós a los datos pero se mantiene estructura• MySQL la usa internamente si una query necesita una tabla temporal. Importante
8
storage engines - ARCHIVE
• Sólo soporta INDEX & SELECT• Cada fila está comprimida, menos I/O que MyISAM• Perfecta para logging …
• Muchos más tipos: Falcon, CSV, NDB Cluster & Maria(remplazo futuro MyISAM)
9
2. Configuración Mysql
• /etc/my.cnf• Una mala configuración puede tumbar el server• No hay que obsesionarse!• Percona al rescate! https://tools.percona.com/wizard• Ejemplos ‐> /usr/share/doc/mysql-server-5.X • Herramientas:
• mysqlreport: Analiza y resume variables estado• mysqltuner: Asistente optimizar configuración
• Google!
10
Variables rendimiento…
• query_cache_size = 256M reserva la memoria
• Query Cache… Por defecto está desactivada• key_buffer = 256M no reserva la memoria
• Key Buffer … tamaño asignado para índices MyISAM• max_connections = 500 ojo, memory leak!
• Procesos de MySQL ‐> Clientes conectados• tmp_table_size = 128M• max_heap_table_size = 128M
• Memoria o disco? Disco = DEAD• innodb_buffer_pool_size=2G
• ¡IMPORTANTE! 50% de RAM mínimo recomendado!11
Variables logging…
• log_error = /log/mysql/mysql-error.log• log_queries_not_using_indexes = 1• slow_query_log = 1• slow_query_log_file = /log/mysql/mysql-slow.log
• Hasta MySQL 5.1.21, queries lentas > 1sg• Parche PERCONA para bajar este tiempo
12
3. Mysql & memory use
• Sumamos todos los buffers: • key_buffer_size, innodb_buffer_pool_size, innodb_additional_memory_pool_size, innodb_log_buffer_size, query_cache_size
• Conexiones máximas * 256Kb *• read_buffer_size• sort_buffer_size• read_rnd_buffer_size• tmp_table_size (128M)
• Si las consultas son complejas o poco óptimas podemos matar el server
13
4. Tipos de campos
• Menos es más. TRIVIAL
• Evitar valores NULL:• Definir como NOT NULL ‐> default value
• INTEGERS:• Espacio almacenamiento: 8,16,24,32 & 64 BITS• UNSIGNED• INT(11) = INT(1)
14
4.1 campos de texto
• STRINGS:• varchar(100): hasta 100 bytes + 1/2 byte• Char(10): siempre 10 bytes• BINARY & VARBINARY• Char vs varchar?, cortas y fijas – char
• TEXT /BLOB• MySQL los trata como objetos independientes• ORDER BY text = tabla temporal en disco = MUERTE• Parche: ORDER BY SUBSTING(field, length)
• ENUM• Muestra STRING, almacena un INT• Mejor controlarlo desde nuestra aplicación 15
4.2 campos fecha
• DATETIME:• Almacena segundos• Desde año 1001 – 9999
• TIMESTAMP:• Almacena segundos• Desde 1970 – 2038
• DATETIME necesita el doble de espacio que TIMESTAMP
16
4.3 Identificadores
• Entero:• UNSIGNED – AUTO_INCREMENT• JOINS más rápidos
• ENUM• solo para tablas estáticas• JOINS no tan rápidos
• String• Necesita mucho espacio, inserts & selects lentos • Ojo con los randoms• UUID‐> usamos UHEX() /HEX() y guardamos BINARY(16)• JOINS más lentos
17
índices
• Estructura ordenada de datos• Importante que los índices puedan alojarse en memoria• Sirven agilizar búsquedas y ordenaciones• Índice funcionan de izquierda a derecha.
• INDEX `user_data` (`apellido`,`nombre`,`fecha_nac`)
• ¿Búsquedas de apellidos empiecen por B?: yes!
• ¿Búsquedas de BOLUFER y nombre empiecen por D?: yes!
• ¿Búsquedas de nombres empiecen por D?: NO!
18
índices: ¿tanto se nota?
• Tabla comentarios de chicisimo: 1M filas• CREATE TABLE comments{
`comment_ID` BIGINT(20) …,…
`comment_type` VARCHAR(20) …,
`comment_approved` VARCHAR(20) …,
`comment_date` DATETIME …,`user_id` BIGINT(20) …,PRIMARY KEY (`comment_ID`)}
19
índices: ¿tanto se nota?
• SELECT SQL_NO_CACHE * FROM `wp_1_comments` WHERE user_id = 3150
• La consulta tardó sin índice 1,023 seg. No está mal …
• La consulta tardó con índice 0,026 seg ¡4000%!
20
id type type keys key_len ref rows Extra
1 SIMPLE ALL NULL NULL NULL 1.012.563 Usingwhere
id type type keys key_len ref rows Extra
1 SIMPLE REF user_id 8 CONST 3004
índices: ¿tanto se nota?
• SELECT SQL_NO_CACHE * FROM `wp_1_comments` WHERE user_id = 3150 ORDER BY `comment_date` DESC
• La consulta tardó sin índice 1,0424 seg
• La consulta tardó con índice anterior 0,0417 seg• EXPLAIN ‐> USING WHERE, USING FILESORT
• Añadimos índice en comment_date … 0,0403 seg• EXPLAIN ‐> USING WHERE, USING FILESORT
• Añadimos índice user_id,comment_date … 0,0253 seg• EXPLAIN ‐> USING WHERE 21
I’m bored…
22
optimización: mi servidor muere…
1. Monitorización2. Analizar SLOW QUERIES 3. Buscar la(s) query(ies) en nuestro código4. Analizar query usando EXPLAIN5. Optimizar la query: índices, denormalización, campos
calculados,…6. Si:
1. Sigue fallando:‐> Volver al paso 1.2. Llevo N iteraciones ‐> Cambia de SERVER/TECNOLOGÍA3. Funciona OK ‐> Congrats!
23
Opt. 1. monitorización
• Utilizamos:• Serverstats: Estado del servidor, memoria, load, cpu, MySQL, …• Pingdom : Avisos ante caídas por aplicación iPhone/Android• mytop: top clone for MySQL
24
Opt. 1. monitorización
• Estamos probando…• Icinga (fork de NAGIOS): Monitorización + alertas
• PINBA: Monitorización tiempos de ejecución sobre PHP
• pt‐collector/pt‐stack: recolectar información en el momento preciso Percona Toolkit
25
Opt. 2. Slow queries
• slow_query_log_file se guardan las queries lentas.• Necesitamos procesar el log y agrupar queries.• mk‐query‐digest de Maatkit• mk-query-digest mysqld-slow.log > slow-mayo.log
• Qué queries han consumido más tiempo, no las que más veces se han ejecutado
• Analiza tiempo ejecución y tiempo de bloqueo
• Maatkit ya no se mantiene, Percona Toolkit
26
Opt. 3. cazando queries
• Profiling:• Clase que permite logar todas las queries• Buscar donde se define una query, WP es un laberinto• Calcula tiempos de ejecución (queries, cURL, PHP, …)• Uso de REDIS (hited, missed, seted, …)
• A parte … usamos XHPROF para analizar la pila de llamadas, uso de tiempo y memoria
27
Opt. 4. EXPLAIN …
• Muestra información sobre como procesa MySQL las queries
• Type (de mejor a peor):• const: ID = 1, buscamos por PK o UNIQUE• eq_ref: ID = 1 AND DNI = ‘111X’, buscamos por PK o UNIQUE• ref: user_id=3150, devuelve todas las filas de un índice• range: user_id > 10, devuelve un rango de filas• index: Escaneo completo del índice• all: Escaneo completo de la tabla
• Rows: Filas máximas a leer. 28
Opt. 5. queries - denormalizar
• Joins entre tablas con order + where = tabla temporal
• SELECT SQL_NO_CACHE * FROM wp_1_comments INNER JOIN wp_1_posts ON wp_1_posts.ID = wp_1_comments.comment_post_ID WHERE wp_1_posts.post_author = 3150 AND wp_1_comments.user_id != 3150 ORDER BY wp_1_comments.comment_date DESC
• Tiempo ejecución 1,815 seg• Rows: 68.801• wp_1_posts: using temporary, using filesort• wp_1_comments: using where 29
Opt. 5. queries - denormalizar
• Denormalizamos añadimos los campos a una de las tablas• Mediante un TRIGGER mantenemos actualizados los campos que hemos denormalizado• Tiempo ejecución 0,008 seg• wp_1_posts: using where
• ¿Este cambio en producción se nota?
30
Opt. 5. queries - denormalizar
31
Opt. 5. queries - calculados
• Votos: 4,3 Millones• Votos de usuarios registrados:
• Rankings mejores looks del día, mes y año. • COUNT() con un RANGE = MUERTE
• ¿Cuantos votos recibe un usuario? COUNT()• ¿Cuantos votos tiene un look? COUNT()
¿Solución?• Proceso cada N que calcula los rankings y actualiza los valoresDATO• Si usamos InnoDB, esto es casi una necesidad 32
Opt. 5. queries – bricoConsejos
• Usar INSERT DELAYED siempre que sea posible: ejemplo logs/activity
• Necesitamos buscar en un campo VARCHAR, ej: URL:• Crear un campo con un hash CRC32(‘http://chicisimo.com’)• Añadimos índice al campo y un TRIGGER para mantener el valor• WHERE url_crc=‘4240669402’ AND url = ‘http://chicisimo.com’
• No utilizar CURRENT_DATE o similares en WHERE, MySQL no las cachea
33
¡¡¡GRACIAS!!!
34