Cuidado con las «clever solutions» de concurrencia

Etiquetas

concurrencia, race condition

Ayer a última hora me encontré con este código:

Quité algunas líneas para que no se pudiese deducir la empresa, que no es importante. Tampoco el programador que lo hizo, no es mi intención criticar a nadie en particular sino a una mala práctica de solucionar problemas de concurrencia con «ideas geniales» que no lo son tanta.

El código anterior recibe consultas B2B, graba los resultados en un fichero (por requerimientos de negocio) y luego lee desde esos mismos ficheros para enviar la respuesta a la agencia que hizo la consulta.

Es un software que factura millones de euros al año y pasó semanas de tests y QA. No se descubrió el problema hasta que una de los clientes optimizó sus consultas enviando varias en paralelo. Allí descubrieron que obtenían resultados erróneos: eran duplicados (con un riesgo financiero bastante importante).

Moraleja 1: Los errores de concurrencia son difíciles de encontrar y cuando aparecen suelen ser difíciles de debuguear, ten mucho cuidado antes de implementar soluciones ad-hoc.

El código intenta resolver el problema de concurrencia de varios procesos que podrían escribir en el mismo fichero verificando primero si el fichero existe, si es así incrementa el contador -que forma parte del nombre- hasta que encuentra uno que no coincida.

Además de detalles de eficiencia tiene un problema grave, las operaciones de verificación (file_exists) y creación del fichero (fopen) no son atómicas. Eso significa que varios procesos concurrentes (con una o varias CPUs) verifican, les da falso a todos y luego todos escriben en el mismo fichero. Una race condition de libro.

Moraleja 2: Si has tardado en encontrar el problema o no entiendes la importancia de operaciones atómicas ya deberías estar aprendiendo más de concurrencia.

Afortunadamente entre los tres que estábamos analizando el código en plan «emergencia» y por vídeoconferencia (la captura es del chat de Skype de Linux) desde países diferentes nos dimos cuenta enseguida del bug y de una solución simple: agregar el PID del proceso al nombre del fichero. Como el PID es único en el sistema y cada proceso individual es secuencial no hay riesgos de que sobreescriban en el mismo fichero.

No es la solución más eficiente (ya lo corregiremos estos días con más tranquilidad) pero es una solución segura y que podía implementarse en pocos minutos y sin efectos colaterales que podrían afectar a la lógica del programa.

Además, el bug podría haber sido menos perjudicial si en vez de escribir los resultados en el fichero y luego leerlos para responder se hubiese enviado directamente la respuesta ya almacenada en el proceso local.

Moraleja 3: Si no te has dado cuenta de la diferencia entre datos locales y compartidos y los problemas que pueden generar estos últimos, ponte ya a aprender de concurrencia.

Moraleja 4: Los problemas de concurrencia son muchos más habituales de los que crees y las soluciones no son tan obvias como parecen a primera vista.

Obviamente tengo que recomendar el libro que ya sabéis (y aparece a la izquierda 😉 ) pero ni aún así se puede asegurar que no cometerás errores, se requiere práctica y ser muy cuidadoso.

 

 

 

Amazon EC2: actualizar Ubuntu 10.04 a 12.04, y a 14.04

Etiquetas

ec2, lts, ubuntu, upgrade

Este es un apunte rápido y corto ya que a algunos les vendrá bien. Estoy preparando la migración del servidor principal (el que hace de control, repositorio de software e imágenes) de Menéame. Es una instancia EBS (con dos volúmenes adicionales) con Ubuntu 10.04 y ya toca migrar a la 12.04 o 14.04 por su antigüedad y porque se quedará sin soporte.

En general no tuve problemas, pero hay que tener un poco de cuidado cuando se migra de 12.04 a 14.04. Los pasos a hacer desde la consola web son los siguientes (no hace falta hacer nada con comandos):

