[GTER] Navegação através de proxy transparente ficando lenta até parar...

Willian Tomaz Nieckarz wt.nieckarz at gmail.com
Tue Jan 5 11:34:51 -02 2010


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
>



More information about the gter mailing list