Archivo

Archive for 28 enero 2010

Comprobar Querys Lentas En PosgresQl con pgFouine

enero 28, 2010 1 comentario

Situación:

Tenemos un servidor de BD Postgresql que en algunos momentos del día va muy lento y queremos saber si hay alguna query ( consulta, actualización, etc ) que tarde demasiado y está afectando al rendimiento de la BD.

Solución:

Pgfouine es una aplicación en php sencilla, que si bajamos en tarball no necesita ni siquiera instalación.

Lo que hace es revisar el log de postgresql y presentarnos en formato html las querys que superen un umbral de segundos especificado por nosotros.

Instalación:

wget http://pgfoundry.org/frs/download.php/2178/pgfouine-1.1.tar.gz

mv pgfouine-1.1.tar.gz /opt/

cd /opt

tar xvzf pgfouine-1.1.tar.gz

rm pgfouine-1.1.tar.gz

cd /opt/pgfouine-1.1/

Para poder ejecutarlo tenemos que instalar php5 y php5-cli, ya que es un script de php.

En debian/ubuntu sería:

aptitude install php5 php5-cli

Ya tenemos pgfouine instalado y listo, así de sencillo.

Ahora sólo queda configurar postgresql y syslog para que logueen de una forma que pgfouine puede entender.

Editamos el fichero /etc/postgresql/8.4/main/postgresql.conf y cambiamos o añadimos las líneas siguientes:

log_destination = ‘syslog’

redirect_stderr = off

silent_mode = on

Para loguear sólo las querys que sean más lentas de 5 seg ( en milisegundos ):

log_min_duration_statement = 5000

log_duration = off

log_statement = ‘none’

Si tenéis syslog instalado, editamos /etc/syslog.conf y añadimos la línea:

local0.*                                         -/var/log/pgsql

Si tenéis rsyslog instalado, editamos /etc/rsyslog.d/50-default.conf y añadimos la misma línea anterior:

local0.*                                         -/var/log/pgsql

De esta forma postgresql logueará en el fichero /var/log/pgsql

Informes Html:

Para que pgfouine nos saque los informes en formato html :

/opt/pgfouine-1.1/pgfouine.php -file /var/log/pgsql > pgsql.html

Para que quede bonito podéis crear un script sencillo que almacene los logs e informes por día, por ejemplo:

#!/bin/bash

mv /var/log/pgsql /var/www/logs/$(date +%d-%m-%Y)-log    #Mueve el log /var/log/pgsql  a /var/www/logs/ nombrado el archivo con la fecha de hoy
/etc/init.d/rsyslog [syslog] restart                                                                       # Reiniciamos rsyslog para que vuelva a crear el fichero /var/log/pgsql
/etc/init.d/postgresql-8.4 reload                                                                          # Recargamos postgresql para que vuelva a loguear en /var/log/pgsql
/opt/pgfouine-1.1/pgfouine.php -file /var/www/logs/$(date +%d-%m-%Y)-log > /var/www/informes/$(date +%d-%m-%Y)-log.html                   #Realizamos el informe y lo guardamos en /var/www/informes con la fecha de hoy

Nombramos logpg al script y le damos permisos de ejecución:

chmod +x logpg

Añadimos una línea a nuestro cron para ejecutar todos los días el script a las 23:00 y así tener un log e informe por día:

crontab -e

00 23 * * *    /rutadelscript/logpg

Evidentemente, no nos podemos olvidar de crear previamente los directorios /var/www/logs y /var/www/informes:

mkdir /var/www/logs

mkdir /var/www/informes

Enlaces Externos:

Categorías:SysAdmin Etiquetas: , , , , ,

Mapear Puertos Sobre SSH

Situación1:

Tenemos 3 ordenadores:

Pc-1: Nuestro ordenador de trabajo con la ip 192.168.0.100

Pc-2: Un firewall-router con la ip 192.168.0.150 y la ip 192.168.1.150

Pc-3: Un servidor web con la ip 192.168.1.200

Queremos conectarnos al servidor web Pc-3 desde nuestro ordenador Pc-1, pero tenemos el problema de que Pc-1 no tiene acceso directamente a Pc-3 por políticas de seguridad.

Pero Pc-2 sí tiene acceso a Pc-3, lo cual vamos a aprovechar.

Solución:

Lo que vamos a hacer es mediante SSH crear en Pc-1 el puerto 2000 que  apuntará a Pc-3 al puerto 80 ( web ) pasando por Pc-2.

Para ello, desde Pc-1 hacemos:

ssh -l root Pc-2 -L 2000:Pc-3:80

Vamos a comentar este comando:

ssh -l root Pc-2: Nos conectamos desde Pc-1 a Pc-2 con el usuario root de Pc-2