1. Crear un AMI del servidor a actualizar: esto generará una imagen arrancable idéntica al servidor, hay que seleccionar que cree también la imagen para los otros volúmenes montados.
2. Arrancar una nueva instancia con ese AMI creado. Esta instancia debe ser idéntica a la original. Ten cuidado de deshabilitar los procesos que puedan interferir con la otra, por ejemplo los que tengan en cron. Verás que creó un AMI y los snapshots correspondientes a cada volumen.
3. Ejecutar do-release-upgrade -d para actualizar a 12.04. Esto pasará a la siguiente versión LTS. Como comencé con 10.04 se actualiza a 12.04. Es un proceso que tarda pocos minutos y no me dio ningún problema. Luego hay que hacerlo nuevamente para actualizar a la versión 14.04, antes es mejor reiniciarlo para estar seguro que todo funciona correctamente (mira los mensajes de arranque con el dmesg).
4. Ejecutar de nuevo do-release-upgrade -d para actualizar a 14.04. Como el anterior, pero si no vas con cuidado, luego no arrancará porque no encontrará los dispositivos EBS. El problema es sencillo, en la 14.04 se renombran de dispositivos, por ejemplo, el /dev/sda1 se renombra a /dev/vxda1, el /dev/sdc a /dev/vxdc, etc. Antes de reiniciar con la versión 14.04 debes cambiar el /etc/fstab para indicar esos nuevos nombres. Si te olvidas -como yo- no hay problemas, más abajo te explico cómo arreglarlo rápidamente si la instancia no te arranca.
5. Ya está, es relativamente sencillo. Ahora debes verificar que las configuraciones te funcionan, reinstalar los módulos que han instalado con herramientas como el pip (Python), o pecl (PHP). Verifica también la configuración del PHP (si lo usas), ya que cambió la estructura de directorios en /etc/php5. Te aconsejo crear otro AMI de este nuevo servidor y probar que arranque correctamente.

Cómo reparar el /etc/fstab (o cualquier otra configuración que impide arrancar una instancia)

Si en el paso #4 te olvidaste de cambiar los nombres de los dispositivos, o lo hiciste pero te equivocaste (o falla cualquier otro fichero), la instancia no arrancará, pero es relativamente sencillo de arreglarlo:

1. Detén el servidor que no arranca (Stop desde la consola web).
2. Arranca otra instancia (si no tienes ninguna en marcha) con una imagen que funcione, incluso con una Ubuntu oficial. Cualquiera sirve.
3. En la ventana de Volumes haz un deattach del volumen raíz de ese disco (no te olvides de apuntar el nombre de /dev con el que estaba enlazado, habitualmente /dev/sda1 o /dev/sda).
4. Haz un attach de ese dispositivo a la otra instancia de trabajo, te sugerirá nombres, usa alguno que no tengas en esa instancia, por ejemplo /dev/sdc.
5. Monta el dispositivo en la instancia, por ejemplo: mkdir /work; mount /dev/sdc /work (ojo, si estás trabajando en una Ubuntu 14.04 será mount /dev/vxdc).
6. Ahora puedes modificar el /work/etc/fstab (o el fichero que tengas que reparar).
7. Desmonta el dispositivo (umount /work) y el deattach del volumen a esa instancia.
8. Ya puedes hacer el attach del mismo volumen a la instancia que habías detenido y hacer el start.

 

Tendencias («trends») históricas del uso de palabras con Sphinx

Etiquetas

menéame trends, sphinx

Hace unos días quise saber desde cuándo se empezó a hablar de desahucios y suicidios en la prensa en España. Fui a Google Trends y el gráfico mostraba una evolución demasiada plana, que no se correspondía con tantas noticias que leímos en la prensa española. Me pregunté si, y cómo, podía obtener esas estadísticas en Menéame. Se me ocurrió que debería haber un truco relativamente sencillo usando los índices de de búsqueda de Sphinx (lo usamos para el buscador de Menéame). Así fue que en pocas horas pude implementar un sistema similar a Google Trends en Menéame.

Esto es lo que salió con las tendencias de esas dos palabras por su frecuencia de aparición por meses:

Técnicas y trucos para la versión móvil «responsive» del Menéame

Etiquetas

menéame, optimizaciones, responsive, versión móvil

No sé si habréis notado, pero si accedéis a Menéame desde un móvil o tableta, se carga muy rápido y están disponibles prácticamente todas las funcionalidades de la versión «normal» de la web. Aunque en realidad no se tratan de dos versiones diferentes, es la misma pero con cambios muy pequeños en la lógica del servidor, y muy poco de Javascript.

