[GTER] Navegação através de proxy transparente ficando lenta até parar...
Igor Luiz Oliveira de Souza
igorluiz at solic.com.br
Tue Jan 5 12:42:55 -02 2010
Exatamente Willian.
--
Igor Luiz
2010/1/5 Willian Tomaz Nieckarz <wt.nieckarz at gmail.com>:
> Esses dados são do momento em que o servidor estava problemático?
>
> 2010/1/2 Igor Luiz Oliveira de Souza <igorluiz at solic.com.br>:
>> 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
>> --
>> gter list https://eng.registro.br/mailman/listinfo/gter
>>
> --
> gter list https://eng.registro.br/mailman/listinfo/gter
>
--
Igor Luiz Oliveira de Souza
Solic Tecnologia e Sistemas
(77) 8829-7678
igorluiz at solic.com.br
More information about the gter
mailing list