Tasca #2918
tancatEl DDD va massa lent; corregir-ho
Afegit per Ferran Jorba fa quasi 12 anys. Actualitzat fa més de 11 anys.
Descripció
Des de fa algunes setmanes o mesos, el DDD va massa lent. Es nota sobretot a estones, on queda ben bé com penjat.
Cal repassar també els consells de:
FJ Actualitzat per Ferran Jorba fa quasi 12 anys Accions #1
D'una banda, cal tenir en compte que, segons les estadístiques, l'ús del DDD continua creixent, ex:
| Mes | 2013 | 2014 | increment |
| abril | 291.410 | 436.139 | 49% |
| març | 324.132 | 653.470 | 101% |
| febrer | 255.491 | 362.462 | 41% |
| gener | 218.210 | 297.565 | 36% |
(dades de http://ddd.uab.cat/usage.py?c=ddd&report=usage)
Per tant, hem de fer-nos la idea que tard o d'hora la màquina se'ns quedarà petita; igualment, també acabarà la seva garantia i l'haurem de canviar aviat.
Durant moltes setmanes hi he estat parant atenció, considerant sobretot que podia ser el MySQL; he retocat alguns paràmetres, i potser sí que semblava que anava millor.
Però igualment, aquesta darrera setmana els bloquejos han estat excessius, i cal trobar-hi una solució.
FJ Actualitzat per Ferran Jorba fa quasi 12 anys Accions #2
El que he estat observant és que la màquina es bloqueja més quan s'estan indexant documents; com que durant les darreres setmanes hem estat fent tots plegats forces tasques de correció, s'ha notat més.
Per tant, he estudiat els logs de la tasca d'indexació (bibindex), i he vist que sovint dóna error intentant fer conversions que no calen, com de .jpg a .txt, o de documents office a .txt (a nosaltres no ens cal perquè ja els tenim en PDF). De moment he deshabilitat aquestes conversions, a veure si hi notem millores.
En aquesta línia, intentaré que aprofiti les conversions .txt que ja tenim pre-extretes al DDD, i que no converteixi PDFs i similars cada cop que es reindexa un registre.
FJ Actualitzat per Ferran Jorba fa quasi 12 anys Accions #3
Acabo de canviar el valor de key_buffer_size de mysql, seguint les indicacions tant del mysqltuner com del tuning-primer.sh, sobretot després d'haver llegit aquesta entrada:
http://serverfault.com/questions/78786/tuning-and-understanding-table-cache-in-mysql
Segons mysqltuner:
[!!] Table cache hit rate: 5% (1K open / 32K opened)
[...]
Variables to adjust:
table_cache (> 1800)
Segons tuning-primer.sh:
TABLE CACHE Current table_open_cache = 1800 tables Current table_definition_cache = 400 tables You have a total of 497 tables You have 1800 open tables. Current table_cache hit rate is 5% , 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.
Tenint en compte que cada Invenio té 500 taules, i tenint en compte 3 invenios = 1500 (i el tercer encara no funciona!), ja el teníem a 1800. Però faltava multiplicar-ho pel número de connexions. Ho pujo a 6000.
No canvio cap altre valor, perquè si no no sabrem quin és el rellevant. Com que s'ha de reiniciar el servidor MySQL, deixo que es faci de matinada.
FJ Actualitzat per Ferran Jorba fa quasi 12 anys Accions #4
- S'ha actualitzat Descripció (diferències)
FJ Actualitzat per Ferran Jorba fa quasi 12 anys Accions #5
Ja no es queixa de key_buffer_size, diu que és correcte. El tuning-primer.sh diu ara:
TABLE CACHE Current table_open_cache = 6000 tables Current table_definition_cache = 400 tables You have a total of 497 tables You have 1983 open tables. The table_cache value seems to be fine You should probably increase your table_definition_cache value.
Ara augmento el table_definition_cache de 400 a 1600, que és 100 més que el número de taules definides entre totes les bases de dades MySQL d'Homs (3 x 500 = 1500):
http://dev.mysql.com/doc/refman/5.5/en/server-system-variables.html#sysvar_table_definition_cache
FJ Actualitzat per Ferran Jorba fa quasi 12 anys Accions #6
El canvi de table_definition_cache sembla que hagi anat bé, doncs:
TABLE CACHE Current table_open_cache = 6000 tables Current table_definition_cache = 1600 tables You have a total of 497 tables You have 1982 open tables. The table_cache value seems to be fine
Ara preparo per demà la primera de les recomanacions de http://invenio-software.org/wiki/Tools/MySQL/Tuning, augmentar max_allowed_packet a 1 GB (fins ara estava a 512 MB).
FJ Actualitzat per Ferran Jorba fa quasi 12 anys Accions #7
- Estat ha canviat de Creada a En curs
FJ Actualitzat per Ferran Jorba fa quasi 12 anys Accions #8
Baixar max_connections de 151 a 20. Segons tuning-primer.sh:
MAX CONNECTIONS Current max_connections = 151 Current threads_connected = 7 Historic max_used_connections = 10 The number of used connections is 6% 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
Mirarem com afecta l'ús global de la memòria, que ara és aquest:
MEMORY USAGE Max Memory Ever Allocated : 810 M Configured Max Per-thread Buffers : 405 M Configured Max Global Buffers : 784 M Configured Max Memory Limit : 1.16 G Physical Memory : 21.62 G Max memory limit seem to be within acceptable norms
FJ Actualitzat per Ferran Jorba fa quasi 12 anys Accions #9
El canvi de max_connections a 20 sembla que funciona perfectament i disminueix el total de memòria utilitzada pel MySQL:
MAX CONNECTIONS Current max_connections = 20 Current threads_connected = 9 Historic max_used_connections = 12 The number of used connections is 60% of the configured maximum. Your max_connections variable seems to be fine.
MEMORY USAGE Max Memory Ever Allocated : 816 M Configured Max Per-thread Buffers : 53 M Configured Max Global Buffers : 784 M Configured Max Memory Limit : 837 M Physical Memory : 21.62 G Max memory limit seem to be within acceptable norms
Aprofitarem aquest estalvi de RAM per prepaprar per demà un canvi d'enveradura: passar el key_buffer de 512M a 4G. La recomanació del tuning-primer.sh és aquesta:
KEY BUFFER Current MyISAM index space = 5.41 G Current key_buffer_size = 512 M Key cache miss rate is 1 : 1446 Key buffer free ratio = 0 % You could increase key_buffer_size It is safe to raise this up to 1/4 of total system memory; assuming this is a dedicated database server.
La idea és mantenir en RAM, si és possible, tots els índexos de les bases de dades MySQL, per estalviar accessos a disc. Ara mateix la suma dels índexos del DDD i Traces (que és el que és rellevant, des del punt de vista de MySQL) és de 9 GB, quasi la meitat de la RAM del servidor, i per tant inviable. Comencem primer amb 4 GB, que és 8 vegades més que el valor per defecte de MySQL.
NC Actualitzat per Núria Casaldaliga fa quasi 12 anys Accions #10
- Paraula clau s'ha establert a JR
FJ Actualitzat per Ferran Jorba fa quasi 12 anys Accions #11
El canvi d'abans d'ahir ha suposat un augment enorme de l'ús de la memòria RAM del servidor, i no estic segur que la millora del rendiment hagi estat tan gran. De fet, durant les indexacions continua anant excessivament lent.
MEMORY USAGE Max Memory Ever Allocated : 4.29 G Configured Max Per-thread Buffers : 53 M Configured Max Global Buffers : 4.26 G Configured Max Memory Limit : 4.31 G Physical Memory : 21.62 G Max memory limit seem to be within acceptable norms KEY BUFFER Current MyISAM index space = 5.42 G Current key_buffer_size = 4.00 G Key cache miss rate is 1 : 3506 Key buffer free ratio = 40 % Your key_buffer_size seems to be too high. Perhaps you can use these resources elsewhere
De tota manera, sembla que l'eina (tuning-primer.sh) tant aviat té en compte valors globals de la base de dades com de l'usuari actual del servidor.
Un altre canvi, seguint http://invenio-software.org/wiki/Tools/MySQL/Tuning. He vist que el valor (per defecte) de max_heap_table_size és 16M; el pujo a 256M.
FJ Actualitzat per Ferran Jorba fa quasi 12 anys Accions #12
Em sabríeu dir si en aquestes dues setmanes que porto afinant els paràmetres el rendiment ha millorat o no, i com? Agrairé tantes valoracions com tingueu a bé fer-me, encara que siguin per repetir el que han dit altres persones.
Gràcies,
Ferran
CA Actualitzat per Cristina Azorin fa quasi 12 anys Accions #13
Hola Ferran,
no, dues setmanes de millores no :-)) Pensem (les habituals del mati de la UTP que treballem amb el DDD) que la millora s'ha notat aquest final de setmana, dijous i divendres, però en canvi recordem cap a dimarts o dimecres un dia especialment dur en quan a lentitud.
Estarem atentes a la setmana vinent...
FJ Actualitzat per Ferran Jorba fa quasi 12 anys Accions #14
Quan va lent, que sí que hi va, és en els moments d'indexació, i més específicament en el moment de la indexació a text complet (taules idxWORD09F i idxWORD09R). Aleshores continua quedant-se com bloquejat. Miraré si puc fer alguna acció específica per a aquestes taules. Són taules especialment grosses:
homs:/etc/mysql/conf.d# ls -lh /var/lib/mysql/ddduab/idxWORD09* -rw-rw---- 1 mysql mysql 8.5K Jul 18 2013 /var/lib/mysql/ddduab/idxWORD09F.frm -rw-rw---- 1 mysql mysql 2.4G Jun 18 12:47 /var/lib/mysql/ddduab/idxWORD09F.MYD -rw-rw---- 1 mysql mysql 1.3G Jun 18 12:47 /var/lib/mysql/ddduab/idxWORD09F.MYI -rw-rw---- 1 mysql mysql 8.5K Jul 8 2013 /var/lib/mysql/ddduab/idxWORD09R.frm -rw-rw---- 1 mysql mysql 842M Jun 18 12:47 /var/lib/mysql/ddduab/idxWORD09R.MYD -rw-rw---- 1 mysql mysql 2.0M Jun 18 12:47 /var/lib/mysql/ddduab/idxWORD09R.MYI
Igualment, he estat revisant els paràmetres de MySQL, i he estat fent proves a Nuix (ddd-test), amb diferents conjunts de valors que venen amb els sistema, i una manera diferent de modificar els propis (posant-los en el directori /etc/mysql/conf.d/ (jo n'he dit invenio.cnf).
FJ Actualitzat per Ferran Jorba fa quasi 12 anys Accions #15
He fet uns quants intents per optimitzar les taules dels índexos de fulltext (idxWORD09F i idxWORD09R), però m'he trobat amb aquest error:
- http://bugs.mysql.com/bug.php?id=61598
- http://www.buildcube.com/tech_blog/2014/01/09/mysql-cant-change-ownership-of-the-file-errcode-1/
[Ho he fet a ddd-test, evidentment!]
Miraré de fer-ho via descàrrega i recàrrega, i de moment d'una sola taula:
Clar que això és una mica delicat decidir quan fer-ho: no es pot fer mentre el DDD està funcionant, i mentre no hi ha accessos, és difícil atrevir-se...
CA Actualitzat per Cristina Azorin fa quasi 12 anys Accions #16
- Data de venciment s'ha establert a 02-07-2014
FJ Actualitzat per Ferran Jorba fa més de 11 anys Accions #17
Aquesta matinada he optimitzat la taula d'índexos de text complet. Ho he documentat a ComOptimitzarUnaTaulaDeMySQL.
Hem d'estar atents a si es nota la millora. Se m'estan acabant les idees...
FJ Actualitzat per Ferran Jorba fa més de 11 anys Accions #18
I avui, aquesta matinada, he refet, tal com explicava a ComOptimitzarUnaTaulaDeMySQL, tota la base de dades del DDD. He explicat els passos al final del mateix document citat.
Hauríem de trobar una millora. M'ho confirmeu?
Estic pensant que això també convindria fer-ho a Traces, perquè, com que s'executa al mateix servidor, la millora seria conjunta. Ara que ja en sabem...
FJ Actualitzat per Ferran Jorba fa més de 11 anys Accions #19
- Estat ha canviat de En curs a Tancada
Tal com comentava, i per completesa, també he aprofitat per reorganitzar Traces.
Jo crec que val la pena tancar ara la tasca, perquè les grans operacions ja estan fetes, i a més a l'estiu el sistema no va tant carregat. Aniré vigilant el rendiment, però sense tanta pressió.
CA Actualitzat per Cristina Azorin fa més de 11 anys Accions #20
Ja se que has tancat la tasca però avui ja t'ho puc confirmar. El DDD va molt, però MOLT millor! Gràcies!! :-))
NC Actualitzat per Núria Casaldaliga fa més de 11 anys Accions #21
Hola,
Estic d'acord amb la Cristina, aquest matí i ahir al matí anava molt millor.
Ara però, va molt lent (14:45) potser estàs fent alguna tasca interna d'indexació??
Núria
FJ Actualitzat per Ferran Jorba fa més de 11 anys Accions #22
Nuria Casaldaliga va escriure:
Estic d'acord amb la Cristina, aquest matí i ahir al matí anava molt millor.
Ara però, va molt lent (14:45) potser estàs fent alguna tasca interna d'indexació??
No, jo no. En tot cas, la previsió que jo m'havia fet era que no hauria d'afectar encara que hi haguessin indexacions. Que diguis que anava molt lent m'amuïna...
FJ Actualitzat per Ferran Jorba fa més de 11 anys Accions #23
- Estat ha canviat de Tancada a En curs
Torno a obrir la tasca.
CA Actualitzat per Cristina Azorin fa més de 11 anys Accions #24
- Data de venciment ha canviat de 02-07-2014 a 19-12-2014
FJ Actualitzat per Ferran Jorba fa més de 11 anys Accions #25
Darrerament estava arribant a la conclusió que el problema no estava ja en MySQL com en l'Apache. Avui, que ha estat un dia especialment dur, amb sobrecàrregues fortes i reinicis d'Apache, era el moment.
Jo estava confós, i havia donat per suposat que el paràmetre processes de la directiva WSGIDaemonProcess, si no es posa, es configurava dinàmicament. Error:
- http://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIDaemonProcess
- https://groups.google.com/forum/#!topic/modwsgi/6Px1LSBftyk
- https://github.com/inveniosoftware/invenio/blob/master/INSTALL#L760
He après, per sorpresa meva, que si no s'hi posa, és 1. De fet, Invenio en posa per defecte 5, però jo l'havia eliminat, i això va ser un error.
Ara l'he posat a 5; com a mínim, demà al reinicar-se Apache, agafarà el nou valor.
FJ Actualitzat per Ferran Jorba fa més de 11 anys Accions #26
- Estat ha canviat de En curs a Tancada
De moment, com que sembla que va bé, encara que sigui perquè n'hi ha molts que estan de vacances, tanquem-ho.
CA Actualitzat per Cristina Azorin fa més de 11 anys Accions #27
- Paraula clau s'ha suprimit (
JR)