El 30% de los accesos a Menéame son desde móviles, antes teníamos una versión más reducida (sigue disponible en m.meneame.net), pero recibíamos quejas por ser muy limitado en cuanto a funcionalidades. Por otro lado, era demasiado trabajo mantener dos versiones diferentes.

También queríamos adaptar la web para los monitores Retina y de alta definición que tienen la mayoría de teléfonos y tabletas de gama media y alta (su densidad de pixels por pulgada es mayor -hasta dobla- a los típicos 96 px/pulgada de los monitores tradicionales), para ello hay que detectarlos y servir en estos casos una imagen del doble de resolución.

Así, hace unas semanas nos pusimos a tope para lograr una única versión integrada, con pocas diferencias en la lógica del backend, y casi ninguna modificación hecha con Javascript en el lado cliente. Aunque el PageSpeed no es una medida cualitativa absoluta, sí que da bastante idea de velocidad y ligereza:

Como se puede deducir, las mejoras de velocidad de carga para móviles también afectó positivamente a la versión normal del web. A continuación describiré cuáles fueron los trucos y técnicas más importantes.

Preguntas y 10 puntos claves de Amazon EC2

Etiquetas

amazon, aws, claves, ec2, trucos

Recibo muchos emails con consultas por tema de Amazon AWS, cuando son breves y concretas las contesto, cuando no, que paguen una consultoría. Una cosa es contar las experiencias para todos, otra muy distinta solucionar gratis  los problemas de una empresa con la que no tengo relación.Hace unas horas recibí uno largo, pero como tiene preguntas interesantes lo contesto, pero para todo el mundo 😉

Limitar a los bots agresivos en las iptables

Etiquetas

Connection throttling, iptables

Hace un tiempo escribí un pequeño apunte para detectar bots agresivos. Pero con la cantidad de bots que hay por el Menéame, y la cantidad de gente que «juega» haciendo varias decenas de conexiones por segundo, ese script era ya prácticamente inservible. En este tiempo estuve probando varios módulos del Apache. El mod_evasive del Apache –el más usado, no entiendo por qué– no sirve para nada ya que sólo controla las conexiones para un sólo proceso –en el Menéame estamos en unos 150-200 procesos concurrente en cada uno de los dos servidores–.

Al final, probando varias opciones de las iptables, la que más me gustó es la del módulo «recent». Funciona muy bien, no consume casi nada y tampoco requiere el módulo conntrack –de nuevo, es muy «caro» en el Menéame por la cantidad de conexiones–

Esto es lo que tengo en reglas de las iptables en Menéame:


#Connection throttling
IF=eth_la_que_corresponda
...
iptables -i $IF -I INPUT -p tcp --syn -m recent --set
iptables -i $IF -I INPUT -p tcp --syn -m recent --update --seconds 10 --hitcount 30 -j DROP

Lo que hace es contar el número de paquetes SYN (inicio de conexión TCP) para cada dirección IP en los últimos 10 segundos. Si llega a 30 descarta ese paquete por lo que no se establecerá la conexión (el TCP volverá a intentar varias veces, cuando baje del límite podrá establecerse). El valor de 30 es un valor que encontré iba muy bien para el Menéame. Podéis comenzar con eso y luego ajustarla.

Para poder mirar el número de conexiones simultáneas de cada IP hice un pequeño script en Python que las muestra ordenadas:


#! /usr/bin/env python
import re

ips = {}
r = re.compile(r’src=([\d\.]+).+ oldest_pkt: (\d)’)
f = open(«/proc/net/ipt_recent/DEFAULT»)
for line in f.readlines():
  g = r.match(line).groups()
  if  int(g[1]) > 4:
    # Store only in it has more than 4 conns.
    ips[g[0]] = int(g[1])

tuples = ips.items()
tuples.sort(lambda (k1,v1),(k2,v2):cmp(v2,v1))
for ip, counter in tuples:
  print ‘%-16s  %-8d’ % (ip, counter)

En cada servidor del Menéame los máximos que suelo observar no superan las 8 ó 9 conexiones. Por ejemplo:


