DDD

M'ha tornat a sortir el missatge de Gateway Error. He augmentat el número de processos de 15 a 20. De tota manera, crec que estem sent víctimes d'una altra onada d'atacs xinesos. El nombre de connexions des de la Xina ha anat augmentant els darrers dies, i les connexions, en general, també:

• https://ddd.uab.cat/accessos/2020/access_a2020m5_geoip.svg
• https://ddd.uab.cat/accessos/2020/access_a2020_actual.txt
• https://ddd.uab.cat/accessos/2020/access_a2020_day.svg

He augmentat també en un 50% el número de processos de Traces, de 4 a 6, perquè aquest cop també els està afectant.

Però ara surten uns missatges nous que poden estar relacionats amb el número de connexions simultànies que MariaDB té configurades, que ara mateix és de 45. El problema és que augmentar-les pot desequilibrar altres valors, i si l'atac de la Xina és massa gran, tampoc no servirà de res pujar-lo.

Tornaré a activar l'expulsió de les connexions de la Xina cap a Baidu. Ho vaig desactivar perquè aquest procés crea uns logs amb errors molt grans, però és tal com ho té Invenio i en fa por tocar-ho.

Augmentar el número de processos per a cada Invenio ha estat causant un excés de connexions a la base de dades, que generava un altre tipus d'errors. Per tant, ho he tornat a deixar als valors d'ahir: el DDD 15, i Traces 4; IFMuC continua amb 1.

Tot i això, segons com el bibsched no arrenca processos, i es queden com encallats i cal forçar-los manualment. Això passa amb tots tres Invenios.

Sembla que amb aquests nous valors el sistema aguanta millor les batzegades que hem rebut aquests darrers dies de maig:

• https://ddd.uab.cat/accessos/2020/access_a2020m5_day.svg
• https://ddd.uab.cat/accessos/2020/access_a2020m5_geoip.svg
• https://ddd.uab.cat/accessos/2020/access_a2020_day.svg

Veient que si augmento el número de processos, MariaDB diu que s'arrien al màxim de connexions configurades, he canviat els paràmetres del MariaDB (/etc/mysql/mariadb.conf.d/invenio.cnf), seguint les recomanacions de les eines mysqltuner i tuning-primer.sh

-key_buffer_size        = 8G
+key_buffer_size        = 10G
-query_cache_size       = 128M
+query_cache_size       = 256M
-max_heap_table_size    = 256M
+max_heap_table_size    = 512M
-max_connections        = 30
+max_connections        = 40
+tmp_table_size         = 64M

Ferran Jorba va escriure:

Estic veient que un procés diferent, el de crear les 856, gasta molta cpu i triga massa, perquè és molt antic i al començament no el sabia fer millor, i miraré de fer-lo més eficient.

Això ja ho vaig fer ahir a la tarda. Una operació que es fa cada 10 minuts i en trigava quasi 5, ara només triga 30 segons, 10 vegades menys.

Trigava tant perquè s'havien anat acumulant registres com si estiguessin pendents (les 856 amb el /files/) però que ja estaven arreglats. Miraré si a partir d'ara se'n continuen acumulant (alguns eren molt antics) i, si passa, a veure si esbrino el perquè.

Ja he actualitzat els paràmetres de MariaDB. Jo m'esperaria uns dies abans de canviar més coses, perquè si no, no sabrem què haurà causat el nou comportament.

Vist que l'increment d'ús del DDD és constant:

https://ddd.uab.cat/accessos/2020/access_a2020_day.svg

I que dontinuen sortint els errors de Gateway timeout, acabo d'augmentar el número de processos de 15 a 20. Demà hauria d'estar actiu.

Amb la mesura del màxim de 300 processos d'Apache simultanis, les estones de Gateway error duren menys. En tot cas, el fet és que sembla que tinguem un altre cop un atac xinès:

https://ddd.uab.cat/accessos/2020/access_a2020_actual.txt

El que no entenc és perquè no m'apareixen en aquest gràfic, que surt del mateix fitxer de log:

https://ddd.uab.cat/accessos/2020/access_a2020m10_geoip.svg

Els accessos des de la Xina els tinc bloquejats per l'aplicació Invenio, però ara mateix no tinc eines per bloquejar-lo pels accessos als fitxers. D'altra banda, segurament no ens afecten gaire, perquè recollir un fitxer no té cap cost significatiu per al servidor, com sí que el té navegar per l'aplicació, i això és el que tinc bloquejat.

