[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