$ recent-ip.py
83.41.13.38       9
88.22.14.52       9
84.78.63.183      9
85.219.45.29      9
83.33.104.1       9
62.43.161.95      8
62.43.51.161      8
85.57.206.54      7
213.60.230.179    7
88.14.107.53      7
85.60.43.31       7
85.85.25.68       7
88.11.242.144     7
84.126.172.191    7
84.127.93.44      6
83.138.223.248    6
212.225.182.55    6
217.127.202.163   6
84.123.119.212    5


Esto no llega ni a boboapunte

Etiquetas

3g, acpi, hsdpa, ubuntu hardy, video toggle

Ayer me mandé una cagada con la Maribuntu, me tuvo despierto hasta las 8 de la mañana de hoy. Como no tengo nada interesante para contar y como este blog es mío, pues lo cuento… bueno, en realidad seguro que ayudará a alguno con el mismo problema.

Ya estaba aburrido y con mucho mono de versiones nuevas –sobre todo del Firefox 3–, así que decidí actualizar mi Thinkpad (X61s) a la Ubuntu Hardy Beta.

Hice un dist-upgrade de la Feisty, salvo unos pequeños errores sin importancia, fue todo bien. Pero al reiniciar y arrancar con el kernel nuevo (2.6.24-12 de AMD64) iba a velocidad de tortuga, muy mal. El hdparm me daba una increible velocidad de 1.6 MB/seg (lo normal es más de 42 MB/seg en ese portátil). Descubrí que era problema del módulo sata y no pude encontrar la forma de solucionarlo.

Así que decidí hacer una instalación nueva. Como el portátil no tiene CD lo hago por la red con el PXE. Me bajo la instalación mínima que pongo en un servidor TFTP de otro ordenador y vía DHCP le indico qué arrancar. Luego todos los paquetes lo baja desde los servidores de Ubuntu.

En la primera instalación la red fue muy lenta, tardó más de tres horas. Moraleja: no dejes que seleccione es.ubuntu.com como mirror, edítalo a mano y pon archive.ubuntu.com, con éste me llegaba a 720 KB/seg por mi conexión de ONO.

Cuando llegó casi al final dió un error al instalar el GRUB. No hubo forma. Intenté con el LILO, el mismo problema. Parece que el instalador beta todavía tiene conflictos con algunos discos sata, al menos si se instala vía red.

Como había puesto una sola partición enorme (de 120 GB) con JFS pensé que podría ser eso. Así que comienzo de nuevo (ahora sí con archive.ubuntu.com, fue mucho más rápido), creé una partición /boot de 300 MB con ext3, pero el error fue exactamente el mismo.

Así que al final terminé haciendo otra cosa que me permitió instalar la Hardy correctamente.

Me bajé el instalador de Gutsy, que sé que funcionaba correctamente, pero sólo hice una instalación mínima con el comando «cli» al inicio de la instalación (así instala sólo lo básico). Esta instalación fue muy rápida, menos de 20 minutos, y dejó al ordenador funcionando correctamente en modo texto.

Una vez hecho esa, edité el sources.list para cambiar de gutsy por hardy. Hice un dist-upgrade que tomó unos diez minutos. Quería probar si así persistía el problema del bajo rendimiento del disco. Reinicié… y todo fue perfecto, el disco iba a su velocidad normal. No entiendo muy bien por qué fallaba antes sólo puedo echarle la culpa a algún módulo, u opción de módulos, heredados de la Gutsy.

Luego hice un aptitude install ubuntu-desktop y en menos de media hora pude tener todo instalado nuevamente… aunque a esa hora ya se veía el sol desde mi ventana.

Bonus

Bueno, como disculpas para este boboapunte daré algo útil, unos pequeños scripts ACPI que ayudarán a bastantes que tengan el X61 (o modelos similares). La Hardy beta soluciona varios problemillas, por ejemplo ya instala por defecto el driver libre de Intel iwlwifi, pero tiene otros. De todas formas hay dos temas que no estaban bien solucionados en la Gutsy y siguen igual.

Uno es el de intercambiar la salida de vídeo entre el LCD y el conector VGA externo. En Hardy si se da al botón <Fn><F7> ya es capaz de habilitar la salida «clon» al VGA, pero sólo hace eso, no intercambia (toggle) la salida entre LCD, LCD+VGA, VGA. Los scripts incluidos en x61-video-toggle.tgz ya lo hacen. Debería funcionar correctamente en cualquiera de las últimas Ubuntu (probado en Gutsy y Hardy). Para instalarlo basta bajarlo y hacer:

