[FUG-BR] Tentando migrar o manicomio-share pra FreeBSD - 3ª tentativa

Quarta Maio 13 22:05:27 BRT 2015

On 13-05-2015 15:36, Rafael Henrique Faria wrote:
> Verdade, bem lembrado pelo Nilton.
>
> Durante a utilização do servidor, fique acompanhando o "iostat -x 1"
>
> Veja a porcentagem de uso do disco  (ultima coluna). Se estiver
> travado em 100%, o gargalo pode estar aí.
Opa boa vou checar isso também. O servidor de teste tem um SSD de 250Gb 
EVO da Samsung.
Vou olhar isso.

>
> Eu não sei como pode estar funcionando esse seu sistema.
> Mas como é um tracker privado, imagino que ele deve fazer os seguintes
> procedimentos:
> - ele recebe a requisição informando um hash do torrent, e também um
> hash do passkey. Com isso o programa precisará realizar 2 consultas ao
> banco de dados, uma para verificar o hash do torrent, e obter as
> informações do mesmo, e a segunda consulta para verificar o acesso da
> passkey.
> - em seguida será atualizada a quantidade de bytes enviados e
> recebidos por aquele passkey (daquele usuário em questão), para
> contabilização. Será um update em alguma tabela do banco.
> - e ele pode também estar fazendo uma verificação de quantas pessoas
> estão realizando o seeding e o leeching deste torrent, assim
> atualizando outra tabela.
> Em média serão 2 acessos de leitura ao banco, e 2 acessos de gravação.
> Isso para cada requisição.
>
> O mariadb está no mesmo servidor? Quantas conexões ele está
> configurado para receber? Lembre de manter sempre em sincronia a
> quantidade de threads que o apache possui com a quantidade de conexões
> que o seu banco pode receber.
O mariadb está no mesmo servidor. Eu usei uma vez aqueles programas pra 
optimizar o acesso à base.
Depois vou colar aqui o my.cnf que agora to sem acesso ao servidor de 
testes.

>
> Essa é uma das vantagens de se utilizar o php-fpm, você consegue
> manipular melhor essa relação de instâncias do servidor de aplicação X
> conexões ao banco de dados.
>
> Você chegou a monitorar a quantidade de queries que o mariadb está
> recebendo no momento que o servidor não aguenta mais?
>
> Qual o tempo de processamento de cada uma destas aplicações (mariadb e apache)?
>
> Boa sorte aí.
>
> Abraço.
>
> 2015-05-13 15:06 GMT-03:00 Nilton Jose Rizzo <rizzo em i805.com.br>:
>> Em Tue, 12 May 2015 19:47:03 -0300, Marcelo Gondim escreveu
>>> On 12-05-2015 18:17, Tiago Ribeiro wrote:
>>>>> Em 12/05/2015, à(s) 17:36, Marcelo Gondim <gondim em 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
>>
>>
>>    Godim .... essas requisições são para o apache, corretp?
>> mas e se não for o apache o problema e sim o mysql?  Já pensou
>> que cada requisição precisa realizar uma query no banco, será que seu
>> sistema de arquivos / disco não está suportando o mysql?
>>
>>
>> ---
>> /*************************************************
>> **Nilton José Rizzo            UFRRJ
>> **http://www.rizzo.eng.br      http://www.ufrrj.br
>> **http://lattes.cnpq.br/0079460703536198
>> **************************************************/
>>