Debian

Instalar PHP 7.2 en Debian 9 para Drupal 8

root — Sat, 20 Oct 2018 23:19:02 +0000

Instalar PHP 7.2 en Debian 9 para Drupal 8

Domingo, Octubre 21, 2018 - 01:19

Debian 9 trae por defecto en sus repositorios PHP 7.0.32. Desde Drupal 8.5.0 ya se soporta PHP 7.2, y por si no os habeis dado cuenta, Drupal 8 dejará de soportar PHP 5.5 y 5.6 el día 6 de marzo de 2019, así que ya va siendo hora de actualizar.

Subir a 7.2 es bastante sencillo:

sudo apt install apt-transport-https lsb-release ca-certificates
sudo wget -O /etc/apt/trusted.gpg.d/php.gpg https://packages.sury.org/php/apt.gpg
sudo sh -c 'echo "deb https://packages.sury.org/php/ $(lsb_release -sc) main" > /etc/apt/sources.list.d/php.list'
sudo apt update

Una vez actualizado, podemos comprobar la versión instalada con:

php -v

Si no se ha actualizado automáticamente, podemos actualizar php a mano:

sudo apt install php7.2 php7.2-cli php7.2-common php7.2-curl php7.2-gd php7.2-json php7.2-mbstring php7.2-mysql php7.2-opcache

Una vez actualizado PHP, hay que actualizar el módulo que usamos en el servidor web. Para Apache:

sudo a2enmod php7.2

sudo a2dismod php7.1

Y reiniciar:

sudo service apache2 restart

Si estáis utilizando composer, es una buena idea incluir la versión de PHP a utilizar:

composer config platform.php 7.2

Y actualizar todo:

composer update

En algunos casos es buena idea borrar el fichero composer.lock antes de correr el update.

Añadir nuevo comentario

Revertir a una version anterior un paquete en Debian

root — Sat, 14 Jul 2018 20:10:45 +0000

Revertir a una version anterior un paquete en Debian

Sábado, Julio 14, 2018 - 22:10

Debian

Linux

Una de las diversiones de utilizar la versión Sid (inestable) de Debian, es actualizar paquetes. Cualquier cosa puede pasar.

Hoy tenia un rato libre y le he dado al apt upgrade a ver que pasaba. Lo que ha pasado es que VirtualBox ha dejado de funcionar, y no arranca las máquinas virtuales, con este error:

virtualbox: fails to start vm (VERR_LDRELF_RELOCATION_NOT_SUPPORTED)

Después de revisar el hilo del error, parece que lo mas rápido es bajar de versión el paquete, ya que la última instalada es la 5.2.14-dfsg-4, por lo que parece, la versión anterior (5.2.14-dfsg-3 en este caso) parece que funciona bien.

Así que voy a intertar explicaros como he hecho para bajar el paquete de versión, sin tener que bajar e instalar a mano el paquete, sino usando los repos de Debian.

Primero, vamos a snapshot.debian.org y buscamos el paquete que nos da problemas, en mi caso virtualbox. Podemos usar la caja de búsqueda o rebuscar a mano por el índice, lo que os de mas morbo.

Hay que seleccionar la versión que buscamos, y debajo del nombre del paquete vereis algo como esto:

Seen in debian on 2018-07-12 14:59:27 in /pool/contrib/v/virtualbox.

Al pinchar en el enlace, llegamos a una dirección de este tipo:

http://snapshot.debian.org/archive/debian/20180712T211510Z/pool/contrib…

Una vez encontrada esta URL, vamos a usarla configurando una nueva fuente para Apt:

cd /etc/apt/sources.list.d

Y creamos un nuevo archivo de fuente:

sudo vi virtualbox.list

Tenemos que usar parte de la URL de antes, sin poner la parte final. En mi caso añado la versión unstable, y el contrib, porque el paquete es de contrib. Quedaría algo así:

deb https://snapshot.debian.org/archive/debian/20180712T211510Z/ unstable contrib

Guardamos el archivo y actualizamos el Apt para que incluya el nuevo índice:

apt update

Una vez termine de actualizar, podemos sacar la lista de versiones disponibles del paquete que necesitamos:

apt-cache showpkg virtualbox

E instalar la que necesitemos, usando el nombre de la version en el mismo comando de Apt:

apt install virtualbox=5.2.14-dfsg-3

En mi caso, el paquete virtualbox tenía un paquete recomendado llamado virtualbox-qt, que Apt muy amablemente me indicó al tratar de instalarlo, así que decidí bajarlo de versión también por si acaso:

apt install virtualbox=5.2.14-dfsg-3 virtualbox-qt=5.2.14-dfsg-3

Con esto se actualizaron los paquetes necesarios para esas versiones, y encima tuve la suerte de que VirtualBox volvió a funcionar perfectamente. Ahora veremos que pasa cuando salga la version siguiente (5.2.14-dfsg-3) y quiera actualizarlo...

Ya os contaré.

Añadir nuevo comentario

Como instalar composer en Debian 8

root — Sat, 30 Sep 2017 23:58:12 +0000

Como instalar composer en Debian 8

Domingo, Octubre 1, 2017 - 01:58

Debian

Drupal

Instalar composer en Debian 8 es muy sencillo:

$ cd /usr/src
$ sudo apt-get install curl php5-cli
$ curl -sS https://getcomposer.org/installer | sudo php -- --install-dir=/usr/local/bin --filename=composer

Después podemos comprobar si se ha instalado correctamente:

$ composer --version

A día de hoy, este comando muestra:

Composer version 1.5.2 2017-09-11 16:59:25

Añadir nuevo comentario

Error ERROR 1071 (42000) al importar una base de datos Drupal

root — Sat, 18 Mar 2017 17:28:08 +0000

Error ERROR 1071 (42000) al importar una base de datos Drupal

Sábado, Marzo 18, 2017 - 18:28

Tratando de importar una copia de base de datos que había creado con drush sql-dump en otro servidor, me he encontrado con este error de MySQL:

ERROR 1071 (42000) at line 25: Specified key was too long; max key length is 767 bytes

El comando que estaba usando era bastante normal:

drush sql-cli <  ../backup.sql

Después de intentar varias opciones, también he llegado a ver este otro error:

ERROR 1709 (HY000) at line 25: Index column size too large. The maximum column size is 767 bytes.

La versión de MySQL que estaba usando es 5.6.30-1, como podéis ver aquí:

dpkg -l | grep mysql-server
ii  mysql-server                                  5.6.30-1                               all          MySQL database server (metapackage depending on the latest
version)
ii  mysql-server-5.6                              5.6.30-1                               amd64        MySQL database server binaries and system database setup
ii  mysql-server-core-5.6                         5.6.30-1                               amd64        MySQL database server binaries

El problema venia de la configuración de INNODB en mi servidor, y la solución es bastante sencilla, basta con editar el fichero de configuracion de MySQL (como root o usando sudo), que en Debian está en:

vi /etc/mysql/my.cnf

Si no teneis ese fichero puede que este aquí:

vi /etc/mysql/mysql.conf.d/mysqld.cnf

Tenemos que incluir las siguientes líneas de configuración en la sección de [mysqld]:

innodb_file_format = true
innodb_file_per_table=true
innodb_file_format=barracuda

Después reiniciamos el servidor y listo:

service mysql restart

Ahora si intentamos importar la base de datos de nuevo no deberíamos tener problemas.

EDIT:

Si no podemos tocar la configuración del servidor, podemos ejecutar esto directamente en mysql antes de ejecutar nuestra query:

SET @@global.innodb_large_prefix = 1;

Referencias:

https://dev.mysql.com/doc/refman/5.6/en/innodb-parameters.html#sysvar_innodb_large_prefix

Comments

gracias

Gracias por este articulo, me estaba volviendo loco con esto

Añadir nuevo comentario

HTTPS con un certificado gratuito de letsencrypt.org y Certbot

root — Mon, 27 Feb 2017 21:03:16 +0000

HTTPS con un certificado gratuito de letsencrypt.org y Certbot

Lunes, Febrero 27, 2017 - 22:03

Let’s Encrypt es una autoridad certificadora (CA) abierta, gratuita, y libre. Llevan funcionando menos de un año, desde 2016, y se puede decir que es un servicio público, dirigido a promover y facilitar la obtención y configuración de certificados de seguridad para la web. Lo que ofrecen son certificados X.509 por dominio que podemos usar para TLS.

https://letsencrypt.org/

Hay varias organizaciones involucradas en el proyecto, siendo la principal la Internet Security Research Group (ISRG), junto a otras como Linux Foundation o Mozilla Foundation, pero también gigantes como Akamai o Cisco Systems. Es decir, que hay gente grande detrás, y el proyecto es bastante interesante, esperemos que dure.