sudo tar xvzf x61-video-toggle.tgz -C /

Luego un /etc/init.d/acpid restart et voilà (pero si te gusta o te deja más tranquilo el método Redmond, puedes reiniciar el ordenador). Recomiendo instalar el paquetes gnome-osd para que veáis el estado en la pantalla.

Otro problema que tengo resuelto es de arrancar automáticamente la conexión 3G/HSDPA con el chip incluido. Eso lo tengo solucionado con <Fn><F9>, originalmente es para expulsar el CD, pero como no tengo la estación base la aprovecho para ahorrarme el trabajo de apagarla o arrancarla con el wvdial. Los scripts están en x61-wan-toggle.tgz. Se extrae igual que el anterior:

sudo tar xvzf x61-wan-toggle.tgz -C /

También funciona en Gutsy y Hardy. Para que funcione necesita del /etc/wvdial.conf correcto, como no quiero que os carguéis nada, os paso cómo está el mío, es importante que tenga el dialer «3G» definido:

[Dialer Defaults]
Phone =
Username =
Password =
New PPPD = yes

[Dialer 3G]
Init2 = ATZ
Init3 = ATE0V1&D2&C1S0=0+IFC=2,2
Modem Type = Analog Modem
Baud = 460800
Stupid Mode = 1
Modem = /dev/ttyUSB0
ISDN = 0
Modem Type = Analog Modem
Init5 = AT+CGDCONT=1,"IP","ac.vodafone.es";
Phone = *99***1#
Username = vodafone
Dial Command = ATDT
Password = vodafon

La beta de Hardy tiene dos pequeños problemas con el acpi del X61.

• No ajusta el brillo de la pantalla con las teclas <Fn><Inicio> y <Fn><Fin>.
• No «detecta» la tarjeta 3G/HSDPA (no se enciende el led).

Arreglarlo es fácil, sólo hay que indicar al módulo thinkpad_acpi que permita ajustar el brillo de la pantalla y que habilite la extensiones experimentales. Yo lo hice creando el fichero /etc/modprobe.d/x61 con la siguiente línea:

# Habilita brillo y wan
options thinkpad_acpi experimental=1 brightness_enable=1

Vale, no me ha quedado un apunte tyan bobo, aunque tampoco es un tratado sobre la ingeniería del software, lo siento, cuando hice la carrera no me enseñaron Ubuntu ni Linux 🙄

Una demo con la Wikipedia, pero sin vandalizarla (o eso creo)

Etiquetas

wikipedia, wikipediafs

Hoy quería hacer una pequeña demo en clase de Administración de Sistema Operativos… la hice, y funcionó. El resultado es una muy pequeña mejora al un artículo de la Wikipedia. Pero lo importante no es la pequeña edición del texto, sino cómo se hizo.

La edición la hice abriendo el fichero con el vim en mi portátil, hice el :w y fuimos a ver la modificación. Allí estaba, como por arte de magia… qué buen hack, son unos frikis 🙂

Protégete de los bots agresivos

Etiquetas

bots agresivos, mysql, optimización apache, optimización wordpress

En los últimos días varias personas con servidores propios –fundamentalmente de wordpress– me pidieron ayuda para reducir la carga de sus servidor o mejorar los tiempos de respuesta. Una de las últimas frecuentes era «porqué a veces la carga del servidor subía mucho». Asumiendo que el servidor está bien configurado y balanceado [1], el problema suele ser por los «bots demasiado agresivos».

[1] Ver abajo Diez reglas básicas para servidores web bien ajustados

El aumento del ancho de banda en las conexiones hogareñas, las pruebas «académicas» y de prácticas desde universidades –en España sus líneas suelen superar creces los 100 Mbps– y los bots de los harvesters de spammers hace que debamos también monitorizarlos e impedir que su molestia sea persistente.

Aunque hay métodos en las iptables y Apache para controlar el número de conexiones —connection throttling— a veces es muy difícil encontrar un valor adecuado sin que genere problemas a conexiones válidas. Incluso puede haber problemas de memoria –de las iptables, que las asigna en el espacio del kernel– en servidores que no tienen suficiente.

