Incluir valores php_value con FastCGI/PHP-FPM

En ocasiones, los clientes, al migrar webs de servidores antiguos a nuevas plataformas, observamos que las webs fallan por los valores php_value en los .htaccess, al ejecutar los sitios bajo FastCGI/PHP-FPM.

Pues bien, existe una forma de utilizar valores tipo php_value como se realiza al usar modulo apache, pero bajo FastCGI, esto se realiza mediante ficheros .user.ini. Es decir, en la ruta en la que teníamos nuestro .htaccess con valores php_value, generaremos un fichero .user.ini en el que añadiremos las variables de PHP con la sintaxis:

Continue reading

Liberar kernels antiguos en CentOS

La entrada de hoy es una solución sencilla cuando actualizamos el kernel de nuestro sistema operativo CentOS y la partición boot comienza a llenarse por el almacenamiento de kernels antiguos en “spare”.

Para ello, vamos a utilizar el paquete yum-utils, por lo que procederemos a instalarlo:

 

Mediante el cual podemos hacer uso del comando package-cleanup:

 

Con este comando, liberaremos todos los kernels antiguos excepto los dos más nuevos.

 

¡Espero que os sirva!

Evitar uso abusivo de la swap en CentOS

La swap es un espacio de disco reservado para que el sistema haga uso de el en caso de que el sistema lo requiera, bien porque la RAM está llena, o bien por volcado de RAM en disco de datos que no son usados y no están en buffers o caché.

Si bien la swap es útil y generalmente necesaria, en ocasiones la configuración del servidor no es correcta, realizando un uso abusivo de esta memoria y no utilizando la memoria RAM. Al ser la swap memoria en disco, la lectura y escritura a esta es mucho más lenta que la RAM y puede desembocar en problemas de rendimiento.

Por ello, os voy a enseñar a configurar la “inercia” del sistema operativo a la hora de usar la swap, a través de la “swappiness”.

Existen dos formas de configurar el uso de la swap, bien de forma permanente, o bien para la sesión activa, de forma que cuando se reinicie el servidor esta configuración se perderá.

El comando para establecer la configuración de forma temporal es:

 

Y para establecerlo de forma definitiva, editamos /etc/sysctl.conf, añadiendo:

 

El valor que indiquemos es determinante, siendo 100 un valor que provocará que el sistema abuse de la swap, y un valor 0 provocará que el sistema prácticamente no la use en ningún momento.

IMPORTANTE: Debemos tener cuidado con el valor que establecemos, pues una mala configuración puede provocar desbordamientos de memoria que provoquen la caída del sistema, por ello, en caso de que observemos abuso de memoria swap, se recomienda hacer primero cambios en caliente con el comando “echo 30 > /proc/sys/vm/swappiness”, e ir cambiando valores hasta que encontremos uno en el que el uso de swap sea correcto para nosotros. Entonces, procederemos a establecer el valor como permamente.

 

Convertir toda una base de datos a InnoDB

En ocasiones necesitaremos cambiar el motor de todas las tablas a InnoDB en lugar de MyISAM, porque el cambio de una única tabla no tiene porque solucionar los bloqueos provocados por MyISAM, para ello, existe una forma sencilla que procedo a explicar.

IMPORTANTE: Siempre es necesario realizar un dump de la bbdd que vamos a modificar.

Para proceder a modificar el motor de toda una BD a InnoDB, lanzaremos en MySQL el siguiente comando:

 

Donde deberemos editar MI_BASE_DE_DATOS por el nombre de la BD en cuestión.

Este comando nos generará un conjunto de queries con la siguiente sintaxis:

 

Simplemente debemos copiar estas queries y lanzar las mismas.

Con esto, habremos convertido todas las tablas de una BBDD a InnoDB. No olvidemos tras este cambio (o previo al mismo) optimizar MySQL para funcionar con InnoDB.

Crecimiento del fichero ibdata1 en MySQL: Que es y como purgarlo

Es relativamente común encontrarse con situaciones de falta de espacio en disco debido a un crecimiento del tamaño del fichero ibdata1 ubicado en /var/lib/mysql.

ibdata1 es un fichero de InnoDB que guarda, por defecto, los metadatos de InnoDB, el buffer de cambios, el buffer de doble escritura, los undo logs y los datos de las tablas en InnoDB.

Este fichero crece de tamaño a medida que se hacen transacciones, se realizan cambios en las tablas, etc, pero nunca disminuye de tamaño, por lo que si, por ejemplo, un día añadimos 4 gb en información en una tabla ibdata1 aumentará en consecuencia, y si al día siguiente borramos esos 4 gb, ibdata1 permanecerá con el mismo tamaño, aunque cierto es que de, por ejemplo, añadir tras esto 2 gb más de información a una tabla, ibdata1 no aumentará puesto que “internamente” tiene 4 gb libres.

Esto es un problema, puesto que no podemos purgar este fichero,  y en ocasiones tendremos problemas de espacio en disco por situaciones internas de la BBDD que escapan a nuestro control.

¿Como lo solucionamos?

La solución consiste en configurar InnoDB para que el fichero ibdata1 guarde los datos de las tablas en ficheros separados, de esta forma generará ficheros .frm e .ibd por cada tabla, y en caso de querer optimizar una tabla y vaciar datos obsoletos, podremos realizarlo con OPTIMIZE TABLE. Lamentablemente, para configurar InnoDB de esta forma, es necesario primero purgar el fichero ibdata1, y para ello, hay que borrar todas las bases de datos y recrearlas, explico el proceso.

 

1. Procedemos a realizar un dump de todas las bases de datos con mysqldump, ya sea una a una:

O, en su defecto todas a la vez:

Dropamos/Borramos todas las bases de datos EXCEPTO mysql_schema, mysql y performance_schema (podéis usar el siguiente comando)

Paramos MySQL/MariaDB

Editamos my.cnf y añadimos las siguientes líneas

(El tamaño de innodb_buffer_pool_size debe asignarse en función de la memoria, si es un servidor sólo dedicado a MySQL, un 80% de la memoria va bien, si es compartido con Apache y correo, etc, con un 30% de memoria debería bastar, pero es importante que innodb_log_file_size sea un 25% de buffer_pool_size)

Eliminamos el fichero ibdata1 y los logfiles:

Arrancamos MySQL de nuevo

Volcamos los dumps de las bbdd a MySQL.

Con esto, habremos purgado el ibdata1 y tendremos cada tabla en un fichero propio, pudiendo optimizar la misma si así lo queremos.