Hasta ahora conseguir un certificado de seguridad para configurar HTTPS como es debido era bastante engorroso, además de que solía ser bastante caro. Últimamente los precios habían comenzado a bajar, pero ahora podemos conseguir un certificado propio por la cara, y con una instalación muy sencilla.

La principal ventaja del servicio se basa en la automatización de todo el proceso. El objetivo es configurar un servidor HTTPS y obtener un certificado de confianza para los navegadores sin intervención humana. Y dejarme deciros que me ha funcionado de verdad, y a la primera.

Esta automatización es la clave de todo el asunto, primero porque los certificados que nos ofrecen solamente son válidos por 90 días, lo que nos va a obligar a configurar la renovación de forma automática si no queremos estar cada tres meses renovando el certificado de forma manual.

Para esto han ideado un protocolo llamado ACME (Automated Certificate Management Environment), y el truco consiste en instalar un agente que se encargue de realizar automáticamente la petición y renovación del certificado, validando el solito nuestros dominios. Tenemos unos cuantos disponibles, pero el que recomiendan desde letsencrypt.org es Certbot:

https://certbot.eff.org

Certbot esta empaquetado en los repos de Debian, pero deberemos usar el repositorio de backports. Para ello basta con incluir una línea en nuestro fichero /etc/apt/sources.list. Si estáis usando Jessie (Debian 8) será:

deb http://ftp.debian.org/debian jessie-backports main

Después actualizamos:

apt-get update

Ahora ya podemos instalar el cliente de Certbot:

$ sudo apt-get install python-certbot-apache -t jessie-backports

Una vez instalado, ya podemos ejecutarlo, si estamos usando Apache, así:

$ certbot --apache

Y ya está. Lo juro. El instalador nos hará una serie de preguntas sobre los certificados que queremos instalar y listo. En mi caso tenia un Apache2 con varios VirtualHosts con diferentes nombres de dominio y alias, todos por el puerto 80. El instalador hizo solito todo esto:

Realizo una copia de cada fichero de configuración de VirtualHost, añadiendo -le-ssl.conf al nombre, y configuró en ellos el certificado.
En cada VirtualHost original, añadió una redirección automática a su versión de HTTPS
Configuró un servicio en Cron /etc/cron.d/certbot para realizar automáticamente la renovación de los certificados.
Reinicio el servidor Apache para cargar la nueva configuración.

Si no os hace mucha gracia que os toque la configuración, o tenéis algo realmente chungo montado, también podemos hacer que solamente consiga el certificado, y configurarlo nosotros a mano, así:

$ certbot --apache certonly

En mi caso, añadió las siguientes líneas a mis archivos de VirtualHost originales en el 80:

RewriteEngine on
RewriteCond %{SERVER_NAME} =xxxxx.com [OR]
RewriteCond %{SERVER_NAME} =www.xxxxx.com
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,QSA,R=permanent]

Los nuevos ficheros para SSL que creó Certbot son copias de los que yo tenía, en los que se añade la configuración del certificado:

SSLCertificateFile /etc/letsencrypt/live/xxxxxxx/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/xxxxxxxx/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf

Y este es el archivo que añade al Cron en /etc/cron.d/certbot para automatizar la renovación de los certificados:

# /etc/cron.d/certbot: crontab entries for the certbot package
#
# Upstream recommends attempting renewal twice a day
#
# Eventually, this will be an opportunity to validate certificates
# haven't been revoked, etc.  Renewal will only occur if expiration
# is within 30 days.
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(3600))' && certbot -q renew

Podemos hacer una simulación del proceso de renovación de los certificados con este comando:

certbot renew --dry-run

Esto nos dará una idea de si funcionará o no cuando lo tenga que hacer el solo.

De momento, está funcionando perfectamente. Ya veremos cuando llegue la primera renovación...

Referencias

Proceso de como funciona completo: https://letsencrypt.org/how-it-works/
Porque 90 días: https://letsencrypt.org/2015/11/09/why-90-days.html
Lista de clientes soportados: https://community.letsencrypt.org/t/list-of-client-implementations/2103
Let's Encrypt en Wikipedia
Debian backports
How to install Certbot

Añadir nuevo comentario

Problemas con Baloo en KDE4 en Debian Sid

root — Mon, 19 Oct 2015 10:20:25 +0000

Problemas con Baloo en KDE4 en Debian Sid

Lunes, Octubre 19, 2015 - 12:20

Linux

Debian

Sid

Con las últimas actualizaciones el indexador de Baloo se esta volviendo loco y se lleva la CPU como un salvaje.

