WordPress. El misterioso caso del cuelgue diario a las 9 de la mañana

icono de wordpress Los blogs están muertos. Por fin. Bueno, no todos. Hay alguno que resiste hoy y siempre a la invasión de las redes sociales. A ratos me gusta pensar que este es uno de ellos… pero si soy sincero conmigo mismo ciertamente está un poco desnutrido. No le presto mucha antención, no… Hace meses, por ejemplo, que se cuelga durante aproximadamente media hora todas las mañanas y ni siquiera me he preocupado de ver que le pasa. Bueno, ya no. Ya está arreglado. Los malos hados subestiman el poder de esas tareas tediosas y desagradables que hacen que hasta te den ganas de ponerte a planchar o a limpiar los baños. Bueno, yo me he conformado con arreglar por fin este problemilla. Los baños otro día. 🙂

¿Síntomas mi querido Watson? Apenas nada: la indisponibilidad se producía por un elevado consumo de CPU y mirando con htop resulta que la responsable es mariadb (aunque en el pantallazo aparezca mysql ya sabéis que son compatibles a nivel binario).

htop - mysql se come todo el tiempo de proceso de ambos cores

Alguna pista mas: conéctandome a mariadb observo que lo que se están ejecutando son consultas aparentemente bastante simples sobre la tabla wp_options:

MariaDB [unlugar]> show processlist;
+-------+---------+-----------+---------+---------+------+--------------+------------------------------------------------------------------------------------------------------+----------+
| Id    | User    | Host      | db      | Command | Time | State        | Info                                                                                                 | Progress |
+-------+---------+-----------+---------+---------+------+--------------+------------------------------------------------------------------------------------------------------+----------+
| 29462 | unlugar | localhost | unlugar | Query   | 1043 | Sending data | DELETE a, b FROM wp_options a, wp_options b
			WHERE a.option_name LIKE '\\_transient\\_%'
			AND a. |    0.000 |