No he deixat d'estar pendent del tema, observar el comportament, veure què estava passant en el moment dels errors de Gateway timout, i llegir la documentació. Fa 10 minuts he afegit un paràmetre nou a la secció wsgi d'Apache:

request-timeout=10

Defines the maximum number of seconds that a request is allowed to run before the daemon process is restarted. This can be used to recover from a scenario where a request blocks indefinitely, and where if all request threads were consumed in this way, would result in the whole WSGI application process being blocked.

La documentació està a https://modwsgi.readthedocs.io/en/develop/configuration-directives/WSGIDaemonProcess.html. De moment, fa una estona que funciona millor, ja veurem...

Com que aquesta nit, i durant el dia d'avui m'estic trobant amb errors de màxim de connexions al servidor de bases de dades (MariaDB), acabo de pujar el valor de 40 a 50:

En primer lloc, al fitxer actiu de configuració:

diff --git a/mysql/mariadb.conf.d/invenio.cnf b/mysql/mariadb.conf.d/invenio.cnf
index 71a6e99..333f1fd 100644
--- a/mysql/mariadb.conf.d/invenio.cnf
+++ b/mysql/mariadb.conf.d/invenio.cnf
@@ -13,7 +13,7 @@ max_allowed_packet    = 1G
 query_cache_size       = 256M
 max_heap_table_size    = 512M
 tmp_table_size         = 64M
-max_connections        = 40
+max_connections        = 50
 table_definition_cache = 1600
 table_cache            = 6000
 character_set_server   = utf8

Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 726259
Server version: 10.3.23-MariaDB-0+deb10u1 Debian 10

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> show variables like 'max_connections';
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| max_connections | 40    |
+-----------------+-------+
1 row in set (0.037 sec)

MariaDB [(none)]> set global max_connections := 50;
Query OK, 0 rows affected (0.018 sec)

MariaDB [(none)]> show variables like 'max_connections';
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| max_connections | 50    |
+-----------------+-------+
1 row in set (0.001 sec)

MariaDB [(none)]> Bye

Els problemes no se solucionen i, a més, ens estem trobant amb errors misteriosos alhora de pujar fitxers no excessivament grans. Provem de canviar un dels paràmetres del wsgi per un altre:

--- a/etc/apache/invenio-apache-vhost-ssl.conf
+++ b/etc/apache/invenio-apache-vhost-ssl.conf
@@ -60,7 +60,7 @@ WSGIRestrictStdout Off
        WSGIApplicationGroup %{GLOBAL}
        # The name has to be unique for the whole server, user and
        # group match unix user and group
-       WSGIDaemonProcess ddd user=ddd group=users display-name=ddd processes=15 threads=1 socket-user=ddd request-timeout=20 python-path=/home/ddd/lib/python
+       WSGIDaemonProcess ddd user=ddd group=users display-name=ddd processes=20 threads=1 socket-user=ddd deadlock-timeout=20 python-path=/home/ddd/lib/python
        WSGIScriptAlias / /home/ddd/invenio/var/www-wsgi/invenio.wsgi
        WSGIPassAuthorization On

Aquesta setmana estem rebent moltes incidències de reinici d'Apache. Remenant els fitxers de log genèrics d'Apache, m'he trobat un missatge que no recordo haver vist mai:

[Fri May 28 06:52:31.539574 2021] [mpm_prefork:error] [pid 26597] AH00161: server reached MaxRequestWorkers setting, consider raising the MaxRequestWorkers setting

Doncs sí, hi ha un fitxer que no coneixia, /etc/apache2/mods-available/mpm_prefork.conf, i hi he augmentat el valor MaxRequestWorkers de 150 a 200. A veure com respon tot plegat.

# prefork MPM
# StartServers: number of server processes to start
# MinSpareServers: minimum number of server processes which are kept spare
# MaxSpareServers: maximum number of server processes which are kept spare
# MaxRequestWorkers: maximum number of server processes allowed to start
# MaxConnectionsPerChild: maximum number of requests a server process serves

<IfModule mpm_prefork_module>
        StartServers              5
        MinSpareServers           5
        MaxSpareServers          10
        MaxRequestWorkers       200
        MaxConnectionsPerChild    0
</IfModule>

Reverteixo el valor un altre cop a a 150, perquè el resultat sembla pitjor: en comptes de reinciar i donar un Gateway timeout, ara es queda com penjat. En fi, continuarem remenant.