Como no se puede desactivar con un servicio o por medio del /etc/init.d, y no quería que siguiese activo, he estado buscando como desactivarlo. Al final lo que he hecho es editar el fichero de configuración

$HOME/.kde/share/config/baloofilerc

y añadir esto:

Indexing-Enabled=false

Después maté el proceso baloo_file_extractor con un kill y se acabó el problema.

En este hilo de los foros de Ubuntu teneis mas info.

Añadir nuevo comentario

Instalar compilador de less en Debian

root — Fri, 02 Oct 2015 23:24:29 +0000

Instalar compilador de less en Debian

Sábado, Octubre 3, 2015 - 01:24

Linux

Debian

less

Primero vamos a probar la versión rápida y sencilla, que es con el paquete de Debian, que instalamos como root:

# apt-get install node-less

Esto nos instalará el paquete principal de node.js y el compilador de less. Ahora ya podemos probar el compilador, con salida por stdout:

$ lessc styles.less

O con salida a un fichero

$ lessc styles.less > styles.css

Al ser un paquete de Debian, es posible que esta versión no este muy actualizada. En mi caso en el momento de instalarlo la versión que ha traido es esta (en Debian Sid):

$ lessc --version
lessc 1.6.3 (LESS Compiler) [JavaScript]

Si queremos tirar de una versión mas actualizada, es mejor instalarlo de otra manera, que es con el gestor de paquetes de node.js: npm. Para ello, lo instalamos tirando del paquete de Debian:

# apt-get install npm

Y después instalamos less usando npm, con la opción -g para que lo instale global todo el sistema (hacer esto como root):

# npm install -g less

Y comprobamos la versión, mucho mas nueva:

lessc --version
lessc 2.5.3 (Less Compiler) [JavaScript]

En mi caso, al instalar con npm, se hace un lío con el ejecutable de node.js, que en unos sitios es node y en otros nodejs, y al ejecutar da errores como este:

lessc
/usr/bin/env: node: No existe el fichero o el directorio

Esto tiene fácil solución, creando un enlace dinámico para que lo encuentre (también hay que hacer esto como root):

# ln -s /usr/bin/nodejs /usr/bin/node

Eso es todo. Supongo que la mayoría funcionara también en Ubuntu, pero eso ya os lo dejo a vosotros...

Añadir nuevo comentario

Encontrar procesos que causan bloqueos de IO (iowait)

root — Thu, 11 Jun 2015 22:21:19 +0000

Encontrar procesos que causan bloqueos de IO (iowait)

Viernes, Junio 12, 2015 - 00:21

Linux

Debian

IOWait es la medida del tiempo que los procesos de la CPU pasan sin hacer nada, en espera de poder hacer una operación de IO, es decir, leer o escribir en el disco.

Generalmente es un indicador claro de un cuello de botella en el sistema, y se produce cuando alguno de los discos (o todos) no dan a basto con operaciones de lectura y/o escritura.

Los síntomas suelen ser bastante claros, en forma de bajada general de rendimiento, largas esperas, etc.

La forma más sencilla y estándar de comprobar la carga de iowait que tenemos es usar el comando top, que tenemos disponible en cualquier sistema GNU / Linux, y en muchos casos no es necesario ni siquiera tener permisos de root. En la primera parte de la salida del top es donde tenemos esta información en la línea de %Cpu(s), marcada como wa.

top - 20:26:25 up 5 days, 22:50,  3 users,  load average: 0,02, 0,31, 0,54
Tasks: 220 total,   1 running, 219 sleeping,   0 stopped,   0 zombie
%Cpu(s):  3,3 us,  1,8 sy,  0,0 ni, 94,3 id,  0,7 wa,  0,0 hi,  0,0 si,  0,0 st
KiB Mem :  7614832 total,   144824 free,  2784012 used,  4685996 buff/cache
KiB Swap:  7815164 total,  7718864 free,    96300 used.  4251800 avail Mem

En este caso, según la salida de top, tenemos 3,3% de procesos de usuario (us), 1,8% un de sistema (sy), 0,0% de procesos de baja prioridad (ni), un 94,3% de CPU sin hacer nada, o en estado idle (id), y solamente un 0,7% de iowait (wa), lo cual está bastante bien. El resto está a cero, y si hacemos la suma sale un 100,1 %. Cosas del redondeo...

Para refrescar, según la información de man del comando top...

