Re: [FUG-BR] [off-topic] segunda tentativa de migração manicomio-share para FreeBSD [RESOLVIDO]
Fala Marcelo, Como ficou a situacao depois de por PERSISTENT CONNECTIONS OFF ? É recomendado não usar conexoes persistentes entre o php e o mysql, como conversamos ja. E o xcache ? Ta rodando ? Parou de dar o load maluco agora ? 2013/1/13 Marcelo Gondim gon...@bsdinfo.com.br: Em 13/01/13 22:59, Antônio Pessoa escreveu: 2013/1/13 Marcelo Gondim gon...@bsdinfo.com.br Pessoal, Acho que descobri algo que pode estar causando todo o problema. Após colocar o KVM-IP e agora também tenho percebido melhor nos logs o seguinte: MCA: Bank 8, Status 0xcc194901009f MCA: Global Cap 0x1c09, Status 0x MCA: Vendor GenuineIntel, ID 0x206c2, APIC ID 0 MCA: CPU 0 COR (25892) OVER RD channel ?? memory error MCA: Address 0x5480c7b40 MCA: Misc 0x4670220100010386 Essa mensagem vira e mexe dá e quando o mysql dispara na cpu elas aparecem. Pelo que estou percebendo isso pode ser problema com algum banco de memória do servidor. Estou correto? Até os filhos do apache estão sendo assassinados com essas mensagens: [Wed Jan 09 23:49:40 2013] [notice] child pid 54806 exit signal Illegal instruction (4) [Wed Jan 09 23:49:40 2013] [notice] child pid 54308 exit signal Illegal instruction (4) [Wed Jan 09 23:49:40 2013] [notice] child pid 53252 exit signal Illegal instruction (4) [Wed Jan 09 23:49:40 2013] [notice] child pid 53120 exit signal Illegal instruction (4) E tipo já corrompeu uma base mysql uma vez e uma partição me obrigando à entrar em fsck manual. Também aconteceu de no meio do boot rebootar e umas duas vezes travar na ACPI e ficar quase 1 hora pra sair. Pedi para checarem a memória do servidor. Vamos ver, depois dessa ainda existe luz no fim do túnel. rsrsrsrs Você tem condições de executar o memtest completo nesse servidor? Seria interessante, mesmo com o resultado do suporte do data center. Ummm vou tentar. O problema também é que o suporte do datacenter não é tão bom, eles demoram muito e eles estão 7 horas na nossa frente. Ainda bem que não é comum ter essas paradas, só fiz dessa vez para tentar migrar para o FreeBSD e acho que acabei descobrindo um problema no Hardware. Também fiz umas mexidas de tunning. Abaixo como estão: sysctl.conf: = kern.ipc.somaxconn=4096 kern.ipc.shmall=262144 net.inet.ip.redirect=0 net.inet.ip.sourceroute=0 net.inet.ip.accept_sourceroute=0 net.inet.icmp.maskrepl=0 net.inet.icmp.log_redirect=0 net.inet.icmp.drop_redirect=1 net.inet.tcp.drop_synfin=1 net.inet.udp.blackhole=1 net.inet.tcp.blackhole=2 net.inet6.icmp6.nodeinfo=0 net.inet6.ip6.use_tempaddr=1 net.inet6.ip6.prefer_tempaddr=1 net.inet6.icmp6.rediraccept=0 net.inet.ip.fw.dyn_max=65536 net.inet.icmp.icmplim=500 loader.conf: == loader_logo=beastie kern.maxusers=1024 kern.ipc.nmbclusters=32768 kern.ipc.semmnu=256 kern.ipc.semmns=1024 kern.ipc.semmni=520 kern.ipc.semume=100 kern.ipc.shmmni=256 kern.ipc.msgseg=32767 kern.ipc.msgssz=32 kern.ipc.msgmnb=65535 kern.ipc.msgtql=2046 netstat -m: = 8659/13361/22020 mbufs in use (current/cache/total) 8551/4127/12678/32768 mbuf clusters in use (current/cache/total/max) 8551/4121 mbuf+clusters out of packet secondary zone in use (current/cache) 89/905/994/16384 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/8192 9k jumbo clusters in use (current/cache/total/max) 0/0/0/4096 16k jumbo clusters in use (current/cache/total/max) 19622K/15214K/34837K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 681 requests for I/O initiated by sendfile 0 calls to protocol drain routines ipcs -a: == Message Queues: T ID KEY MODEOWNERGROUPCREATOR CGROUP CBYTES QNUM QBYTES LSPIDLRPID STIMERTIMECTIME Shared Memory: T ID KEY MODEOWNERGROUPCREATOR CGROUP NATTCHSEGSZ CPID LPID ATIME DTIMECTIME Semaphores: T ID KEY MODEOWNERGROUPCREATOR CGROUP NSEMS OTIMECTIME gstat: = dT: 1.002s w: 1.000s L(q) ops/sr/s kBps ms/rw/s kBps ms/w %busy Name 0 2 0 00.0 2 640.40.1| mfid0 0 0 0 00.0 0 00.00.0| mfid0p1 0 0 0 00.0 0 00.00.0| mfid0p2 0 0 0 00.0 0 00.00.0| mfid0p3 0 0 0 00.0 0 00.00.0| mfid0p4 0 2 0 00.0 2 640.40.1| mfid0p5 0 0 0 00.0 0 00.00.0| mfid0p6 0 0 0 00.0 0 00.00.0|
Re: [FUG-BR] [off-topic] segunda tentativa de migração manicomio-share para FreeBSD [RESOLVIDO]
Em 24/01/13 08:24, Leonardo Augusto escreveu: Fala Marcelo, Como ficou a situacao depois de por PERSISTENT CONNECTIONS OFF ? É recomendado não usar conexoes persistentes entre o php e o mysql, como conversamos ja. E o xcache ? Ta rodando ? Parou de dar o load maluco agora ? Opa Leonardo :) Agora vai ficar para uma 3ª tentativa hahahahah mas fazendo essas e outras mudanças no próprio Debian, já melhorou muita coisa. Tinha uma query lá louca que foi acertada também. Atualmente está rodando com memcache e xcache. Show de bola! Também precisei aumentar o número de conexões do apache que estava em 1800 e estava estourando no horário de pico. Depois que corrigi isso, no pico chegou à 3200 conexões. Mas blz. Vou tentar programar outra manutenção dessa mais pro meio do ano e tentar novamente. :D Valeu pela ajuda meu amigo e vamos ver na próxima. 2013/1/13 Marcelo Gondim gon...@bsdinfo.com.br: Em 13/01/13 22:59, Antônio Pessoa escreveu: 2013/1/13 Marcelo Gondim gon...@bsdinfo.com.br Pessoal, Acho que descobri algo que pode estar causando todo o problema. Após colocar o KVM-IP e agora também tenho percebido melhor nos logs o seguinte: MCA: Bank 8, Status 0xcc194901009f MCA: Global Cap 0x1c09, Status 0x MCA: Vendor GenuineIntel, ID 0x206c2, APIC ID 0 MCA: CPU 0 COR (25892) OVER RD channel ?? memory error MCA: Address 0x5480c7b40 MCA: Misc 0x4670220100010386 Essa mensagem vira e mexe dá e quando o mysql dispara na cpu elas aparecem. Pelo que estou percebendo isso pode ser problema com algum banco de memória do servidor. Estou correto? Até os filhos do apache estão sendo assassinados com essas mensagens: [Wed Jan 09 23:49:40 2013] [notice] child pid 54806 exit signal Illegal instruction (4) [Wed Jan 09 23:49:40 2013] [notice] child pid 54308 exit signal Illegal instruction (4) [Wed Jan 09 23:49:40 2013] [notice] child pid 53252 exit signal Illegal instruction (4) [Wed Jan 09 23:49:40 2013] [notice] child pid 53120 exit signal Illegal instruction (4) E tipo já corrompeu uma base mysql uma vez e uma partição me obrigando à entrar em fsck manual. Também aconteceu de no meio do boot rebootar e umas duas vezes travar na ACPI e ficar quase 1 hora pra sair. Pedi para checarem a memória do servidor. Vamos ver, depois dessa ainda existe luz no fim do túnel. rsrsrsrs Você tem condições de executar o memtest completo nesse servidor? Seria interessante, mesmo com o resultado do suporte do data center. Ummm vou tentar. O problema também é que o suporte do datacenter não é tão bom, eles demoram muito e eles estão 7 horas na nossa frente. Ainda bem que não é comum ter essas paradas, só fiz dessa vez para tentar migrar para o FreeBSD e acho que acabei descobrindo um problema no Hardware. Também fiz umas mexidas de tunning. Abaixo como estão: sysctl.conf: = kern.ipc.somaxconn=4096 kern.ipc.shmall=262144 net.inet.ip.redirect=0 net.inet.ip.sourceroute=0 net.inet.ip.accept_sourceroute=0 net.inet.icmp.maskrepl=0 net.inet.icmp.log_redirect=0 net.inet.icmp.drop_redirect=1 net.inet.tcp.drop_synfin=1 net.inet.udp.blackhole=1 net.inet.tcp.blackhole=2 net.inet6.icmp6.nodeinfo=0 net.inet6.ip6.use_tempaddr=1 net.inet6.ip6.prefer_tempaddr=1 net.inet6.icmp6.rediraccept=0 net.inet.ip.fw.dyn_max=65536 net.inet.icmp.icmplim=500 loader.conf: == loader_logo=beastie kern.maxusers=1024 kern.ipc.nmbclusters=32768 kern.ipc.semmnu=256 kern.ipc.semmns=1024 kern.ipc.semmni=520 kern.ipc.semume=100 kern.ipc.shmmni=256 kern.ipc.msgseg=32767 kern.ipc.msgssz=32 kern.ipc.msgmnb=65535 kern.ipc.msgtql=2046 netstat -m: = 8659/13361/22020 mbufs in use (current/cache/total) 8551/4127/12678/32768 mbuf clusters in use (current/cache/total/max) 8551/4121 mbuf+clusters out of packet secondary zone in use (current/cache) 89/905/994/16384 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/8192 9k jumbo clusters in use (current/cache/total/max) 0/0/0/4096 16k jumbo clusters in use (current/cache/total/max) 19622K/15214K/34837K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 681 requests for I/O initiated by sendfile 0 calls to protocol drain routines ipcs -a: == Message Queues: T ID KEY MODEOWNERGROUPCREATOR CGROUP CBYTES QNUM QBYTES LSPIDLRPID STIMERTIMECTIME Shared Memory: T ID KEY MODEOWNERGROUPCREATOR CGROUP NATTCHSEGSZ CPID LPID ATIME DTIMECTIME Semaphores: T ID KEY MODEOWNERGROUPCREATOR CGROUP NSEMS OTIMECTIME gstat: = dT: 1.002s w: 1.000s
Re: [FUG-BR] [off-topic] segunda tentativa de migração manicomio-share para FreeBSD [RESOLVIDO]
2013/1/24 Marcelo Gondim gon...@bsdinfo.com.br ouca que foi acertada também. Atualmente está rodando com memcache e xcache. Show de bola! Também precisei aumentar o número de conexões do apache que estava em 1800 e estava estourando no horário de pico. Depois que corrigi isso, no pico chegou à 3200 conexões. Mas blz. Vou tentar programar outra manutenção dessa mais pro meio do ano e tentar novamente. :D Valeu pela ajuda meu amigo e vamos ver na Não sei se tem muita diferença, ainda não parei para olhar as mudanças, tenta fazer um teste com o MariaDB. Aproveitando, alguém da lista já migrou para o MariaDB, tem alguma melhoria? ou só ficou a questão do licenciamento? [ ]'s Indio -- Claudio P Costa - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [off-topic] segunda tentativa de migração manicomio-share para FreeBSD [RESOLVIDO]
2013/1/13 Marcelo Gondim gon...@bsdinfo.com.br Pessoal, Acho que descobri algo que pode estar causando todo o problema. Após colocar o KVM-IP e agora também tenho percebido melhor nos logs o seguinte: MCA: Bank 8, Status 0xcc194901009f MCA: Global Cap 0x1c09, Status 0x MCA: Vendor GenuineIntel, ID 0x206c2, APIC ID 0 MCA: CPU 0 COR (25892) OVER RD channel ?? memory error MCA: Address 0x5480c7b40 MCA: Misc 0x4670220100010386 Essa mensagem vira e mexe dá e quando o mysql dispara na cpu elas aparecem. Pelo que estou percebendo isso pode ser problema com algum banco de memória do servidor. Estou correto? Até os filhos do apache estão sendo assassinados com essas mensagens: [Wed Jan 09 23:49:40 2013] [notice] child pid 54806 exit signal Illegal instruction (4) [Wed Jan 09 23:49:40 2013] [notice] child pid 54308 exit signal Illegal instruction (4) [Wed Jan 09 23:49:40 2013] [notice] child pid 53252 exit signal Illegal instruction (4) [Wed Jan 09 23:49:40 2013] [notice] child pid 53120 exit signal Illegal instruction (4) E tipo já corrompeu uma base mysql uma vez e uma partição me obrigando à entrar em fsck manual. Também aconteceu de no meio do boot rebootar e umas duas vezes travar na ACPI e ficar quase 1 hora pra sair. Pedi para checarem a memória do servidor. Vamos ver, depois dessa ainda existe luz no fim do túnel. rsrsrsrs Você tem condições de executar o memtest completo nesse servidor? Seria interessante, mesmo com o resultado do suporte do data center. -- Atenciosamente, Antônio Pessoa - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [off-topic] segunda tentativa de migração manicomio-share para FreeBSD [RESOLVIDO]
Em 13/01/13 22:59, Antônio Pessoa escreveu: 2013/1/13 Marcelo Gondim gon...@bsdinfo.com.br Pessoal, Acho que descobri algo que pode estar causando todo o problema. Após colocar o KVM-IP e agora também tenho percebido melhor nos logs o seguinte: MCA: Bank 8, Status 0xcc194901009f MCA: Global Cap 0x1c09, Status 0x MCA: Vendor GenuineIntel, ID 0x206c2, APIC ID 0 MCA: CPU 0 COR (25892) OVER RD channel ?? memory error MCA: Address 0x5480c7b40 MCA: Misc 0x4670220100010386 Essa mensagem vira e mexe dá e quando o mysql dispara na cpu elas aparecem. Pelo que estou percebendo isso pode ser problema com algum banco de memória do servidor. Estou correto? Até os filhos do apache estão sendo assassinados com essas mensagens: [Wed Jan 09 23:49:40 2013] [notice] child pid 54806 exit signal Illegal instruction (4) [Wed Jan 09 23:49:40 2013] [notice] child pid 54308 exit signal Illegal instruction (4) [Wed Jan 09 23:49:40 2013] [notice] child pid 53252 exit signal Illegal instruction (4) [Wed Jan 09 23:49:40 2013] [notice] child pid 53120 exit signal Illegal instruction (4) E tipo já corrompeu uma base mysql uma vez e uma partição me obrigando à entrar em fsck manual. Também aconteceu de no meio do boot rebootar e umas duas vezes travar na ACPI e ficar quase 1 hora pra sair. Pedi para checarem a memória do servidor. Vamos ver, depois dessa ainda existe luz no fim do túnel. rsrsrsrs Você tem condições de executar o memtest completo nesse servidor? Seria interessante, mesmo com o resultado do suporte do data center. Ummm vou tentar. O problema também é que o suporte do datacenter não é tão bom, eles demoram muito e eles estão 7 horas na nossa frente. Ainda bem que não é comum ter essas paradas, só fiz dessa vez para tentar migrar para o FreeBSD e acho que acabei descobrindo um problema no Hardware. Também fiz umas mexidas de tunning. Abaixo como estão: sysctl.conf: = kern.ipc.somaxconn=4096 kern.ipc.shmall=262144 net.inet.ip.redirect=0 net.inet.ip.sourceroute=0 net.inet.ip.accept_sourceroute=0 net.inet.icmp.maskrepl=0 net.inet.icmp.log_redirect=0 net.inet.icmp.drop_redirect=1 net.inet.tcp.drop_synfin=1 net.inet.udp.blackhole=1 net.inet.tcp.blackhole=2 net.inet6.icmp6.nodeinfo=0 net.inet6.ip6.use_tempaddr=1 net.inet6.ip6.prefer_tempaddr=1 net.inet6.icmp6.rediraccept=0 net.inet.ip.fw.dyn_max=65536 net.inet.icmp.icmplim=500 loader.conf: == loader_logo=beastie kern.maxusers=1024 kern.ipc.nmbclusters=32768 kern.ipc.semmnu=256 kern.ipc.semmns=1024 kern.ipc.semmni=520 kern.ipc.semume=100 kern.ipc.shmmni=256 kern.ipc.msgseg=32767 kern.ipc.msgssz=32 kern.ipc.msgmnb=65535 kern.ipc.msgtql=2046 netstat -m: = 8659/13361/22020 mbufs in use (current/cache/total) 8551/4127/12678/32768 mbuf clusters in use (current/cache/total/max) 8551/4121 mbuf+clusters out of packet secondary zone in use (current/cache) 89/905/994/16384 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/8192 9k jumbo clusters in use (current/cache/total/max) 0/0/0/4096 16k jumbo clusters in use (current/cache/total/max) 19622K/15214K/34837K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 681 requests for I/O initiated by sendfile 0 calls to protocol drain routines ipcs -a: == Message Queues: T ID KEY MODEOWNERGROUPCREATOR CGROUP CBYTES QNUM QBYTES LSPIDLRPID STIMERTIMECTIME Shared Memory: T ID KEY MODEOWNERGROUPCREATOR CGROUP NATTCHSEGSZ CPID LPID ATIME DTIMECTIME Semaphores: T ID KEY MODEOWNERGROUPCREATOR CGROUP NSEMS OTIMECTIME gstat: = dT: 1.002s w: 1.000s L(q) ops/sr/s kBps ms/rw/s kBps ms/w %busy Name 0 2 0 00.0 2 640.40.1| mfid0 0 0 0 00.0 0 00.00.0| mfid0p1 0 0 0 00.0 0 00.00.0| mfid0p2 0 0 0 00.0 0 00.00.0| mfid0p3 0 0 0 00.0 0 00.00.0| mfid0p4 0 2 0 00.0 2 640.40.1| mfid0p5 0 0 0 00.0 0 00.00.0| mfid0p6 0 0 0 00.0 0 00.00.0| mfid0p7 0 0 0 00.0 0 00.00.0| mfid0p8 0 0 0 00.0 0 00.00.0| gptid/f315c6e7-5a5d-11e2-97d0-001e67036860 0 0 0 00.0 0 00.00.0| label/rootfs 0 0 0 00.0 0 00.00.0| label/swap
Re: [FUG-BR] [off-topic] segunda tentativa de migração manicomio-share para FreeBSD [RESOLVIDO]
Em 11/01/13 16:52, Marcelo Gondim escreveu: Em 11/01/13 15:53, NoRm4nD escreveu: Em 01/10/2013 10:46 PM, Marcelo Gondim escreveu: Em 10/01/13 22:31, Antônio Pessoa escreveu: 2013/1/10 Marcelo Gondimgon...@bsdinfo.com.br: Opa Wendell, Quanto ao sistema falei cedo demais. Hoje pela manhã deu problema com o MySQL. Começou à consumir 300% e vi chegar até 1200%, depois disso não vi nem mais a shell do servidor. HahAhahAH só rindo pra não chorar. Agora estou no aguardo do KVM-IP que retiraram e vou precisar. O curioso é como num Debian genérico a coisa flui tranquila o máximo que via nele era o MySQL chegar à 57% e o load em 1.5. No Freeba procurei usar as mesmas configurações de apache, php e mysql mas a coisa não flui da mesma forma, dá algum pau. O load salta de 2.4 pra 800, o MySQL pula de 30% pra 300, 400, 600 e até 1200% Nos logs não aparece nada que possa me dar uma direção. Olhei nos logs do apache, do mysql, do sistema. Usei o mytop, tuning-primer e nada. O site é o mesmo em php com memcache que estava rodando no Debian. Agora sei porque dizem que alegria de cego dura pouco. :( Agora porque em um sistema o mysql fica estável e no freeba acontece essa alteração grande de uso de processamento? FreeBSD 9.1-STABLE MySQL 5.1 compilado com BUILD_OPTIMIZED=yes PHP53 com o memcache Provavelmente o erro está em algum tunning que está faltando, algo que está causando isso. Porque não acredito e não quero acreditar que o FreeBSD não rodaria redondo ou melhor do que no Debian. []'s Gondim - Ainda bato na tecla da solução que você deu na thread anterior, que foi o downgrade para o 8.3, pelo que me lembro foi o mesmo problema com o MySQL. Opa Antonio, Aqueles eu resolvi. O MySQL até estourava a ram por causa de um parâmetro errado no my.cnf. O problema do load alto pelo que to vendo é o seguinte: MySQL começa subir o processamento, nesse momento o Apache tá fazendo mais acessos ao MySQL mas como o processamento tá alto deve começar a dizer pro Apache: Ou cara segura aí rapidinho que já me libero. Só que os processos do Apache não gostam de esperar e aí pronto vai o load pro saco. Enquanto o MySQL tá em 34%, 50% fica show o load e tudo funciona rápido. Mas quando o MySQL sobe pra 300, 400, 600, 800% a coisa fica feia. :) - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd As conexões no scripts PHP estão percistentes ou não percistentes ? ( no PHP5.3 o zabbix funfa de boa, mais na 5.4 não vai muito bem com conexões percistentes, embora eu esteja usando PostgreSQL esse comportamento no 5.4 esta tornando meu dia curto e minhas noites longas ). Como estão os semaphores e Sys V parametros ( problema chato semana passada com o PostgreSQL e os parametros do Sys V )? Teria como colocar o arquivo do kernel para podermos saber como está configurado o sistema ? Att. Opa, Então, estou usando as mesmas versões que estavam anteriormente no Debian. Tanto Apache 2.2, PHP 5.3 quanto MySQL 5.1. As páginas são as mesmas, logo deveria ter o mesmo comportamento nos dois SOs. Se rodava bem no Debian genérico sem tunning algum, teria que rodar pelo menos igual no FreeBSD ou melhor. O que pode estar acontecendo é exatamente alguma configuração no sistema. No Apache eu já descobri uma diferença para o Linux tanto que acertei o primeiro pepino. No MySQL pode estar necessitando de alguma mudança também. Até mesmo algum tunning no FreeBSD. Assim que eu conseguir ter acesso remoto ao servidor vou tentar algumas mudanças no MySQL conforme vi no link indicado aqui na lista [1]. [1] mysql.rjweb.org/doc.php/memory#64_bit_os_and_mysql E aproveito e pego as outras informações e posto aqui. []'s Gondim Pessoal, Acho que descobri algo que pode estar causando todo o problema. Após colocar o KVM-IP e agora também tenho percebido melhor nos logs o seguinte: MCA: Bank 8, Status 0xcc194901009f MCA: Global Cap 0x1c09, Status 0x MCA: Vendor GenuineIntel, ID 0x206c2, APIC ID 0 MCA: CPU 0 COR (25892) OVER RD channel ?? memory error MCA: Address 0x5480c7b40 MCA: Misc 0x4670220100010386 Essa mensagem vira e mexe dá e quando o mysql dispara na cpu elas aparecem. Pelo que estou percebendo isso pode ser problema com algum banco de memória do servidor. Estou correto? Até os filhos do apache estão sendo assassinados com essas mensagens: [Wed Jan 09 23:49:40 2013] [notice] child pid 54806 exit signal Illegal instruction (4) [Wed Jan 09 23:49:40 2013] [notice] child pid 54308 exit signal Illegal instruction (4) [Wed Jan 09 23:49:40 2013] [notice] child pid 53252 exit signal Illegal instruction (4) [Wed Jan 09 23:49:40 2013] [notice] child pid 53120 exit signal Illegal instruction (4) E tipo já corrompeu uma base mysql uma vez e uma partição me obrigando à entrar em fsck manual. Também aconteceu de no meio do boot
Re: [FUG-BR] [off-topic] segunda tentativa de migração manicomio-share para FreeBSD [RESOLVIDO]
Em 01/10/2013 10:46 PM, Marcelo Gondim escreveu: Em 10/01/13 22:31, Antônio Pessoa escreveu: 2013/1/10 Marcelo Gondimgon...@bsdinfo.com.br: Opa Wendell, Quanto ao sistema falei cedo demais. Hoje pela manhã deu problema com o MySQL. Começou à consumir 300% e vi chegar até 1200%, depois disso não vi nem mais a shell do servidor. HahAhahAH só rindo pra não chorar. Agora estou no aguardo do KVM-IP que retiraram e vou precisar. O curioso é como num Debian genérico a coisa flui tranquila o máximo que via nele era o MySQL chegar à 57% e o load em 1.5. No Freeba procurei usar as mesmas configurações de apache, php e mysql mas a coisa não flui da mesma forma, dá algum pau. O load salta de 2.4 pra 800, o MySQL pula de 30% pra 300, 400, 600 e até 1200% Nos logs não aparece nada que possa me dar uma direção. Olhei nos logs do apache, do mysql, do sistema. Usei o mytop, tuning-primer e nada. O site é o mesmo em php com memcache que estava rodando no Debian. Agora sei porque dizem que alegria de cego dura pouco. :( Agora porque em um sistema o mysql fica estável e no freeba acontece essa alteração grande de uso de processamento? FreeBSD 9.1-STABLE MySQL 5.1 compilado com BUILD_OPTIMIZED=yes PHP53 com o memcache Provavelmente o erro está em algum tunning que está faltando, algo que está causando isso. Porque não acredito e não quero acreditar que o FreeBSD não rodaria redondo ou melhor do que no Debian. []'s Gondim - Ainda bato na tecla da solução que você deu na thread anterior, que foi o downgrade para o 8.3, pelo que me lembro foi o mesmo problema com o MySQL. Opa Antonio, Aqueles eu resolvi. O MySQL até estourava a ram por causa de um parâmetro errado no my.cnf. O problema do load alto pelo que to vendo é o seguinte: MySQL começa subir o processamento, nesse momento o Apache tá fazendo mais acessos ao MySQL mas como o processamento tá alto deve começar a dizer pro Apache: Ou cara segura aí rapidinho que já me libero. Só que os processos do Apache não gostam de esperar e aí pronto vai o load pro saco. Enquanto o MySQL tá em 34%, 50% fica show o load e tudo funciona rápido. Mas quando o MySQL sobe pra 300, 400, 600, 800% a coisa fica feia. :) - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd As conexões no scripts PHP estão percistentes ou não percistentes ? ( no PHP5.3 o zabbix funfa de boa, mais na 5.4 não vai muito bem com conexões percistentes, embora eu esteja usando PostgreSQL esse comportamento no 5.4 esta tornando meu dia curto e minhas noites longas ). Como estão os semaphores e Sys V parametros ( problema chato semana passada com o PostgreSQL e os parametros do Sys V )? Teria como colocar o arquivo do kernel para podermos saber como está configurado o sistema ? Att. -- by NoRm4nD UnixBSD. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [off-topic] segunda tentativa de migração manicomio-share para FreeBSD [RESOLVIDO]
Em 11/01/13 15:53, NoRm4nD escreveu: Em 01/10/2013 10:46 PM, Marcelo Gondim escreveu: Em 10/01/13 22:31, Antônio Pessoa escreveu: 2013/1/10 Marcelo Gondimgon...@bsdinfo.com.br: Opa Wendell, Quanto ao sistema falei cedo demais. Hoje pela manhã deu problema com o MySQL. Começou à consumir 300% e vi chegar até 1200%, depois disso não vi nem mais a shell do servidor. HahAhahAH só rindo pra não chorar. Agora estou no aguardo do KVM-IP que retiraram e vou precisar. O curioso é como num Debian genérico a coisa flui tranquila o máximo que via nele era o MySQL chegar à 57% e o load em 1.5. No Freeba procurei usar as mesmas configurações de apache, php e mysql mas a coisa não flui da mesma forma, dá algum pau. O load salta de 2.4 pra 800, o MySQL pula de 30% pra 300, 400, 600 e até 1200% Nos logs não aparece nada que possa me dar uma direção. Olhei nos logs do apache, do mysql, do sistema. Usei o mytop, tuning-primer e nada. O site é o mesmo em php com memcache que estava rodando no Debian. Agora sei porque dizem que alegria de cego dura pouco. :( Agora porque em um sistema o mysql fica estável e no freeba acontece essa alteração grande de uso de processamento? FreeBSD 9.1-STABLE MySQL 5.1 compilado com BUILD_OPTIMIZED=yes PHP53 com o memcache Provavelmente o erro está em algum tunning que está faltando, algo que está causando isso. Porque não acredito e não quero acreditar que o FreeBSD não rodaria redondo ou melhor do que no Debian. []'s Gondim - Ainda bato na tecla da solução que você deu na thread anterior, que foi o downgrade para o 8.3, pelo que me lembro foi o mesmo problema com o MySQL. Opa Antonio, Aqueles eu resolvi. O MySQL até estourava a ram por causa de um parâmetro errado no my.cnf. O problema do load alto pelo que to vendo é o seguinte: MySQL começa subir o processamento, nesse momento o Apache tá fazendo mais acessos ao MySQL mas como o processamento tá alto deve começar a dizer pro Apache: Ou cara segura aí rapidinho que já me libero. Só que os processos do Apache não gostam de esperar e aí pronto vai o load pro saco. Enquanto o MySQL tá em 34%, 50% fica show o load e tudo funciona rápido. Mas quando o MySQL sobe pra 300, 400, 600, 800% a coisa fica feia. :) - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd As conexões no scripts PHP estão percistentes ou não percistentes ? ( no PHP5.3 o zabbix funfa de boa, mais na 5.4 não vai muito bem com conexões percistentes, embora eu esteja usando PostgreSQL esse comportamento no 5.4 esta tornando meu dia curto e minhas noites longas ). Como estão os semaphores e Sys V parametros ( problema chato semana passada com o PostgreSQL e os parametros do Sys V )? Teria como colocar o arquivo do kernel para podermos saber como está configurado o sistema ? Att. Opa, Então, estou usando as mesmas versões que estavam anteriormente no Debian. Tanto Apache 2.2, PHP 5.3 quanto MySQL 5.1. As páginas são as mesmas, logo deveria ter o mesmo comportamento nos dois SOs. Se rodava bem no Debian genérico sem tunning algum, teria que rodar pelo menos igual no FreeBSD ou melhor. O que pode estar acontecendo é exatamente alguma configuração no sistema. No Apache eu já descobri uma diferença para o Linux tanto que acertei o primeiro pepino. No MySQL pode estar necessitando de alguma mudança também. Até mesmo algum tunning no FreeBSD. Assim que eu conseguir ter acesso remoto ao servidor vou tentar algumas mudanças no MySQL conforme vi no link indicado aqui na lista [1]. [1] mysql.rjweb.org/doc.php/memory#64_bit_os_and_mysql E aproveito e pego as outras informações e posto aqui. []'s Gondim - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [off-topic] segunda tentativa de migração manicomio-share para FreeBSD
Cara, porque não troca o apache pelo nginx? É facinho! 2013/1/10 Marcelo Gondim gon...@bsdinfo.com.br Em 10/01/13 01:33, Antônio Pessoa escreveu: 2013/1/10 Marcelo Gondim gon...@bsdinfo.com.br: No /var/log/messages fica batendo direto: Jan 10 00:58:17 ms kernel: Limiting open port RST response from 265 to 200 packets/sec Jan 10 00:58:18 ms kernel: Limiting open port RST response from 235 to 200 packets/sec Jan 10 00:58:19 ms kernel: Limiting open port RST response from 336 to 200 packets/sec Jan 10 00:58:20 ms kernel: Limiting open port RST response from 322 to 200 packets/sec Jan 10 00:58:21 ms kernel: Limiting open port RST response from 243 to 200 packets/sec Jan 10 00:58:22 ms kernel: Limiting open port RST response from 309 to 200 packets/sec Jan 10 00:58:23 ms kernel: Limiting open port RST response from 227 to 200 packets/sec Jan 10 00:58:24 ms kernel: Limiting open port RST response from 280 to 200 packets/sec Jan 10 00:58:25 ms kernel: Limiting open port RST response from 246 to 200 packets/sec Jan 10 00:58:26 ms kernel: Limiting open port RST response from 341 to 200 packets/sec To usando no sysctl.conf: net.inet.udp.blackhole=1 net.inet.tcp.blackhole=2 - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Lembro que na thread anterior você tinha conseguido resolver o problema do load do MySQL com um downgrade para o 8.3. Qual a versão que você está usando desta vez? Antônio, Acho que descobri. uhuhuhuh nossa essa foi flórida! O problema pra resolver o lockf foi fazer o apache escutar somente em 1 IP. Como o servidor tem 2 IPs e escutava na porta 80 dos 2 aí caía no lockf. Até agora está excelente! - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- Bruno Ribeiro da Silva Python/Django/Java Developer Homebrewer - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [off-topic] segunda tentativa de migração manicomio-share para FreeBSD [RESOLVIDO]
On 10/01/2013, at 02:27, Marcelo Gondim gon...@bsdinfo.com.br wrote: Em 10/01/13 02:07, Marcelo Gondim []'s e finalmente o manicômio está rodando em FreeBSD 9.1-STABLE :D Adeus Debian! http://www.manicomio-share.com https://www.facebook.com/groups/manicomioshareconvites/ https://www.facebook.com/ Parabéns Gondim... E parece que ficou mais rápido hein... - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [off-topic] segunda tentativa de migração manicomio-share para FreeBSD
Em 9 de janeiro de 2013 14:56, Claudio Pereira claudiopere...@gmail.comescreveu: 2013/1/9 Marcelo Gondim gon...@bsdinfo.com.br Vamos que vamos que não posso ficar sem os meus seriados e filmes não HaHaHaha - Gondim, aproveita quando terminar e cria a minha conta/convite! ;-) Também quero :( hehehe -neilson - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [off-topic] segunda tentativa de migração manicomio-share para FreeBSD [RESOLVIDO]
Em 10/01/13 07:37, Wendell Borges escreveu: On 10/01/2013, at 02:27, Marcelo Gondim gon...@bsdinfo.com.br wrote: Em 10/01/13 02:07, Marcelo Gondim []'s e finalmente o manicômio está rodando em FreeBSD 9.1-STABLE :D Adeus Debian! http://www.manicomio-share.com https://www.facebook.com/groups/manicomioshareconvites/ https://www.facebook.com/ Parabéns Gondim... E parece que ficou mais rápido hein... Opa Wendell, Quanto ao sistema falei cedo demais. Hoje pela manhã deu problema com o MySQL. Começou à consumir 300% e vi chegar até 1200%, depois disso não vi nem mais a shell do servidor. HahAhahAH só rindo pra não chorar. Agora estou no aguardo do KVM-IP que retiraram e vou precisar. O curioso é como num Debian genérico a coisa flui tranquila o máximo que via nele era o MySQL chegar à 57% e o load em 1.5. No Freeba procurei usar as mesmas configurações de apache, php e mysql mas a coisa não flui da mesma forma, dá algum pau. O load salta de 2.4 pra 800, o MySQL pula de 30% pra 300, 400, 600 e até 1200% Nos logs não aparece nada que possa me dar uma direção. Olhei nos logs do apache, do mysql, do sistema. Usei o mytop, tuning-primer e nada. O site é o mesmo em php com memcache que estava rodando no Debian. Agora sei porque dizem que alegria de cego dura pouco. :( Agora porque em um sistema o mysql fica estável e no freeba acontece essa alteração grande de uso de processamento? FreeBSD 9.1-STABLE MySQL 5.1 compilado com BUILD_OPTIMIZED=yes PHP53 com o memcache Provavelmente o erro está em algum tunning que está faltando, algo que está causando isso. Porque não acredito e não quero acreditar que o FreeBSD não rodaria redondo ou melhor do que no Debian. []'s Gondim - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [off-topic] segunda tentativa de migração manicomio-share para FreeBSD [RESOLVIDO]
Opa Wendell, Quanto ao sistema falei cedo demais. Hoje pela manhã deu problema com o MySQL. Começou à consumir 300% e vi chegar até 1200%, depois disso não vi nem mais a shell do servidor. HahAhahAH só rindo pra não chorar. Agora estou no aguardo do KVM-IP que retiraram e vou precisar. O curioso é como num Debian genérico a coisa flui tranquila o máximo que via nele era o MySQL chegar à 57% e o load em 1.5. No Freeba procurei usar as mesmas configurações de apache, php e mysql mas a coisa não flui da mesma forma, dá algum pau. O load salta de 2.4 pra 800, o MySQL pula de 30% pra 300, 400, 600 e até 1200% Nos logs não aparece nada que possa me dar uma direção. Olhei nos logs do apache, do mysql, do sistema. Usei o mytop, tuning-primer e nada. O site é o mesmo em php com memcache que estava rodando no Debian. Agora sei porque dizem que alegria de cego dura pouco. :( Agora porque em um sistema o mysql fica estável e no freeba acontece essa alteração grande de uso de processamento? FreeBSD 9.1-STABLE MySQL 5.1 compilado com BUILD_OPTIMIZED=yes PHP53 com o memcache Provavelmente o erro está em algum tunning que está faltando, algo que está causando isso. Porque não acredito e não quero acreditar que o FreeBSD não rodaria redondo ou melhor do que no Debian. []'s Gondim Gondim Tenta fazer a coisa sem muito tuning. Se no Debian não tinha, o FreeBSD inicialmente, tente não colocar também... Tenta montar um passo a passo do que você fez e coloca aqui pra gente tentar ajudar. O Ambiente FAMP é tão trivial que realmente não dá pra entender o que pode estar acontecendo... Dá uma olhada aqui nesse link do MySQL. Pode ser que pra você alguma luz brote. http://mysql.rjweb.org/doc.php/memory#64_bit_os_and_mysql -- .:: Lucas Dias .:: OS3 Soluções em TI .:: (82) 8813-1494 / 8111-2288 .:: Antes de imprimir, veja se realmente é necessário!!! - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [off-topic] segunda tentativa de migração manicomio-share para FreeBSD [RESOLVIDO]
2013/1/10 Marcelo Gondim gon...@bsdinfo.com.br: Opa Wendell, Quanto ao sistema falei cedo demais. Hoje pela manhã deu problema com o MySQL. Começou à consumir 300% e vi chegar até 1200%, depois disso não vi nem mais a shell do servidor. HahAhahAH só rindo pra não chorar. Agora estou no aguardo do KVM-IP que retiraram e vou precisar. O curioso é como num Debian genérico a coisa flui tranquila o máximo que via nele era o MySQL chegar à 57% e o load em 1.5. No Freeba procurei usar as mesmas configurações de apache, php e mysql mas a coisa não flui da mesma forma, dá algum pau. O load salta de 2.4 pra 800, o MySQL pula de 30% pra 300, 400, 600 e até 1200% Nos logs não aparece nada que possa me dar uma direção. Olhei nos logs do apache, do mysql, do sistema. Usei o mytop, tuning-primer e nada. O site é o mesmo em php com memcache que estava rodando no Debian. Agora sei porque dizem que alegria de cego dura pouco. :( Agora porque em um sistema o mysql fica estável e no freeba acontece essa alteração grande de uso de processamento? FreeBSD 9.1-STABLE MySQL 5.1 compilado com BUILD_OPTIMIZED=yes PHP53 com o memcache Provavelmente o erro está em algum tunning que está faltando, algo que está causando isso. Porque não acredito e não quero acreditar que o FreeBSD não rodaria redondo ou melhor do que no Debian. []'s Gondim - Ainda bato na tecla da solução que você deu na thread anterior, que foi o downgrade para o 8.3, pelo que me lembro foi o mesmo problema com o MySQL. -- Atenciosamente, Antônio Pessoa - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [off-topic] segunda tentativa de migração manicomio-share para FreeBSD [RESOLVIDO]
Em 10/01/13 22:18, Lucas Dias escreveu: Opa Wendell, Quanto ao sistema falei cedo demais. Hoje pela manhã deu problema com o MySQL. Começou à consumir 300% e vi chegar até 1200%, depois disso não vi nem mais a shell do servidor. HahAhahAH só rindo pra não chorar. Agora estou no aguardo do KVM-IP que retiraram e vou precisar. O curioso é como num Debian genérico a coisa flui tranquila o máximo que via nele era o MySQL chegar à 57% e o load em 1.5. No Freeba procurei usar as mesmas configurações de apache, php e mysql mas a coisa não flui da mesma forma, dá algum pau. O load salta de 2.4 pra 800, o MySQL pula de 30% pra 300, 400, 600 e até 1200% Nos logs não aparece nada que possa me dar uma direção. Olhei nos logs do apache, do mysql, do sistema. Usei o mytop, tuning-primer e nada. O site é o mesmo em php com memcache que estava rodando no Debian. Agora sei porque dizem que alegria de cego dura pouco. :( Agora porque em um sistema o mysql fica estável e no freeba acontece essa alteração grande de uso de processamento? FreeBSD 9.1-STABLE MySQL 5.1 compilado com BUILD_OPTIMIZED=yes PHP53 com o memcache Provavelmente o erro está em algum tunning que está faltando, algo que está causando isso. Porque não acredito e não quero acreditar que o FreeBSD não rodaria redondo ou melhor do que no Debian. []'s Gondim Gondim Tenta fazer a coisa sem muito tuning. Se no Debian não tinha, o FreeBSD inicialmente, tente não colocar também... Posso tentar. :) Tenta montar um passo a passo do que você fez e coloca aqui pra gente tentar ajudar. O Ambiente FAMP é tão trivial que realmente não dá pra entender o que pode estar acontecendo... Pois é, não consigo entender como: mesmo site, mesma versão de PHP e MySQL, mesmas configurações de php.ini, my.cnf e apache. Mesmo com tudo isso ainda sim dá essa zica. Uma delas eu descobri nas minhas pesquisas: o lance do lockf que só ocorre no FreeBSD e quando você tem mais de um IP definido e porta. Aí começa à dar lockf nos processos do apache e daqui à pouco ele não responde mais. Nesse caso resolvi colocando no conf: Listen IP_DO_SERVER:80 só em definir o IP já resolveu o problema do lockf. Isso já não acontece no Linux. Por que? Bem, deve ser pela diferença entre os sistemas mesmo. O mesmo deve acontecer com o MySQL mas esse ainda não descobri como resolver e pelo que to vendo só falta ele. Dá uma olhada aqui nesse link do MySQL. Pode ser que pra você alguma luz brote. http://mysql.rjweb.org/doc.php/memory#64_bit_os_and_mysql Vou olhar agora. :) Valeu! Quando Albertinho disse: Loucura é querer obter resultados diferentes fazendo sempre a mesma coisa. Eu percebi que não sou tão louco porque eu quero pelo menos obter os mesmos resultados e fazendo a mesma coisa que fazia antes. rsrsrsrsr - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [off-topic] segunda tentativa de migração manicomio-share para FreeBSD [RESOLVIDO]
Em 10/01/13 22:31, Antônio Pessoa escreveu: 2013/1/10 Marcelo Gondim gon...@bsdinfo.com.br: Opa Wendell, Quanto ao sistema falei cedo demais. Hoje pela manhã deu problema com o MySQL. Começou à consumir 300% e vi chegar até 1200%, depois disso não vi nem mais a shell do servidor. HahAhahAH só rindo pra não chorar. Agora estou no aguardo do KVM-IP que retiraram e vou precisar. O curioso é como num Debian genérico a coisa flui tranquila o máximo que via nele era o MySQL chegar à 57% e o load em 1.5. No Freeba procurei usar as mesmas configurações de apache, php e mysql mas a coisa não flui da mesma forma, dá algum pau. O load salta de 2.4 pra 800, o MySQL pula de 30% pra 300, 400, 600 e até 1200% Nos logs não aparece nada que possa me dar uma direção. Olhei nos logs do apache, do mysql, do sistema. Usei o mytop, tuning-primer e nada. O site é o mesmo em php com memcache que estava rodando no Debian. Agora sei porque dizem que alegria de cego dura pouco. :( Agora porque em um sistema o mysql fica estável e no freeba acontece essa alteração grande de uso de processamento? FreeBSD 9.1-STABLE MySQL 5.1 compilado com BUILD_OPTIMIZED=yes PHP53 com o memcache Provavelmente o erro está em algum tunning que está faltando, algo que está causando isso. Porque não acredito e não quero acreditar que o FreeBSD não rodaria redondo ou melhor do que no Debian. []'s Gondim - Ainda bato na tecla da solução que você deu na thread anterior, que foi o downgrade para o 8.3, pelo que me lembro foi o mesmo problema com o MySQL. Opa Antonio, Aqueles eu resolvi. O MySQL até estourava a ram por causa de um parâmetro errado no my.cnf. O problema do load alto pelo que to vendo é o seguinte: MySQL começa subir o processamento, nesse momento o Apache tá fazendo mais acessos ao MySQL mas como o processamento tá alto deve começar a dizer pro Apache: Ou cara segura aí rapidinho que já me libero. Só que os processos do Apache não gostam de esperar e aí pronto vai o load pro saco. Enquanto o MySQL tá em 34%, 50% fica show o load e tudo funciona rápido. Mas quando o MySQL sobe pra 300, 400, 600, 800% a coisa fica feia. :) - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] [off-topic] segunda tentativa de migração manicomio-share para FreeBSD
É isso aí pessoal, Para aqueles aqui que já são usuários do manicomio-share.com, torçam aí por mim que dessa vez não cometerei os mesmos erros. HaHaHaHaHa Já iniciei a instalação mas interrompi porque acabei descobrindo um banco de memória ferrado no servidor e o Datacenter tá vendo lá agora. []'s Gondim - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [off-topic] segunda tentativa de migração manicomio-share para FreeBSD
Em 9 de janeiro de 2013 13:37, Marcelo Gondim gon...@bsdinfo.com.br escreveu: É isso aí pessoal, Para aqueles aqui que já são usuários do manicomio-share.com, torçam aí uati diz ?? eu não conheço :) e não abriu aqui a url. -- Luiz Gustavo Costa (Powered by BSD) *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+ mundoUnix - Consultoria em Software Livre http://www.mundounix.com.br ICQ: 2890831 / MSN: cont...@mundounix.com.br Tel: 55 (21) 4063-7110 / 8194-1905 / (11) 4063-0407 Blog: http://www.luizgustavo.pro.br - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [off-topic] segunda tentativa de migração manicomio-share para FreeBSD
2013/1/9 Marcelo Gondim gon...@bsdinfo.com.br: É isso aí pessoal, Para aqueles aqui que já são usuários do manicomio-share.com, torçam aí por mim que dessa vez não cometerei os mesmos erros. HaHaHaHaHa Já iniciei a instalação mas interrompi porque acabei descobrindo um banco de memória ferrado no servidor e o Datacenter tá vendo lá agora. []'s Gondim - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Sim, resolva logo que estou sem acesso. Até sexta-feira quero o relatório de migração na minha mesa. :-P -- Atenciosamente, Antônio Pessoa - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [off-topic] segunda tentativa de migração manicomio-share para FreeBSD
Em 09/01/13 14:07, Luiz Gustavo S. Costa escreveu: Em 9 de janeiro de 2013 13:37, Marcelo Gondim gon...@bsdinfo.com.br escreveu: É isso aí pessoal, Para aqueles aqui que já são usuários do manicomio-share.com, torçam aí uati diz ?? eu não conheço :) e não abriu aqui a url. heheh nem vai abrir Guga, to instalando ainda o sistema e configurando. :D Tá lembrado não da primeira vez que tentei e criei uma thread grande aqui na FUG por causa do MySQL? :) []'s Gondim - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [off-topic] segunda tentativa de migração manicomio-share para FreeBSD
Em 09/01/13 14:13, Matheus L. Abreu escreveu: 2013/1/9 Luiz Gustavo S. Costa luizgust...@luizgustavo.pro.br Em 9 de janeiro de 2013 13:37, Marcelo Gondim gon...@bsdinfo.com.br escreveu: É isso aí pessoal, Para aqueles aqui que já são usuários do manicomio-share.com, torçam aí uati diz ?? eu não conheço :) e não abriu aqui a url. -- Luiz Gustavo Costa (Powered by BSD) *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+ mundoUnix - Consultoria em Software Livre http://www.mundounix.com.br ICQ: 2890831 / MSN: cont...@mundounix.com.br Tel: 55 (21) 4063-7110 / 8194-1905 / (11) 4063-0407 Blog: http://www.luizgustavo.pro.br - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Se precisar de um help ... além de usuário do manicomio tenho um pouco de experiência em otimizações no apache/ngnix/freebsd. Opa Matheus, Tranquilo e obrigado pela força. Qualquer coisa venho aqui com as novidades. Espero concluir tudo ainda hoje. O que atrasou também foram os caras do Datacenter com o KVM-IP e a troca de uma das memórias do servidor que estava com problemas. Vamos que vamos que não posso ficar sem os meus seriados e filmes não HaHaHaha - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [off-topic] segunda tentativa de migração manicomio-share para FreeBSD
Em 09/01/13 14:30, Antônio Pessoa escreveu: 2013/1/9 Marcelo Gondim gon...@bsdinfo.com.br: É isso aí pessoal, Para aqueles aqui que já são usuários do manicomio-share.com, torçam aí por mim que dessa vez não cometerei os mesmos erros. HaHaHaHaHa Já iniciei a instalação mas interrompi porque acabei descobrindo um banco de memória ferrado no servidor e o Datacenter tá vendo lá agora. []'s Gondim - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Sim, resolva logo que estou sem acesso. Até sexta-feira quero o relatório de migração na minha mesa. :-P Positivo e operante rsrsrsrsrsr ainda tenho 2 dias. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [off-topic] segunda tentativa de migração manicomio-share para FreeBSD
2013/1/9 Marcelo Gondim gon...@bsdinfo.com.br Vamos que vamos que não posso ficar sem os meus seriados e filmes não HaHaHaha - Gondim, aproveita quando terminar e cria a minha conta/convite! ;-) [ ]'s IndioX -- Claudio P Costa - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [off-topic] segunda tentativa de migração manicomio-share para FreeBSD
Em 09/01/13 14:13, Matheus L. Abreu escreveu: 2013/1/9 Luiz Gustavo S. Costa luizgust...@luizgustavo.pro.br Em 9 de janeiro de 2013 13:37, Marcelo Gondim gon...@bsdinfo.com.br escreveu: É isso aí pessoal, Para aqueles aqui que já são usuários do manicomio-share.com, torçam aí uati diz ?? eu não conheço :) e não abriu aqui a url. -- Luiz Gustavo Costa (Powered by BSD) *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+ mundoUnix - Consultoria em Software Livre http://www.mundounix.com.br ICQ: 2890831 / MSN: cont...@mundounix.com.br Tel: 55 (21) 4063-7110 / 8194-1905 / (11) 4063-0407 Blog: http://www.luizgustavo.pro.br - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Se precisar de um help ... além de usuário do manicomio tenho um pouco de experiência em otimizações no apache/ngnix/freebsd. É povo. Muito estranho. Coloquei teoricamente as mesmas configurações de apache e mysql que estavam rodando com o outro sistema e o que acontece é o seguinte: Site entra normal e depois de alguns segundos babau, load vai lá em 400, mysql usando mais de 200% e aí o apache morre, morre de um jeito que os filhos ficam lá mas quando tenta acessar o site diz: A conexão para o servidor foi reiniciada durante o carregamento da página. E aí só re-iniciando o apache novamente. To aqui na luta tentando descobrir. 10143/13797/23940 mbufs in use (current/cache/total) 9919/2887/12806/262144 mbuf clusters in use (current/cache/total/max) 9919/2881 mbuf+clusters out of packet secondary zone in use (current/cache) 112/878/990/33280 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/16640 9k jumbo clusters in use (current/cache/total/max) 0/0/0/8320 16k jumbo clusters in use (current/cache/total/max) 22821K/12735K/35557K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 538 requests for I/O initiated by sendfile 0 calls to protocol drain routines # swapinfo Device 1K-blocks UsedAvail Capacity /dev/label/swap 167772120 16777212 0% e o i/o de disco tá baixo. To tentando descobrir o que tá fazendo o load saltar de 5 pra 200. Sinistro. Com certeza tem algum tunning faltando. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [off-topic] segunda tentativa de migração manicomio-share para FreeBSD
Em 10/01/13 00:36, Marcelo Gondim escreveu: Em 09/01/13 14:13, Matheus L. Abreu escreveu: 2013/1/9 Luiz Gustavo S. Costa luizgust...@luizgustavo.pro.br Em 9 de janeiro de 2013 13:37, Marcelo Gondim gon...@bsdinfo.com.br escreveu: É isso aí pessoal, Para aqueles aqui que já são usuários do manicomio-share.com, torçam aí uati diz ?? eu não conheço :) e não abriu aqui a url. -- Luiz Gustavo Costa (Powered by BSD) *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+ mundoUnix - Consultoria em Software Livre http://www.mundounix.com.br ICQ: 2890831 / MSN: cont...@mundounix.com.br Tel: 55 (21) 4063-7110 / 8194-1905 / (11) 4063-0407 Blog: http://www.luizgustavo.pro.br - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Se precisar de um help ... além de usuário do manicomio tenho um pouco de experiência em otimizações no apache/ngnix/freebsd. É povo. Muito estranho. Coloquei teoricamente as mesmas configurações de apache e mysql que estavam rodando com o outro sistema e o que acontece é o seguinte: Site entra normal e depois de alguns segundos babau, load vai lá em 400, mysql usando mais de 200% e aí o apache morre, morre de um jeito que os filhos ficam lá mas quando tenta acessar o site diz: A conexão para o servidor foi reiniciada durante o carregamento da página. E aí só re-iniciando o apache novamente. To aqui na luta tentando descobrir. 10143/13797/23940 mbufs in use (current/cache/total) 9919/2887/12806/262144 mbuf clusters in use (current/cache/total/max) 9919/2881 mbuf+clusters out of packet secondary zone in use (current/cache) 112/878/990/33280 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/16640 9k jumbo clusters in use (current/cache/total/max) 0/0/0/8320 16k jumbo clusters in use (current/cache/total/max) 22821K/12735K/35557K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 538 requests for I/O initiated by sendfile 0 calls to protocol drain routines # swapinfo Device 1K-blocks UsedAvail Capacity /dev/label/swap 167772120 16777212 0% e o i/o de disco tá baixo. To tentando descobrir o que tá fazendo o load saltar de 5 pra 200. Sinistro. Com certeza tem algum tunning faltando. No /var/log/messages fica batendo direto: Jan 10 00:58:17 ms kernel: Limiting open port RST response from 265 to 200 packets/sec Jan 10 00:58:18 ms kernel: Limiting open port RST response from 235 to 200 packets/sec Jan 10 00:58:19 ms kernel: Limiting open port RST response from 336 to 200 packets/sec Jan 10 00:58:20 ms kernel: Limiting open port RST response from 322 to 200 packets/sec Jan 10 00:58:21 ms kernel: Limiting open port RST response from 243 to 200 packets/sec Jan 10 00:58:22 ms kernel: Limiting open port RST response from 309 to 200 packets/sec Jan 10 00:58:23 ms kernel: Limiting open port RST response from 227 to 200 packets/sec Jan 10 00:58:24 ms kernel: Limiting open port RST response from 280 to 200 packets/sec Jan 10 00:58:25 ms kernel: Limiting open port RST response from 246 to 200 packets/sec Jan 10 00:58:26 ms kernel: Limiting open port RST response from 341 to 200 packets/sec To usando no sysctl.conf: net.inet.udp.blackhole=1 net.inet.tcp.blackhole=2 - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [off-topic] segunda tentativa de migração manicomio-share para FreeBSD
2013/1/10 Marcelo Gondim gon...@bsdinfo.com.br: No /var/log/messages fica batendo direto: Jan 10 00:58:17 ms kernel: Limiting open port RST response from 265 to 200 packets/sec Jan 10 00:58:18 ms kernel: Limiting open port RST response from 235 to 200 packets/sec Jan 10 00:58:19 ms kernel: Limiting open port RST response from 336 to 200 packets/sec Jan 10 00:58:20 ms kernel: Limiting open port RST response from 322 to 200 packets/sec Jan 10 00:58:21 ms kernel: Limiting open port RST response from 243 to 200 packets/sec Jan 10 00:58:22 ms kernel: Limiting open port RST response from 309 to 200 packets/sec Jan 10 00:58:23 ms kernel: Limiting open port RST response from 227 to 200 packets/sec Jan 10 00:58:24 ms kernel: Limiting open port RST response from 280 to 200 packets/sec Jan 10 00:58:25 ms kernel: Limiting open port RST response from 246 to 200 packets/sec Jan 10 00:58:26 ms kernel: Limiting open port RST response from 341 to 200 packets/sec To usando no sysctl.conf: net.inet.udp.blackhole=1 net.inet.tcp.blackhole=2 - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Lembro que na thread anterior você tinha conseguido resolver o problema do load do MySQL com um downgrade para o 8.3. Qual a versão que você está usando desta vez? -- Atenciosamente, Antônio Pessoa - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [off-topic] segunda tentativa de migração manicomio-share para FreeBSD
Em 10/01/13 01:33, Antônio Pessoa escreveu: 2013/1/10 Marcelo Gondim gon...@bsdinfo.com.br: No /var/log/messages fica batendo direto: Jan 10 00:58:17 ms kernel: Limiting open port RST response from 265 to 200 packets/sec Jan 10 00:58:18 ms kernel: Limiting open port RST response from 235 to 200 packets/sec Jan 10 00:58:19 ms kernel: Limiting open port RST response from 336 to 200 packets/sec Jan 10 00:58:20 ms kernel: Limiting open port RST response from 322 to 200 packets/sec Jan 10 00:58:21 ms kernel: Limiting open port RST response from 243 to 200 packets/sec Jan 10 00:58:22 ms kernel: Limiting open port RST response from 309 to 200 packets/sec Jan 10 00:58:23 ms kernel: Limiting open port RST response from 227 to 200 packets/sec Jan 10 00:58:24 ms kernel: Limiting open port RST response from 280 to 200 packets/sec Jan 10 00:58:25 ms kernel: Limiting open port RST response from 246 to 200 packets/sec Jan 10 00:58:26 ms kernel: Limiting open port RST response from 341 to 200 packets/sec To usando no sysctl.conf: net.inet.udp.blackhole=1 net.inet.tcp.blackhole=2 - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Lembro que na thread anterior você tinha conseguido resolver o problema do load do MySQL com um downgrade para o 8.3. Qual a versão que você está usando desta vez? Opa Antônio, O MySQL não está mais estourando a ram como tava daquela vez. Agora ficou dentro dos valores. Eu estou reparando o seguinte: no apache quando inicio o state dos processos ficam como select mas aí daqui a pouco começam à ficar com lockf e aí quando tudo ficou em lockf dá o problema. Estou usando o FreeBSD 9.1-STABLE com apache22 + php53 + mysql 5.1. Procurei usar nas confs a mesma parametrização que já estava funcionando no outro sistema. Li em uma página que esse lockf se daria no caso de escutar em mais de uma porta no apache mas eu só estou escutando na 80. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [off-topic] segunda tentativa de migração manicomio-share para FreeBSD
Em 10/01/13 01:33, Antônio Pessoa escreveu: 2013/1/10 Marcelo Gondim gon...@bsdinfo.com.br: No /var/log/messages fica batendo direto: Jan 10 00:58:17 ms kernel: Limiting open port RST response from 265 to 200 packets/sec Jan 10 00:58:18 ms kernel: Limiting open port RST response from 235 to 200 packets/sec Jan 10 00:58:19 ms kernel: Limiting open port RST response from 336 to 200 packets/sec Jan 10 00:58:20 ms kernel: Limiting open port RST response from 322 to 200 packets/sec Jan 10 00:58:21 ms kernel: Limiting open port RST response from 243 to 200 packets/sec Jan 10 00:58:22 ms kernel: Limiting open port RST response from 309 to 200 packets/sec Jan 10 00:58:23 ms kernel: Limiting open port RST response from 227 to 200 packets/sec Jan 10 00:58:24 ms kernel: Limiting open port RST response from 280 to 200 packets/sec Jan 10 00:58:25 ms kernel: Limiting open port RST response from 246 to 200 packets/sec Jan 10 00:58:26 ms kernel: Limiting open port RST response from 341 to 200 packets/sec To usando no sysctl.conf: net.inet.udp.blackhole=1 net.inet.tcp.blackhole=2 - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Lembro que na thread anterior você tinha conseguido resolver o problema do load do MySQL com um downgrade para o 8.3. Qual a versão que você está usando desta vez? Antônio, Acho que descobri. uhuhuhuh nossa essa foi flórida! O problema pra resolver o lockf foi fazer o apache escutar somente em 1 IP. Como o servidor tem 2 IPs e escutava na porta 80 dos 2 aí caía no lockf. Até agora está excelente! - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [off-topic] segunda tentativa de migração manicomio-share para FreeBSD [RESOLVIDO]
Em 10/01/13 02:07, Marcelo Gondim escreveu: Em 10/01/13 01:33, Antônio Pessoa escreveu: 2013/1/10 Marcelo Gondim gon...@bsdinfo.com.br: No /var/log/messages fica batendo direto: Jan 10 00:58:17 ms kernel: Limiting open port RST response from 265 to 200 packets/sec Jan 10 00:58:18 ms kernel: Limiting open port RST response from 235 to 200 packets/sec Jan 10 00:58:19 ms kernel: Limiting open port RST response from 336 to 200 packets/sec Jan 10 00:58:20 ms kernel: Limiting open port RST response from 322 to 200 packets/sec Jan 10 00:58:21 ms kernel: Limiting open port RST response from 243 to 200 packets/sec Jan 10 00:58:22 ms kernel: Limiting open port RST response from 309 to 200 packets/sec Jan 10 00:58:23 ms kernel: Limiting open port RST response from 227 to 200 packets/sec Jan 10 00:58:24 ms kernel: Limiting open port RST response from 280 to 200 packets/sec Jan 10 00:58:25 ms kernel: Limiting open port RST response from 246 to 200 packets/sec Jan 10 00:58:26 ms kernel: Limiting open port RST response from 341 to 200 packets/sec To usando no sysctl.conf: net.inet.udp.blackhole=1 net.inet.tcp.blackhole=2 - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Lembro que na thread anterior você tinha conseguido resolver o problema do load do MySQL com um downgrade para o 8.3. Qual a versão que você está usando desta vez? Antônio, Acho que descobri. uhuhuhuh nossa essa foi flórida! O problema pra resolver o lockf foi fazer o apache escutar somente em 1 IP. Como o servidor tem 2 IPs e escutava na porta 80 dos 2 aí caía no lockf. Até agora está excelente! - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Pessoal, Para quem tiver um problema parecido com o meu. A luz que recebi foi daqui [1]. [1] http://docs.freebsd.org/cgi/getmsg.cgi?fetch=77632+0+/usr/local/www/db/text/2001/freebsd-hackers/20010415.freebsd-hackers []'s e finalmente o manicômio está rodando em FreeBSD 9.1-STABLE :D Adeus Debian! http://www.manicomio-share.com https://www.facebook.com/groups/manicomioshareconvites/ https://www.facebook.com/groups/manicomioshare/ - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
