On 13-05-2015 11:12, Fabricio Lima wrote:
Vc informou anteriormente:
# sysctl kern.ipc.nmbclusters
kern.ipc.nmbclusters: 1013816
Cada cluster consome 2K de memoria.
como vc ja ta com 1milhao de mbufs. o q daria 2GB ram.
Como essa maquina é amd64, vamos aumentar isso. ___dobra este valor.__ poe
2048000
Esse servidor precisa ter no minimo 8gb. serao 4gb so pra entregar as
conexoes pro apache!
e uns 4gb pra banco/apache.
Então essa máquina de teste tem 16Gb de ram mas o servidor em produção
tem 48Gb e usa quase toda ela.
Quanto ao tráfego é muito pouco em torno de 5Mbps com cloudflare e
30Mbps sem cloudflare. O lance mesmo são a quantidade de conexões
simultâneas que temos por causa do tracker. Olha a estatística:
Informações de Usuários
Online no Momento 2461
Online nas Últimas 24 Horas 24174
Último Membro Registrado marlomattos
Registros Hoje 30
Total de Registrados 139,317
Pendentes 0
Homens 122,463
Mulheres 14,799
Sexo Indefinido 2,055
Advertidos 1,027
Total Upado 158.33 PB
Informações de Torrents
Total de Torrents 174,151
Torrents Ativos 88,273
Torrents reciclados  4,759
Torrents na Moderação 3
Peers 584,893
Seeders 556,548
Leechers 28,345
Conectáveis Sim 251,581
Conectáveis Não 333,253
Status de Registro Mensal
Mês Usuarios
2015-05 526
2015-04 1348
2015-03 1312
2015-02 1230
2015-01 1355
2014-12 1311
2014-11 1272
altera tb os pontos abaixo, achei seus valores muito 'fraquinhos' e outros
tunaram pro proprio valor default:
kern.ipc.maxsockbuf=4194304 #este é o valor indicado pra gigabit, mesmo q
vc esteja em 100mbit, creio q vc ta topando esta placa, o q lhe deixaria
elegivel pra usar este valor.
net.inet.tcp.sendbuf_max=4194304 # (default 2097152)
net.inet.tcp.recvbuf_max=4194304 # (default 2097152)
kern.ipc.soacceptqueue=1024 # backlog queue depth for accepting new TCP
connections
net.inet.tcp.mssdflt=1460 # maximum segment size (largest payload)
net.inet.tcp.recvspace: 262144 # estava em 128k
net.inet.tcp.sendspace: 262144 # estava no default 32k
agora quero ver esse cabrunco nao aguentar...
Vou checar com essas confs valeu!!! :)
mesmo eskema, aplica estes valores, vira o IP, e na hora q der crash pega o
nestat -m e aquele outro q sugeriram q tem tanta letra q nao consigo
decorar heheeh -Lapnmasdfhasdflasd
[ ]'s
Fabricio Lima
Sendmail administration is not black magic. There are legitimate technical
reasons why it requires the sacrifice of a live chicken.
Em 13 de maio de 2015 05:44, Fabricio Lima <lis...@fabriciolima.com.br>
escreveu:
Blz
Ta mole
Aumenta mbufs e bytes allocated to network
To no cel
Em terça-feira, 12 de maio de 2015, Marcelo Gondim <gon...@bsdinfo.com.br>
escreveu:
On 12-05-2015 18:17, Tiago Ribeiro wrote:
Em 12/05/2015, à(s) 17:36, Marcelo Gondim <gon...@bsdinfo.com.br>
escreveu:
On 12-05-2015 17:06, Fabricio Lima wrote:
consegue virar o site pra ele, dar um netstat -m deixar fritar e colar
pra
nos?
enquanto o DNS está virando gradualmente na internet, o site chega a
abrir?
e so depois q 'frita' q passa a nao abrir mais?
quanto tem de memoria?
Vou fazer um teste mais tarde. O teste é instantâneo porque uso a
cloudflare e aí só mudo o IP de destino. Dessa forma não preciso mexer com
os DNS. :)
Altero o IP e aí é só contar até 10 rsrsrsrs
Vou fazer isso e mando aqui na lista. Mais alguma saída pra eu postar
aqui?
[]'s
Pega o netstat -LnAa | grep fffff800079cb800
sendo o fffff800079cb800 a saída do sonewconn, você
vai conseguir pegar se é o apache mesmo que está fazendo a fila.
Não conheço nada do Nginx, mas vale dar uma olhada sobres estes tunings
do
FreeBSD pra rodar com ele, neste link[1] .
[1] http://nginx.org/en/docs/freebsd_tuning.html
Fiz um teste agora e o resultado aí abaixo:
# netstat -m
90991/8954/99945 mbufs in use (current/cache/total)
90990/1376/92366/1013816 mbuf clusters in use (current/cache/total/max)
90990/1355 mbuf+clusters out of packet secondary zone in use
(current/cache)
0/300/300/506907 4k (page size) jumbo clusters in use
(current/cache/total/max)
0/0/0/150194 9k jumbo clusters in use (current/cache/total/max)
0/0/0/84484 16k jumbo clusters in use (current/cache/total/max)
204727K/6190K/210918K bytes allocated to network (current/cache/total)
0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters delayed (4k/9k/16k)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
0 requests for sfbufs denied
0 requests for sfbufs delayed
140 requests for I/O initiated by sendfile
May 12 19:39:28 www kernel: sonewconn: pcb 0xfffff80229096930: Listen
queue overflow: 30001 already in queue awaiting acceptance (20368
occurrences)
Pois é não aparece esse endereçamento sonewconn saca só abaixo:
# netstat -LnAa
Current listen queue sizes (qlen/incqlen/maxqlen)
Tcpcb Proto Listen Local Address
fffff804401e6800 tcp4 33/0/50000 186.193.48.14.443
fffff802a0d05400 tcp4 20358/2/50000 186.193.48.14.80
fffff8000de95800 tcp4 0/0/128 *.4321
fffff8000de95c00 tcp6 0/0/128 *.4321
fffff8000dd74000 tcp4 0/0/150 127.0.0.1.3306
Some tcp sockets may have been created.
unix 0/0/150 /tmp/mysql.sock
unix 0/0/1024 /var/run/memcached.sock
unix 0/0/4 /var/run/devd.pipe
unix 0/0/4 /var/run/devd.seqpacket.pipe
-------------------------
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
--
[ ]'s
Fabricio Lima
Sendmail administration is not black magic. There are legitimate technical
reasons why it requires the sacrifice of a live chicken.
-------------------------
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