us: user cpu time (or) % CPU time spent in user space
sy: system cpu time (or) % CPU time spent in kernel space
ni: user nice cpu time (or) % CPU time spent on low priority processes
id: idle cpu time (or) % CPU time spent idle
wa: io wait cpu time (or) % CPU time spent in wait (on disk)
hi: hardware irq (or) % CPU time spent servicing/handling hardware interrupts
si: software irq (or) % CPU time spent servicing/handling software interrupts
st: steal time - - % CPU time in involuntary wait by virtual cpu while hypervisor is servicing another processor (or) % CPU time stolen from a virtual machine

Ahora veamos un ejemplo de proceso generando esperas de iowait. Lo que voy a hacer es ejecutar un comando sencillo pero que va a generar muchas operaciones de lectura, en este caso, un simple du para comprobar el espacio usado, pero sobre el raiz del sistema de ficheros:

du -h /

Al ejecutar el comando, los resultados del top ya empiezan a mostrar una subida del iowait.

Tasks: 226 total,   3 running, 223 sleeping,   0 stopped,   0 zombie
%Cpu(s): 11,5 us,  6,5 sy,  2,0 ni, 60,8 id, 19,0 wa,  0,0 hi,  0,1 si,  0,0 st
KiB Mem :  7614832 total,    52068 free,  3388748 used,  4174016 buff/cache
KiB Swap:  7815164 total,  7711876 free,   103288 used.  3580684 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                      
 2356 charles   20   0  882788 147036  83488 S  17,6  1,9   0:30.12 chrome                                                       
 2513 charles   20   0    7076   3156   2384 D  14,6  0,0   0:02.09 du                                                           
12156 charles   20   0  564288  62128  43656 S  13,6  0,8   0:36.61 konsole                                                      
 2442 charles   20   0  623544 182416 134288 S   7,0  2,4  26:52.05 chrome

Aquí podemos ver que el %wa ha subido al 19,0%, con lo que vamos a empezar a notar problemas de rendimiento. En este caso, y solamente usando el comando top, podemos identificar rápidamente el proceso, fijándonos en la columna de estado (S) del top, vemos que hay un proceso du que tiene su estado a D. El estado D significa 'uninterruptible sleep', lo que suele ser indicativo de que el proceso está esperando por una operación de IO.

También para refrescar, esta es la lista de estados que muestra el man del comando top.

D = uninterruptible sleep
R = running
S = sleeping
T = stopped by job control signal
t = stopped by debugger during trace
Z = zombie

Normalmente, los procesos en top estarán en estado S (durmiendo a gusto) o R (corriendo). Si empezamos a ver procesos en D, es señal de que estamos teniendo lo esperas largas de IO.

Para sacar algo más de información de que están haciendo nuestros procesos conflictivos, otro comando muy útil y más específico el top es iotop. Ojo, porque este no viene "de serie" en la mayoría de distribuciones, aunque es muy recomendable tenerlo a mano. En Debian, lo tenemos sencillo:

apt-get install iotop

Con iotop tenemos un listado del uso de operaciones de IO por procesos. La primera información que nos muestra son los totales de lectura y escritura del sistema, y después las de cada proceso ordenados por actividad. Y aquí sí que podremos ver de forma muy clara cuáles son los procesos que más recursos están utilizando.

Total DISK READ :    1265.11 K/s | Total DISK WRITE :       0.00 B/s
Actual DISK READ:     875.85 K/s | Actual DISK WRITE:       0.00 B/s
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND                                                                  
14344 be/4 charles  1265.11 K/s    0.00 B/s  0.00 % 64.06 % du -h /
    1 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % init
    2 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [kthreadd]
    3 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [ksoftirqd/0]
    5 be/0 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [kworker/0:0H]

Ahora si podemos ver sin duda que el proceso du es el que está leyendo del disco como si no hubiese mañana, y bueno, en este caso la solución es sencilla: podemos matarlo con un kill, con el PID que nos da el iotop.

kill 14344

Si queremos seguir investigando un poco más, podemos usar el comando lsof, que nos va a mostrar un listado de los archivos que está utilizando un proceso, con su PID:

lsof -p 14344

La salida mostrará algo parecido a lo que vemos a continuación, y en muchos casos también nos puede dar pistas de lo que está sucediendo.

