Squid 3.2.4 SMP en Debian Squeeze

17/12/2012

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 :-)



5 Comentarios a “Squid 3.2.4 SMP en Debian Squeeze”

  1. Jhon Morci dice:

    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.

  2. Andres Castillo dice:

    @John Morci, la verdad no es tan complicado hacer un paquete .deb como parece. Quizás un rpm es un poquito más fácil pero nada del otro mundo. El problema realmente es que la filosofía de los paquetes es hacer las cosas más fácil pero perdiendo flexibilidad del usuario. Muchísimos programas de software libre tienen una gran cantidad de opciones que muchas veces no se compilan porque no le interesa a la mayoría de la gente. Para esto hay una solución que son distros como Gentoo que utilizando etiquetas USE, se puede especificar lo que se necesita y el se lo hace saber a cada respectivo ./configure.
    Pero en sí lo de los paquetes que comentas, desde mi punto de vista el mejor enfoque lo tuvo Slackware. Es extremadamente sencillo crear paquetes para esa distro para administrar sus propios sistemas. Así que el mundo ideal sería un Gentoo con soporte fuera de línea y un montón de paquetes precompilados, para uno sólo tener que compilar lo que sea realmente necesario.

    Respecto al comentario de Octavio y Squid, te recomiendo que pruebes habilitando el caché en memoria RAM lo más alto que puedas y deshabilitar cualquier caché de disco. Creeme que ahi si vas a ver muchísimo aumento en el desempeño de Squid. He tenido que experimentar mucho con eso porque tuve que hacer un sistema propio para saltarme el great firewall en China, y la máquina disponible era un VPS sin mucho poder en Estados Unidos, y de todas todas, el mayor cuello de botella es el caché.

  3. Vicente Lopez dice:

    Hola a todos, uso Debian desde hace tiempo por lo “facil” de administrar que es, ahora me encuentro con la necesidad de utilizar un squid, que ya tengo corriendo en la version 3.3.8 y que me gustaria que utilizara los 6 cores del procesador, de momento no tengo problemas de rendimiento, pero me gustaria adelantarme al problema y saber si en esta version ya esta compilado el tema de SMP.

    Gracias.

  4. [TR0N] dice:

    Saludos, Vicente.

    En las versiones nuevas de Debian tienes el paquete ya compilado. Si se te complica compilarlo usando el método que he descrito, puedes usar las versiones en backport de Debian Wheezy o (si no es un sistema crítico) de Debian Jessie. Saludos.

  5. Excelente post para describir unas de las varias formas de instalar Squid, lo cierto que la mejor forma de que este programa funcione es esta compilarlo desde las fuentes, pues ningún paquete pre-compilado en debían trae soporte para ssl activado entre otras cosas, esto se ve cuando hacemos un squid3 -v

    :~# squid3 -v
    Squid Cache: Version 3.3.8
    configure options: ‘–build=i486-linux-gnu’ ‘–prefix=/usr’ ‘–includedir=${prefix}/include’ ‘–mandir=${prefix}/share/man’ ‘–infodir=${prefix}/share/info’ ‘–sysconfdir=/etc’ ‘–localstatedir=/var’ ‘–libexecdir=${prefix}/lib/squid3′ ‘–srcdir=.’ ‘–disable-maintainer-mode’ ‘–disable-dependency-tracking’ ‘–disable-silent-rules’ ‘–datadir=/usr/share/squid3′ ‘–sysconfdir=/etc/squid3′ ‘–mandir=/usr/share/man’ ‘–enable-inline’ ‘–enable-async-io=8′ ‘–enable-storeio=ufs,aufs,diskd,rock’ ‘–enable-removal-policies=lru,heap’ ‘–enable-delay-pools’ ‘–enable-cache-digests’ ‘–enable-underscores’ ‘–enable-icap-client’ ‘–enable-follow-x-forwarded-for’ ‘–enable-auth-basic=DB,fake,getpwnam,LDAP,MSNT,MSNT-multi-domain,NCSA,NIS,PAM,POP3,RADIUS,SASL,SMB’ ‘–enable-auth-digest=file,LDAP’ ‘–enable-auth-negotiate=kerberos,wrapper’ ‘–enable-auth-ntlm=fake,smb_lm’ ‘–enable-external-acl-helpers=file_userip,kerberos_ldap_group,LDAP_group,session,SQL_session,unix_group,wbinfo_group’ ‘–enable-url-rewrite-helpers=fake’ ‘–enable-eui’ ‘–enable-esi’ ‘–enable-icmp’ ‘–enable-zph-qos’ ‘–enable-ecap’ ‘–disable-translation’ ‘–with-swapdir=/var/spool/squid3′ ‘–with-logdir=/var/log/squid3′ ‘–with-pidfile=/var/run/squid3.pid’ ‘–with-filedescriptors=65536′ ‘–with-large-files’ ‘–with-default-user=proxy’ ‘–enable-linux-netfilter’ ‘build_alias=i486-linux-gnu’ ‘CFLAGS=-g -O2 -fPIE -fstack-protector –param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall’ ‘LDFLAGS=-fPIE -pie -Wl,-z,relro -Wl,-z,now’ ‘CPPFLAGS=-D_FORTIFY_SOURCE=2′ ‘CXXFLAGS=-g -O2 -fPIE -fstack-protector –param=ssp-buffer-size=4 -Wformat -Werror=format-security’

    esa es la salida de un squid en debian testing (jessie) notamos que hay cosas activadas y otras que ni existen como el tan importante soporte para SSL, por ende hay dos opciones, o compilas y te creas tu propio paquete (yo lo hago sin tanto rollo con checkinstall) o te cambias a otra distro u otro sistema operativo como FreeBSD o en su defecto un Pfsense

Deja tu comentario