systemadmin.es » LAMP y web » Guía de supervivencia con Apache

Guía de supervivencia con Apache

El servidor web Apache es uno de los más extendidos y con más opciones de configuración, esto implica que es complejo. Vamos a ver cómo sobrevivir con Apache.

Guía de supervivencia con Apache

Guía de supervivencia con Apache

Otras veces ya hemos visto como realizar una instalación de Apache con PHP y eAccelerator, una vez instalado los ficheros ejecutables importantes son:

  • apachectl: Mediante este script podremos:
    • Gestionar el arranque y parada del daemon (start/stop)
    • Comprobar la configuración (configtest):
      # /usr/local/apache22/bin/apachectl configtest
      Syntax OK
      
    • Recargar la configuración en caliente, sin apagar el daemon (graceful)
  • httpd: Binario del daemon, con dicho fichero podemos:
    • Indicar que fichero de configuración cargar (opción -f)
    • Ver el listado de módulos que carga (opción -M):
      # /usr/local/apache22/bin/httpd -M
      Loaded Modules:
       core_module (static)
      (...)
       jrun_module (shared)
      
    • Al igual que con apachectl, comprobar la configuración con la opción -t:
      # /usr/local/apache22/bin/httpd -t
      Syntax OK
      
    • Ver el resumen de configuración de los VirtualHosts con la opción -S:
      # /usr/local/apache22/bin/httpd -S
      VirtualHost configuration:
      wildcard NameVirtualHosts and _default_ servers:
      *:80                   is a NameVirtualHost
               default server shuvak.systemadmin.es (/usr/local/apache22/conf/extra/httpd-vhosts.conf:7)
               port 80 namevhost shuvak.systemadmin.es (/usr/local/apache22/conf/extra/httpd-vhosts.conf:7)
               port 80 namevhost systemadmin.es (/usr/local/apache22/conf/extra/vhosts/systemadmin.es.conf:1)
               port 80 namevhost foro.systemadmin.es (/usr/local/apache22/conf/extra/vhosts/foro.systemadmin.es.conf:1)
      Syntax OK
      

Un ejemplo de configuración típica de un VirtualHost sería la siguiente:

<VirtualHost *:80>
        DocumentRoot "/var/www/systemadmin.es/htdocs"
        DirectoryIndex index.php
        ServerName systemadmin.es
        ServerAlias foro.systemadmin.es

        <Directory /var/www/systemadmin.es/htdocs>
            Options FollowSymLinks
            AllowOverride all
            Order deny,allow
            Allow from all
        </Directory>

        ErrorLog  "| /usr/local/sbin/cronolog -S /var/www/systemadmin.es/logs/current.error.log /var/www/systemadmin.es/logs/%Y/%m/%d/error.log"
        CustomLog "| /usr/local/sbin/cronolog -S /var/www/systemadmin.es/logs/current.custom.log /var/www/systemadmin.es/logs/%Y/%m/%d/custom.log" combined

</VirtualHost>

Las directivas importantes son:

  • DocumentRoot: Directorio base desde el cual serviremos el contenido. Deberemos acompañarlo de la directiva Directory para establecer si se puede servir o no su contenido
  • DirectoryIndex: Cuando se intente servir la raíz o cualquier directorio (sin especificar fichero), cual se debería servir. Típicamente se usa index.algo, pero podría ser cualquier fichero. Esta directiva indica que fichero servir y en que orden de prioridad. Por ejemplo:
    DirectoryIndex index.php index.html index.htm
    

    Primero miraría si existe un fichero index.php, en caso que no exista buscaría el siguiente (index.html) y así el listado que indiquemos. En caso que no exista ninguno, se serviría un 404

  • ServerName y ServerAlias: Nombres a los que responde según el header Host. Se pueden especificar wildcards tanto pode delante (*.systemadmin.es) como por detrás (webmail.*). La diferencia entre ServerName y ServerAlias a la practica tiene poca importancia.

En cuanto a la gestión de logs, personalmente uso cronolog ya que una vez configurado cómo queremos almacenar los logs no deberemos hacer mantenimiento a no se que queramos eliminar los antiguos. Para ello suelo emplear un simple script que haga limpieza:

