En una red de alto tráfico (con cientos de estaciones de trabajo conectándose simultáneamente) me topé con un Proxy SQUID que estaba causando un cuello de botella debido a la utilización de sólo uno de los 4 núcleos del procesador donde estaba corriendo el servicio.
Investigando conseguí que sólo la versión 3.2 de SQUID permite SMP y me encontré con que esta versión aún no está empaquetada, ni siquiera en la rama “experimental” de Debian SID (para el momento en el cual escribo esto). Por lo tanto me tocó compilar el paquete a mano, siguiendo los pasos acostumbrados, con estos parámetros específicos en Debian Squeeze:
aptitude install build-essential samba-client \
samba-tools libcppunit-1.12-1 libcppunit-dev \
libcap2-dev libpam0g-dev libssl-dev
wget http://www.squid-cache.org/Versions/v3/3.2/squid-3.2.4.tar.gz
tar -xzf squid-3.2.4.tar.gz
cd squid-3.2.4
./configure --enable-delay-pools --enable-ssl \
--enable-linux-netfilter --enable-auth \
--prefix=/usr --localstatedir=/var \
--libexecdir=${prefix}/lib/squid --srcdir=. \
--datadir=${prefix}/share/squid --sysconfdir=/etc/squid \
--with-default-user=proxy --with-logdir=/var/log/squid \
--with-pidfile=/var/run/squid.pid
make -j 5 all
make install
Hecho esto ya se pueden levantar tantos procesos simultáneos del servicio se deseen con sólo colocar en la directiva “workers” de squid.conf la cantidad de instancias de SQUID que se querrán a la vez:
workers 4
Antes de este cambio, un sólo núcleo de los 4 disponibles en el procesador del servidor registraba uso del 100% permanentemente, ofuscándose y limitando gravemente el ancho de banda disponible. Luego usando la versión 2.3.4 compilada, los cuatro procesadores se mantienen por debajo del 20% y el ancho de banda se multiplicó visiblemente hasta lograr usar todo el disponible.
Cuello de botella resuelto :-)
Bueno mantener software asi, compilado a mano para produccion no es una muy buena solucion, temporalmente si, pero cuando tienes que mantener varias cosas que tienen dependencias y tienes que ir compilando todo ya que las versiones de las mismas necesitan ser compatibles, etc, es un infierno (bah, es como mantener un Slackware)
Cada vez que un sysadmin / usuario .. Debianita tiene que hacer esto (compilar e instalar directamente en el sistema) y crean un tutorial me pregunto ciertas cosas:
1) Ok si Debian no tiene el paquete porque no lo haces?
2) Cuantos pasos mas hay de bajar el tar.gz y hacer los pasos de la configuracion?
Y la respuesta es tan sencilla como, Debian y su sistema de empaquetado de los 80 (sin ahondar mucho) deberia evolucionar.
Si los paquetes fuesen mas sencillos de hacer, probablemente en vez de ponerel tutorial de squid 3.2.4 con soporte a SMP pudieras hostear el paquete en distintas arquitecturas, inclusive, e inclusive enviarselo al maintaner de squid en debian.
Lamentablemente, nadie influenciable dentro de la comunidad de Debian va a leer esto, y aun asi leyendolo, Debian como organizacion es de lo mas burocratico en el mundo del software libre, mi consejo, usen otras distros, (no basadas en Debian), o comiencen a generar *ruido* -no flames- con ideas para que se pueda mover movimientos para actualizar (al menos llevarlo al 2000) el sistema de paquetes de debian.
Mis 2 lochas fuertes.