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í. 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. 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 <ri...@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 <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 > > > > 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 > **************************************************/ > > ------------------------- > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- Rafael Henrique da Silva Faria ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
