[spanish]

Al monitorizar un sistema, una de las variables más básicas a observar es el consumo de CPU, algo que típicamente haremos con top de forma interactiva o con vmstat si queremos automatizar el proceso.

El problema viene al tratar con un sistema con más de una CPU (física o virtual), ya que en este caso vmstat mostrará la media de todas las CPUs. Dependiendo de la arquitectura hardware y/o software nos podemos encontrar con cuellos de botella o bloqueos en el momento que una de las CPUs esté al 100% aunque la otra esté completamente libre, caso en el que vmstat indicaría un 50% idle. Es una situación típica en equipos con una única CPU física pero con HyperThreading.

Una alternativa a vmstat en estos casos es mpstat, del paquete sysstat, que muestra el consumo por CPU de forma independiente. Imprescindible p.ej. a la hora de escribir un script para hacer gráficas con Cacti o lanzar alertas con Nagios.

[/spanish][english]

One of the most basic variables to monitor on a system is CPU usage, something we usually do interactively with top or with vmstat when we want to script the process.

But there’s a problem with multi-CPU systems, with either physical or virtual CPUs, because in these cases vmstat shows the average usage across all CPUs. Depending on the software or hardware architecture, a CPU at 100% can become a bottleneck and produce process blockings ever if the other CPUs are completely idle, while vmstat would show us just a 50% CPU usage. This is quite typical with single CPU systems with HyperThreading technology.

An alternative to vmstat for these situations is mpstat, from the sysstat package, that shows the individual per-CPU usage rates. Very useful when writing a script for displaying graphs with Cacti or raising alarms with Nagios.

[/english]

# mpstat -P ALL
Linux 2.6.9-023stab046.2-enterprise (domain.com) 	25/09/08
20:39:02     CPU   %user   %nice %system %iowait    %irq   %soft   %idle    intr/s
20:39:02     all    0,79    0,00    0,17    5,74    0,00    0,00   93,30      0,00
20:39:02       0    0,87    0,01    0,19    6,85    0,00    0,00   92,09      0,00
20:39:02       1    0,87    0,00    0,18    5,94    0,00    0,00   93,00      0,00
20:39:02       2    0,74    0,00    0,16    5,14    0,00    0,00   93,96      0,00
20:39:02       3    0,68    0,00    0,16    5,02    0,00    0,00   94,15      0,00

Artículos relacionados (o no):

• iostat & iotop: I/O debugging
• Shell-script: timestamp
• [spanish]Picos de CPU raros en Leopard[/spanish][english]Weird CPU load spikes on Leopard[/english]

[spanish]

Hace unos meses tuvimos un caso raro en un cliente: una aplicación no daba el rendimiento que debería, sin embargo más del 20% de CPU estaba en estado “idle” y no se había tocado la swap, por lo que no era por falta de recursos. Fijándonos mejor en los porcentajes de CPU que daba vmstat, vimos que alrededor del 30% estaba en I/O, por lo que el problema era un cuello de botella en entrada/salida.

Para averiguar la causa utilizamos dos programas:

• iostat (viene en el paquete sysstat): similar a vmstat o ifstat, pero para operaciones de I/O. Muestra por dispositivo y por partición, cada X segundos, la cantidad de bloques leídos/escritos.
• iotop: como el top de toda la vida, pero ordena los procesos por consumo de I/O.

Con ayuda de éstas dos utilidades es fácil detectar qué programa está causando el cuello de botella, y en qué dispositivo.

En nuestro caso, el problema era una controladora RAID hardware que estaba dando muy mal rendimiento de escritura, unida a un programa que realizaba del orden de 15 pequeñas escrituras aleatorias por segundo.

[/spanish]

[english]

A couple of months ago, we had an interesting issue at a customer: an application wasn’t performing well, but the system had more than 20% CPU idle and wasn’t swapping memory, so it wasn’t a lack of resources. After a deeper look into vmstat, we saw a constant 30% of CPU in I/O state. We had some kind of I/O bottleneck.

To discover the root of the issue we used two programs:

• iostat (comes with the sysstat package): similar to vmstat or ifstat, but shows I/O operations per device and partition, updating its output every X seconds.
• iotop: like the classic top, sorting the processes according to their I/O rate.

By using these two utilities it’s quite easy to discover which process is creating the I/O bottleneck, and on which particular device.

In our case, the problem was a RAID controller that was giving a terrible writing performance, coupled with a process that was doing around 15 small, random access writes per second.

[/english]

Artículos relacionados (o no):

• mpstat
• Shell-script: timestamp
• [spanish]Liberar espacio extra en MacOS X[/spanish][english]Reclaim some wasted HD on MacOS X[/english]
• [spanish]Redundancia para torpes[/spanish][english]Redundancy for dummies[/english]