COMMAND   PID    USER   FD   TYPE DEVICE SIZE/OFF     NODE NAME
du      14883 charles  rtd    DIR  252,0     4096        2 /
du      14883 charles  txt    REG  252,0   113576  5796815 /usr/bin/du
du      14883 charles  mem    REG  252,0   341146 10477596 /usr/share/locale/es/LC_MESSAGES/coreutils.mo
du      14883 charles  mem    REG  252,0  1729984 13221996 /lib/x86_64-linux-gnu/libc-2.19.so
du      14883 charles  mem    REG  252,0   140928 13221991 /lib/x86_64-linux-gnu/ld-2.19.so
du      14883 charles  mem    REG  252,0  1607632  4309902 /usr/lib/locale/locale-archive
du      14883 charles  mem    REG  252,0   151111 16318536 /usr/share/locale/es/LC_MESSAGES/libc.mo
du      14883 charles  mem    REG  252,0    26258  4322370 /usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache
du      14883 charles    0u   CHR  136,1      0t0        4 /dev/pts/1
du      14883 charles    1u   CHR  136,1      0t0        4 /dev/pts/1
du      14883 charles    2u   CHR  136,1      0t0        4 /dev/pts/1

Otro comando útil para estos casos es iostat, que nos muestra estadísticas de operaciones de IO sobre los discos. En este caso, no tenemos información de los procesos que las causan, solamente las operaciones globales que se están realizando, y principalmente nos va a permitir descubrir, o confirmar, en cuál de nuestros discos es en el que se están produciendo los bloqueos.

Al igual que con iotop, normalmente tendremos que instalarlo a parte. En Debian:

apt-get install iostat

La primera muestra de iostat nos muestra el resumen total desde que levantó la máquina, y en las siguientes iteraciones se muestra la estadística desde el informe anterior, y es donde podremos ver que está pasando.

iostat 2

La salida de iostat, con iteraciones cada 2 segundos:

Linux 4.2.0-1-amd64 (totoro2)    20/10/15        _x86_64_        (4 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           2,38    0,32    1,15    2,69    0,00   93,45

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda              31,91        84,58       725,86    7867640   67517095
dm-0             37,82        83,47       723,61    7764404   67308108
dm-1              0,64         0,59         2,00      54648     185684

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           4,79    0,00    2,52   24,34    0,00   68,35

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda             573,50      2304,00        18,00       4608         36
dm-0            580,50      2304,00        18,00       4608         36
dm-1              0,00         0,00         0,00          0          0

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           5,51    0,00    2,38   23,53    0,00   68,59

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda             197,00       780,00        10,00       1560         20
dm-0            197,00       780,00        10,00       1560         20
dm-1              0,00         0,00         0,00          0          0

En este caso, vemos que tenemos un iowait de alrededor de un 24%, que se está produciendo en el disco sda. Este comando es muy útil cuando tenemos varios, por ejemplo, y podemos combinar con lsof para indagar más sobre los ficheros que están causando el problema.

A partir de aquí, las soluciones dependen del tipo de problema que tengamos entre mano, y eso ya daría no para otro artículo, sino para un libro entero, pero siempre podremos recurrir a nuestro querido kill, al menos para quedarnos agusto.

Para ampliar un poco de información, y como fuentes que he utilizado para consulta, recomiendo varias lecturas interesantes, aunque todas en inglés.

http://serverfault.com/questions/12679/can-anyone-explain-precisely-wha…

http://stackoverflow.com/questions/666783/how-to-find-out-which-process…

http://bencane.com/2012/08/06/troubleshooting-high-io-wait-in-linux/

Debian

Instalar PHP 7.2 en Debian 9 para Drupal 8

Instalar PHP 7.2 en Debian 9 para Drupal 8

Añadir nuevo comentario

Revertir a una version anterior un paquete en Debian

Revertir a una version anterior un paquete en Debian

Añadir nuevo comentario

Como instalar composer en Debian 8

Como instalar composer en Debian 8

Añadir nuevo comentario

Error ERROR 1071 (42000) al importar una base de datos Drupal

Error ERROR 1071 (42000) al importar una base de datos Drupal

Referencias:

Comments

gracias

Añadir nuevo comentario

HTTPS con un certificado gratuito de letsencrypt.org y Certbot

HTTPS con un certificado gratuito de letsencrypt.org y Certbot

Referencias

Añadir nuevo comentario

Problemas con Baloo en KDE4 en Debian Sid

Problemas con Baloo en KDE4 en Debian Sid

Añadir nuevo comentario

Instalar compilador de less en Debian

Instalar compilador de less en Debian

Añadir nuevo comentario

Encontrar procesos que causan bloqueos de IO (iowait)

Encontrar procesos que causan bloqueos de IO (iowait)

Comments

IO Wait

buena info, se agradece

IO Wait

Util

Me ha resultado muy util

Artículo IO

Añadir nuevo comentario