ASIX/M10/UF2/A05/E3

Guillem Solà i Boeck (host A10BPC22)

Fent servir scripts de monitorització per optimitzar el rendiment de l'SGBD

• Indicar quins scripts i eines de monitoratge hi ha de BBDD
• Identificar diferents tipus d'optimització: emmagatzematge, espai de disc i procediments de transferències i comunicacions. Indica els resultats obtinguts.
• Identifica tècniques d'optimització de consultes en un SGBD. Indica els resultats obtinguts.

Fer les modificacions al fitxer de configuració que es necessitin

Indicar quins scripts i eines de monitoratge hi ha de BBDD

• Un script escrit en Perl és molt conegut en el món MariaDB/MySQL. Es tracta de mysqltuner.
• Un altre script conegut com a mysql tuning primer. Aquest està escrit en bash i és molt semblant a l'anterior a nivell de funcionalitat.

Com a conclusió, crec que aquests 2 scripts hem de veure'ls com un conjunt ja que és difícil dir si un és millor que l'altre. Com a administradors de sistemes hem de ser capaços de poder treure bones conclusions a partir dels resultats de cadascun.

Identificar diferents tipus d'optimització

• Emmagatzematge

A nivell d'emmagatzematge es pot destacar el tipus de suport on tindrem instal·lat el sistema operatiu+SGBD i les dades de la Base de Dades en general. Com a norma general, descartarem discos durs mecànics perquè tenen temps d'accés molt lents en comparació als discos durs sòlids (SSD) basats en memòria flash. Encara que el SGBD carregarà les dades més accedides en RAM per a evitar lectures a disc (infinitament més lentes encara que es llegeixi d'un SSD), sempre serà millor un disc ràpid per si s'ha de fer una consulta sobre unes dades que no estiguin cachejades en memòria.

• Espai de disc

Generalment, com més espai disponible en disc, millor en termes d'escalabilitat del sistema que suporta el SGBD; de manera que no fem curt al cap d'un temps quan la BBDD creixi i haguem de migrar a discos durs més grans o, fins i tot, haver de canviar el servidor sencer. El que és interessant és trobar un balanç entre rendiment de velocitat i espai disponible; ja que com més gran sigui el disc, més car serà. Això potser no és problema per una empresa més o menys gran, però normalment, a les empreses, els sol costar bastant buidar la butxaca per a equipament informàtic i aquest tema serà més delicat. Per tant, tampoc podem donar una conclusió genèrica sinó que haurem d'estudiar cada cas en concret i prendre decisions basant-nos en aquella situació.

• Procediments de transferències i comunicacions

Per suposat que l'estàndard de comunicacions serà a velocitat de gigabit per qüestions òbvies. Llavors el servidor hauria de tenir, com a mínim, 2 targetes de xarxa en sistema failover per a evitar downtimes en cas que una interfície falli o tingui problemes.

Exemple de funcionament

MySQL Tuning Primer

Per a utilitzar aquest script necessitem tenir instal·lat el programari bc. L'instal·larem amb

yum install bc -y

Una vegada instal·lat el podem fer executable amb

chmod +x tuning-primer.sh

i executar-lo pròpiament amb

./tuning-primer.sh

El meu resultat d'execusió és el següent:

[root@pt5x ~]# ./tuning-primer.sh 

Using login values from ~/.my.cnf
- INITIAL LOGIN ATTEMPT FAILED -
Testing for stored webmin passwords:
 None Found
Could not auto detect login info!
Found potential sockets: /var/lib/mysql/mysql.sock
Using: /var/lib/mysql/mysql.sock
Would you like to provide a different socket?: [y/N] 
Do you have your login handy ? [y/N] : y
User: root
Password: [ommitted]
 
Would you like me to create a ~/.my.cnf file for you? [y/N] : n
 
        -- MYSQL PERFORMANCE TUNING PRIMER --
             - By: Matthew Montgomery -

MySQL Version 5.5.56-MariaDB x86_64

Uptime = 0 days 0 hrs 8 min 31 sec
Avg. qps = 0
Total Questions = 373
Threads Connected = 1

Warning: Server has not been running for at least 48hrs.
It may not be safe to use these recommendations

To find out more information on how each of these
runtime variables effects performance visit:                                                                                                                            
http://dev.mysql.com/doc/refman/5.5/en/server-system-variables.html
Visit http://www.mysql.com/products/enterprise/advisors.html
for info about MySQL's Enterprise Monitoring and Advisory Service

SLOW QUERIES
The slow query log is NOT enabled.
Current long_query_time = 10.000000 sec.
You have 0 out of 394 that take longer than 10.000000 sec. to complete
Your long_query_time seems to be fine

BINARY UPDATE LOG
The binary update log is NOT enabled.
You will not be able to do point in time recovery
See http://dev.mysql.com/doc/refman/5.5/en/point-in-time-recovery.html

WORKER THREADS
Current thread_cache_size = 0
Current threads_cached = 0
Current threads_per_sec = 1
Historic threads_per_sec = 0
Your thread_cache_size is fine

MAX CONNECTIONS
Current max_connections = 151
Current threads_connected = 1
Historic max_used_connections = 1
The number of used connections is 0% of the configured maximum.
You are using less than 10% of your configured max_connections.
Lowering max_connections could help to avoid an over-allocation of memory                                                                                               
See "MEMORY USAGE" section to make sure you are not over-allocating                                                                                                     

INNODB STATUS
Current InnoDB index space = 11 M
Current InnoDB data space = 6 M
Current InnoDB buffer pool free = 67 %
Current innodb_buffer_pool_size = 128 M
Depending on how much space your innodb indexes take up it may be safe
to increase this value to up to 2 / 3 of total system memory

MEMORY USAGE
Max Memory Ever Allocated : 274 M
Configured Max Per-thread Buffers : 419 M
Configured Max Global Buffers : 272 M
Configured Max Memory Limit : 691 M
Physical Memory : 991 M
Max memory limit seem to be within acceptable norms

KEY BUFFER
No key reads?!
Seriously look into using some indexes                                                                                                                                  
Current MyISAM index space = 99 K
Current key_buffer_size = 128 M
Key cache miss rate is 1 : 0
Key buffer free ratio = 81 %
Your key_buffer_size seems to be fine

QUERY CACHE
Query cache is supported but not enabled
Perhaps you should set the query_cache_size                                                                                                                             

SORT OPERATIONS
Current sort_buffer_size = 2 M
Current read_rnd_buffer_size = 256 K
No sort operations have been performed
Sort buffer seems to be fine

JOINS
./tuning-primer.sh: line 402: export: `2097152': not a valid identifier
Current join_buffer_size = 132.00 K
You have had 0 queries where a join could not use an index properly
Your joins seem to be using indexes properly

OPEN FILES LIMIT
Current open_files_limit = 1024 files
The open_files_limit should typically be set to at least 2x-3x
that of table_cache if you have heavy MyISAM usage.                                                                                                                     
Your open_files_limit value seems to be fine

TABLE CACHE
Current table_open_cache = 400 tables
Current table_definition_cache = 400 tables
You have a total of 400 tables
You have 400 open tables.
Current table_cache hit rate is 106%
, while 100% of your table cache is in use
You should probably increase your table_cache
You should probably increase your table_definition_cache value.

TEMP TABLES
Current max_heap_table_size = 16 M
Current tmp_table_size = 16 M
Of 704 temp tables, 9% were created on disk
Created disk tmp tables ratio seems fine

TABLE SCANS
Current read_buffer_size = 128 K
Current table scan ratio = 15 : 1
read_buffer_size seems to be fine

TABLE LOCKING
Current Lock Wait ratio = 0 : 652
Your table locking seems to be fine

Conclusions

Els apartats que veiem que no estan del tot bé pot ser degut al poc ús que ha tingut el SGBD perquè es tracta de la màquina on he instal·lat el Moodle per a la pràctica 51 i no seran del tot "útils" però poden servir per tenir una orientació o informació arran de la configuració que tenim actualment i per a saber, sobretot, per a què serveix cada paràmetre comprovat. Per exemple, en l'apartat de TABLE CACHE

TABLE CACHE
Current table_open_cache = 400 tables
Current table_definition_cache = 400 tables
You have a total of 400 tables
You have 400 open tables.
Current table_cache hit rate is 106%
, while 100% of your table cache is in use
You should probably increase your table_cache
You should probably increase your table_definition_cache value.

se'ns suggereix augmentar el valor de table_cache i table_definition_cache. En prenem nota i compararem els resultats amb el següent script.