[spanish]exec es un comando interno de la shell que fuerza a que un binario se ejecute sobre el propio proceso de la shell en vez de sobre un hijo.

Cuando en shell-script se invoca un comando, normalmente se crea un proceso hijo que lo ejecute. Esto a nivel de llamadas al sistema sería el típico:

if( (pid=fork()) == 0) {
    exec(command);
    exit();
}
wait();

En general ésto es lo que queremos, para poder seguir ejecutando comandos en la shell. Sin embargo puede haber situaciones en las que no, casos típicos:

• tenemos un programa que va a monitorizar la ejecución de otro, y si hay un proceso shell por en medio no funciona bien, pero necesitamos esa shell para lo que sea (p.ej. preparar variables de entorno, ejecutar el comando con nice, etc.)
• lanzamos un programa vía un shell-script en MacOS y en el dock salen dos iconos

Con exec en lugar de hacer un fork que ejecute el comando, se ejecuta directamente sobre el proceso actual. Importante darse cuenta que, por lo tanto, cualquier comando que hubiera detrás del exec en la shell nunca se llega a ejecutar, pues el comando digamos que “suplanta” a la shell.

#!/bin/sh

#inicializar variables, parsear parámetros, etc.
export IP=$1

exec nice comando $*

[/spanish]
[english]
exec is a built-in shell command that forces a binary to be executed by the currently running shell process instead of forking the process and running the binary on that child process.

When you run a command on a shell-script, it forks a child process and runs the command there. On a syscall level this is the classic:

if( (pid=fork()) == 0) {
    exec(command);
    exit();
}
wait();

And this is usually what we want, because we will keep running commands after that one. Nevertheless, sometimes this is a problem, like when:

• we have a program that’s going to monitor a given process, and it doesn’t run properly if there’s an intermediate shell process but we need to run this second process via a shel-script for whatever reasons (to initialize some variables, run the program with nice, whatever)
• on MacOS we’re running a program via a shell-script and get two icons on the dock, one for the shell and another one for the program

Running a command with exec forces the shell not to fork, but to run the command directly over the shell process. An important thing to note here is that the shell-script will end there, no further commands of the shell script will be executed as the shell process will be substituted by the command process, so to speak.

#!/bin/sh

# initialize variables, parse command-line parameters, etc.
export IP=$1

exec nice command $*

[/english]

Artículos relacionados (o no):

• Shell-script: timestamp
• CrossOver de gratis y otras ¿apuestas? ¿o marketing?
• [spanish]Mi nuevo servidor[/spanish][english]My new server[/english]
• [spanish]Broadcom Wireless en Linux[/spanish][english]Broadcom Wireless on Linux[/english]
• Shell-script: substrings
• ifstat
• Command Line
• [spanish]Servidor VNC para MacOS X[/spanish][english]MacOS X VNC Server[/english]

[spanish]¡cat al revés![/spanish]
[english]A reverse cat![/english]

# cat file
1st line
2nd line
3rd line

# tac file
3rd line
2nd line
1st line

[spanish]A veces es necesario procesar un fichero en orden inverso, p.ej. un log para tener las últimas entradas primero. Recuerdo haber tenido que programar algo así en C hace unos años porque no conocía éste comando…[/spanish]
[english]Sometimes you need to process a file starting at the end, case in point a log file and you want to go from the last lines up. I remember programming something like this in C some years ago because I didn’t knew this command existed…[/english]

Artículos relacionados (o no):

• Move to the city

[spanish]
Todo el mundo conoce el programa rsync. Es muy útil para sincronizar el contenido de dos máquinas por red, minimizando el tráfico.

El problema es la primera vez que se ejecuta o se sincroniza un determinado archivo, ya que si la conexión es inestable y no se copia el archivo entero, rsync borra el trozo que haya llegado a copiar. Dicho de otra forma, cuando copia en lugar de sincronizar, sólo copia ficheros completos.

Por suerte hay un parámetro en línea de comandos para evitarlo, y que ante un corte en la conexión, deje el archivo parcial y lo continúe en la próxima ejecución:
[/spanish]
[english]Everybody knows the rsync command. It’s very useful when you need to keep two machines in sync over the network, minimizing the bandwidth used.

The only problem lies when running it for the first time, or when a new file appears and it’s newly uploaded to the other end: if the network connection is unstable and goes down, rsync deletes the partially uploaded file and it needs to be uploaded again. In other words, when copying new files instead of syncing existing ones, rsync only copies full files.

Luckily there’s a command line parameter to avoid this behaviour and, in the event of a network failure, force rsync to leave the partially-uploaded file as-is and continue syncing it from there on the next run:[/english]

# rsync --help
...
    --partial               keep partially transferred files

Artículos relacionados (o no):

