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

Igor Luiz Oliveira de Souza igorluiz at solic.com.br
Sat Jan 2 23:17:02 -02 2010


É... também acho que não seja RAM...

Sobre os parâmetros de tunning que você citou, eu já tinha alguns
deles, e alguns já vem até com valor maior no Slackware 13, como o
/proc/sys/fs/file-max, que já vem com 786932.
Vou consultar como está o status dos outros que você sugeriu o ajuste
via sysctl, e se for aplicável, vou mandar ver...

Vou precisar fazer um plano de execução das sugestões da turma, pra
poder realmente identificar o fóco do problema... se aplicar tudo de
vez, posso resolver e ficar perdido sem saber qual efetivamente foi a
solução.

-- 
Igor Luiz Oliveira de Souza
Solic Tecnologia e Sistemas
(77) 8829-7678
igorluiz at solic.com.br


2010/1/2 Juliano Primavesi | KingHost <juliano at kinghost.com.br>:
>
> Te digo mais... tu tinha 7 Giga livres... não considero buffers e cached
> como "usado"...
>
> Entao RAM definitivamente não é...
>
> Se voce estiver usando linux, isso pode ajudar:
>
> /bin/echo 32768 > /proc/sys/net/ipv4/ip_queue_maxlen
> /bin/echo 20 > /proc/sys/vm/swappiness
> /bin/echo 128000 > /proc/sys/fs/file-max
> /bin/echo 8192 > /proc/sys/net/ipv4/tcp_max_syn_backlog
>
> /sbin/sysctl -w net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait=60
> /sbin/sysctl -w net.netfilter.nf_conntrack_tcp_timeout_time_wait=60
> /sbin/sysctl -w
> net.ipv4.netfilter.ip_conntrack_sctp_timeout_established=86400
> /sbin/sysctl -w
> net.ipv4.netfilter.ip_conntrack_tcp_timeout_established=86400
> /sbin/sysctl -w net.netfilter.nf_conntrack_sctp_timeout_established=86400
> /sbin/sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=43200
> /sbin/sysctl -w
> net.ipv4.netfilter.ip_conntrack_tcp_timeout_established=43200
> /sbin/sysctl -w net.ipv4.netfilter.ip_conntrack_udp_timeout=10
> /sbin/sysctl -w net.core.somaxconn=65535
> /sbin/sysctl -w net.core.netdev_max_backlog=8192
>
> Esses comandos vao "alargar" a capacidade de processamento IP do servidor,
> reduzir a probabilidade de uso de swap e aumentar o numero de arquivos que
> voce pode abrir ao mesmo tempo.
>
> NORMALMENTE apareceria uma mensagem de erro no dmesg sobre alguma dessas
> ocorrencias chegar no seu limite.
>
> Juliano
>
> Igor Luiz Oliveira de Souza escreveu:
>>
>> Juliano,
>>
>> Tinha colocado lá no meu e-mail original, descrevendo o problema...
>> Esso foi o valor durante a ocorrência do problema, ou seja no mesmo
>> momento que coletei aquelas informações do cache_manager:
>>
>> => 'free' COMMAND OUTPUT:
>> --------------------------------
>>            total       used       free     shared    buffers     cached
>> Mem:       8305904    3648668    4657236          0     527276    1991908
>> -/+ buffers/cache:    1129484    7176420
>> Swap:      6297440          0    6297440
>>
>>
>> Ou seja, no momento da ocorrência eu ainda tinha 4.6 Gb de RAM livres!
>> Alguma relação que eu possa estar negligenciando?
>>
>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>



More information about the gter mailing list