Diferència entre revisions de la pàgina «ASIX/M10/UF2/A05/E3»

De Lordwektabyte Wiki
Salta a la navegació Salta a la cerca
Línia 27: Línia 27:
 
<source lang='bash'>
 
<source lang='bash'>
 
yum install bc -y
 
yum install bc -y
 +
</source>
 +
Una vegada instal·lat el podem fer executable amb
 +
<source lang='bash'>
 +
chmod +x tuning-primer.sh
 +
</source>
 +
i executar-lo pròpiament amb
 +
<source lang='bash'>./tuning-primer.sh</source>
 +
El meu resultat d'execusió és el següent:
 +
<source>
 +
[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: toor
 +
 +
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
 
</source>
 
</source>

Revisió del 13:15, 24 maig 2018

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 Tuner

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: toor
 
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