[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: optimizacion cache squid



On 10/09/13 15:54, Mario Vila wrote:
jors@enchufado.com escribió:
On , Mario Vila wrote:
Hola mundo:
Haber si podeis dar luz a una pequeña duda que me corroe.
Tengo un squid corriento en un guruplug 1,2ghz y 1gb RAM. Soporta el
tráfico de una red comunitaria de 35 usuarios para un adsl asimetrico
de 20 mb. Ultimamente se queda muy corto y ando mirando como optimizar
el squid.
Está usando un sistema de ficheros ufs y un algoritmo de busqueda lru.
Habia pensado usar una tarjeta sdhc clase10 para optimizar la
velocidad de lectura escritura del cache y usar aufs y heap LFUDA como
parametros del cache, pero e visto gente que prefiere coss o incluso
dividir el cache en varios directorios según el tamaño de paquetes.
En este servidor tan limitado como podria optimizar los recursos y
evitar la saturación el mismo, pues ahora con 10 usuarios conectados
se satura y rechaza conexiones.
Un saludo y gracias de antemano.

Con ese cacharro, antes de mirar si es el software (o su
configuración) el que te hace algún cuello de botella, ¿has mirado que
no sea el hardware? Es decir, cuando notas que Squid va saturado,
deberías mirar el uso de los diferentes recursos (cpu, memòria RAM,
disco...).

Yo tengo un trasto pequeñajo de estos y sin duda la tarjeta SD
(también de clase10) es un cuello de botella considerable. Si te
encuentras que ese es el factor limitante, igual puedes probar con
otro almacenamiento (SATA no creo que tengas, pero diría que un USB es
más rápido que la SD).

Salut,
jors


Gracias por los comentarios, han sido de gran ayuda.

Aquí estamos, para aprender y enseñar lo aprendido :)

Creo que el problema es la limitación de la memoria ssd interna un
hdparm contra la particion del sistema solo da 7m/s se satura muy
facilmente de ram y cpu va sobrado.

¿7MB/s? ¿Qué storage es ese? La tarjeta SD de mi Raspberry Pi (diria es Clase 10) que ya me parece un tanto lenta me da estos valores:

# hdparm -Tt /dev/mmcblk0p1
/dev/mmcblk0p1:
 Timing cached reads:   326 MB in  2.01 seconds = 162.35 MB/sec
 Timing buffered disk reads:  48 MB in  3.09 seconds =  15.55 MB/sec

# ioping -c3 .
4.0 kb from . (ext4 /dev/root): request=1 time=1.5 ms
4.0 kb from . (ext4 /dev/root): request=2 time=1.3 ms
4.0 kb from . (ext4 /dev/root): request=3 time=1.5 ms

--- . (ext4 /dev/root) ioping statistics ---
3 requests completed in 2.0 s, 696 iops, 2.7 mb/s
min/avg/max/mdev = 1.3 ms / 1.4 ms / 1.5 ms / 110 us

Y a la que le metes un poco de chicha p.ej en escritura secuencial sostenida, la cosa se viene abajo:

# dd if=/dev/zero of=test.dd count=1 bs=250M
1+0 records in
1+0 records out
262144000 bytes (262 MB) copied, 38.8989 s, 6.7 MB/s

Como bien habeis recomendado voy instalar una sdhc en reiserfs noatime
notail XD(he echo diversas pruebas de velocidad y creo que funciona
mejor que un pincho usb2.0)

Y 'commit=600,data=writeback', y si usas ext4 también 'discard'.

No hice ninguna prueba al respecto, pero cuando escribo en un USB tengo la sensación que va bastante más rápido que contra la SD (a pesar de la escritura asíncrona).

Otro cuello de botella que me e encontrado en el server:
cat /proc/sys/fs/file-max 51301

¿Quieres decir que tienes un número tan alto de ficheros abiertos?

ulimit -Sn 1024
ulimit -Hn 1024
creo que son valores demasiado bajos

Yo tengo el hard limit más alto (4096), pero estos límites ya no son "system wide", sino por usuario.

Salut,
jors


Reply to: