David Fernandez

A veces en el fichero error_log del Apache nos puede aparecer un mensaje como el siguiente:

[Thu Feb 04 15:23:42 2010] [notice] child pid 1241 exit signal Segmentation fault (11)

Revisando el fichero error_log y el access_log no encontramos más información sobre la posible causa del error. Para obtener más información lo que podemos hacer es activar los core dumps en el Apache. Para ello añadiremos al fichero de configuración la directiva:

CoreDumpDirectory /var/tmp

En esta directiva le indicamos el directorio donde guardar los dumps. Deberá ser un directorio escribible por el usuario con el que se ejecuta Apache (apache, nobody,…). Ahora se reinicia el servidor Apache.

Cuando se produzca el error, se nos debería generar un fichero /var/tmp/core.nnnn

Para poder analizar este fichero podemos usar un programa como gdb (the GNU project debugger).

# gdb /usr/sbin/httpd core.nnnn

Al ejecutar este comando obtendremos información sobre el error y con un poco de suerte podremos averiguar que biblioteca ha sido la causante del error.

DAVID FERNANDEZ ACIN Apache Apache, core dump, debug, gdb, Linux

En determinadas ocasiones puede sernos útil escribir algún mensaje en el syslog del servidor, ya que esta herramienta es más habitual que sea monitorizada a diferencia de escribir el mensaje en un fichero de log normal. Para hacer esto desde un script disponemos del comando logger.

# logger -i -p $level $mensaje

La opción -i hace que se guarde el PID del proceso que ha enviado el mensaje.

Con la opción -p indicamos el nivel del mensaje. Hay varios valores (consultar el man del comando), pero unos valores habituales son “warning” y “err”.

DAVID FERNANDEZ ACIN Linux Linux, syslog

El IO scheduler de un sistema operativo es la parte del mismo encargada de organizar las operaciones de entrada y salida contra el disco.

En los kernels actuales de Linux (2.6.x) tenemos disponibles varios de estos schedulers (planificadores). Por ejemplo en la distribución Red Hat Linux 5 disponemos de los siguientes:

• noop
• anticipatory
• deadline
• cfq

Cada uno de estos planificadores tiene ventajas e inconvenientes según el tipo de uso que se le vaya a dar al disco del servidor. Por defecto, en Red Hat viene configurado como planificador cfq. El planificador se puede configurar para cada disco del servidor. Podemos ver el planificador con el siguiente comando:

# cat /sys/block/<<disco>>/queue/scheduler

En el caso de MySQL parece que el planificador cfq no es el que proporciona el rendimiento optimo. Parece que los planificador noop o deadline proporcionan mejor rendimiento.

Para cambiar el planificador de nuestro disco lo podemos hacer de dos formas:

• En el arranque del servidor: añadiendo el parámetro elevator=<<nombre-scheduler>> a la línea kernel del gestor de arranque. Esto cambiará el planificador para todos los discos duros de nuestro servidor.
• Mediante el siguiente comando:

# echo "<<nombre-scheduler>>" > /sys/block/<<disco>>/queue/scheduler

La segunda forma permite cambiar el planificador en caliente y también especificar un planificador distinto para cada disco. Por ejemplo, en el caso se un servidor MySQL con un disco para el sistema operativo y otro para los datos del MySQL, podríamos configurar cfq para el disco del sistema operativo y deadline para el disco de los datos.

Más información:

• http://www.kernel-labs.org/?q=blockiolayer
• http://kerneltrap.org/node/7637
• http://www.mysqlperformanceblog.com/2009/01/30/linux-schedulers-in-tpcc-like-benchmark/
• http://planet.mysql.com/entry/?id=19017

DAVID FERNANDEZ ACIN Linux, MySQL Linux, MySQL

Para saber si  un servidor con Linux tiene habilitado el Hyper-Threading sin necesidad de rebotar el servidor, podemos proceder de la siguiente maneara:

Revisamos el contenido de /proc/cpuinfo y nos fijanos en el valor de los campos siblings y cpu cores.

Si el valor de siblings es igual al de cpu cores entonces no tenemos Hyper-Threading habilitado. Si por el contrario, el valor de siblings es el doble que el de cpu cores entonces el Hyper-Threading está habilitado.

Ejemplos:
Hyper-Threading habilitado:

physical id     : 1
siblings        : 4
core id         : 1
cpu cores       : 2

Hyper-Threading NO habilitado:

physical id     : 0
siblings        : 4
core id         : 3
cpu cores       : 4

DAVID FERNANDEZ ACIN Linux CPU, Hardware, Linux

El siguiente script permite borrar unas líneas de un fichero a partir de un patrón dado y borrando líneas adicionales antes y después del patrón buscado.

#!/bin/bash

# Script para borrar lineas de un fichero, a partir de un patron dado
# y borrando n lineas anteriores y posteriores a la buscada.

# Se pasan los siguientes parametros:
#       1 --> Fichero donde borrar las lineas
#       2 --> Patron que cumplira la linea central a borrar
#       3 --> Num lineas antes a borrar
#       4 --> Num lineas despues a borrar

# 1. Comprobación del numero de argumentos en la entrada
EXPECTED_ARGS=4
if [ $# -ne $EXPECTED_ARGS ]
then
 echo "Usage: `basename $0` fichero patron numantes numdespues" > /dev/stderr
 exit 1
fi

file=$1
patron=$2
antes=$3
despues=$4

# Buscamos la linea que contiene el patron a borrar
i=`grep -n "$patron" $file | cut -d":" -f 1`

if [[ -z $i ]]
then
 echo "Patron $patron no encontrado en $file. No se borra nada"
 exit 1
fi

# Seleccionamos las lineas anteriores y posteriores que deseemos borrar
inicio=`expr $i - $antes`
fin=`expr $i + $despues`

# Ahora borramos las lineas en cuestion
sed -i "$inicio,${fin}d" $file

DAVID FERNANDEZ ACIN Linux Linux