#!/bin/bash
for i in $(find /var/www/ -maxdepth 2 -iname logs);
do

        #eliminacion de los mas antiguos de 10 dias
        find $i -mtime +10 -type f -exec rm {} \;

        #eliminacion de directios vacios
        find $i -empty -type d -exec rmdir {} \; 2>/dev/null

        #compresión de logs ya rotados
        find $i -type f -iname \*\.log -mtime +2 -exec gzip {} \;

done

Deberemos adaptar el find del for para que encuentre los directorios raíz dónde tenemos los logs.

Para conocer el estado del Apache existe el modulo mod_status, que nos indica que esta haciendo dicho daemon. Generalmente se instala en /server-staus con acceso limitado por IP de origen.

En el scoreboard veremos los estado del los apachitos (procesos apache) y podremos ver si existe algún problema con algún VirtualHost. Típicamente podremos ver:

  • Se nos llena el scoreboard de W: Cuando un slot esta en estado W significa que esta contestando, pero si vemos que se nos acumulan W posiblemente esta contestando muy lentamente por algún motivo o bien simplemente se queda colgado. Generalmente indica problemas en la base de datos.

    Si habilitamos la opción

    ExtendedStatus On
    

    Tendremos un listado de todas las peticiones y su estado, para cuanto tiempo lleva un slot en el estado actual deberemos fijarnos en la columna SS. Por lo tanto, las peticiones en estado W que tenga el SS alto son las primeras que deberemos investigar. Evidentemente, si servimos contenido estático (un mp3) es lógico que tarde en ser entregado y por lo tanto que su SS sea alto.

  • Se nos llena el scoreboard de K: Tendremos que ver si nos interesa reducir el tiempo de KeepAlive de las conexiones. Por defecto lo tenemos a 5 segundos, pero lo podemos dejar en 1 o 2 segundos según la aplicación.

En otra ocasión ya hablamos de en que debemos fijarnos para entender el problema que tenga un entorno LAMP

Otra cosa a tener en cuenta es la diferencia entre ServerLimit y MaxClients: ServerLimit es el límite fijo que no puede ser modificado mediante una recarga de configuración (graceful) mientras que MaxClients es el límite actual.

Actualmente mod_status no muestra los slots de Apache que quedan deshabilitados por la directiva MaxClients, por lo que nos puede dar pie a error al suponerlos libres. En su momento hice un patch para evitar esto y será incluido en la próxima release de Apache (2.4), actualmente ya se encuentra disponible en la versión beta desde la versión 2.3.11.

Relacionados

Imprimir Imprimir

4 comments to “Guía de supervivencia con Apache”

  1. Pero ¿el módulo mod_status aporta algo más de lo que nos muestra apachectl? porque con la opción status ya nos da el estado de los threads de apache y vemos si tenemos demasiados en situación de keep_alive:

    8 requests currently being processed, 4 idle workers

    KC_C_C.WC__C

    Scoreboard Key:
    “_” Waiting for Connection, “S” Starting up, “R” Reading Request,
    “W” Sending Reply, “K” Keepalive (read), “D” DNS Lookup,
    “C” Closing connection, “L” Logging, “G” Gracefully finishing,
    “I” Idle cleanup of worker, “.” Open slot with no current process

  2. En realidad justo eso es el mod_status, fíjate en el apachectl lo que esta haciendo:

    status)
        $LYNX $STATUSURL | awk ' /process$/ { print; exit } { print } '
        ;;
    fullstatus)
        $LYNX $STATUSURL
        ;;
    

    El apachectl pide la información por una petición HTTP al mod_status

  3. Ah, que bobo… claro, por eso necesitas tener instalado el lynx para que funcione la opción de status en apachectl… ya me extrañaba a mi que la gente de apache duplicara esfuerzos así de forma tan tonta :-)

  4. Hola chicos

    (8 requests currently being processed, 4 idle workers ) = 12 conexiones de apache abiertas, esto se podría considerar como 12 “clients” en base a una directiva de MaxCllients de 256?

Deja un comentario:

XHTML - Tags permitidos:<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>