Por ello a veces es más fácil analizar los logs de Apache en situaciones de alta carga para detectar desde qué direcciones IP se están haciendo tantas conexiones y agregar una regla a las iptables para hacer in drop a paquetes desde esa dirección.

En Menéame es bastante habitual que nos aparezca un bot de estos y que sus conexiones duren bastante tiempo mientras recorre absolutamente todos los posibles URLs. Como estos son centenares de miles, la «agresión» suele durar horas o días, así que me preparé un pequeño script en Python que me permite analizar el número de conexiones desde cada IP.

#! /usr/bin/python

import fileinput
import re

to_ignore = ['/img/', '/js/', '/css/'] # Los cgi o directorios a ignorar
ips = {}; res = []

try:
    for s in to_ignore:
        res.append(re.compile(re.escape(s)))
    for line in fileinput.input():
        words = line.split()
        for r in res:
            if r.search(words[6]): break
        else:
            try: ips[words[0]] += 1
            except KeyError: ips[words[0]] = 1
    tuples = ips.items()
    tuples.sort(lambda (k1,v1),(k2,v2):cmp(v2,v1))
    for ip, counter in tuples:
        print '%-8d\t%s' % (counter, ip)
except IOError:
    pass

El programa anterior analiza el logs del apache desde la entrada estándar o los ficheros que se indiquen en la línea de comandos e imprime una tabla de números de conexiones de cada IP.

Yo lo suelo usar de la siguiente forma:

tail -1000000 /var/log/apache2/meneame_net.access.log | ./freq-ip.py | less

aunque también se puede hacer:

./freq-ip.py fichero1.log fichero2.log …

Nota: aunque el ejemplo es con las últimas 1.000.000 de líneas, elige un valor adecuado a tu servidor, por ejemplo si te interesa analizar los últimos 5 minutos y tienes unas 100.000 conexiones en ese período, ese es el valor que debes poner como argumento del tail.

El resultado es una tabla ordenada de mayor a menor, por ejemplo:

22759           66.249.72.103
914             62.43.58. xxx
837             84.77.96.xxx
645             89.248.99.xx
522             65.214.44.xx
486             89.17.210.xx
483             72.14.199.xx
...

Las IPs que aparecen primeras son las sospechosas de bot agresivos, pero hay que analizarlas con el whois para asegurarse. En el resultado anterior se puede observar claramente que la dirección 66.249.72.103 es sospechosa, pero en este caso no hay que hacer nada porque es el bot de Google (el de búsquedas y el del AdSense). Pero si se trata de una IP que no pertenece a ningún buscador o directorio conocido, o que viene de países como China o Ucrania, seguramente se trate de un bot incontrolado o mal programado.

En todo caso siempre conviene analizar el historial de los logs para asegurarse:

tail -1000000 /var/log/apache2/access.log | grep ^66.249.72.103 | less

Una vez que estés seguro que quieres evitarle los accesos, basta agregarlo en las iptables. Yo tengo preparado un script que lee las IP «prohibidas» desde un fichero y ejecuta los comandos de las iptables:

#! /bin/sh

iptables -F

# START Drops from ip_forbiden
for ip in `cat /DIRECTORIO/ip_forbiden` ## AQUI el pathname del fichero
do
    if [[ "$ip" =~ "[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+" ]]
    then
        echo Dropping $ip
        iptables -i ethX -A INPUT -s $ip  -j DROP ### AQUI la interfaz que corresponda, eth0 o eth1, etc.
    fi;
done
# tus reglas propias
...

Diez reglas básicas para servidores web bien ajustados

Al principio mencioné que primero debemos asegurarnos que el servidor web está bien configurado y ajustado para nuestras necesidades. En realidad no es tan difícil ajustar los parámetros básicos del Apache.