• [spanish]Cluster de correo escalable con software libre[/spanish][english]Open source, scalable MTA clusters[/english]
• [spanish]Time Machine y máquinas virtuales[/spanish][english]Time Machine and Virtual Machines[/english]

[spanish]

Muchas veces cuando un servidor web va lento es posible que esté ante un “ataque”, intencionado o no, por parte de algún bot. He visto casos en los que el propio Google Bot o bots de universidades u otros indexadores generaban más de la mitad del tráfico de un sitio web. Estos casos no son un ataque DoS como tal, sería tráfico legítimo, pero el resultado es que nos “tumban” el servicio. En algunos casos como con Google se puede configurar con las Webmaster Tools y los ficheros sitemaps y/o robots.txt la frecuencia de las visitas y a qué páginas acceder, en otros no y tendremos que valorar filtrar ese tráfico a nivel de firewall. Pero en cualquier caso el primer paso es detectar que realmente hay una IP (o un grupo de IPs) que nos está “machacando” y con whois averiguar quién es.

Para ver las cinco IPs con más accesos en el Apache podemos ejecutar algo así:

[/spanish]
[english]

Many times the reason because a web server is slow and unresponsive is that it’s under “attack”, on purpose or not, by a bot. I’ve seen cases where Google Bot, bots from research engines from universities or some other kind of indexer were responsible for more than half the traffic of a site. These cases are not real DoS attacks, this traffic can be considered legitimate, but the result is that it brings the service down. You can instruct some of these bots not to visit your site so often, like Google Bot using the Google Webmaster Tools and the sitemaps and/or robots.txt files, but usually you can’t and have to consider filtering all this traffic at the firewall. But in any case, the first step is realizing that a single IP (or a couple of them) is responsible for most of your traffic, identifying this IP and using whois learn who it belongs to.

You can run something like this to list the top five IP addresses on your Apache’s access.log:

[/english]

cut -d" " -f 1 access.log | sort | uniq -c | sort -nr | head -n 5

Artículos relacionados (o no):

• tail -f access.log … ¡gráfico!
• pkill
• [spanish]Varios websites con HTTPS sobre una misma IP[/spanish][english]How to serve several domains with HTTPS and a single IP address[/english]

[spanish]El comando tar, como la mayoría de comandos UNIX, permite usar como entrada o salida se su operación la entrada/salida estandar del sistema, indicando “-” como origen/destino en lugar de un fichero.

¿Utilidades? P.ej. copiar estructuras de directorios completas manteniendo fecha, propietarios y permisos, en local o incluso en remoto con ayuda de ssh.

(luego me llaman friki por hacer éste tipo de cosas en el trabajo…)

[/spanish]
[english]The tar command, like many other UNIX commands, can use stdin/stdout as its input/output target by using “-” instead of a real file.

What’s this useful for? For example, copying a full directory tree while keeping dates, ownerships and permissions, locally or remotely with ssh.

[/english]

$ tar cf - . | ( cd /some/other/dir ; tar xfv - )
$ tar cf - dir | ssh usr@srv "tar xfv -"

Artículos relacionados (o no):

• cssh: Cluster SSH

[spanish]

Puedes darle un valor p.def. a una variable cuando no esté ya definida con:

FOO=${FOO:=bar}

Ejemplo:
[/spanish]
[english]
It’s possible to assign a default value to a variable in case it isn’t already defined. The syntax is:

FOO=${FOO:=bar}

Example:
[/english]

$ FOO=${FOO:=bar}
$ echo $FOO
bar

$ BAR=test
$ BAR=${BAR:=foo}
$ echo $BAR
test

Artículos relacionados (o no):

• Pues no hay. :-(

[spanish]

watch ejecuta un comando y mantiene su salida en pantalla, refrescándola cada X tiempo y, opcionalmente, marcando las diferencias entre ejecuciones. Es una forma de monitorizar cambios en algún comando sin tener que estar todo el rato haciendo “cursor arriba - enter”. :-)

[/spanish]

[english]

watch runs a command and keeps its output on screen updating it ever X seconds and, optionally, highlighting the differences on the output between executions. It’s an easy way to monitor the output of some command without having to spend several minutes pressing “cursor up - enter”. :-)

[/english]

watch -n 1 "ps aux | grep apache"

Artículos relacionados (o no):

• pkill

[spanish]Es posible extraer subcadenas de una variable con el formato:

${VARIABLE:INICIO:TAMAÑO}

Ejemplo:

$ A=abcdefghi
$ echo ${A:3:2}
de

[/spanish]
[english]
You can work with substrings in bash using the following syntax:

${VARIABLE:START:LENGTH}

Like in:

$ A=abcdefghi
$ echo ${A:3:2}
de

[/english]

Artículos relacionados (o no):

• exec