DDD

D'una banda, cal tenir en compte que, segons les estadístiques, l'ús del DDD continua creixent, ex:

(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ó.

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.

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.

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

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).

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

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.

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.

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

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...

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).

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:

• http://www.zyxware.com/articles/3064/how-to-backup-dump-and-restore-a-specific-table-in-mysql-using-the-terminal-commandline-utilities-provided-by-linu

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...

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...

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...

Ja se que has tancat la tasca però avui ja t'ho puc confirmar. El DDD va molt, però MOLT millor! Gràcies!! :-))

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

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...

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.