[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