[GTER] Navegação através de proxy transparente ficando lenta até parar...
Igor Luiz Oliveira de Souza
igorluiz at solic.com.br
Sat Jan 2 20:05:22 -02 2010
Olá pessoal,
Há algum tempo venho sofrendo com um problema com o Squid e depois de
muita busca, ainda não consegui encontrar o ponto de falha.
Acredito que essa discussão talvez seja recorrente, mas me parece ser
algum tipo de ajuste particular no meu ambiente pra ter o problema
resolvido. Então, aqui vai minha história...
A cerca de dois meses atrás, comecei uma configuração padrão de Squid
em 15 servidores em 10 ISP's diferentes, dos quais sou responsável por
essa área. O número de usuários atendido por cada servidor varia em
torno de 150 a 500 usuários. A banda em cada provedor varia de 4 a 30
Mbps. Eu sei que pode ser um grande intervalo de variação, mas estou
citando isso, apenas para dar uma idéia da dimensão dos ambientes que
estamos tratando.
Bem, nos primeiros 10 a 15 dias, tudo funcionou perfeitamente em todos
eles... sem qualquer problema, sem qualquer ocorrência.
Depois disso, 4 destes servidores(11 ainda estão funcionando
perfeitamente) começaram a apresentar o mesmo sintoma:
- A navegação começa a ficar lenta até quase parar (em alguns casos
retorna ao normal sem qualquer intervenção - de forma intermitente -
eis o grande calo!!!)
Os proxies estão rodando em modo transparente, então se eu desativar o
redirecionamento do netfilter, fazendo o tráfego ir direto pra
internet, a navegação volta ao normal, de imediato.
Estou usando quase que a mesma configuração do Squid em todos os
servidores, basicamente mudando apenas o cache_dir, baseado no tamanho
do disco disponível para o cache.
A intenção principal destes proxies são para economia de banda, mas
claramente visando manter o equilíbrio com o tempo de resposta para o
usuário, de forma que usando o proxy, a navegação continue mais
rápida(ou igual) se comparada à navegação conectando diretamente sem
proxy.
Todos os servidores estão rodando Squid v.2.6.stable22
Já chequei carga de CPU, uso de memória, I/O em disco, e na minha
humilde análise, não consegui identificar o ponto de falha.
Vou colocar aqui algumas informações que podem úteis na identificação,
tomando como exemplo um dos servidores que está apresentando o
problema.
==================================================================
=> Link do provedor:
10 Mbps
=> Usuários atendidos simultanamente:
170 em um momento de ocorrência do problema (há alguns dias atrás já
chegou a ter picos de quase 500 sem apresentar o problema)
=> Hardware Configs
--------------------------------
CPU: Intel Core 2 Quad - 2.66GHz
RAM: 8 Gb
=> OS
--------------------------------
Linux Slackware v.13 - Kernel 2.6.29.6-smp
=> SQUID CONF (Squid v.2.6.stable22)
--------------------------------
acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl to_localhost dst 127.0.0.0/8
acl SSL_ports port 443
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 # https
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl CONNECT method CONNECT
http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
acl our_networks src xxx.xxx.xxx.xxx/16
acl this_server src yyy.yyy.yyy.yyy/32
http_access allow our_networks
http_access allow localhost
http_access deny all
icp_access allow all
http_port 3128 transparent
hierarchy_stoplist cgi-bin ?
cache_mem 512 MB
maximum_object_size_in_memory 384 KB
memory_replacement_policy heap GDSF
cache_replacement_policy heap LFUDA
cache_dir aufs /cache 500000 64 256
maximum_object_size 400 MB
access_log /usr/local/squid/var/logs/access.log squid
cache_log /usr/local/squid/var/logs/cache.log
cache_store_log none
logfile_rotate 3
acl QUERY urlpath_regex cgi-bin \?
cache deny QUERY
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern . 0 20% 4320
acl apache rep_header Server ^Apache
broken_vary_encoding allow apache
cache_mgr support at mydomain.com.br
visible_hostname yyy.yyy.yyy.yyy
snmp_port 3401
acl snmppublic snmp_community public
snmp_access allow snmppublic this_server
snmp_access deny all
snmp_incoming_address 0.0.0.0
snmp_outgoing_address 255.255.255.255
coredump_dir /cache
=> Squid CACHE MANAGER INFO:
--------------------------------
Squid Object Cache: Version 2.6.STABLE22
Start Time: Sat, 02 Jan 2010 18:08:57 GMT
Current Time: Sat, 02 Jan 2010 21:10:19 GMT
Connection information for squid:
Number of clients accessing cache: 9
Number of HTTP requests received: 277856
Number of ICP messages received: 0
Number of ICP messages sent: 0
Number of queued ICP replies: 0
Request failure ratio: 0.00
Average HTTP requests per minute since start: 1532.1
Average ICP messages per minute since start: 0.0
Select loop called: 3581679 times, 3.038 ms avg
Cache information for squid:
Request Hit Ratios: 5min: 35.5%, 60min: 39.7%
Byte Hit Ratios: 5min: 17.0%, 60min: 17.0%
Request Memory Hit Ratios: 5min: 9.0%, 60min: 5.7%
Request Disk Hit Ratios: 5min: 52.4%, 60min: 48.6%
Storage Swap size: 56684352 KB
Storage Mem size: 513584 KB
Mean Object Size: 20.48 KB
Requests given to unlinkd: 0
Median Service Times (seconds) 5 min 60 min:
HTTP Requests (All): 0.18699 0.15888
Cache Misses: 0.30459 0.30459
Cache Hits: 0.01309 0.00562
Near Hits: 0.32154 0.08265
Not-Modified Replies: 0.00286 0.00286
DNS Lookups: 0.13042 0.12472
ICP Queries: 0.00000 0.00000
Resource usage for squid:
UP Time: 10881.453 seconds
CPU Time: 127.668 seconds
CPU Usage: 1.17%
CPU Usage, 5 minute avg: 1.30%
CPU Usage, 60 minute avg: 0.91%
Process Data Segment Size via sbrk(): 851000 KB
Maximum Resident Size: 0 KB
Page faults with physical i/o: 0
Memory usage for squid via mallinfo():
Total space in arena: 851000 KB
Ordinary blocks: 850398 KB 31794 blks
Small blocks: 0 KB 0 blks
Holding blocks: 27348 KB 5 blks
Free Small blocks: 0 KB
Free Ordinary blocks: 601 KB
Total in use: 877746 KB 100%
Total free: 601 KB 0%
Total size: 878348 KB
Memory accounted for:
Total accounted: 726322 KB
memPoolAlloc calls: 51472567
memPoolFree calls: 44989921
File descriptor usage for squid:
Maximum number of file descriptors: 16384
Largest file desc currently in use: 1153
Number of file desc currently in use: 972
Files queued for open: 0
Available number of file descriptors: 15412
Reserved number of file descriptors: 100
Store Disk files open: 69
IO loop method: epoll
Internal Data Structures:
2767942 StoreEntries
36519 StoreEntries with MemObjects
36391 Hot Object Cache Items
2767222 on-disk objects
=> 'top' COMMAND OUTPUT:
--------------------------------
top - 18:14:18 up 2 days, 23:34, 1 user, load average: 0.26, 0.17, 0.08
Tasks: 113 total, 1 running, 112 sleeping, 0 stopped, 0 zombie
Cpu0 : 0.0%us, 0.3%sy, 0.0%ni, 98.7%id, 1.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu1 : 0.0%us, 0.3%sy, 0.0%ni, 97.7%id, 2.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu2 : 0.3%us, 0.0%sy, 0.0%ni, 99.3%id, 0.3%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu3 : 0.3%us, 0.0%sy, 0.0%ni, 99.0%id, 0.3%wa, 0.0%hi, 0.3%si, 0.0%st
Mem: 8305904k total, 3632340k used, 4673564k free, 525752k buffers
Swap: 6297440k total, 0k used, 6297440k free, 1980300k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
12561 nobody 20 0 874m 863m 2372 S 0 10.6 2:09.52 squid
=> 'free' COMMAND OUTPUT:
--------------------------------
total used free shared buffers cached
Mem: 8305904 3648668 4657236 0 527276 1991908
-/+ buffers/cache: 1129484 7176420
Swap: 6297440 0 6297440
=> 'vmstat' COMMAND OUTPUT:
--------------------------------
root at proxy:/usr/local/squid/etc# vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 0 4655236 527384 1993244 0 0 12 37 8 24 0 0 98 1
0 0 0 4654980 527384 1993292 0 0 0 504 4612 368 0 0 99 0
0 0 0 4654848 527424 1993524 0 0 40 0 4816 671 0 0 98 2
0 0 0 4654724 527436 1993712 0 0 168 0 4740 522 0 0 99 1
0 0 0 4654352 527448 1993876 0 0 0 76 4818 487 0 0 100 0
0 0 0 4654344 527460 1993976 0 0 4 0 4718 500 0 0 100 0
0 0 0 4654220 527468 1994120 0 0 24 588 4579 398 0 0 99 1
0 0 0 4653848 527480 1994332 0 0 104 0 4853 627 0 0 99 1
0 0 0 4653360 527500 1994532 0 0 0 0 4909 683 0 0 100 0
0 0 0 4653212 527516 1994716 0 0 0 40 4877 447 0 0 100 0
0 0 0 4652964 527536 1994732 0 0 12 0 4721 518 0 0 100 0
0 0 0 4652964 527548 1994800 0 0 16 820 4810 708 0 1 99 1
0 0 0 4652716 527572 1994936 0 0 20 0 4696 628 0 0 99 1
==================================================================
Então, com essas informações, alguém consegui visualizar algum erro ou
sugerir algum ajuste?
Peço desculpas pelo e-mail longo, mas tentei ser detalhado o
suficiente para esclarecer a situação.
Grato a todos desde já, principalmente àqueles que tiveram a paciência
e o interesse de chegar até aqui. :-)
Abraços,
--
Igor Luiz Oliveira de Souza
Solic Tecnologia e Sistemas
(77) 8829-7678
igorluiz at solic.com.br
More information about the gter
mailing list