1. Asegúrate verificando en el error.log si el Apache no llega al número máximos de procesos. Si es así debes incrementar el máximo, por ejemplo: MaxClients 150
2. Algunas distribuciones, como Debian, tiene el máximo «absoluto» en 256 procesos, si necesitas más debes cambiarlo: ServerLimit 512
3. Habilita el KeepAlive, pero ponle un timeout bajo: KeepAliveTimeout 2
4. StartServers debe tener un valor adecuado, que sea ≥ que MinSpareServers y ≤ que MaxSpareServers. Por ejemplo : StartServers 40, MinSpareServers 30, MaxSpareServers 50
5. MaxSpareServers debe ser mayor en al menos un 50% el valor de MinSpareServers.
6. El PHP puede consumir mucha memoria en algunas conexiones (subida de ficheros, compilación de muchos módulos, etc.) y no las libera hasta que «muera» el proceso. Por eso es mejor que los procesos de Apache tengan una «vida limitada» para permitir liberar esa memoria que no se necesita: MaxRequestsPerChild 10000. Ajusta el valord de 10.000 a tus propias necesidades, si tu servidor tiene muchas conexiones puedes subirlo, por ejemplo a 1.000.000 como en el caso del Menéame.
7. Para saber mejor cuál es el problema de tu servidor usa los comando top y vmstat 2. El primero te dará el uso de CPU de los procesos, si es el mysqld el que aparece con casi el 100% de CPU, el problema es de base de datos, por el contrario se trata del PHP. El vmstat te dará más pistas, si los valores de la columna wait (la última, wa) son altos, es porque necesita mucha entrada salida, necesitas más memoria RAM. Si por el contrario las valores de la columna idle (la penúltima, id) son muy bajos necesitas más CPU.
8. El WordPress no es un gran consumidor de CPU en base de datos (a menos que ésta sea inmensa), sino de CPU para compilar todos los módulos para cada conexión. Si tu problema es de carga alta de CPU lo más probable es que necesites usar «cache» de PHP compilados, por ejemplo el eaccelerator.
   • Si tienes instalado el WP-Cache, éste evita que se tengan que compilar todos los módulos en el caso de encontrarse la página en cache.
9. Si el el Mysql del WordPress te consume mucha CPU lo más probable es que sea algún plugin (especialmente esos que guardan estadísticas en la base de datos) o que tengas muy poca memoria RAM disponible para cache de disco. Pero primero analiza o deshabilita los plugins sospechosos.
10. Si has desarrollado tu propio programa y el Mysql te consume mucho, tienes problemas de SQLs, índices o problemas de estructura de la base de datos. recuerda la regla de oro en programas web con base de datos (general para cualquier gestor): debes evitar a toda costa los recorridos secuenciales en las tablas. Para eso debes ser muy cuidadoso en la creación de los índices adecuados o de cómo haces las consultas SQL. Si no puedes asegurarte de ello tienes dos opciones primordiales para el caso que las modificaciones a las tablas no sean muy frecuentes:
    1. Jugar con los valores de cache de queries sql en el propio gestor (query_cache_size y query_cache_type en el Mysql).
    2. Usar memcached.

No entiendo nada

Si lo que te comento arriba te suena a chino:

• Quizás no deberías haber contratado un servidor dedicado si eres capaz de administrarlo y ajustarlo, o
• deberías estudiar un poco de administración de servidores, especialmente del Apache, MySQL e iptables, o
• podrías pedir ayuda a un amigo, o menor aún para evitar la proliferación de pringaos, contrata a un amigoo conocido de confianza por unos 50-60 euros la hora (tarifa española más o menos adecuada) que sepa del tema y te ajuste el servidor. Si tiene que hacer todo lo que explico aquí, le llevará más o menos una hora para ajustar, y monitorizar para asegurarse que los valores son adecuados.

Pequeño truco para Ubuntu…

Etiquetas

trasteo, ubuntu

Si quieres que el ordenata te arranque más rápido, cuando de aparezca la pantalla del grub haz lo siguiente:

• Posiciona el selector sobre el kernel que arrancas.
• Presiona «e» para editar
• Posiciona el cursor sobre las líneas donde están las opciones.
• Presiona «e» para editar
• Agrega al final la palabra «profile» (dejando un espacio con las anteriores), luego dale al enter.
• Cuando vuelva a la pantalla anterior presiona «b» para que arranque.
• Espera un poco más que hará el índice.
• Et voilà

Lo aprendí mientras trasteo instalando varios sistemas en mi Thinkpad X61s. Ya tengo todo funcionando bien, con unos cuantos scripts hasta para controlar el 3G/HSDPA con las teclas de IBM, y ahorrando batería. Ya pondré un artículo completo y los ficheros para instalar.