Re: [FUG-BR] [off-topic] segunda tentativa de migração manicomio-share para FreeBSD [RESOLVIDO]
2013/1/24 Marcelo Gondim > 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]
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 : >> Em 13/01/13 22:59, Antônio Pessoa escreveu: >>> 2013/1/13 Marcelo 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 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 MODEOWNERGROUPCR
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 : > Em 13/01/13 22:59, Antônio Pessoa escreveu: >> 2013/1/13 Marcelo 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 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.4
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 >> 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 0
Re: [FUG-BR] [off-topic] segunda tentativa de migração manicomio-share para FreeBSD [RESOLVIDO]
2013/1/13 Marcelo 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 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 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 Gondim: > 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
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 Gondim: 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 [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 Gondim: >>> 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 10/01/13 22:31, Antônio Pessoa escreveu: > 2013/1/10 Marcelo Gondim : >> 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
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]
2013/1/10 Marcelo Gondim : > 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]
> > 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]
Em 10/01/13 07:37, Wendell Borges escreveu: > On 10/01/2013, at 02:27, Marcelo Gondim 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]
On 10/01/2013, at 02:27, Marcelo Gondim 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 [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 : >>> 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