| 29552 | root    | localhost | unlugar | Query   |    0 | init         | show processlist                                                                                     |    0.000 |
| 29559 | unlugar | localhost | unlugar | Query   |   40 | update       | INSERT INTO `wp_options` (`option_name`, `option_value`, `autoload`) VALUES ('jetpack_nonce_15275779 |    0.000 |
| 29560 | unlugar | localhost | unlugar | Query   |   22 | updating     | UPDATE `wp_options` SET `option_value` = '1527578481.1030609607696533203125' WHERE `option_name` = ' |    0.000 |
| 29561 | unlugar | localhost | unlugar | Query   |    7 | updating     | UPDATE `wp_options` SET `option_value` = '1527578505', `autoload` = 'yes' WHERE `option_name` = 'jet |    0.000 |
| 29562 | unlugar | localhost | unlugar | Query   |    0 | updating     | UPDATE `wp_options` SET `option_value` = '1527578503.1177010536193847656250' WHERE `option_name` = ' |    0.000 |
+-------+---------+-----------+---------+---------+------+--------------+------------------------------------------------------------------------------------------------------+----------+

Así que le echamos un vistazo a esa tabla y resulta que tiene la friolera de más de 40.000 registros y consume cerca de 38 Megas de espacio ¿Qué tiene dentro?¿Los casos de corrupción del PP? Porque la estructura de la tabla también es bastante simplona:

MariaDB [unlugar]> describe wp_options;
+--------------+---------------------+------+-----+---------+----------------+
| Field        | Type                | Null | Key | Default | Extra          |
+--------------+---------------------+------+-----+---------+----------------+
| option_id    | bigint(20) unsigned | NO   | PRI | NULL    | auto_increment |
| option_name  | varchar(191)        | NO   |     | NULL    |                |
| option_value | longtext            | NO   |     | NULL    |                |
| autoload     | varchar(20)         | NO   |     | yes     |                |
+--------------+---------------------+------+-----+---------+----------------+
4 rows in set (0.01 sec)

Un último dato: la exactitud en la periodicidad me escamaba también. Incluso uno de esos días de puentes con un tiempo maravilloso donde no queda ni el friki más irredento paseándose por algo donde no despachan cerveza el blog también se caía. Y a la misma hora, así que le eché un vistazo al cron del sistema y no había nada que se lanzara a esa hora. ¿Y? De repente recordé que wordpress viene con su propio planificador de tareas y que estas se pueden inspeccionar fácilmente. Por ejemplo a través del plugin WP Cron Cleaner. Bingo. Ahí la tengo: Justo a las 9.04 y todos los días hay una tarea que se llama delete_expired_transients. Y eso de “transient” ya era algo que habíamos visto por ahí arriba en la consulta que se estaba realizando en mariadb.

El proceso que se lanza diariamente alrededor de las 9 realiza una limpieza de transients

Tocaba googlear a ver que es eso de los transients pero ya teníamos datos suficientes para reunir en la biblioteca a todos los implicados y desvelar quien es el asesino.

Los transients, al parecer, son registros con información temporal que proviene de los plugins que tenemos instalados. ¿Sirven para algo? Pues una vez que caducan no, para nada. De hecho precisamente por eso está ahí esa tarea que elimina los caducados. ¿Qué es lo que ocurre entoces? Pues que es evidente que muy bien no funciona porque la mayoría de esos 40.000 registros son transients. Más de 35.000, de hecho. Y la búsqueda se realiza a través del campo wp_options que como vemos no está indexado. Fatal. La primera aproximación al problema pasa, pues, por crear un índice sobre esa columna:

MariaDB [unlugar]> alter table wp_options add index (option_name);
Query OK, 0 rows affected (3 min 47.86 sec)         
Records: 0  Duplicates: 0  Warnings: 0

Mano de santo, oigan. Al día siguiente a las 9.04 por primera vez en meses el blog no se colgó. ¿Lo dejo así?¿Con una tabla diez veces mas grande que el contenido de todo lo escrito en el blog?¿Hasta donde la dejo crecer entonces? Toca hacer otra búsqueda y por ahí me encuentro con mucha mas gente que ha tenido problemas similares y que asegura que se puede hacer tábula rasa y borrarlos todos. Así que hago un backup rápido, los elimino… y parece que todo va bien. Fantástico 🙂

¿Cómo eliminarlos? Pues a través de línea de comando es fácil:

MariaDB [unlugar]> DELETE FROM `wp_options` WHERE `option_name` LIKE ('%\_transient\_%')

Puestos a buscar una solución más cómoda y permanente para no llegar de nuevo aquí dentro de 10 años encontré otro plugin (Transient Cleaner) que te permite borrarlos puntualmente y/o programar una tarea para hacer una limpieza mas efectiva que la de wordpress de forma periódica.

Y listo. O eso parece. Mañana los baños. Sin falta 🙂

Laravel 5.6. Estructura y primeros pasos: Autenticación de usuarios

icono de php Ya yenemos Laravel 5.6 instalado en alguno de los dos entornos que hemos visto antes. ¿Qué sigue? Lo primero, entender un poquito la estructura de directorios que nos ha creado composer. Sólo lo imprescindible. El resto lo iremos viendo a medida que avanzamos.

josemaria@valeria /var/www/html/prueba $ ls -la
total 236
drwxr-xr-x 12 root www-data   4096 mar  9 19:31 .
drwxr-xr-x  3 root www-data   4096 mar  9 18:29 ..
drwxr-xrwx  6 root www-data   4096 ene  3 17:52 app
-rwxr-xrwx  1 root www-data   1686 ene  3 17:52 artisan
drwxr-xrwx  3 root www-data   4096 ene  3 17:52 bootstrap
-rw-r--rw-  1 root www-data   1413 ene  3 17:52 composer.json
-rw-r--rw-  1 root www-data 143565 mar  8 07:37 composer.lock
drwxr-xrwx  2 root www-data   4096 ene  3 17:52 config
drwxr-xrwx  5 root www-data   4096 ene  3 17:52 database
-rw-r--r--  1 root www-data    612 mar  9 19:31 .env
-rw-r--r--  1 root www-data    565 ene  3 17:52 .env.example
-rw-r--r--  1 root www-data    111 ene  3 17:52 .gitattributes
-rw-r--r--  1 root www-data    146 ene  3 17:52 .gitignore
-rw-r--rw-  1 root www-data   1125 ene  3 17:52 package.json
-rw-r--rw-  1 root www-data   1040 ene  3 17:52 phpunit.xml
drwxr-xrwx  4 root www-data   4096 ene  3 17:52 public
-rw-r--rw-  1 root www-data   3550 ene  3 17:52 readme.md
drwxr-xrwx  5 root www-data   4096 ene  3 17:52 resources
drwxr-xrwx  2 root www-data   4096 ene  3 17:52 routes
-rw-r--rw-  1 root www-data    563 ene  3 17:52 server.php
drwxrwxrwx  5 root www-data   4096 ene  3 17:52 storage
drwxr-xrwx  4 root www-data   4096 ene  3 17:52 tests
drwxr-xrwx 36 root www-data   4096 mar  8 07:38 vendor
-rw-r--rw-  1 root www-data    549 ene  3 17:52 webpack.mix.js

El directorio public ejerce de DocumentRoot. Allí encontraremos el index.php que da entrada a nuestra aplicación web así como las hojas de estilos, etc. El fichero .env que vemos aquí arriba en el directorio raiz de nuestra aplicación es el fichero de configuración principal. De hecho, puesto que vamos a empezar a trabajar con bases de datos en este momento podemos aprovechar para editar las siguientes directivas:

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=laravel
DB_USERNAME=laravel
DB_PASSWORD=secreto

Importante: aunque usemos mariadb la directiva DB_CONNECTION debe de ser mysql porque Laravel no entiende otra y, a fin de cuentas, ambas son compatibles a nivel binario. Para que Laravel sea capaz de hacer uso de esa base de datos debemos de crearla. A ella y al usuario que le hemos dicho que va a usar para manejarla. Entramos en nuestro gestor (mysql o mariadb) y ejecutamos lo siguiente:

CREATE DATABASE laravel;
CREATE USER laravel@localhost IDENTIFIED BY 'secreto';
GRANT ALL ON laravel.* TO laravel@localhost;

Vamos ahora a crear nuestro sistema de autenticación. Laravel viene ya con un módulo llamado User.php que reside en el directorio app. Para generar el resto de lo que necesitamos ejecutamos lo siguiente:

php artisan make:auth
php artisan migrate

La primera línea crea el código y rutas necesario para la gestión de usuarios. En particular, creará o modificará los siguientes ficheros:

routes/web.php
resources/views/auth/login.blade.php
resources/views/auth/register.blade.php
resources/views/auth/passwords/email.blade.php
resources/views/auth/passwords/reset.blade.php

La segunda instrucción crea la estructura de tablas necesaria en la base de datos que hemos configurado previamente. Si ahora volvemos a cargar la web de nuestro aplicación veremos que en la esquina superior derecha tenemos dos nuevos enlaces correspondientes a las funcionalidades de Login y Registro:

Laravel 5.6 con la funcionalidad de login y registro

Las pantallas de registro y login por defecto son estas:

Pantalla de registro en Laravel 5.6
Pantalla de login en Laravel 5.6

Y una vez hecho login vemos que en la barra de menú se nos identifica con nuestro nombre de usuario y tenemos la posibilidad de cerrar sesión:

Logout en Laravel 5.6

Si le echamos un vistazo a “las tripas” vemos que nos ha creado dos tablas una de las cuales, la de usuarios, es la que guardará la información relativa a los registros de usuarios.
Tablas creadas por Laravel 5.6 para la autenticación de usuarios

Además, tal y como está mandado, vemos que no almacena las contraseñas en claro sino un hash de las mismas:

hash de las passwords en Laravel 5.6

La castellanización de los recursos es tan sencilla como editar alguno de los ficheros php que hemos indicado anteriormente. Por ejemplo, el fichero login.blade.php es el que contiene la ventana de login y register.blade.php la de registro. Con muy poco esfuerzo tendremos las ventanas anteriores en perfecto castellano. Pero eso ya os lo dejo a vosotros 😉

Chuletillas (y XXXXVIII) – Cambiar el formato de tablas de MySQL o MariaDB de Antelope a Barracuda (para instalar o actualizar Moodle)

chuletaLas últimas versiones de moodle exigen que las tablas usen InnoDB con formato Barracuda en lugar de Antelope. De hecho, en algunos casos puede que la actualización falle sólo por el hecho de no cumplir este requisito y sin que medie ningún comentario informativo acerca de cual es el origen del problema.

Para evitar este problema tenemos que añadir las siguientes líneas en el archivo my.cnf de configuración de mysql o mariadb:

innodb_large_prefix=ON
innodb_file_format=Barracuda
innodb_file_per_table=ON
innodb_file_format_check=ON
innodb_file_format_max=Barracuda

No soy un gran experto en bases de datos, mi lector habitual ya lo sabe, pero tengo entendido que la principal ventaja que aporta Barracuda es la compresión de datos. Quién quiera hablar sobre ello con propiedad puede echarle un vistazo a este texto. En cualquier caso, si quieres seguir usando moodle no tienes mas remedio que pasar por el aro. Son lentejas, ya sabes 😉