-L 2000:Pc-3:80: Creamos en Pc-1 el puerto 2000 que apunta al puerto 80 de Pc-3 a través de Pc-2.

Ahora abrimos el navegador web en Pc-1 y tecleamos:

localhost:2000

Nos aparece la página web de Pc-3.

Situación 2:

Tenemos la misma situación que la anterior, pero queremos que los ordenadores que están en la misma red que Pc-1 también puedan acceder al servidor web Pc-3.

Con el comando anterior:

ssh -l root Pc-2 -L 2000:Pc-3:80

No podrían conectarse, ya que crea el puerto 2000 en Pc-1 en su interfaz localhost ( 127.0.0.1 ) por lo que sólo Pc-1 puede conectarse a Pc-3 a través de ese puerto.

Solución:

La solución es crear el puerto en Pc-1 en la interfaz de su red local que tiene la ip 192.168.0.100:

ssh -l root Pc-2 -L 192.168.0.100:2000:Pc-3:80

Como vemos lo único que cambia del comando es añadir la ip 192.168.0.100 en la que crear el puerto 2000 que apunta a Pc-3 al 80.

De esta forma tanto Pc-1 como el resto de ordenadores que están en su red podrían conectarse poniendo en el navegador web la dirección:

192.168.0.100:2000

Nota: En cualquiera de las 2 situaciones se añade el plus de que las comunicaciones contra el servidor web Pc-3 se hacen de forma segura, ya que viajan a través de un túnel ssh.

Categorías:SysAdmin Etiquetas: , ,

Convertir Raid1 En Raid5 Sobre LVM Sin Perder Datos

Situación:

Tenemos un Raid1 /dev/md0 con 2 discos de 250GB /dev/sdb1 y /dev/sdc1.

Con el dispositivo /dev/md0 hemos creado un LV ( logical volume ) llamado datos, dentro de un VG ( volume group ) también llamado datos, con lo que obtenemos:

/dev/mapper/datos-datos 230G  115G  115G  50% /mnt/datos

Objetivo:

Hemos obtenido un tercer disco de 250GB /dev/sdd1 y queremos convertir el Raid1 existente en un Raid5 con los tres discos de 250GB, sin perder datos y manteniendo el LV datos.

En Marcha:

– Sobreescribimos el metadata del Raid1 con el metadata del Raid5

mdadm –create /dev/md0 –level=5 -n 2 /dev/sdb1 /dev/sdc1

– Comprobamos que hemos pasado de un Raid1 a un Raid5:

mdadm -D /dev/md0

– Añadimos el tercer disco /dev/sdd1 al array /dev/md0

mdadm –add /dev/md0 /dev/sdd1

– Comprobamos que se está realizando la reconstrucción del array, de nuevo con:

mdadm -D /dev/md0

– Una vez que ha finalizado la reconstrucción hacemos crecer el array, utilizando también un fichero de backup en caso de que se interrumpiera el proceso por alguna razón:

mdadm –grow /dev/md0 –raid-disks=3 –backup-file=/tmp/raid1to5.backup

– Esto puede tardar muchas horas, dependiendo del tamaño de los discos y de los datos que hubiera en el array.
Comprobamos periódicamente el array con:

mdadm -D /dev/md0

Y cuando haya finalizado el proceso, procedemos a redimensionar nuestro LV datos:

pvresize /dev/md0

Si el comando anterior nos da el error “too many metadata areas for pvresize” debemos hacer:

– vgcfgbackup -v -f /tmp/file datos     Dónde datos es el nombre de mi VG.
– vgchange -an datos                    Dónde datos es el nombre de mi VG.

Ahora tenemos que editar el fichero /tmp/file y buscar y copiar el UUID del pv /dev/md0 para luego utilizarlo:

– pvcreate -ff –metadatacopies 1 –restorefile /tmp/file –uuid elUUID /dev/md0
– vgcfgrestore -v -f /tmp/file datos
– pvresize /dev/md0

Ahora sólo queda extender el LV que en mi caso se llama datos, al igual que el VG.
Para extender un LV se hace dependiendo del sistema de archivos que tenga.

En mi caso uso xfs, y se extiende:

– xfs_growfs /dev/mapper/datos

Con ext3 sería:

– e2fsck -f /dev/mapper/datos
– resize2fs -p /dev/mapper/datos

Si ahora hacemos un df -h obtenemos el nuevo tamaño de nuestro LV datos:

– dev/mapper/datos-datos        465G  115G  350G  25% /mnt/datos

Listo. Parece más complicado de lo que en realidad es.

Advertencia:

Todas las veces que he realizado este proceso no he tenido ningún problema, ni he perdido ningún dato.
De todas formas siempre hago un backup de mis datos antes de jugar con mis discos duros, por lo tanto, siempre, siempre haz un backup.

Categorías:SysAdmin Etiquetas: , ,