Re: [FUG-BR] Servidor com load altíssimo
Marcelo, estou enviando algumas confs de um 7.2 onde o mysql funciona muito bem, nao fiz um teste de 4000 conexoes, mas na epoca fiz um text com o ab da apache, que chamava um php que conectava no mysql pegava uma string de 50k e enviava, foram na media 780 requests por segundo, sem keep alive. KERNEL (removi todos os drivers nao existentes na maquina) (detalhe, vc compilou o conf do amd64 certo ?) cpu HAMMER ident KERNEL64 options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET# InterNETworking options INET6 # IPv6 communications protocols options SCTP# Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL# Enable gjournal-based UFS journaling options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFSLOCKD# Network Lock Manager options NFS_ROOT# NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS# Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMPAT_43TTY# BSD 4.3 TTY compat [KEEP THIS!] options COMPAT_IA32 # Compatible with i386 binaries options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV# install a CDEV entry in /dev options ADAPTIVE_GIANT # Giant mutex is adaptive. options STOP_NMI# Stop CPUS using NMI instead of IPI options AUDIT # Security event auditing # Make an SMP-capable kernel by default options SMP # Symmetric MultiProcessor Kernel # CPU frequency control device cpufreq #- maxusers384 options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=10 options IPFIREWALL_FORWARD options IPFIREWALL_DEFAULT_TO_ACCEPT options DEVICE_POLLING options HZ=1000 (o resto sao drivers) SYSCTL.CONF machdep.hyperthreading_allowed=1 security.jail.set_hostname_allowed=0 security.jail.allow_raw_sockets=1 security.jail.socket_unixiproute_only=1 security.jail.sysvipc_allowed=0 security.jail.enforce_statfs=2 security.jail.allow_raw_sockets=1 security.jail.chflags_allowed=0 kern.maxfiles=65535 kern.maxfilesperproc=32768 kern.ipc.somaxconn=8192 kern.ipc.maxsockbuf=2097152 kern.ipc.maxsockets=81920 kern.ipc.shmmax=33554432 kern.ipc.shmall=32768 #kern.ipc.shm_use_phys=1 # kernel to lock shared memory into RAM # and prevent it from being paged out to swap kern.polling.enable=1 kern.polling.user_frac=50 vfs.vmiodirenable=1 vfs.ufs.dirhash_maxmem=67108864 kern.maxvnodes=50 net.inet.ip.check_interface=1 net.inet.udp.blackhole=1 net.inet.tcp.blackhole=2 # blackhole pings, traceroutes, etc. net.inet.icmp.icmplim=100 net.inet.ip.fw.dyn_max=4000 net.inet.tcp.sendspace=65535 net.inet.tcp.recvspace=32768 net.inet.udp.recvspace=65535 net.inet.udp.maxdgram=57344 net.local.stream.recvspace=65535 net.local.stream.sendspace=65535 LOADER.CONF - accf_http_load=YES #kern.ipc.nmbclusters=0 autoboot_delay=5 beastie_disable=NO
Re: [FUG-BR] Servidor com load altíssimo
Em 10/07/2012 10:22, Leonardo Augusto escreveu: Marcelo, estou enviando algumas confs de um 7.2 onde o mysql funciona muito bem, nao fiz um teste de 4000 conexoes, mas na epoca fiz um text com o ab da apache, que chamava um php que conectava no mysql pegava uma string de 50k e enviava, foram na media 780 requests por segundo, sem keep alive. KERNEL (removi todos os drivers nao existentes na maquina) (detalhe, vc compilou o conf do amd64 certo ?) Isso amd64 mesmo porque com 24Gb de ram só ele mesmo rsrsrsrs Quanto aos drivers não removi todos todos porque como a máquina estava em um datacenter e muito longe, fiquei com medo de tirar algo em excesso mas tirei bastante coisa principalmente drivers das interfaces de rede, onde só deixei a igb mesmo que eu tava usando. usb, paralela, wireless, firewire, som essas coisas arranquei tudo. :) Até o HZ eu tentei com 1000 e com 3000 :) Vou guardar aqui a conf pra gente testar na máquina de testes. Show! cpu HAMMER ident KERNEL64 options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET# InterNETworking options INET6 # IPv6 communications protocols options SCTP# Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL# Enable gjournal-based UFS journaling options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFSLOCKD# Network Lock Manager options NFS_ROOT# NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS# Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMPAT_43TTY# BSD 4.3 TTY compat [KEEP THIS!] options COMPAT_IA32 # Compatible with i386 binaries options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV# install a CDEV entry in /dev options ADAPTIVE_GIANT # Giant mutex is adaptive. options STOP_NMI# Stop CPUS using NMI instead of IPI options AUDIT # Security event auditing # Make an SMP-capable kernel by default options SMP # Symmetric MultiProcessor Kernel # CPU frequency control device cpufreq #- maxusers384 options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=10 options IPFIREWALL_FORWARD options IPFIREWALL_DEFAULT_TO_ACCEPT options DEVICE_POLLING options HZ=1000 (o resto sao drivers) SYSCTL.CONF machdep.hyperthreading_allowed=1 security.jail.set_hostname_allowed=0 security.jail.allow_raw_sockets=1 security.jail.socket_unixiproute_only=1 security.jail.sysvipc_allowed=0 security.jail.enforce_statfs=2 security.jail.allow_raw_sockets=1 security.jail.chflags_allowed=0 kern.maxfiles=65535 kern.maxfilesperproc=32768 kern.ipc.somaxconn=8192 kern.ipc.maxsockbuf=2097152 kern.ipc.maxsockets=81920 kern.ipc.shmmax=33554432 kern.ipc.shmall=32768 #kern.ipc.shm_use_phys=1 # kernel to lock shared memory into RAM # and prevent it from being paged out to swap
Re: [FUG-BR] Servidor com load altíssimo
2012/7/10 Leonardo Augusto lalin...@gmail.com options DEVICE_POLLING options HZ=1000 kern.polling.enable=1 kern.polling.user_frac=50 Habilitar polling em placas modernas com moderação de interrupção dá um resultado pior do que deixar desativado. Outra coisa importante de desativar é o FLOWTABLE. -- Eduardo Schoedler - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
2012/7/10 Marcelo Gondim gon...@bsdinfo.com.br Até o HZ eu tentei com 1000 e com 3000 :) Acho que não precisa de HZ tão alto, já que é um servidor... se fosse um router, iria bem. -- Eduardo Schoedler - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
Em 08/07/2012 11:36, Leonardo Augusto escreveu: Bom Marcelo, Pelos graficos que voce me mandou, por hora, sao mais de 3000 selects contra 700 inserts... entao nao sei se foi com ou sem o tal anounce rodando, mas tem bem mais select que insert. Tava sem announce rsrsrs o announce arregaça tudo ahahha O que ja vi tambem, é que esse sistema é um sistema opensource, ja baixei ele pra dar uma olhada, vi que no index tem um select sinistro la, que o memcache ajudaria muito. É ele vai tentar usar sim o memcache. Infelizmente tive que por o Debian lá dessa vez. Nossa está muito mas muito rápido sem fazer quase que nada. Mas mesmo assim ele quer implementar o memcache sim. Só vamos preparar tudo com calma agora. :D MAS CLARO, TEM UM POREM BEM BOM PRA UM DOMINGO DEMANHA, teu programador php ta relutante a usar o memcache, pq NAO FOI ele que desenvolveu esse sistema e por o memcache ali da um pouco de trabalho, pois tem que entender/alterar a classe de acesso ao mysql, se bem que vi que a maioria ta usando as funcoes @mysql nua a crua... o que é ridiculo, quando deveria ser uma classe responsavel por isso, para justamente nao ter que correr o sistema todo para alterar qualquer comportamento do mysql. O fato é esse, o magrao do php ta mais perdido que cusco no meio de procissao, kkk ehheeh mas agora ele quer implementar isso sim. Vou até depois te mandar uns e-mails pvt. Uma duvida que tenho que faz muita diferenca é a seguinte: - esse sistema é acessado(alguma url dele) pelos clientes de torrent ? por exemplo, se peguei um link dum torrent do teu site e to baixando o torrento no meu MICRO TORRENT NA MINHA MAQUINA, o microtorrent ele por si só acessa o site ? ou o proprio site que usa o anounce quando eu clico num link do mesmo ? resumindo: algum agente externo(cliente de torrent) atualiza algo no site, ou tudo acontece a partir dos clicks no site ? O problema são o número de conexões ao mysql que chega à 4000. Tipo vamos dizer que você tenha uns 30 torrents compartilhando. Cada vez que você pára um torrent, inicia, termina de baixar e fica de seeder, começa à baixar outro, o cliente torrent (ex. utorrent) vai no announce usando uma passkey tua, e faz a atualização na base de dados, update, insert, essas coisas pra atualizar as informações sobre o que você tá fazendo. É assim por exemplo que o seu ratio sobe ou desce, porque em sites de torrent fechados você não pode ter ratio baixo porque senão você é banido. :) Agora você coloca aí uns 400mil peers pessoas fazendo isso. rsrsrsr é muita conexão concorrente na base. Tudo com update, insert, etc :) Pelo que li lá nos caras do mysql. No linux eu consigo chegar até 4000 conexões tranquilo com uma certa quantidade de memória. Mas se eu coloco 4000 conexões no mysql do freebsd o sistema me pede mais de 70Gb de ram. Vi outros relatos sobre isso também na minha pesquisa, pessoas reclamando do mysql no freebsd quando a carga é alta. top - 10:01:12 up 7:51, 1 user, load average: 0.79, 0.75, 0.71 Tasks: 2067 total, 2 running, 2064 sleeping, 0 stopped, 1 zombie Cpu(s): 13.4%us, 2.6%sy, 0.0%ni, 83.3%id, 0.3%wa, 0.0%hi, 0.4%si, 0.0%st Mem: 24678000k total, 16547540k used, 8130460k free, 209944k buffers Swap: 7812492k total,0k used, 7812492k free, 6641460k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 15351 mysql 20 0 2190m 837m 7536 S 265 3.5 94:21.35 mysqld 14453 www-data 20 0 254m 14m 4060 S3 0.1 0:00.57 apache2 6383 root 20 0 20700 3024 1020 R2 0.0 0:02.32 top 18700 www-data 20 0 254m 15m 4064 S2 0.1 0:00.52 apache2 5383 www-data 20 0 254m 15m 3992 S2 0.1 0:00.78 apache2 14593 www-data 20 0 255m 15m 4072 S2 0.1 0:00.52 apache2 10539 www-data 20 0 254m 15m 4112 S1 0.1 0:02.37 apache2 27538 www-data 20 0 254m 15m 4076 S1 0.1 0:01.93 apache2 4866 www-data 20 0 254m 14m 3884 S1 0.1 0:00.18 apache2 5442 www-data 20 0 253m 13m 3916 S1 0.1 0:00.46 apache2 8461 www-data 20 0 254m 15m 4004 S1 0.1 0:01.36 apache2 8583 www-data 20 0 253m 13m 3888 S1 0.1 0:00.13 apache2 9040 www-data 20 0 254m 14m 4052 S1 0.1 0:00.45 apache2 10561 www-data 20 0 254m 14m 4008 S1 0.1 0:02.36 apache2 11519 www-data 20 0 254m 14m 3948 S1 0.1 0:00.53 apache2 15082 www-data 20 0 254m 14m 3948 S1 0.1 0:00.31 apache2 15574 www-data 20 0 254m 15m 3956 S1 0.1 0:00.29 apache2 28101 www-data 20 0 254m 14m 4032 S1 0.1 0:00.22 apache2 28382 www-data 20 0 254m 15m 4032 S1 0.1 0:00.26 apache2 28392 www-data 20 0 254m 14m 3828 S1 0.1 0:00.19 apache2 29783 www-data 20 0 252m 13m 3896 S1 0.1 0:00.13 apache2 31990 www-data 20 0 254m 15m 3940 S1 0.1 0:00.17 apache2 32356 www-data 20 0 254m 15m 4076 S1 0.1 0:02.13
Re: [FUG-BR] Servidor com load altíssimo
Em 9 de julho de 2012 10:42, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Em 08/07/2012 11:36, Leonardo Augusto escreveu: Bom Marcelo, Pelos graficos que voce me mandou, por hora, sao mais de 3000 selects contra 700 inserts... entao nao sei se foi com ou sem o tal anounce rodando, mas tem bem mais select que insert. Tava sem announce rsrsrs o announce arregaça tudo ahahha O que ja vi tambem, é que esse sistema é um sistema opensource, ja baixei ele pra dar uma olhada, vi que no index tem um select sinistro la, que o memcache ajudaria muito. É ele vai tentar usar sim o memcache. Infelizmente tive que por o Debian lá dessa vez. Nossa está muito mas muito rápido sem fazer quase que nada. Mas mesmo assim ele quer implementar o memcache sim. Só vamos preparar tudo com calma agora. :D MAS CLARO, TEM UM POREM BEM BOM PRA UM DOMINGO DEMANHA, teu programador php ta relutante a usar o memcache, pq NAO FOI ele que desenvolveu esse sistema e por o memcache ali da um pouco de trabalho, pois tem que entender/alterar a classe de acesso ao mysql, se bem que vi que a maioria ta usando as funcoes @mysql nua a crua... o que é ridiculo, quando deveria ser uma classe responsavel por isso, para justamente nao ter que correr o sistema todo para alterar qualquer comportamento do mysql. O fato é esse, o magrao do php ta mais perdido que cusco no meio de procissao, kkk ehheeh mas agora ele quer implementar isso sim. Vou até depois te mandar uns e-mails pvt. Uma duvida que tenho que faz muita diferenca é a seguinte: - esse sistema é acessado(alguma url dele) pelos clientes de torrent ? por exemplo, se peguei um link dum torrent do teu site e to baixando o torrento no meu MICRO TORRENT NA MINHA MAQUINA, o microtorrent ele por si só acessa o site ? ou o proprio site que usa o anounce quando eu clico num link do mesmo ? resumindo: algum agente externo(cliente de torrent) atualiza algo no site, ou tudo acontece a partir dos clicks no site ? O problema são o número de conexões ao mysql que chega à 4000. Tipo vamos dizer que você tenha uns 30 torrents compartilhando. Cada vez que você pára um torrent, inicia, termina de baixar e fica de seeder, começa à baixar outro, o cliente torrent (ex. utorrent) vai no announce usando uma passkey tua, e faz a atualização na base de dados, update, insert, essas coisas pra atualizar as informações sobre o que você tá fazendo. É assim por exemplo que o seu ratio sobe ou desce, porque em sites de torrent fechados você não pode ter ratio baixo porque senão você é banido. :) Agora você coloca aí uns 400mil peers pessoas fazendo isso. rsrsrsr é muita conexão concorrente na base. Tudo com update, insert, etc :) Pelo que li lá nos caras do mysql. No linux eu consigo chegar até 4000 conexões tranquilo com uma certa quantidade de memória. Mas se eu coloco 4000 conexões no mysql do freebsd o sistema me pede mais de 70Gb de ram. Vi outros relatos sobre isso também na minha pesquisa, pessoas reclamando do mysql no freebsd quando a carga é alta. Prezado Marcelo: Poderia nos colocar a par das suas fontes de pesquisa comprovando o problema do Mysql no FreeBSD? Acho que seria importante para documentarmos o fato bem como para podermos procurar uma solução. Lembro que há alguns anos atrás um cara do Yahoo documentou um problema semelhante e teve uns caras depois que colocaram para funcionar tão bem no FreeBSD como no Linux. Acho que foi usando a implementação do linuxthreads, se não me falha a memória. Depois a implementação de threads do FreeBSD mudou. Acho que na época do FreeBSD 7 uma pessoa do core team documentou que o MySQL funcionava até melhor no Free que no Linux. Além disso deve haver pessoas que tem concorrência brutal de MySQL no Free, também não me conformo de não ter dado certo ... :-( . Acho que podemos fazer o seguinte: 1 - Nos torne a par das suas fontes que relatam o problema de concorrência para ver se ajudamos; 2 - Como montaríamos um ambiente offline para simularmos o caso sem ter que fazer uma atividade tão corrida como foi essa sua agora? 3 - Acho que a documentação da época do Free 7 dizia os parâmetros de tuning. Talvez ajude mas, acho que o correto seria simular este seu ambiente ... Abraços e parabéns pelo esforço! -- Francisco Ricardo ___ Administrador de Redes e Sistemas Unix/Linux Profissional Certificado RedHat | Entusiasta FreeBSD Natal/RN | (84)9461-4801 | frica...@bsd.com.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] Servidor com load altíssimo
Umm bom, Já que o problema entao esta comprovadamente no mysql sobre o freebsd, fica mais direcionada nossa pesquisa. Olhe esse pdf sobre o freebsd 7 http://people.freebsd.org/~kris/scaling/7.0%20Preview.pdf Nao entendo com poderia ter piorado. Faz uma coisa, manda pra nós a o teu kernel.conf o teu sysctl,conf, teu loader.conf e o teu my.cnf E tambem o comando que tu usou no port (as opcoes do make install) para instalar o mysql. Nao me convenco que possa ficar tao ruim no freebsd, voce atualizou o ports e o sys depois que instalou o os ? antes de compilar o mysql ? Uma opcao, seria instalar o BIN do linux e rodar emulado no freebsd para ver, ja vi mysql rodando bin no freebsd ficar mais rapido que no proprio linux. Passa as configs aí pra galera analizar. abraco - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
Em 09/07/2012 12:52, Francisco Cardoso escreveu: Em 9 de julho de 2012 10:42, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Em 08/07/2012 11:36, Leonardo Augusto escreveu: Bom Marcelo, Pelos graficos que voce me mandou, por hora, sao mais de 3000 selects contra 700 inserts... entao nao sei se foi com ou sem o tal anounce rodando, mas tem bem mais select que insert. Tava sem announce rsrsrs o announce arregaça tudo ahahha O que ja vi tambem, é que esse sistema é um sistema opensource, ja baixei ele pra dar uma olhada, vi que no index tem um select sinistro la, que o memcache ajudaria muito. É ele vai tentar usar sim o memcache. Infelizmente tive que por o Debian lá dessa vez. Nossa está muito mas muito rápido sem fazer quase que nada. Mas mesmo assim ele quer implementar o memcache sim. Só vamos preparar tudo com calma agora. :D MAS CLARO, TEM UM POREM BEM BOM PRA UM DOMINGO DEMANHA, teu programador php ta relutante a usar o memcache, pq NAO FOI ele que desenvolveu esse sistema e por o memcache ali da um pouco de trabalho, pois tem que entender/alterar a classe de acesso ao mysql, se bem que vi que a maioria ta usando as funcoes @mysql nua a crua... o que é ridiculo, quando deveria ser uma classe responsavel por isso, para justamente nao ter que correr o sistema todo para alterar qualquer comportamento do mysql. O fato é esse, o magrao do php ta mais perdido que cusco no meio de procissao, kkk ehheeh mas agora ele quer implementar isso sim. Vou até depois te mandar uns e-mails pvt. Uma duvida que tenho que faz muita diferenca é a seguinte: - esse sistema é acessado(alguma url dele) pelos clientes de torrent ? por exemplo, se peguei um link dum torrent do teu site e to baixando o torrento no meu MICRO TORRENT NA MINHA MAQUINA, o microtorrent ele por si só acessa o site ? ou o proprio site que usa o anounce quando eu clico num link do mesmo ? resumindo: algum agente externo(cliente de torrent) atualiza algo no site, ou tudo acontece a partir dos clicks no site ? O problema são o número de conexões ao mysql que chega à 4000. Tipo vamos dizer que você tenha uns 30 torrents compartilhando. Cada vez que você pára um torrent, inicia, termina de baixar e fica de seeder, começa à baixar outro, o cliente torrent (ex. utorrent) vai no announce usando uma passkey tua, e faz a atualização na base de dados, update, insert, essas coisas pra atualizar as informações sobre o que você tá fazendo. É assim por exemplo que o seu ratio sobe ou desce, porque em sites de torrent fechados você não pode ter ratio baixo porque senão você é banido. :) Agora você coloca aí uns 400mil peers pessoas fazendo isso. rsrsrsr é muita conexão concorrente na base. Tudo com update, insert, etc :) Pelo que li lá nos caras do mysql. No linux eu consigo chegar até 4000 conexões tranquilo com uma certa quantidade de memória. Mas se eu coloco 4000 conexões no mysql do freebsd o sistema me pede mais de 70Gb de ram. Vi outros relatos sobre isso também na minha pesquisa, pessoas reclamando do mysql no freebsd quando a carga é alta. Prezado Marcelo: Poderia nos colocar a par das suas fontes de pesquisa comprovando o problema do Mysql no FreeBSD? Acho que seria importante para documentarmos o fato bem como para podermos procurar uma solução. Lembro que há alguns anos atrás um cara do Yahoo documentou um problema semelhante e teve uns caras depois que colocaram para funcionar tão bem no FreeBSD como no Linux. Acho que foi usando a implementação do linuxthreads, se não me falha a memória. Sim mas o linuxthreads está marcado como não compilável mais no ports. Tentei compilar o mysql com ele pra testar mas não deixou. http://dev.mysql.com/doc/refman/5.1/ja/too-many-connections.html The maximum number of connections MySQL can support depends on the quality of the thread library on a given platform. Linux or Solaris should be able to support 500-1000 simultaneous connections, depending on how much RAM you have and what your clients are doing. Static Linux binaries provided by MySQL AB can support up to 4000 connections. Depois a implementação de threads do FreeBSD mudou. Acho que na época do FreeBSD 7 uma pessoa do core team documentou que o MySQL funcionava até melhor no Free que no Linux. Pois é até agora não entendi isso como que no Linux a coisa funciona de cara e sem nenhum esforço e no freebsd deu essa zica toda. Defeito no hardware não creio porque só pedi para o Datacenter colocar o KVM-IP e o cd Debian e refiz a Instalação. Pra ter uma idéia da situação: o site sem o announce liberado e sem liberação para os usuários. Somente eu e mais 2 pessoas da administração online... quando eu fazia uma consulta de torrent ficava bem lento. Poderia ser o ZFS? Além disso deve haver pessoas que tem concorrência brutal de MySQL no Free, também não me conformo de não ter dado certo ... :-( . Acho que podemos fazer o seguinte: 1 - Nos torne a par das suas fontes
Re: [FUG-BR] Servidor com load altíssimo
Em 09/07/2012 13:39, Leonardo Augusto escreveu: Umm bom, Já que o problema entao esta comprovadamente no mysql sobre o freebsd, fica mais direcionada nossa pesquisa. Olhe esse pdf sobre o freebsd 7 http://people.freebsd.org/~kris/scaling/7.0%20Preview.pdf Vou dar uma olhada. Nao entendo com poderia ter piorado. Nem eu. Foi muito estranho. Será que podia ser o ZFS? Mas creio que não. A única melhora que vi realmente foi sair do 9.0-Stable e ir pro 8.3-Stable. Faz uma coisa, manda pra nós a o teu kernel.conf o teu sysctl,conf, teu loader.conf e o teu my.cnf Puts vou ficar devendo porque foram pro saco quando re-instalei. Mas eu cheguei à colocar eles aqui se eu não me engano. No início da thread. E tambem o comando que tu usou no port (as opcoes do make install) para instalar o mysql. Nao me convenco que possa ficar tao ruim no freebsd, voce atualizou o ports e o sys depois que instalou o os ? antes de compilar o mysql ? Sim. Primeiramente instalei o 9.0 via KVM-IP, atualizei para o 9-stable. Depois achei o load muito alto e falaram aqui na thread que o 9 estava com problemas de performance em relação ao 8.x Aí fiz um downgrade para o 8.3-stable e realmente melhorou muito o load. Uma opcao, seria instalar o BIN do linux e rodar emulado no freebsd para ver, ja vi mysql rodando bin no freebsd ficar mais rapido que no proprio linux. É esse não cheguei à testar não. Passa as configs aí pra galera analizar. abraco - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
Em 9 de julho de 2012 14:15, Marcelo Gondim gon...@bsdinfo.com.brescreveu: Em 09/07/2012 12:52, Francisco Cardoso escreveu: Em 9 de julho de 2012 10:42, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Em 08/07/2012 11:36, Leonardo Augusto escreveu: Bom Marcelo, Pelos graficos que voce me mandou, por hora, sao mais de 3000 selects contra 700 inserts... entao nao sei se foi com ou sem o tal anounce rodando, mas tem bem mais select que insert. Tava sem announce rsrsrs o announce arregaça tudo ahahha O que ja vi tambem, é que esse sistema é um sistema opensource, ja baixei ele pra dar uma olhada, vi que no index tem um select sinistro la, que o memcache ajudaria muito. É ele vai tentar usar sim o memcache. Infelizmente tive que por o Debian lá dessa vez. Nossa está muito mas muito rápido sem fazer quase que nada. Mas mesmo assim ele quer implementar o memcache sim. Só vamos preparar tudo com calma agora. :D MAS CLARO, TEM UM POREM BEM BOM PRA UM DOMINGO DEMANHA, teu programador php ta relutante a usar o memcache, pq NAO FOI ele que desenvolveu esse sistema e por o memcache ali da um pouco de trabalho, pois tem que entender/alterar a classe de acesso ao mysql, se bem que vi que a maioria ta usando as funcoes @mysql nua a crua... o que é ridiculo, quando deveria ser uma classe responsavel por isso, para justamente nao ter que correr o sistema todo para alterar qualquer comportamento do mysql. O fato é esse, o magrao do php ta mais perdido que cusco no meio de procissao, kkk ehheeh mas agora ele quer implementar isso sim. Vou até depois te mandar uns e-mails pvt. Uma duvida que tenho que faz muita diferenca é a seguinte: - esse sistema é acessado(alguma url dele) pelos clientes de torrent ? por exemplo, se peguei um link dum torrent do teu site e to baixando o torrento no meu MICRO TORRENT NA MINHA MAQUINA, o microtorrent ele por si só acessa o site ? ou o proprio site que usa o anounce quando eu clico num link do mesmo ? resumindo: algum agente externo(cliente de torrent) atualiza algo no site, ou tudo acontece a partir dos clicks no site ? O problema são o número de conexões ao mysql que chega à 4000. Tipo vamos dizer que você tenha uns 30 torrents compartilhando. Cada vez que você pára um torrent, inicia, termina de baixar e fica de seeder, começa à baixar outro, o cliente torrent (ex. utorrent) vai no announce usando uma passkey tua, e faz a atualização na base de dados, update, insert, essas coisas pra atualizar as informações sobre o que você tá fazendo. É assim por exemplo que o seu ratio sobe ou desce, porque em sites de torrent fechados você não pode ter ratio baixo porque senão você é banido. :) Agora você coloca aí uns 400mil peers pessoas fazendo isso. rsrsrsr é muita conexão concorrente na base. Tudo com update, insert, etc :) Pelo que li lá nos caras do mysql. No linux eu consigo chegar até 4000 conexões tranquilo com uma certa quantidade de memória. Mas se eu coloco 4000 conexões no mysql do freebsd o sistema me pede mais de 70Gb de ram. Vi outros relatos sobre isso também na minha pesquisa, pessoas reclamando do mysql no freebsd quando a carga é alta. Prezado Marcelo: Poderia nos colocar a par das suas fontes de pesquisa comprovando o problema do Mysql no FreeBSD? Acho que seria importante para documentarmos o fato bem como para podermos procurar uma solução. Lembro que há alguns anos atrás um cara do Yahoo documentou um problema semelhante e teve uns caras depois que colocaram para funcionar tão bem no FreeBSD como no Linux. Acho que foi usando a implementação do linuxthreads, se não me falha a memória. Sim mas o linuxthreads está marcado como não compilável mais no ports. Tentei compilar o mysql com ele pra testar mas não deixou. http://dev.mysql.com/doc/refman/5.1/ja/too-many-connections.html The maximum number of connections MySQL can support depends on the quality of the thread library on a given platform. Linux or Solaris should be able to support 500-1000 simultaneous connections, depending on how much RAM you have and what your clients are doing. Static Linux binaries provided by MySQL AB can support up to 4000 connections. Depois a implementação de threads do FreeBSD mudou. Acho que na época do FreeBSD 7 uma pessoa do core team documentou que o MySQL funcionava até melhor no Free que no Linux. Pois é até agora não entendi isso como que no Linux a coisa funciona de cara e sem nenhum esforço e no freebsd deu essa zica toda. Defeito no hardware não creio porque só pedi para o Datacenter colocar o KVM-IP e o cd Debian e refiz a Instalação. Pra ter uma idéia da situação: o site sem o announce liberado e sem liberação para os usuários. Somente eu e mais 2 pessoas da administração online... quando eu fazia uma consulta de torrent ficava bem lento. Poderia ser o ZFS? Além disso deve haver pessoas que tem
Re: [FUG-BR] Servidor com load altíssimo
Em 9 de julho de 2012 14:32, Matheus Weber da Conceição matheusw...@gmail.com escreveu: Em 9 de julho de 2012 14:15, Marcelo Gondim gon...@bsdinfo.com.brescreveu: Em 09/07/2012 12:52, Francisco Cardoso escreveu: Em 9 de julho de 2012 10:42, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Em 08/07/2012 11:36, Leonardo Augusto escreveu: Bom Marcelo, Pelos graficos que voce me mandou, por hora, sao mais de 3000 selects contra 700 inserts... entao nao sei se foi com ou sem o tal anounce rodando, mas tem bem mais select que insert. Tava sem announce rsrsrs o announce arregaça tudo ahahha O que ja vi tambem, é que esse sistema é um sistema opensource, ja baixei ele pra dar uma olhada, vi que no index tem um select sinistro la, que o memcache ajudaria muito. É ele vai tentar usar sim o memcache. Infelizmente tive que por o Debian lá dessa vez. Nossa está muito mas muito rápido sem fazer quase que nada. Mas mesmo assim ele quer implementar o memcache sim. Só vamos preparar tudo com calma agora. :D MAS CLARO, TEM UM POREM BEM BOM PRA UM DOMINGO DEMANHA, teu programador php ta relutante a usar o memcache, pq NAO FOI ele que desenvolveu esse sistema e por o memcache ali da um pouco de trabalho, pois tem que entender/alterar a classe de acesso ao mysql, se bem que vi que a maioria ta usando as funcoes @mysql nua a crua... o que é ridiculo, quando deveria ser uma classe responsavel por isso, para justamente nao ter que correr o sistema todo para alterar qualquer comportamento do mysql. O fato é esse, o magrao do php ta mais perdido que cusco no meio de procissao, kkk ehheeh mas agora ele quer implementar isso sim. Vou até depois te mandar uns e-mails pvt. Uma duvida que tenho que faz muita diferenca é a seguinte: - esse sistema é acessado(alguma url dele) pelos clientes de torrent ? por exemplo, se peguei um link dum torrent do teu site e to baixando o torrento no meu MICRO TORRENT NA MINHA MAQUINA, o microtorrent ele por si só acessa o site ? ou o proprio site que usa o anounce quando eu clico num link do mesmo ? resumindo: algum agente externo(cliente de torrent) atualiza algo no site, ou tudo acontece a partir dos clicks no site ? O problema são o número de conexões ao mysql que chega à 4000. Tipo vamos dizer que você tenha uns 30 torrents compartilhando. Cada vez que você pára um torrent, inicia, termina de baixar e fica de seeder, começa à baixar outro, o cliente torrent (ex. utorrent) vai no announce usando uma passkey tua, e faz a atualização na base de dados, update, insert, essas coisas pra atualizar as informações sobre o que você tá fazendo. É assim por exemplo que o seu ratio sobe ou desce, porque em sites de torrent fechados você não pode ter ratio baixo porque senão você é banido. :) Agora você coloca aí uns 400mil peers pessoas fazendo isso. rsrsrsr é muita conexão concorrente na base. Tudo com update, insert, etc :) Pelo que li lá nos caras do mysql. No linux eu consigo chegar até 4000 conexões tranquilo com uma certa quantidade de memória. Mas se eu coloco 4000 conexões no mysql do freebsd o sistema me pede mais de 70Gb de ram. Vi outros relatos sobre isso também na minha pesquisa, pessoas reclamando do mysql no freebsd quando a carga é alta. Prezado Marcelo: Poderia nos colocar a par das suas fontes de pesquisa comprovando o problema do Mysql no FreeBSD? Acho que seria importante para documentarmos o fato bem como para podermos procurar uma solução. Lembro que há alguns anos atrás um cara do Yahoo documentou um problema semelhante e teve uns caras depois que colocaram para funcionar tão bem no FreeBSD como no Linux. Acho que foi usando a implementação do linuxthreads, se não me falha a memória. Sim mas o linuxthreads está marcado como não compilável mais no ports. Tentei compilar o mysql com ele pra testar mas não deixou. http://dev.mysql.com/doc/refman/5.1/ja/too-many-connections.html The maximum number of connections MySQL can support depends on the quality of the thread library on a given platform. Linux or Solaris should be able to support 500-1000 simultaneous connections, depending on how much RAM you have and what your clients are doing. Static Linux binaries provided by MySQL AB can support up to 4000 connections. Depois a implementação de threads do FreeBSD mudou. Acho que na época do FreeBSD 7 uma pessoa do core team documentou que o MySQL funcionava até melhor no Free que no Linux. Pois é até agora não entendi isso como que no Linux a coisa funciona de cara e sem nenhum esforço e no freebsd deu essa zica toda. Defeito no hardware não creio porque só pedi para o Datacenter colocar o KVM-IP e o cd Debian e refiz a Instalação. Pra ter uma idéia da situação: o site sem o announce liberado e sem liberação para os usuários. Somente eu e mais 2 pessoas da administração online... quando eu fazia uma consulta de torrent
Re: [FUG-BR] Servidor com load altíssimo
2012/7/9 Luiz Gustavo S. Costa luizgust...@luizgustavo.pro.br: Em 9 de julho de 2012 14:32, Matheus Weber da Conceição matheusw...@gmail.com escreveu: Em 9 de julho de 2012 14:15, Marcelo Gondim gon...@bsdinfo.com.brescreveu: Em 09/07/2012 12:52, Francisco Cardoso escreveu: Em 9 de julho de 2012 10:42, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Em 08/07/2012 11:36, Leonardo Augusto escreveu: Bom Marcelo, Pelos graficos que voce me mandou, por hora, sao mais de 3000 selects contra 700 inserts... entao nao sei se foi com ou sem o tal anounce rodando, mas tem bem mais select que insert. Tava sem announce rsrsrs o announce arregaça tudo ahahha O que ja vi tambem, é que esse sistema é um sistema opensource, ja baixei ele pra dar uma olhada, vi que no index tem um select sinistro la, que o memcache ajudaria muito. É ele vai tentar usar sim o memcache. Infelizmente tive que por o Debian lá dessa vez. Nossa está muito mas muito rápido sem fazer quase que nada. Mas mesmo assim ele quer implementar o memcache sim. Só vamos preparar tudo com calma agora. :D MAS CLARO, TEM UM POREM BEM BOM PRA UM DOMINGO DEMANHA, teu programador php ta relutante a usar o memcache, pq NAO FOI ele que desenvolveu esse sistema e por o memcache ali da um pouco de trabalho, pois tem que entender/alterar a classe de acesso ao mysql, se bem que vi que a maioria ta usando as funcoes @mysql nua a crua... o que é ridiculo, quando deveria ser uma classe responsavel por isso, para justamente nao ter que correr o sistema todo para alterar qualquer comportamento do mysql. O fato é esse, o magrao do php ta mais perdido que cusco no meio de procissao, kkk ehheeh mas agora ele quer implementar isso sim. Vou até depois te mandar uns e-mails pvt. Uma duvida que tenho que faz muita diferenca é a seguinte: - esse sistema é acessado(alguma url dele) pelos clientes de torrent ? por exemplo, se peguei um link dum torrent do teu site e to baixando o torrento no meu MICRO TORRENT NA MINHA MAQUINA, o microtorrent ele por si só acessa o site ? ou o proprio site que usa o anounce quando eu clico num link do mesmo ? resumindo: algum agente externo(cliente de torrent) atualiza algo no site, ou tudo acontece a partir dos clicks no site ? O problema são o número de conexões ao mysql que chega à 4000. Tipo vamos dizer que você tenha uns 30 torrents compartilhando. Cada vez que você pára um torrent, inicia, termina de baixar e fica de seeder, começa à baixar outro, o cliente torrent (ex. utorrent) vai no announce usando uma passkey tua, e faz a atualização na base de dados, update, insert, essas coisas pra atualizar as informações sobre o que você tá fazendo. É assim por exemplo que o seu ratio sobe ou desce, porque em sites de torrent fechados você não pode ter ratio baixo porque senão você é banido. :) Agora você coloca aí uns 400mil peers pessoas fazendo isso. rsrsrsr é muita conexão concorrente na base. Tudo com update, insert, etc :) Pelo que li lá nos caras do mysql. No linux eu consigo chegar até 4000 conexões tranquilo com uma certa quantidade de memória. Mas se eu coloco 4000 conexões no mysql do freebsd o sistema me pede mais de 70Gb de ram. Vi outros relatos sobre isso também na minha pesquisa, pessoas reclamando do mysql no freebsd quando a carga é alta. Prezado Marcelo: Poderia nos colocar a par das suas fontes de pesquisa comprovando o problema do Mysql no FreeBSD? Acho que seria importante para documentarmos o fato bem como para podermos procurar uma solução. Lembro que há alguns anos atrás um cara do Yahoo documentou um problema semelhante e teve uns caras depois que colocaram para funcionar tão bem no FreeBSD como no Linux. Acho que foi usando a implementação do linuxthreads, se não me falha a memória. Sim mas o linuxthreads está marcado como não compilável mais no ports. Tentei compilar o mysql com ele pra testar mas não deixou. http://dev.mysql.com/doc/refman/5.1/ja/too-many-connections.html The maximum number of connections MySQL can support depends on the quality of the thread library on a given platform. Linux or Solaris should be able to support 500-1000 simultaneous connections, depending on how much RAM you have and what your clients are doing. Static Linux binaries provided by MySQL AB can support up to 4000 connections. Depois a implementação de threads do FreeBSD mudou. Acho que na época do FreeBSD 7 uma pessoa do core team documentou que o MySQL funcionava até melhor no Free que no Linux. Pois é até agora não entendi isso como que no Linux a coisa funciona de cara e sem nenhum esforço e no freebsd deu essa zica toda. Defeito no hardware não creio porque só pedi para o Datacenter colocar o KVM-IP e o cd Debian e refiz a Instalação. Pra ter uma idéia da situação: o site sem o announce liberado e sem liberação para os usuários. Somente eu e mais 2 pessoas da
Re: [FUG-BR] Servidor com load altíssimo
Em 09/07/2012 14:55, Luiz Gustavo S. Costa escreveu: Em 9 de julho de 2012 14:32, Matheus Weber da Conceição matheusw...@gmail.com escreveu: Em 9 de julho de 2012 14:15, Marcelo Gondim gon...@bsdinfo.com.brescreveu: Em 09/07/2012 12:52, Francisco Cardoso escreveu: Em 9 de julho de 2012 10:42, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Em 08/07/2012 11:36, Leonardo Augusto escreveu: Bom Marcelo, Pelos graficos que voce me mandou, por hora, sao mais de 3000 selects contra 700 inserts... entao nao sei se foi com ou sem o tal anounce rodando, mas tem bem mais select que insert. Tava sem announce rsrsrs o announce arregaça tudo ahahha O que ja vi tambem, é que esse sistema é um sistema opensource, ja baixei ele pra dar uma olhada, vi que no index tem um select sinistro la, que o memcache ajudaria muito. É ele vai tentar usar sim o memcache. Infelizmente tive que por o Debian lá dessa vez. Nossa está muito mas muito rápido sem fazer quase que nada. Mas mesmo assim ele quer implementar o memcache sim. Só vamos preparar tudo com calma agora. :D MAS CLARO, TEM UM POREM BEM BOM PRA UM DOMINGO DEMANHA, teu programador php ta relutante a usar o memcache, pq NAO FOI ele que desenvolveu esse sistema e por o memcache ali da um pouco de trabalho, pois tem que entender/alterar a classe de acesso ao mysql, se bem que vi que a maioria ta usando as funcoes @mysql nua a crua... o que é ridiculo, quando deveria ser uma classe responsavel por isso, para justamente nao ter que correr o sistema todo para alterar qualquer comportamento do mysql. O fato é esse, o magrao do php ta mais perdido que cusco no meio de procissao, kkk ehheeh mas agora ele quer implementar isso sim. Vou até depois te mandar uns e-mails pvt. Uma duvida que tenho que faz muita diferenca é a seguinte: - esse sistema é acessado(alguma url dele) pelos clientes de torrent ? por exemplo, se peguei um link dum torrent do teu site e to baixando o torrento no meu MICRO TORRENT NA MINHA MAQUINA, o microtorrent ele por si só acessa o site ? ou o proprio site que usa o anounce quando eu clico num link do mesmo ? resumindo: algum agente externo(cliente de torrent) atualiza algo no site, ou tudo acontece a partir dos clicks no site ? O problema são o número de conexões ao mysql que chega à 4000. Tipo vamos dizer que você tenha uns 30 torrents compartilhando. Cada vez que você pára um torrent, inicia, termina de baixar e fica de seeder, começa à baixar outro, o cliente torrent (ex. utorrent) vai no announce usando uma passkey tua, e faz a atualização na base de dados, update, insert, essas coisas pra atualizar as informações sobre o que você tá fazendo. É assim por exemplo que o seu ratio sobe ou desce, porque em sites de torrent fechados você não pode ter ratio baixo porque senão você é banido. :) Agora você coloca aí uns 400mil peers pessoas fazendo isso. rsrsrsr é muita conexão concorrente na base. Tudo com update, insert, etc :) Pelo que li lá nos caras do mysql. No linux eu consigo chegar até 4000 conexões tranquilo com uma certa quantidade de memória. Mas se eu coloco 4000 conexões no mysql do freebsd o sistema me pede mais de 70Gb de ram. Vi outros relatos sobre isso também na minha pesquisa, pessoas reclamando do mysql no freebsd quando a carga é alta. Prezado Marcelo: Poderia nos colocar a par das suas fontes de pesquisa comprovando o problema do Mysql no FreeBSD? Acho que seria importante para documentarmos o fato bem como para podermos procurar uma solução. Lembro que há alguns anos atrás um cara do Yahoo documentou um problema semelhante e teve uns caras depois que colocaram para funcionar tão bem no FreeBSD como no Linux. Acho que foi usando a implementação do linuxthreads, se não me falha a memória. Sim mas o linuxthreads está marcado como não compilável mais no ports. Tentei compilar o mysql com ele pra testar mas não deixou. http://dev.mysql.com/doc/refman/5.1/ja/too-many-connections.html The maximum number of connections MySQL can support depends on the quality of the thread library on a given platform. Linux or Solaris should be able to support 500-1000 simultaneous connections, depending on how much RAM you have and what your clients are doing. Static Linux binaries provided by MySQL AB can support up to 4000 connections. Depois a implementação de threads do FreeBSD mudou. Acho que na época do FreeBSD 7 uma pessoa do core team documentou que o MySQL funcionava até melhor no Free que no Linux. Pois é até agora não entendi isso como que no Linux a coisa funciona de cara e sem nenhum esforço e no freebsd deu essa zica toda. Defeito no hardware não creio porque só pedi para o Datacenter colocar o KVM-IP e o cd Debian e refiz a Instalação. Pra ter uma idéia da situação: o site sem o announce liberado e sem liberação para os usuários. Somente eu e mais 2 pessoas da administração online... quando eu fazia uma consulta de torrent ficava bem lento.
Re: [FUG-BR] Servidor com load altíssimo
Em 09/07/2012 14:32, Matheus Weber da Conceição escreveu: Em 9 de julho de 2012 14:15, Marcelo Gondim gon...@bsdinfo.com.brescreveu: Em 09/07/2012 12:52, Francisco Cardoso escreveu: Em 9 de julho de 2012 10:42, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Em 08/07/2012 11:36, Leonardo Augusto escreveu: Bom Marcelo, Pelos graficos que voce me mandou, por hora, sao mais de 3000 selects contra 700 inserts... entao nao sei se foi com ou sem o tal anounce rodando, mas tem bem mais select que insert. Tava sem announce rsrsrs o announce arregaça tudo ahahha O que ja vi tambem, é que esse sistema é um sistema opensource, ja baixei ele pra dar uma olhada, vi que no index tem um select sinistro la, que o memcache ajudaria muito. É ele vai tentar usar sim o memcache. Infelizmente tive que por o Debian lá dessa vez. Nossa está muito mas muito rápido sem fazer quase que nada. Mas mesmo assim ele quer implementar o memcache sim. Só vamos preparar tudo com calma agora. :D MAS CLARO, TEM UM POREM BEM BOM PRA UM DOMINGO DEMANHA, teu programador php ta relutante a usar o memcache, pq NAO FOI ele que desenvolveu esse sistema e por o memcache ali da um pouco de trabalho, pois tem que entender/alterar a classe de acesso ao mysql, se bem que vi que a maioria ta usando as funcoes @mysql nua a crua... o que é ridiculo, quando deveria ser uma classe responsavel por isso, para justamente nao ter que correr o sistema todo para alterar qualquer comportamento do mysql. O fato é esse, o magrao do php ta mais perdido que cusco no meio de procissao, kkk ehheeh mas agora ele quer implementar isso sim. Vou até depois te mandar uns e-mails pvt. Uma duvida que tenho que faz muita diferenca é a seguinte: - esse sistema é acessado(alguma url dele) pelos clientes de torrent ? por exemplo, se peguei um link dum torrent do teu site e to baixando o torrento no meu MICRO TORRENT NA MINHA MAQUINA, o microtorrent ele por si só acessa o site ? ou o proprio site que usa o anounce quando eu clico num link do mesmo ? resumindo: algum agente externo(cliente de torrent) atualiza algo no site, ou tudo acontece a partir dos clicks no site ? O problema são o número de conexões ao mysql que chega à 4000. Tipo vamos dizer que você tenha uns 30 torrents compartilhando. Cada vez que você pára um torrent, inicia, termina de baixar e fica de seeder, começa à baixar outro, o cliente torrent (ex. utorrent) vai no announce usando uma passkey tua, e faz a atualização na base de dados, update, insert, essas coisas pra atualizar as informações sobre o que você tá fazendo. É assim por exemplo que o seu ratio sobe ou desce, porque em sites de torrent fechados você não pode ter ratio baixo porque senão você é banido. :) Agora você coloca aí uns 400mil peers pessoas fazendo isso. rsrsrsr é muita conexão concorrente na base. Tudo com update, insert, etc :) Pelo que li lá nos caras do mysql. No linux eu consigo chegar até 4000 conexões tranquilo com uma certa quantidade de memória. Mas se eu coloco 4000 conexões no mysql do freebsd o sistema me pede mais de 70Gb de ram. Vi outros relatos sobre isso também na minha pesquisa, pessoas reclamando do mysql no freebsd quando a carga é alta. Prezado Marcelo: Poderia nos colocar a par das suas fontes de pesquisa comprovando o problema do Mysql no FreeBSD? Acho que seria importante para documentarmos o fato bem como para podermos procurar uma solução. Lembro que há alguns anos atrás um cara do Yahoo documentou um problema semelhante e teve uns caras depois que colocaram para funcionar tão bem no FreeBSD como no Linux. Acho que foi usando a implementação do linuxthreads, se não me falha a memória. Sim mas o linuxthreads está marcado como não compilável mais no ports. Tentei compilar o mysql com ele pra testar mas não deixou. http://dev.mysql.com/doc/refman/5.1/ja/too-many-connections.html The maximum number of connections MySQL can support depends on the quality of the thread library on a given platform. Linux or Solaris should be able to support 500-1000 simultaneous connections, depending on how much RAM you have and what your clients are doing. Static Linux binaries provided by MySQL AB can support up to 4000 connections. Depois a implementação de threads do FreeBSD mudou. Acho que na época do FreeBSD 7 uma pessoa do core team documentou que o MySQL funcionava até melhor no Free que no Linux. Pois é até agora não entendi isso como que no Linux a coisa funciona de cara e sem nenhum esforço e no freebsd deu essa zica toda. Defeito no hardware não creio porque só pedi para o Datacenter colocar o KVM-IP e o cd Debian e refiz a Instalação. Pra ter uma idéia da situação: o site sem o announce liberado e sem liberação para os usuários. Somente eu e mais 2 pessoas da administração online... quando eu fazia uma consulta de torrent ficava bem lento. Poderia ser o ZFS? Além disso deve haver pessoas que tem concorrência brutal de MySQL no
Re: [FUG-BR] Servidor com load altíssimo
Em 09/07/2012 15:06, William Grzybowski escreveu: 2012/7/9 Luiz Gustavo S. Costa luizgust...@luizgustavo.pro.br: Em 9 de julho de 2012 14:32, Matheus Weber da Conceição matheusw...@gmail.com escreveu: Em 9 de julho de 2012 14:15, Marcelo Gondim gon...@bsdinfo.com.brescreveu: Em 09/07/2012 12:52, Francisco Cardoso escreveu: Em 9 de julho de 2012 10:42, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Em 08/07/2012 11:36, Leonardo Augusto escreveu: Bom Marcelo, Pelos graficos que voce me mandou, por hora, sao mais de 3000 selects contra 700 inserts... entao nao sei se foi com ou sem o tal anounce rodando, mas tem bem mais select que insert. Tava sem announce rsrsrs o announce arregaça tudo ahahha O que ja vi tambem, é que esse sistema é um sistema opensource, ja baixei ele pra dar uma olhada, vi que no index tem um select sinistro la, que o memcache ajudaria muito. É ele vai tentar usar sim o memcache. Infelizmente tive que por o Debian lá dessa vez. Nossa está muito mas muito rápido sem fazer quase que nada. Mas mesmo assim ele quer implementar o memcache sim. Só vamos preparar tudo com calma agora. :D MAS CLARO, TEM UM POREM BEM BOM PRA UM DOMINGO DEMANHA, teu programador php ta relutante a usar o memcache, pq NAO FOI ele que desenvolveu esse sistema e por o memcache ali da um pouco de trabalho, pois tem que entender/alterar a classe de acesso ao mysql, se bem que vi que a maioria ta usando as funcoes @mysql nua a crua... o que é ridiculo, quando deveria ser uma classe responsavel por isso, para justamente nao ter que correr o sistema todo para alterar qualquer comportamento do mysql. O fato é esse, o magrao do php ta mais perdido que cusco no meio de procissao, kkk ehheeh mas agora ele quer implementar isso sim. Vou até depois te mandar uns e-mails pvt. Uma duvida que tenho que faz muita diferenca é a seguinte: - esse sistema é acessado(alguma url dele) pelos clientes de torrent ? por exemplo, se peguei um link dum torrent do teu site e to baixando o torrento no meu MICRO TORRENT NA MINHA MAQUINA, o microtorrent ele por si só acessa o site ? ou o proprio site que usa o anounce quando eu clico num link do mesmo ? resumindo: algum agente externo(cliente de torrent) atualiza algo no site, ou tudo acontece a partir dos clicks no site ? O problema são o número de conexões ao mysql que chega à 4000. Tipo vamos dizer que você tenha uns 30 torrents compartilhando. Cada vez que você pára um torrent, inicia, termina de baixar e fica de seeder, começa à baixar outro, o cliente torrent (ex. utorrent) vai no announce usando uma passkey tua, e faz a atualização na base de dados, update, insert, essas coisas pra atualizar as informações sobre o que você tá fazendo. É assim por exemplo que o seu ratio sobe ou desce, porque em sites de torrent fechados você não pode ter ratio baixo porque senão você é banido. :) Agora você coloca aí uns 400mil peers pessoas fazendo isso. rsrsrsr é muita conexão concorrente na base. Tudo com update, insert, etc :) Pelo que li lá nos caras do mysql. No linux eu consigo chegar até 4000 conexões tranquilo com uma certa quantidade de memória. Mas se eu coloco 4000 conexões no mysql do freebsd o sistema me pede mais de 70Gb de ram. Vi outros relatos sobre isso também na minha pesquisa, pessoas reclamando do mysql no freebsd quando a carga é alta. Prezado Marcelo: Poderia nos colocar a par das suas fontes de pesquisa comprovando o problema do Mysql no FreeBSD? Acho que seria importante para documentarmos o fato bem como para podermos procurar uma solução. Lembro que há alguns anos atrás um cara do Yahoo documentou um problema semelhante e teve uns caras depois que colocaram para funcionar tão bem no FreeBSD como no Linux. Acho que foi usando a implementação do linuxthreads, se não me falha a memória. Sim mas o linuxthreads está marcado como não compilável mais no ports. Tentei compilar o mysql com ele pra testar mas não deixou. http://dev.mysql.com/doc/refman/5.1/ja/too-many-connections.html The maximum number of connections MySQL can support depends on the quality of the thread library on a given platform. Linux or Solaris should be able to support 500-1000 simultaneous connections, depending on how much RAM you have and what your clients are doing. Static Linux binaries provided by MySQL AB can support up to 4000 connections. Depois a implementação de threads do FreeBSD mudou. Acho que na época do FreeBSD 7 uma pessoa do core team documentou que o MySQL funcionava até melhor no Free que no Linux. Pois é até agora não entendi isso como que no Linux a coisa funciona de cara e sem nenhum esforço e no freebsd deu essa zica toda. Defeito no hardware não creio porque só pedi para o Datacenter colocar o KVM-IP e o cd Debian e refiz a Instalação. Pra ter uma idéia da situação: o site sem o announce liberado e sem liberação para os usuários. Somente eu e mais 2 pessoas da administração online...
Re: [FUG-BR] Servidor com load altíssimo
Em 9 de julho de 2012 15:09, Marcelo Gondim gon...@bsdinfo.com.brescreveu: Em 09/07/2012 14:55, Luiz Gustavo S. Costa escreveu: Em 9 de julho de 2012 14:32, Matheus Weber da Conceição matheusw...@gmail.com escreveu: Em 9 de julho de 2012 14:15, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Em 09/07/2012 12:52, Francisco Cardoso escreveu: Em 9 de julho de 2012 10:42, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Em 08/07/2012 11:36, Leonardo Augusto escreveu: Bom Marcelo, Pelos graficos que voce me mandou, por hora, sao mais de 3000 selects contra 700 inserts... entao nao sei se foi com ou sem o tal anounce rodando, mas tem bem mais select que insert. Tava sem announce rsrsrs o announce arregaça tudo ahahha O que ja vi tambem, é que esse sistema é um sistema opensource, ja baixei ele pra dar uma olhada, vi que no index tem um select sinistro la, que o memcache ajudaria muito. É ele vai tentar usar sim o memcache. Infelizmente tive que por o Debian lá dessa vez. Nossa está muito mas muito rápido sem fazer quase que nada. Mas mesmo assim ele quer implementar o memcache sim. Só vamos preparar tudo com calma agora. :D MAS CLARO, TEM UM POREM BEM BOM PRA UM DOMINGO DEMANHA, teu programador php ta relutante a usar o memcache, pq NAO FOI ele que desenvolveu esse sistema e por o memcache ali da um pouco de trabalho, pois tem que entender/alterar a classe de acesso ao mysql, se bem que vi que a maioria ta usando as funcoes @mysql nua a crua... o que é ridiculo, quando deveria ser uma classe responsavel por isso, para justamente nao ter que correr o sistema todo para alterar qualquer comportamento do mysql. O fato é esse, o magrao do php ta mais perdido que cusco no meio de procissao, kkk ehheeh mas agora ele quer implementar isso sim. Vou até depois te mandar uns e-mails pvt. Uma duvida que tenho que faz muita diferenca é a seguinte: - esse sistema é acessado(alguma url dele) pelos clientes de torrent ? por exemplo, se peguei um link dum torrent do teu site e to baixando o torrento no meu MICRO TORRENT NA MINHA MAQUINA, o microtorrent ele por si só acessa o site ? ou o proprio site que usa o anounce quando eu clico num link do mesmo ? resumindo: algum agente externo(cliente de torrent) atualiza algo no site, ou tudo acontece a partir dos clicks no site ? O problema são o número de conexões ao mysql que chega à 4000. Tipo vamos dizer que você tenha uns 30 torrents compartilhando. Cada vez que você pára um torrent, inicia, termina de baixar e fica de seeder, começa à baixar outro, o cliente torrent (ex. utorrent) vai no announce usando uma passkey tua, e faz a atualização na base de dados, update, insert, essas coisas pra atualizar as informações sobre o que você tá fazendo. É assim por exemplo que o seu ratio sobe ou desce, porque em sites de torrent fechados você não pode ter ratio baixo porque senão você é banido. :) Agora você coloca aí uns 400mil peers pessoas fazendo isso. rsrsrsr é muita conexão concorrente na base. Tudo com update, insert, etc :) Pelo que li lá nos caras do mysql. No linux eu consigo chegar até 4000 conexões tranquilo com uma certa quantidade de memória. Mas se eu coloco 4000 conexões no mysql do freebsd o sistema me pede mais de 70Gb de ram. Vi outros relatos sobre isso também na minha pesquisa, pessoas reclamando do mysql no freebsd quando a carga é alta. Prezado Marcelo: Poderia nos colocar a par das suas fontes de pesquisa comprovando o problema do Mysql no FreeBSD? Acho que seria importante para documentarmos o fato bem como para podermos procurar uma solução. Lembro que há alguns anos atrás um cara do Yahoo documentou um problema semelhante e teve uns caras depois que colocaram para funcionar tão bem no FreeBSD como no Linux. Acho que foi usando a implementação do linuxthreads, se não me falha a memória. Sim mas o linuxthreads está marcado como não compilável mais no ports. Tentei compilar o mysql com ele pra testar mas não deixou. http://dev.mysql.com/doc/refman/5.1/ja/too-many-connections.html The maximum number of connections MySQL can support depends on the quality of the thread library on a given platform. Linux or Solaris should be able to support 500-1000 simultaneous connections, depending on how much RAM you have and what your clients are doing. Static Linux binaries provided by MySQL AB can support up to 4000 connections. Depois a implementação de threads do FreeBSD mudou. Acho que na época do FreeBSD 7 uma pessoa do core team documentou que o MySQL funcionava até melhor no Free que no Linux. Pois é até agora não entendi isso como que no Linux a coisa funciona de cara e sem nenhum esforço e no freebsd deu essa zica toda. Defeito no hardware não creio porque só pedi para o Datacenter colocar o KVM-IP e o cd Debian e refiz a Instalação. Pra ter uma idéia da
Re: [FUG-BR] Servidor com load altíssimo
Em 09/07/2012 15:36, Saul Figueiredo escreveu: Em 9 de julho de 2012 15:09, Marcelo Gondim gon...@bsdinfo.com.brescreveu: Em 09/07/2012 14:55, Luiz Gustavo S. Costa escreveu: Em 9 de julho de 2012 14:32, Matheus Weber da Conceição matheusw...@gmail.com escreveu: Em 9 de julho de 2012 14:15, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Em 09/07/2012 12:52, Francisco Cardoso escreveu: Em 9 de julho de 2012 10:42, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Em 08/07/2012 11:36, Leonardo Augusto escreveu: Bom Marcelo, Pelos graficos que voce me mandou, por hora, sao mais de 3000 selects contra 700 inserts... entao nao sei se foi com ou sem o tal anounce rodando, mas tem bem mais select que insert. Tava sem announce rsrsrs o announce arregaça tudo ahahha O que ja vi tambem, é que esse sistema é um sistema opensource, ja baixei ele pra dar uma olhada, vi que no index tem um select sinistro la, que o memcache ajudaria muito. É ele vai tentar usar sim o memcache. Infelizmente tive que por o Debian lá dessa vez. Nossa está muito mas muito rápido sem fazer quase que nada. Mas mesmo assim ele quer implementar o memcache sim. Só vamos preparar tudo com calma agora. :D MAS CLARO, TEM UM POREM BEM BOM PRA UM DOMINGO DEMANHA, teu programador php ta relutante a usar o memcache, pq NAO FOI ele que desenvolveu esse sistema e por o memcache ali da um pouco de trabalho, pois tem que entender/alterar a classe de acesso ao mysql, se bem que vi que a maioria ta usando as funcoes @mysql nua a crua... o que é ridiculo, quando deveria ser uma classe responsavel por isso, para justamente nao ter que correr o sistema todo para alterar qualquer comportamento do mysql. O fato é esse, o magrao do php ta mais perdido que cusco no meio de procissao, kkk ehheeh mas agora ele quer implementar isso sim. Vou até depois te mandar uns e-mails pvt. Uma duvida que tenho que faz muita diferenca é a seguinte: - esse sistema é acessado(alguma url dele) pelos clientes de torrent ? por exemplo, se peguei um link dum torrent do teu site e to baixando o torrento no meu MICRO TORRENT NA MINHA MAQUINA, o microtorrent ele por si só acessa o site ? ou o proprio site que usa o anounce quando eu clico num link do mesmo ? resumindo: algum agente externo(cliente de torrent) atualiza algo no site, ou tudo acontece a partir dos clicks no site ? O problema são o número de conexões ao mysql que chega à 4000. Tipo vamos dizer que você tenha uns 30 torrents compartilhando. Cada vez que você pára um torrent, inicia, termina de baixar e fica de seeder, começa à baixar outro, o cliente torrent (ex. utorrent) vai no announce usando uma passkey tua, e faz a atualização na base de dados, update, insert, essas coisas pra atualizar as informações sobre o que você tá fazendo. É assim por exemplo que o seu ratio sobe ou desce, porque em sites de torrent fechados você não pode ter ratio baixo porque senão você é banido. :) Agora você coloca aí uns 400mil peers pessoas fazendo isso. rsrsrsr é muita conexão concorrente na base. Tudo com update, insert, etc :) Pelo que li lá nos caras do mysql. No linux eu consigo chegar até 4000 conexões tranquilo com uma certa quantidade de memória. Mas se eu coloco 4000 conexões no mysql do freebsd o sistema me pede mais de 70Gb de ram. Vi outros relatos sobre isso também na minha pesquisa, pessoas reclamando do mysql no freebsd quando a carga é alta. Prezado Marcelo: Poderia nos colocar a par das suas fontes de pesquisa comprovando o problema do Mysql no FreeBSD? Acho que seria importante para documentarmos o fato bem como para podermos procurar uma solução. Lembro que há alguns anos atrás um cara do Yahoo documentou um problema semelhante e teve uns caras depois que colocaram para funcionar tão bem no FreeBSD como no Linux. Acho que foi usando a implementação do linuxthreads, se não me falha a memória. Sim mas o linuxthreads está marcado como não compilável mais no ports. Tentei compilar o mysql com ele pra testar mas não deixou. http://dev.mysql.com/doc/refman/5.1/ja/too-many-connections.html The maximum number of connections MySQL can support depends on the quality of the thread library on a given platform. Linux or Solaris should be able to support 500-1000 simultaneous connections, depending on how much RAM you have and what your clients are doing. Static Linux binaries provided by MySQL AB can support up to 4000 connections. Depois a implementação de threads do FreeBSD mudou. Acho que na época do FreeBSD 7 uma pessoa do core team documentou que o MySQL funcionava até melhor no Free que no Linux. Pois é até agora não entendi isso como que no Linux a coisa funciona de cara e sem nenhum esforço e no freebsd deu essa zica toda. Defeito no hardware não creio porque só pedi para o Datacenter colocar o KVM-IP e o cd Debian e refiz a Instalação. Pra ter uma idéia da situação: o site sem o announce liberado e sem
Re: [FUG-BR] Servidor com load altíssimo
Cada conexao tcp é como se fosse um file aberto. Se vc ta tentando abrir mais files que o kernel permite, acho que ou enfilera e espera liberar por um tempo ou fica num while ate acaba o mundo tentando um buraco pra se enfiar, hehe Por isso pedi teu tuning do kernel e do dysctl, pra comparar com o meu. Menos slots que o necessario vai dar zica, o que exatamente ja nao sei. Vc nao simulou o update de um usuario apenas ne? Faz o seguinte, limita via ipfw as conexoes na porta 80 em 100 simultaneas, so pra ver se nesse caso os mysql tb ficariam com alto load. O primeiro a comer um slot do kernel via o socket e o apache que dai o php envia a query pro mysql que nao consegue executar pq nao tem mais slot, pode ter a ver isso sim - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
Bom Marcelo, Pelos graficos que voce me mandou, por hora, sao mais de 3000 selects contra 700 inserts... entao nao sei se foi com ou sem o tal anounce rodando, mas tem bem mais select que insert. O que ja vi tambem, é que esse sistema é um sistema opensource, ja baixei ele pra dar uma olhada, vi que no index tem um select sinistro la, que o memcache ajudaria muito. MAS CLARO, TEM UM POREM BEM BOM PRA UM DOMINGO DEMANHA, teu programador php ta relutante a usar o memcache, pq NAO FOI ele que desenvolveu esse sistema e por o memcache ali da um pouco de trabalho, pois tem que entender/alterar a classe de acesso ao mysql, se bem que vi que a maioria ta usando as funcoes @mysql nua a crua... o que é ridiculo, quando deveria ser uma classe responsavel por isso, para justamente nao ter que correr o sistema todo para alterar qualquer comportamento do mysql. O fato é esse, o magrao do php ta mais perdido que cusco no meio de procissao, kkk Uma duvida que tenho que faz muita diferenca é a seguinte: - esse sistema é acessado(alguma url dele) pelos clientes de torrent ? por exemplo, se peguei um link dum torrent do teu site e to baixando o torrento no meu MICRO TORRENT NA MINHA MAQUINA, o microtorrent ele por si só acessa o site ? ou o proprio site que usa o anounce quando eu clico num link do mesmo ? resumindo: algum agente externo(cliente de torrent) atualiza algo no site, ou tudo acontece a partir dos clicks no site ? Vamos aos fatos que vc tem que observar: - É de dominio publico que o innodb para inserts funciona melhor que o myisam, isso é facil de mudar (pra quem sabe, pelo jeito teu phpman nao sabe, eheh tu ta lascado!) - Entao adotar o innodb faria muito diferenca, pois o tuning dele é mais consistente para concorrencia, threads e justamente alto IO. - Voce usou as opcoes de otimizacao no make.conf na hora que instalou o apache, php, mysql ? tipo: CFLAGS= -O2 -pipe -funroll-loops -ffast-math COPTFLAGS= -O2 -pipe -funroll-loops -ffast-math WITHOUT_X11=yes NO_X=yes - O myisam tem opcoes que podem ajudar, como o tamanho do cache para criar indices(afeta o insert), mas ele nao é para alta concorrencia( monte de desocupado fazendo insert ao mesmo tempo, ehe ) - Se (essa joça) funciona no linSUX, numa maquina inferior, e agora no bsd esta mais lento ou com mais load acusando no sistema, algo esta errado(quem nao sabe ne), temos que considerar: a) o mesmo numero de usuarios esta acesando o sistema agora ? ou tem mais do que na epoca do linux ? b) alguma mudanca de comportamente do sistema foi feita ? ativou algum recurso que nao usava antes ? Se A e B nao indicam alguma mudanca de comportamento ou de acessos, é obvio que o problema esta na configuracao da infra estrutura, php, mysql ( o apache nao influencia muito ) Imagino, tenho quase certeza que a instalacao do php/mysql no linux via o APT da vida, coloca tudo ja otimizado pra funcionar o melhor possivel no linux, como ja comentei. No bsd, vc quem que instalar tudo via ports fazendo na mao os tunings necessarios, mas no final fica mais rapido que no linux, nao sou eu que digo, varios benchmarks, principalmente de mysql mostram isso. - Como nao temos dominio sobre o comportamento exato do sistema, pois NAO FOI FEITO por nos, nem pelo teu phpman, vamos focar na infra-estrutura.. Me fale como instalou o conjunto php mysql apache. Pode ter algum xabu ai com o php/mysql Qual o numero de registros nas tabelas: USERS, TORRENTS E PEERS ? Voce esta usando ufs com soft updates ? ou o tal zfs ? (nunca usei zfs, pode ter algum xabu na config dele) O myisam requer mais IO durantes os inserts que o innodb( eu acredito ) entao isso pode estar influenciando. TEM O TAL PARTICIONAMENTO do mysql, que pode ser feito, o que vai melhorar os inserts, pois o tamanho do indice fica menor, mas isso se justifica se voce tiver milhoes de registros. http://dev.mysql.com/doc/refman/5.1/en/partitioning-overview.html http://tech.bluesmoon.info/2009/09/scaling-writes-in-mysql.html Enfim, o que posso dizer é que pro numero de select/inserts por hora que os graficos indicam, é nada pra maquina que voce citou, nem cocegas deveria fazer, ou tem algo muito mal na instalacao(algum bug talvez) ou o teu phpman ativou algo agora que nao estava ativado antes la no linux. Perguntei antes se o anounce é chamado pelo proprio site quando vc clica num link por exemplo, para se fazer um teste, apenas voce clicar no lugar que chama o anounce(e que esta travando/demorando para o mundo externo) para ver se com um evento fica lento ou aparece no top, se uma chamada do anounce esta demorando, ja mostra que é problema de infra ou de estrutura logica da aplicacao, agora se a lentidao e o load so aparecem quando tem muito acesso... aí temos que voltar ao que estava discutindo antes. Entao, voce consegue fazer esse tipo de teste ?Como ele ativa/desativa esse anounce ? bota um exit; no inicio dele ? achei muito ruim o codigo desse sistema... é muito antigo, fala php 4 e usava register
Re: [FUG-BR] Servidor com load altíssimo
Olhando por cima o codigo do anounce, vi algo que pode estar causando
esse alto load do apache (ja que o php esta dentro dele)
if (!isset($self)){ //IF PEER IS NOT IN PEERS TABLE DO THE WAIT TIME CHECK
if ($MEMBERSONLY_WAIT $MEMBERSONLY){
//wait time check
if($left 0 in_array($user[class],
explode(,,$site_config[WAIT_CLASS])))
{ //check only leechers and lowest user class
$gigs = $user[uploaded] / (1024*1024*1024);
$elapsed = floor((gmtime() - $torrent[ts]) / 3600);
$ratio = (($user[downloaded] 0) ?
($user[uploaded] /
$user[downloaded]) : 1);
if ($ratio == 0 $gigs == 0) $wait =
$site_config[WAITA];
elseif ($ratio $site_config[RATIOA] || $gigs
$site_config[GIGSA]) $wait = $site_config[WAITA];
elseif ($ratio $site_config[RATIOB] || $gigs
$site_config[GIGSB]) $wait = $site_config[WAITB];
elseif ($ratio $site_config[RATIOC] || $gigs
$site_config[GIGSC]) $wait = $site_config[WAITC];
elseif ($ratio $site_config[RATIOD] || $gigs
$site_config[GIGSD]) $wait = $site_config[WAITD];
else $wait = 0;
if ($elapsed $wait)
err(Wait Time ( . ($wait - $elapsed) . hours) -
Visit
.$site_config[SITEURL]. for more info);
}
}
$sockres = @fsockopen($ip, $port, $errno, $errstr, 5);
if (!$sockres)
$connectable = no;
else
$connectable = yes;
@fclose($sockres);
}else{
$upthis = max(0, $uploaded - $self[uploaded]);
$downthis = max(0, $downloaded - $self[downloaded]);
if (($upthis 0 || $downthis 0) is_valid_id($userid)){ // LIVE STATS!)
if ($torrent[freeleech] == 1){
SQL_Query_exec(UPDATE users SET uploaded = uploaded +
$upthis
WHERE id=$userid) or err(Tracker error: Unable to update stats);
}else{
SQL_Query_exec(UPDATE users SET uploaded = uploaded +
$upthis,
downloaded = downloaded + $downthis WHERE id=$userid) or err(Tracker
error: Unable to update stats);
}
}
}//END WAIT AND STATS UPDATE
O php pelo que entendi tenta conectar via socket diretamente la no
cliente externo...
ativa esse anunce mas comenta essa parte para ver se muda alguma coisa
/*- comenta isso
$sockres = @fsockopen($ip, $port, $errno, $errstr, 5);
if (!$sockres)
$connectable = no;
else
$connectable = yes;
@fclose($sockres);
*/
$connectable = no; // adiciona essa linha
Talvez essa conexao do socket esteja demorando muito pra se
decidir aí fica parado ali.
Pode nao ter nada a ver... mas é o que encontrei que nao ta
relacionado ao mysql mas pode estar gerando load
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
Ooo ta brab Cara, ja falei, vou falar denovo: 1) INSTALA O MEMCACHE E USA PARA CACHEAR O MYSQL E O SESSION. 2) INSTALA UM APC, XCACHE DA VIDA PARA O PHP. Depois ve o que acontece, antes disso é complicado Usar php sem cache/acelerador é SUÍCIDIO, ele vai compilar o script a cada request,, e se ta dentro do apache, aparece como sendo o apache o criminoso... Por isso que é melhor usar o php fora, via fast-cgi. Usar cache pro php e memcache hoje em dia é MANDATÓRIO para qualquer setup php/mysql. Ainda mais com altissimo numero de acessos como o seu site. Faz isso cara, senao pega a 12 como ja disse , e se mata, eheheh abraco - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
Em 07/07/2012 10:26, Leonardo Augusto escreveu: Ooo ta brab Cara, ja falei, vou falar denovo: 1) INSTALA O MEMCACHE E USA PARA CACHEAR O MYSQL E O SESSION. 2) INSTALA UM APC, XCACHE DA VIDA PARA O PHP. Pessoal primeiramente umas considerações: 1º Fiz o downgrade do FreeBSD 9-STABLE para o FreeBSD 8.3-STABLE e recompilei todos os pacotes. É realmente gritante a diferença de performance!! Os loads que antes iam na casa dos 200 agora ficam em 0. , 3.0, 2.0 e olhe lá. 2º O MySQL não vai mais nas alturas em processamento fica bem baixo. 3º Descobri o causador daquele erro de criar threads (Can't create a new thread (errno 35); if you are not out of available memory, you can consult the manual for a possible OS-dependent bug) no MySQL. Eu tive que aumentar esse cara no sysctl: kern.threads.max_threads_per_proc=250 o default estava em 1500 e quando consulto: sysctl kern.threads.max_threads_hits me retorna 1982281 só não sei a causa disso ainda mas estamos indo. 4º Meu problema agora é o seguinte: Estou tendo mais de 4000 conexões no mysql devido ao announce.php que quando o site sobe ele arregaça geral ahhahah Se eu coloco 4000 conexões simultâneas o mysql automaticamente usa mais memória que eu tenho disponível. Hoje estou com 1500 conexões configuradas. Minhas configurações estão assim: skip-locking key_buffer_size = 2G max_allowed_packet = 1M table_open_cache = 512 sort_buffer_size = 2M read_buffer_size = 2M read_rnd_buffer_size = 8M myisam_sort_buffer_size = 64M thread_cache_size = 8 query_cache_size = 32M max_connections = 1500 thread_concurrency = 48 Leonardo estou vendo com o programador da gente por o memcache pra testarmos. Você acha que se ele colocar o memcache o número de conexões na base vai cair? Você diz instalar e usar esse cara aqui? /usr/ports/databases/memcached Depois ve o que acontece, antes disso é complicado Usar php sem cache/acelerador é SUÍCIDIO, ele vai compilar o script a cada request,, e se ta dentro do apache, aparece como sendo o apache o criminoso... Por isso que é melhor usar o php fora, via fast-cgi. Usar cache pro php e memcache hoje em dia é MANDATÓRIO para qualquer setup php/mysql. Ainda mais com altissimo numero de acessos como o seu site. Faz isso cara, senao pega a 12 como ja disse , e se mata, eheheh abraco - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
2012/7/7 Marcelo Gondim gon...@bsdinfo.com.br: Em 07/07/2012 10:26, Leonardo Augusto escreveu: Ooo ta brab Cara, ja falei, vou falar denovo: 1) INSTALA O MEMCACHE E USA PARA CACHEAR O MYSQL E O SESSION. 2) INSTALA UM APC, XCACHE DA VIDA PARA O PHP. Pessoal primeiramente umas considerações: 1º Fiz o downgrade do FreeBSD 9-STABLE para o FreeBSD 8.3-STABLE e recompilei todos os pacotes. É realmente gritante a diferença de performance!! Os loads que antes iam na casa dos 200 agora ficam em 0. , 3.0, 2.0 e olhe lá. 2º O MySQL não vai mais nas alturas em processamento fica bem baixo. 3º Descobri o causador daquele erro de criar threads (Can't create a new thread (errno 35); if you are not out of available memory, you can consult the manual for a possible OS-dependent bug) no MySQL. Eu tive que aumentar esse cara no sysctl: kern.threads.max_threads_per_proc=250 o default estava em 1500 e quando consulto: sysctl kern.threads.max_threads_hits me retorna 1982281 só não sei a causa disso ainda mas estamos indo. 4º Meu problema agora é o seguinte: Estou tendo mais de 4000 conexões no mysql devido ao announce.php que quando o site sobe ele arregaça geral ahhahah Se eu coloco 4000 conexões simultâneas o mysql automaticamente usa mais memória que eu tenho disponível. Hoje estou com 1500 conexões configuradas. Minhas configurações estão assim: skip-locking key_buffer_size = 2G max_allowed_packet = 1M table_open_cache = 512 sort_buffer_size = 2M read_buffer_size = 2M read_rnd_buffer_size = 8M myisam_sort_buffer_size = 64M thread_cache_size = 8 query_cache_size = 32M max_connections = 1500 thread_concurrency = 48 Leonardo estou vendo com o programador da gente por o memcache pra testarmos. Você acha que se ele colocar o memcache o número de conexões na base vai cair? Você diz instalar e usar esse cara aqui? /usr/ports/databases/memcached Depois ve o que acontece, antes disso é complicado Usar php sem cache/acelerador é SUÍCIDIO, ele vai compilar o script a cada request,, e se ta dentro do apache, aparece como sendo o apache o criminoso... Por isso que é melhor usar o php fora, via fast-cgi. Usar cache pro php e memcache hoje em dia é MANDATÓRIO para qualquer setup php/mysql. Ainda mais com altissimo numero de acessos como o seu site. Faz isso cara, senao pega a 12 como ja disse , e se mata, eheheh abraco - Entao, seguindo a regra da lista de escrever a resposta NO FINAL DA THREAD Cara, depois de vc me dizer que tem tipo 4000 conexoes onde o php tem que ler coisas do mysql, desculpe o palavreado ( é em tom de brincadeira ok ) PORRRAA DO CARALHO NEM FALO MAIS, ME CALO DAQUI PRA FRENTE, SÓ VOU FALAR MAIS UMA VEZ INSTALA O MEMCACHE E UM ACELERADOR PRA PHP !! ESSA BOSTA AI VAI ATENDER 50.000 REQUESTS BRINCANDO SE FIZER CORRETAMENTE O QUE EU SUGERI ! tem trocentos tutorias na net,mas é esse port ai mesmo memcached, e tem que instalar um treco la pro php tal de pecl-memcached meu pkg_info mostra: www4# pkg_info | grep memc libmemcached-0.51 A C and C++ client library to the memcached server pecl-memcache-3.0.6 Memcached extension pecl-memcached-1.0.2 PHP extension for interfacing with memcached via libmemcach Ja te mandei ate o exemplo de como cachear as queryes do mysql no memcache e como setar o session nele tambem... PQP!!! - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
2012/7/7 Leonardo Augusto lalin...@gmail.com: 2012/7/7 Marcelo Gondim gon...@bsdinfo.com.br: Em 07/07/2012 10:26, Leonardo Augusto escreveu: Ooo ta brab Cara, ja falei, vou falar denovo: 1) INSTALA O MEMCACHE E USA PARA CACHEAR O MYSQL E O SESSION. 2) INSTALA UM APC, XCACHE DA VIDA PARA O PHP. Pessoal primeiramente umas considerações: 1º Fiz o downgrade do FreeBSD 9-STABLE para o FreeBSD 8.3-STABLE e recompilei todos os pacotes. É realmente gritante a diferença de performance!! Os loads que antes iam na casa dos 200 agora ficam em 0. , 3.0, 2.0 e olhe lá. 2º O MySQL não vai mais nas alturas em processamento fica bem baixo. 3º Descobri o causador daquele erro de criar threads (Can't create a new thread (errno 35); if you are not out of available memory, you can consult the manual for a possible OS-dependent bug) no MySQL. Eu tive que aumentar esse cara no sysctl: kern.threads.max_threads_per_proc=250 o default estava em 1500 e quando consulto: sysctl kern.threads.max_threads_hits me retorna 1982281 só não sei a causa disso ainda mas estamos indo. 4º Meu problema agora é o seguinte: Estou tendo mais de 4000 conexões no mysql devido ao announce.php que quando o site sobe ele arregaça geral ahhahah Se eu coloco 4000 conexões simultâneas o mysql automaticamente usa mais memória que eu tenho disponível. Hoje estou com 1500 conexões configuradas. Minhas configurações estão assim: skip-locking key_buffer_size = 2G max_allowed_packet = 1M table_open_cache = 512 sort_buffer_size = 2M read_buffer_size = 2M read_rnd_buffer_size = 8M myisam_sort_buffer_size = 64M thread_cache_size = 8 query_cache_size = 32M max_connections = 1500 thread_concurrency = 48 Leonardo estou vendo com o programador da gente por o memcache pra testarmos. Você acha que se ele colocar o memcache o número de conexões na base vai cair? Você diz instalar e usar esse cara aqui? /usr/ports/databases/memcached Depois ve o que acontece, antes disso é complicado Usar php sem cache/acelerador é SUÍCIDIO, ele vai compilar o script a cada request,, e se ta dentro do apache, aparece como sendo o apache o criminoso... Por isso que é melhor usar o php fora, via fast-cgi. Usar cache pro php e memcache hoje em dia é MANDATÓRIO para qualquer setup php/mysql. Ainda mais com altissimo numero de acessos como o seu site. Faz isso cara, senao pega a 12 como ja disse , e se mata, eheheh abraco - Entao, seguindo a regra da lista de escrever a resposta NO FINAL DA THREAD Cara, depois de vc me dizer que tem tipo 4000 conexoes onde o php tem que ler coisas do mysql, desculpe o palavreado ( é em tom de brincadeira ok ) PORRRAA DO CARALHO NEM FALO MAIS, ME CALO DAQUI PRA FRENTE, SÓ VOU FALAR MAIS UMA VEZ INSTALA O MEMCACHE E UM ACELERADOR PRA PHP !! ESSA BOSTA AI VAI ATENDER 50.000 REQUESTS BRINCANDO SE FIZER CORRETAMENTE O QUE EU SUGERI ! tem trocentos tutorias na net,mas é esse port ai mesmo memcached, e tem que instalar um treco la pro php tal de pecl-memcached meu pkg_info mostra: www4# pkg_info | grep memc libmemcached-0.51 A C and C++ client library to the memcached server pecl-memcache-3.0.6 Memcached extension pecl-memcached-1.0.2 PHP extension for interfacing with memcached via libmemcach Ja te mandei ate o exemplo de como cachear as queryes do mysql no memcache e como setar o session nele tambem... PQP!!! COntinuando que a porcaria do gmail dei um enter a mandou a mensagem antes do tempo. (JA TO ESTRESSADO COM ESSA NOVELA, ENTAO DESCULPEM O TOM ESCRACHADO) entao, ja te mandei ate os exemplos de como usar o memcache tanto no mysql como no session, quer que eu faca pra voce ? me da o ssh Assim cara na boa, voce devia ouvir os outros, tem um site de alto trafego, dinheiro pra investir em host e maquina e ta aperreado por IMATURIDADE do teu responsavel por infra de web. COMO JA FALEI, php/mysql hoje em dia sem memcache e acelerador, é SUICIDIO / AMADORISMO / INFANTILIDADE O FACEBOOK usa o memcache cara !!! A logica é simples, pra esses 4000 requests, é a mesma query ela fica grava num servidor socket(memcache) na ram, em vez de o mysql montar e realizar a query, vai ler UM STRINGAO direto da ram chega a ser 1000 vezes mais rapido que pegar o mysql !!1 bah to comecando a me irritar ! fala serio, pq tu nao escuta o maluco . pode tacar um 20 core com 100G de ram que teu site vai continuar um lixo ! aplicacoes web que consultam base de dados, com alto trafego, numa maquina so ?? SO FUNCIONA COM MEMCACHE, do contrario teras que montar um cluster sinistro, aí o bixo pega. tu quer por tudo numa maquina so, blz, mas tem que fazer a coisa certa. ficar aí batendo cabeca achando que a culpa é do freebsd ou
Re: [FUG-BR] Servidor com load altíssimo
Dale dale... Esse 9.0 ta uma coisa Te falei q dava certo no 8.2 :p Em 07/07/2012 11:07, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Em 07/07/2012 10:26, Leonardo Augusto escreveu: Ooo ta brab Cara, ja falei, vou falar denovo: 1) INSTALA O MEMCACHE E USA PARA CACHEAR O MYSQL E O SESSION. 2) INSTALA UM APC, XCACHE DA VIDA PARA O PHP. Pessoal primeiramente umas considerações: 1º Fiz o downgrade do FreeBSD 9-STABLE para o FreeBSD 8.3-STABLE e recompilei todos os pacotes. É realmente gritante a diferença de performance!! Os loads que antes iam na casa dos 200 agora ficam em 0. , 3.0, 2.0 e olhe lá. 2º O MySQL não vai mais nas alturas em processamento fica bem baixo. 3º Descobri o causador daquele erro de criar threads (Can't create a new thread (errno 35); if you are not out of available memory, you can consult the manual for a possible OS-dependent bug) no MySQL. Eu tive que aumentar esse cara no sysctl: kern.threads.max_threads_per_proc=250 o default estava em 1500 e quando consulto: sysctl kern.threads.max_threads_hits me retorna 1982281 só não sei a causa disso ainda mas estamos indo. 4º Meu problema agora é o seguinte: Estou tendo mais de 4000 conexões no mysql devido ao announce.php que quando o site sobe ele arregaça geral ahhahah Se eu coloco 4000 conexões simultâneas o mysql automaticamente usa mais memória que eu tenho disponível. Hoje estou com 1500 conexões configuradas. Minhas configurações estão assim: skip-locking key_buffer_size = 2G max_allowed_packet = 1M table_open_cache = 512 sort_buffer_size = 2M read_buffer_size = 2M read_rnd_buffer_size = 8M myisam_sort_buffer_size = 64M thread_cache_size = 8 query_cache_size = 32M max_connections = 1500 thread_concurrency = 48 Leonardo estou vendo com o programador da gente por o memcache pra testarmos. Você acha que se ele colocar o memcache o número de conexões na base vai cair? Você diz instalar e usar esse cara aqui? /usr/ports/databases/memcached Depois ve o que acontece, antes disso é complicado Usar php sem cache/acelerador é SUÍCIDIO, ele vai compilar o script a cada request,, e se ta dentro do apache, aparece como sendo o apache o criminoso... Por isso que é melhor usar o php fora, via fast-cgi. Usar cache pro php e memcache hoje em dia é MANDATÓRIO para qualquer setup php/mysql. Ainda mais com altissimo numero de acessos como o seu site. Faz isso cara, senao pega a 12 como ja disse , e se mata, eheheh abraco - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
Comecei lendo a thread pensando que load alto, deve algum problema de algum site grande igual ao manicomio kkk Quando você colou a mensagem de erro, dei logo um ctrl + f e procurei manicomio, e achei! kkk Po, Gondim, põe logo isso online pra eu compartilhar.. preciso acalmar as crianças aqui com os desenhos! Brincadeiras a parte, desejo toda sorte e que tudo se resolva logo! E desculpa por não poder ajudar =/ Abração. Em 6 de julho de 2012 15:25, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Em 06/07/2012 15:23, Felipe Nogueira Oliva escreveu: BJ-Share !!! Nada. Conheço eles também. Foram os primeiros à rodar. Até agora eles não voltaram. A gente até já migrou mas esse pau tá matando a gente. ahahahah Se eu não conseguir hoje resolver isso, infelizmente vou ter que jogar o Debian lá no servidor novo. :( Bem vou falar, é o manicomio-share.com ;) Em 6 de julho de 2012 15:20, Marcelo Gondim gon...@bsdinfo.com.brescreveu: Em 06/07/2012 15:07, nervoso escreveu: Mais uma Dá uma olhada no acesso aos discos. a luz de acesso ao disco tem que ficar PISCANDO e nao acesa... se estiver acesa, coloca no loader.conf a opcao: vm.kmem_size=16G (nao se esqueça das =) sendo 16G o dobro da memoria real... site de torrent mirror do TPB??? solta para nóis ai a url que o final de semana já está ai e um bom filme sempre é uma opcao... principalmente se for em portugues e dublado para as criancas... hehehe assim que estiver no ar posto aí pro pessoal. É um dos sites mais acessados e conhecidos ;) Na verdade a gente tá migrando ele da Holanda para a Russia porque fomos obrigados à deixar o Datacenter por ser um server de torrents. Na Russia só não podemos compartilhar conteúdo russo. Olha o status, mais um dado: Current Time: Friday, 06-Jul-2012 15:15:25 BRT Restart Time: Friday, 06-Jul-2012 15:14:16 BRT Parent Server Generation: 0 Server uptime: 1 minute 9 seconds Total accesses: 9468 - Total Traffic: 8.0 MB CPU Usage: u12.0781 s11.3594 cu0 cs0 - 34% CPU load 137 requests/sec - 118.0 kB/second - 880 B/request 1557 requests currently being processed, 86 idle workers WWCWWWCWWCCWCCWW W.WWWKWW_WWWK_WW _WWW_WWW_WWK_WCWW__WCWWWKWWW CWCWCWWWCWKWWWCW_WWC CW_WWCWC WW_WWC.W_WCCWWWC CCWCWWCWWWCWWC_WWWCC KWCWWKWCKWKKWWWC WWWKCW..WWWCWWWC KWWCWWWCWWW_CWK_CWWW K.W__KWWRCWWWKKWKWWK WKWWCWWWCWWWCWKCWWCW_WWWCWW_ WWWKWWWCWWWCWWCW WWKWCKWWWCCWCWWW WWWCKWWCCWWW WWCWWCWWWKWWW_CWWKKWWWCWWWCWWWKW WWWCWWWCWWWKWCWWCWW_ _KWCWW_WWWCCCWWW CWW_WKCC_WWW CCKWWCCWWKWWCWWW WCWWWKKWWWKWWCCC.WWKWKWW WWCWWCW_WWW.W_WKWWKWCCWW WWWKCWCWWCWWWKCWWWCW WWCWWC_WW.WWWCWC WWCWCWWW.CWK_W_WK_CWW_WW__WW_WWW_W__W_WW WW_WW___W___ Scoreboard Key: *|_|* Waiting for Connection, *|S|* Starting up, *|R|* Reading Request, *|W|* Sending Reply, *|K|* Keepalive (read), *|D|* DNS Lookup, *|C|* Closing connection, *|L|* Logging, *|G|* Gracefully finishing, *|I|* Idle cleanup of worker, *|.|* Open slot with no current process - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- Att, Marcus Vinicius. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
Em 07/07/2012 11:49, Leonardo Augusto escreveu: 2012/7/7 Leonardo Augusto lalin...@gmail.com: 2012/7/7 Marcelo Gondim gon...@bsdinfo.com.br: Em 07/07/2012 10:26, Leonardo Augusto escreveu: Ooo ta brab Cara, ja falei, vou falar denovo: 1) INSTALA O MEMCACHE E USA PARA CACHEAR O MYSQL E O SESSION. 2) INSTALA UM APC, XCACHE DA VIDA PARA O PHP. Pessoal primeiramente umas considerações: 1º Fiz o downgrade do FreeBSD 9-STABLE para o FreeBSD 8.3-STABLE e recompilei todos os pacotes. É realmente gritante a diferença de performance!! Os loads que antes iam na casa dos 200 agora ficam em 0. , 3.0, 2.0 e olhe lá. 2º O MySQL não vai mais nas alturas em processamento fica bem baixo. 3º Descobri o causador daquele erro de criar threads (Can't create a new thread (errno 35); if you are not out of available memory, you can consult the manual for a possible OS-dependent bug) no MySQL. Eu tive que aumentar esse cara no sysctl: kern.threads.max_threads_per_proc=250 o default estava em 1500 e quando consulto: sysctl kern.threads.max_threads_hits me retorna 1982281 só não sei a causa disso ainda mas estamos indo. 4º Meu problema agora é o seguinte: Estou tendo mais de 4000 conexões no mysql devido ao announce.php que quando o site sobe ele arregaça geral ahhahah Se eu coloco 4000 conexões simultâneas o mysql automaticamente usa mais memória que eu tenho disponível. Hoje estou com 1500 conexões configuradas. Minhas configurações estão assim: skip-locking key_buffer_size = 2G max_allowed_packet = 1M table_open_cache = 512 sort_buffer_size = 2M read_buffer_size = 2M read_rnd_buffer_size = 8M myisam_sort_buffer_size = 64M thread_cache_size = 8 query_cache_size = 32M max_connections = 1500 thread_concurrency = 48 Leonardo estou vendo com o programador da gente por o memcache pra testarmos. Você acha que se ele colocar o memcache o número de conexões na base vai cair? Você diz instalar e usar esse cara aqui? /usr/ports/databases/memcached Depois ve o que acontece, antes disso é complicado Usar php sem cache/acelerador é SUÍCIDIO, ele vai compilar o script a cada request,, e se ta dentro do apache, aparece como sendo o apache o criminoso... Por isso que é melhor usar o php fora, via fast-cgi. Usar cache pro php e memcache hoje em dia é MANDATÓRIO para qualquer setup php/mysql. Ainda mais com altissimo numero de acessos como o seu site. Faz isso cara, senao pega a 12 como ja disse , e se mata, eheheh abraco - Entao, seguindo a regra da lista de escrever a resposta NO FINAL DA THREAD Cara, depois de vc me dizer que tem tipo 4000 conexoes onde o php tem que ler coisas do mysql, desculpe o palavreado ( é em tom de brincadeira ok ) PORRRAA DO CARALHO NEM FALO MAIS, ME CALO DAQUI PRA FRENTE, SÓ VOU FALAR MAIS UMA VEZ INSTALA O MEMCACHE E UM ACELERADOR PRA PHP !! ESSA BOSTA AI VAI ATENDER 50.000 REQUESTS BRINCANDO SE FIZER CORRETAMENTE O QUE EU SUGERI ! tem trocentos tutorias na net,mas é esse port ai mesmo memcached, e tem que instalar um treco la pro php tal de pecl-memcached meu pkg_info mostra: www4# pkg_info | grep memc libmemcached-0.51 A C and C++ client library to the memcached server pecl-memcache-3.0.6 Memcached extension pecl-memcached-1.0.2 PHP extension for interfacing with memcached via libmemcach Ja te mandei ate o exemplo de como cachear as queryes do mysql no memcache e como setar o session nele tambem... PQP!!! COntinuando que a porcaria do gmail dei um enter a mandou a mensagem antes do tempo. (JA TO ESTRESSADO COM ESSA NOVELA, ENTAO DESCULPEM O TOM ESCRACHADO) Vamos lá quem tinha que estar estressado era eu e não você. No entanto estou calmo. Ainda. entao, ja te mandei ate os exemplos de como usar o memcache tanto no mysql como no session, quer que eu faca pra voce ? me da o ssh Não fiz essa mudança ainda por alguns motivos: 1º o site não é meu é desse programador burro de quem você falou. Já passei pra ele tudo que você me colocou. Mas não depende só de mim a mudança. O que ele coloca é que no Debian estava funcionando e em uma máquina inferior e com kernel generico. 2º temos pouco tempo pra por no ar e já estamos alguns dias fora. Mas estou tentando convencer eles da gente fazer o teste do memcache. Assim cara na boa, voce devia ouvir os outros, tem um site de alto trafego, dinheiro pra investir em host e maquina e ta aperreado por IMATURIDADE do teu responsavel por infra de web. Primeiro, ouvir ficaria difícil já que é uma lista mas eu leio sim e muitas das pessoas senão quase todas que me sugeriram algumas alterações eu fiz porque respeito a opinião de todos e a experiência de cada um. Nunca fui e nunca serei o dono da verdade. COMO JA FALEI, php/mysql hoje em dia sem memcache e acelerador, é SUICIDIO / AMADORISMO / INFANTILIDADE Pois é mas até hoje não
Re: [FUG-BR] Servidor com load altíssimo
Em 07/07/2012 13:45, Marcus Vinicius. escreveu: Comecei lendo a thread pensando que load alto, deve algum problema de algum site grande igual ao manicomio kkk Quando você colou a mensagem de erro, dei logo um ctrl + f e procurei manicomio, e achei! kkk Po, Gondim, põe logo isso online pra eu compartilhar.. preciso acalmar as crianças aqui com os desenhos! Brincadeiras a parte, desejo toda sorte e que tudo se resolva logo! E desculpa por não poder ajudar =/ Abração. Obrigado e vamos voltar sim. Nem que eu tenha que convencer os outros aqui à porem o tal do memcache que um estressado aqui da lista estava falando. Parece até aquelas crianças quando não tem atenção suficiente e ficam batendo o pé no chão e chorando. Po tenho 39 anos e filhos de de 4, 11 e 15 anos e nenhum deles faz isso. Bem só o de 4 anos, mas veja só tem 4 anos. :) Em 6 de julho de 2012 15:25, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Em 06/07/2012 15:23, Felipe Nogueira Oliva escreveu: BJ-Share !!! Nada. Conheço eles também. Foram os primeiros à rodar. Até agora eles não voltaram. A gente até já migrou mas esse pau tá matando a gente. ahahahah Se eu não conseguir hoje resolver isso, infelizmente vou ter que jogar o Debian lá no servidor novo. :( Bem vou falar, é o manicomio-share.com ;) Em 6 de julho de 2012 15:20, Marcelo Gondim gon...@bsdinfo.com.brescreveu: Em 06/07/2012 15:07, nervoso escreveu: Mais uma Dá uma olhada no acesso aos discos. a luz de acesso ao disco tem que ficar PISCANDO e nao acesa... se estiver acesa, coloca no loader.conf a opcao: vm.kmem_size=16G (nao se esqueça das =) sendo 16G o dobro da memoria real... site de torrent mirror do TPB??? solta para nóis ai a url que o final de semana já está ai e um bom filme sempre é uma opcao... principalmente se for em portugues e dublado para as criancas... hehehe assim que estiver no ar posto aí pro pessoal. É um dos sites mais acessados e conhecidos ;) Na verdade a gente tá migrando ele da Holanda para a Russia porque fomos obrigados à deixar o Datacenter por ser um server de torrents. Na Russia só não podemos compartilhar conteúdo russo. Olha o status, mais um dado: Current Time: Friday, 06-Jul-2012 15:15:25 BRT Restart Time: Friday, 06-Jul-2012 15:14:16 BRT Parent Server Generation: 0 Server uptime: 1 minute 9 seconds Total accesses: 9468 - Total Traffic: 8.0 MB CPU Usage: u12.0781 s11.3594 cu0 cs0 - 34% CPU load 137 requests/sec - 118.0 kB/second - 880 B/request 1557 requests currently being processed, 86 idle workers WWCWWWCWWCCWCCWW W.WWWKWW_WWWK_WW _WWW_WWW_WWK_WCWW__WCWWWKWWW CWCWCWWWCWKWWWCW_WWC CW_WWCWC WW_WWC.W_WCCWWWC CCWCWWCWWWCWWC_WWWCC KWCWWKWCKWKKWWWC WWWKCW..WWWCWWWC KWWCWWWCWWW_CWK_CWWW K.W__KWWRCWWWKKWKWWK WKWWCWWWCWWWCWKCWWCW_WWWCWW_ WWWKWWWCWWWCWWCW WWKWCKWWWCCWCWWW WWWCKWWCCWWW WWCWWCWWWKWWW_CWWKKWWWCWWWCWWWKW WWWCWWWCWWWKWCWWCWW_ _KWCWW_WWWCCCWWW CWW_WKCC_WWW CCKWWCCWWKWWCWWW WCWWWKKWWWKWWCCC.WWKWKWW WWCWWCW_WWW.W_WKWWKWCCWW WWWKCWCWWCWWWKCWWWCW WWCWWC_WW.WWWCWC WWCWCWWW.CWK_W_WK_CWW_WW__WW_WWW_W__W_WW WW_WW___W___ Scoreboard Key: *|_|* Waiting for Connection, *|S|* Starting up, *|R|* Reading Request, *|W|* Sending Reply, *|K|* Keepalive (read), *|D|* DNS Lookup, *|C|* Closing connection, *|L|* Logging, *|G|* Gracefully finishing, *|I|* Idle cleanup of worker, *|.|* Open slot with no current process - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico:
Re: [FUG-BR] Servidor com load altíssimo
Em 07/07/2012 13:30, Saul Figueiredo escreveu: Dale dale... Esse 9.0 ta uma coisa Te falei q dava certo no 8.2 :p Opa Saul não resolveu o problema não mas a diferença de performance é visível. Em 07/07/2012 11:07, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Em 07/07/2012 10:26, Leonardo Augusto escreveu: Ooo ta brab Cara, ja falei, vou falar denovo: 1) INSTALA O MEMCACHE E USA PARA CACHEAR O MYSQL E O SESSION. 2) INSTALA UM APC, XCACHE DA VIDA PARA O PHP. Pessoal primeiramente umas considerações: 1º Fiz o downgrade do FreeBSD 9-STABLE para o FreeBSD 8.3-STABLE e recompilei todos os pacotes. É realmente gritante a diferença de performance!! Os loads que antes iam na casa dos 200 agora ficam em 0. , 3.0, 2.0 e olhe lá. 2º O MySQL não vai mais nas alturas em processamento fica bem baixo. 3º Descobri o causador daquele erro de criar threads (Can't create a new thread (errno 35); if you are not out of available memory, you can consult the manual for a possible OS-dependent bug) no MySQL. Eu tive que aumentar esse cara no sysctl: kern.threads.max_threads_per_proc=250 o default estava em 1500 e quando consulto: sysctl kern.threads.max_threads_hits me retorna 1982281 só não sei a causa disso ainda mas estamos indo. 4º Meu problema agora é o seguinte: Estou tendo mais de 4000 conexões no mysql devido ao announce.php que quando o site sobe ele arregaça geral ahhahah Se eu coloco 4000 conexões simultâneas o mysql automaticamente usa mais memória que eu tenho disponível. Hoje estou com 1500 conexões configuradas. Minhas configurações estão assim: skip-locking key_buffer_size = 2G max_allowed_packet = 1M table_open_cache = 512 sort_buffer_size = 2M read_buffer_size = 2M read_rnd_buffer_size = 8M myisam_sort_buffer_size = 64M thread_cache_size = 8 query_cache_size = 32M max_connections = 1500 thread_concurrency = 48 Leonardo estou vendo com o programador da gente por o memcache pra testarmos. Você acha que se ele colocar o memcache o número de conexões na base vai cair? Você diz instalar e usar esse cara aqui? /usr/ports/databases/memcached Depois ve o que acontece, antes disso é complicado Usar php sem cache/acelerador é SUÍCIDIO, ele vai compilar o script a cada request,, e se ta dentro do apache, aparece como sendo o apache o criminoso... Por isso que é melhor usar o php fora, via fast-cgi. Usar cache pro php e memcache hoje em dia é MANDATÓRIO para qualquer setup php/mysql. Ainda mais com altissimo numero de acessos como o seu site. Faz isso cara, senao pega a 12 como ja disse , e se mata, eheheh abraco - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
Em 7 de julho de 2012 14:35, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Em 07/07/2012 13:30, Saul Figueiredo escreveu: Dale dale... Esse 9.0 ta uma coisa Te falei q dava certo no 8.2 :p Opa Saul não resolveu o problema não mas a diferença de performance é visível. Em 07/07/2012 11:07, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Em 07/07/2012 10:26, Leonardo Augusto escreveu: Ooo ta brab Cara, ja falei, vou falar denovo: 1) INSTALA O MEMCACHE E USA PARA CACHEAR O MYSQL E O SESSION. 2) INSTALA UM APC, XCACHE DA VIDA PARA O PHP. Pessoal primeiramente umas considerações: 1º Fiz o downgrade do FreeBSD 9-STABLE para o FreeBSD 8.3-STABLE e recompilei todos os pacotes. É realmente gritante a diferença de performance!! Os loads que antes iam na casa dos 200 agora ficam em 0. , 3.0, 2.0 e olhe lá. 2º O MySQL não vai mais nas alturas em processamento fica bem baixo. 3º Descobri o causador daquele erro de criar threads (Can't create a new thread (errno 35); if you are not out of available memory, you can consult the manual for a possible OS-dependent bug) no MySQL. Eu tive que aumentar esse cara no sysctl: kern.threads.max_threads_per_proc=250 o default estava em 1500 e quando consulto: sysctl kern.threads.max_threads_hits me retorna 1982281 só não sei a causa disso ainda mas estamos indo. 4º Meu problema agora é o seguinte: Estou tendo mais de 4000 conexões no mysql devido ao announce.php que quando o site sobe ele arregaça geral ahhahah Se eu coloco 4000 conexões simultâneas o mysql automaticamente usa mais memória que eu tenho disponível. Hoje estou com 1500 conexões configuradas. Minhas configurações estão assim: skip-locking key_buffer_size = 2G max_allowed_packet = 1M table_open_cache = 512 sort_buffer_size = 2M read_buffer_size = 2M read_rnd_buffer_size = 8M myisam_sort_buffer_size = 64M thread_cache_size = 8 query_cache_size = 32M max_connections = 1500 thread_concurrency = 48 Leonardo estou vendo com o programador da gente por o memcache pra testarmos. Você acha que se ele colocar o memcache o número de conexões na base vai cair? Você diz instalar e usar esse cara aqui? /usr/ports/databases/memcached Depois ve o que acontece, antes disso é complicado Usar php sem cache/acelerador é SUÍCIDIO, ele vai compilar o script a cada request,, e se ta dentro do apache, aparece como sendo o apache o criminoso... Por isso que é melhor usar o php fora, via fast-cgi. Usar cache pro php e memcache hoje em dia é MANDATÓRIO para qualquer setup php/mysql. Ainda mais com altissimo numero de acessos como o seu site. Faz isso cara, senao pega a 12 como ja disse , e se mata, eheheh abraco - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Marcelo seu servidor está usando swap ? Tive um problema assim depois de uma atualização do mysql. Na é poca fiz um downgrade de 5.5 para 5.1 e recompilei as extensões do PHP. Os sintomas eram : Carga de CPU muito alta de mysql e http e uso de muita memória, praticamente toda disponível. ( 8G de ram e mais 16G de swap ) numa máquina que só tinha esta aplicação em PHP+mysql rodando. Tem o downgrade. Ao menos veja a versão do mysql do debian e use a mesma no freebsd. -- Otavio Augusto - Consultor de TI Citius Tecnologia 31 37761866 31 88651242 http://www.citiustecnologia.com.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] Servidor com load altíssimo
Em 7 de julho de 2012 14:34, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Em 07/07/2012 13:45, Marcus Vinicius. escreveu: Comecei lendo a thread pensando que load alto, deve algum problema de algum site grande igual ao manicomio kkk Quando você colou a mensagem de erro, dei logo um ctrl + f e procurei manicomio, e achei! kkk Po, Gondim, põe logo isso online pra eu compartilhar.. preciso acalmar as crianças aqui com os desenhos! Brincadeiras a parte, desejo toda sorte e que tudo se resolva logo! E desculpa por não poder ajudar =/ Abração. Obrigado e vamos voltar sim. Nem que eu tenha que convencer os outros aqui à porem o tal do memcache que um estressado aqui da lista estava falando. Parece até aquelas crianças quando não tem atenção suficiente e ficam batendo o pé no chão e chorando. Po tenho 39 anos e filhos de de 4, 11 e 15 anos e nenhum deles faz isso. Bem só o de 4 anos, mas veja só tem 4 anos. :) Em 6 de julho de 2012 15:25, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Em 06/07/2012 15:23, Felipe Nogueira Oliva escreveu: BJ-Share !!! Nada. Conheço eles também. Foram os primeiros à rodar. Até agora eles não voltaram. A gente até já migrou mas esse pau tá matando a gente. ahahahah Se eu não conseguir hoje resolver isso, infelizmente vou ter que jogar o Debian lá no servidor novo. :( Bem vou falar, é o manicomio-share.com ;) Em 6 de julho de 2012 15:20, Marcelo Gondim gon...@bsdinfo.com.brescreveu: Em 06/07/2012 15:07, nervoso escreveu: Mais uma Dá uma olhada no acesso aos discos. a luz de acesso ao disco tem que ficar PISCANDO e nao acesa... se estiver acesa, coloca no loader.conf a opcao: vm.kmem_size=16G (nao se esqueça das =) sendo 16G o dobro da memoria real... site de torrent mirror do TPB??? solta para nóis ai a url que o final de semana já está ai e um bom filme sempre é uma opcao... principalmente se for em portugues e dublado para as criancas... hehehe assim que estiver no ar posto aí pro pessoal. É um dos sites mais acessados e conhecidos ;) Na verdade a gente tá migrando ele da Holanda para a Russia porque fomos obrigados à deixar o Datacenter por ser um server de torrents. Na Russia só não podemos compartilhar conteúdo russo. Olha o status, mais um dado: Current Time: Friday, 06-Jul-2012 15:15:25 BRT Restart Time: Friday, 06-Jul-2012 15:14:16 BRT Parent Server Generation: 0 Server uptime: 1 minute 9 seconds Total accesses: 9468 - Total Traffic: 8.0 MB CPU Usage: u12.0781 s11.3594 cu0 cs0 - 34% CPU load 137 requests/sec - 118.0 kB/second - 880 B/request 1557 requests currently being processed, 86 idle workers WWCWWWCWWCCWCCWW W.WWWKWW_WWWK_WW _WWW_WWW_WWK_WCWW__WCWWWKWWW CWCWCWWWCWKWWWCW_WWC CW_WWCWC WW_WWC.W_WCCWWWC CCWCWWCWWWCWWC_WWWCC KWCWWKWCKWKKWWWC WWWKCW..WWWCWWWC KWWCWWWCWWW_CWK_CWWW K.W__KWWRCWWWKKWKWWK WKWWCWWWCWWWCWKCWWCW_WWWCWW_ WWWKWWWCWWWCWWCW WWKWCKWWWCCWCWWW WWWCKWWCCWWW WWCWWCWWWKWWW_CWWKKWWWCWWWCWWWKW WWWCWWWCWWWKWCWWCWW_ _KWCWW_WWWCCCWWW CWW_WKCC_WWW CCKWWCCWWKWWCWWW WCWWWKKWWWKWWCCC.WWKWKWW WWCWWCW_WWW.W_WKWWKWCCWW WWWKCWCWWCWWWKCWWWCW WWCWWC_WW.WWWCWC WWCWCWWW.CWK_W_WK_CWW_WW__WW_WWW_W__W_WW WW_WW___W___ Scoreboard Key: *|_|* Waiting for Connection, *|S|* Starting up, *|R|* Reading Request, *|W|* Sending Reply, *|K|* Keepalive (read), *|D|* DNS Lookup, *|C|* Closing connection, *|L|* Logging, *|G|* Gracefully finishing, *|I|* Idle cleanup of worker, *|.|* Open slot with no current process - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista:
Re: [FUG-BR] Servidor com load altíssimo
Em 07/07/2012 14:45, Otavio Augusto escreveu: Em 7 de julho de 2012 14:35, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Em 07/07/2012 13:30, Saul Figueiredo escreveu: Dale dale... Esse 9.0 ta uma coisa Te falei q dava certo no 8.2 :p Opa Saul não resolveu o problema não mas a diferença de performance é visível. Em 07/07/2012 11:07, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Em 07/07/2012 10:26, Leonardo Augusto escreveu: Ooo ta brab Cara, ja falei, vou falar denovo: 1) INSTALA O MEMCACHE E USA PARA CACHEAR O MYSQL E O SESSION. 2) INSTALA UM APC, XCACHE DA VIDA PARA O PHP. Pessoal primeiramente umas considerações: 1º Fiz o downgrade do FreeBSD 9-STABLE para o FreeBSD 8.3-STABLE e recompilei todos os pacotes. É realmente gritante a diferença de performance!! Os loads que antes iam na casa dos 200 agora ficam em 0. , 3.0, 2.0 e olhe lá. 2º O MySQL não vai mais nas alturas em processamento fica bem baixo. 3º Descobri o causador daquele erro de criar threads (Can't create a new thread (errno 35); if you are not out of available memory, you can consult the manual for a possible OS-dependent bug) no MySQL. Eu tive que aumentar esse cara no sysctl: kern.threads.max_threads_per_proc=250 o default estava em 1500 e quando consulto: sysctl kern.threads.max_threads_hits me retorna 1982281 só não sei a causa disso ainda mas estamos indo. 4º Meu problema agora é o seguinte: Estou tendo mais de 4000 conexões no mysql devido ao announce.php que quando o site sobe ele arregaça geral ahhahah Se eu coloco 4000 conexões simultâneas o mysql automaticamente usa mais memória que eu tenho disponível. Hoje estou com 1500 conexões configuradas. Minhas configurações estão assim: skip-locking key_buffer_size = 2G max_allowed_packet = 1M table_open_cache = 512 sort_buffer_size = 2M read_buffer_size = 2M read_rnd_buffer_size = 8M myisam_sort_buffer_size = 64M thread_cache_size = 8 query_cache_size = 32M max_connections = 1500 thread_concurrency = 48 Leonardo estou vendo com o programador da gente por o memcache pra testarmos. Você acha que se ele colocar o memcache o número de conexões na base vai cair? Você diz instalar e usar esse cara aqui? /usr/ports/databases/memcached Depois ve o que acontece, antes disso é complicado Usar php sem cache/acelerador é SUÍCIDIO, ele vai compilar o script a cada request,, e se ta dentro do apache, aparece como sendo o apache o criminoso... Por isso que é melhor usar o php fora, via fast-cgi. Usar cache pro php e memcache hoje em dia é MANDATÓRIO para qualquer setup php/mysql. Ainda mais com altissimo numero de acessos como o seu site. Faz isso cara, senao pega a 12 como ja disse , e se mata, eheheh abraco - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Marcelo seu servidor está usando swap ? Tive um problema assim depois de uma atualização do mysql. Na é poca fiz um downgrade de 5.5 para 5.1 e recompilei as extensões do PHP. Os sintomas eram : Carga de CPU muito alta de mysql e http e uso de muita memória, praticamente toda disponível. ( 8G de ram e mais 16G de swap ) numa máquina que só tinha esta aplicação em PHP+mysql rodando. Tem o downgrade. Ao menos veja a versão do mysql do debian e use a mesma no freebsd. Tá não o swap tá zeradinho: root@ms:~# swapinfo Device 1K-blocks UsedAvail Capacity /dev/zvol/zroot/swap 41943040 4194304 0% Eu acredito que realmente a solução seja mexer na aplicação e usar recursos como o memcache já mencionado aqui. O que fiquei sabendo ainda agora é que eles usaram memcache no passado e não foi esse ganho todo e que eles mudaram pra outro tipo de cache. Mas não sei também se fizeram certo porque não participei dessa alteração. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
Em 07/07/2012 14:46, Marcus Vinicius. escreveu: Em 7 de julho de 2012 14:34, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Em 07/07/2012 13:45, Marcus Vinicius. escreveu: Comecei lendo a thread pensando que load alto, deve algum problema de algum site grande igual ao manicomio kkk Quando você colou a mensagem de erro, dei logo um ctrl + f e procurei manicomio, e achei! kkk Po, Gondim, põe logo isso online pra eu compartilhar.. preciso acalmar as crianças aqui com os desenhos! Brincadeiras a parte, desejo toda sorte e que tudo se resolva logo! E desculpa por não poder ajudar =/ Abração. Obrigado e vamos voltar sim. Nem que eu tenha que convencer os outros aqui à porem o tal do memcache que um estressado aqui da lista estava falando. Parece até aquelas crianças quando não tem atenção suficiente e ficam batendo o pé no chão e chorando. Po tenho 39 anos e filhos de de 4, 11 e 15 anos e nenhum deles faz isso. Bem só o de 4 anos, mas veja só tem 4 anos. :) Em 6 de julho de 2012 15:25, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Em 06/07/2012 15:23, Felipe Nogueira Oliva escreveu: BJ-Share !!! Nada. Conheço eles também. Foram os primeiros à rodar. Até agora eles não voltaram. A gente até já migrou mas esse pau tá matando a gente. ahahahah Se eu não conseguir hoje resolver isso, infelizmente vou ter que jogar o Debian lá no servidor novo. :( Bem vou falar, é o manicomio-share.com ;) Em 6 de julho de 2012 15:20, Marcelo Gondim gon...@bsdinfo.com.brescreveu: Em 06/07/2012 15:07, nervoso escreveu: Mais uma Dá uma olhada no acesso aos discos. a luz de acesso ao disco tem que ficar PISCANDO e nao acesa... se estiver acesa, coloca no loader.conf a opcao: vm.kmem_size=16G (nao se esqueça das =) sendo 16G o dobro da memoria real... site de torrent mirror do TPB??? solta para nóis ai a url que o final de semana já está ai e um bom filme sempre é uma opcao... principalmente se for em portugues e dublado para as criancas... hehehe assim que estiver no ar posto aí pro pessoal. É um dos sites mais acessados e conhecidos ;) Na verdade a gente tá migrando ele da Holanda para a Russia porque fomos obrigados à deixar o Datacenter por ser um server de torrents. Na Russia só não podemos compartilhar conteúdo russo. Olha o status, mais um dado: Current Time: Friday, 06-Jul-2012 15:15:25 BRT Restart Time: Friday, 06-Jul-2012 15:14:16 BRT Parent Server Generation: 0 Server uptime: 1 minute 9 seconds Total accesses: 9468 - Total Traffic: 8.0 MB CPU Usage: u12.0781 s11.3594 cu0 cs0 - 34% CPU load 137 requests/sec - 118.0 kB/second - 880 B/request 1557 requests currently being processed, 86 idle workers WWCWWWCWWCCWCCWW W.WWWKWW_WWWK_WW _WWW_WWW_WWK_WCWW__WCWWWKWWW CWCWCWWWCWKWWWCW_WWC CW_WWCWC WW_WWC.W_WCCWWWC CCWCWWCWWWCWWC_WWWCC KWCWWKWCKWKKWWWC WWWKCW..WWWCWWWC KWWCWWWCWWW_CWK_CWWW K.W__KWWRCWWWKKWKWWK WKWWCWWWCWWWCWKCWWCW_WWWCWW_ WWWKWWWCWWWCWWCW WWKWCKWWWCCWCWWW WWWCKWWCCWWW WWCWWCWWWKWWW_CWWKKWWWCWWWCWWWKW WWWCWWWCWWWKWCWWCWW_ _KWCWW_WWWCCCWWW CWW_WKCC_WWW CCKWWCCWWKWWCWWW WCWWWKKWWWKWWCCC.WWKWKWW WWCWWCW_WWW.W_WKWWKWCCWW WWWKCWCWWCWWWKCWWWCW WWCWWC_WW.WWWCWC WWCWCWWW.CWK_W_WK_CWW_WW__WW_WWW_W__W_WW WW_WW___W___ Scoreboard Key: *|_|* Waiting for Connection, *|S|* Starting up, *|R|* Reading Request, *|W|* Sending Reply, *|K|* Keepalive (read), *|D|* DNS Lookup, *|C|* Closing connection, *|L|* Logging, *|G|* Gracefully finishing, *|I|* Idle cleanup of worker, *|.|* Open slot with no current process - Histórico:
Re: [FUG-BR] Servidor com load altíssimo
hehe cara nao to estressado com isso nao, é so o jeito de falar mesmo, tudo ironia, leve pra esse lado. e meus pesames se vc ainda tem que convencer alguem a usar o memcache. e quando a intencao é nobre, a grossura é doçura. tudo que eu disse esta contextualizado em te ajudar, agora se vc ficou nervoso com a maneir Em 07/07/2012 11:49, Leonardo Augusto escreveu: 2012/7/7 Leonardo Augusto lalin...@gmail.com: 2012/7/7 Marcelo Gondim gon...@bsdinfo.com.br: Em 07/07/2012 10:26, Leonardo Augusto escreveu: Ooo ta brab Cara, ja falei, vou falar denovo: 1) INSTALA O MEMCACHE E USA PARA CACHEAR O MYSQL E O SESSION. 2) INSTALA UM APC, XCACHE DA VIDA PARA O PHP. Pessoal primeiramente umas considerações: 1º Fiz o downgrade do FreeBSD 9-STABLE para o FreeBSD 8.3-STABLE e recompilei todos os pacotes. É realmente gritante a diferença de performance!! Os loads que antes iam na casa dos 200 agora ficam em 0. , 3.0, 2.0 e olhe lá. 2º O MySQL não vai mais nas alturas em processamento fica bem baixo. 3º Descobri o causador daquele erro de criar threads (Can't create a new thread (errno 35); if you are not out of available memory, you can consult the manual for a possible OS-dependent bug) no MySQL. Eu tive que aumentar esse cara no sysctl: kern.threads.max_threads_per_proc=250 o default estava em 1500 e quando consulto: sysctl kern.threads.max_threads_hits me retorna 1982281 só não sei a causa disso ainda mas estamos indo. 4º Meu problema agora é o seguinte: Estou tendo mais de 4000 conexões no mysql devido ao announce.php que quando o site sobe ele arregaça geral ahhahah Se eu coloco 4000 conexões simultâneas o mysql automaticamente usa mais memória que eu tenho disponível. Hoje estou com 1500 conexões configuradas. Minhas configurações estão assim: skip-locking key_buffer_size = 2G max_allowed_packet = 1M table_open_cache = 512 sort_buffer_size = 2M read_buffer_size = 2M read_rnd_buffer_size = 8M myisam_sort_buffer_size = 64M thread_cache_size = 8 query_cache_size = 32M max_connections = 1500 thread_concurrency = 48 Leonardo estou vendo com o programador da gente por o memcache pra testarmos. Você acha que se ele colocar o memcache o número de conexões na base vai cair? Você diz instalar e usar esse cara aqui? /usr/ports/databases/memcached Depois ve o que acontece, antes disso é complicado Usar php sem cache/acelerador é SUÍCIDIO, ele vai compilar o script a cada request,, e se ta dentro do apache, aparece como sendo o apache o criminoso... Por isso que é melhor usar o php fora, via fast-cgi. Usar cache pro php e memcache hoje em dia é MANDATÓRIO para qualquer setup php/mysql. Ainda mais com altissimo numero de acessos como o seu site. Faz isso cara, senao pega a 12 como ja disse , e se mata, eheheh abraco - Entao, seguindo a regra da lista de escrever a resposta NO FINAL DA THREAD Cara, depois de vc me dizer que tem tipo 4000 conexoes onde o php tem que ler coisas do mysql, desculpe o palavreado ( é em tom de brincadeira ok ) PORRRAA DO CARALHO NEM FALO MAIS, ME CALO DAQUI PRA FRENTE, SÓ VOU FALAR MAIS UMA VEZ INSTALA O MEMCACHE E UM ACELERADOR PRA PHP !! ESSA BOSTA AI VAI ATENDER 50.000 REQUESTS BRINCANDO SE FIZER CORRETAMENTE O QUE EU SUGERI ! tem trocentos tutorias na net,mas é esse port ai mesmo memcached, e tem que instalar um treco la pro php tal de pecl-memcached meu pkg_info mostra: www4# pkg_info | grep memc libmemcached-0.51 A C and C++ client library to the memcached server pecl-memcache-3.0.6 Memcached extension pecl-memcached-1.0.2 PHP extension for interfacing with memcached via libmemcach Ja te mandei ate o exemplo de como cachear as queryes do mysql no memcache e como setar o session nele tambem... PQP!!! COntinuando que a porcaria do gmail dei um enter a mandou a mensagem antes do tempo. (JA TO ESTRESSADO COM ESSA NOVELA, ENTAO DESCULPEM O TOM ESCRACHADO) Vamos lá quem tinha que estar estressado era eu e não você. No entanto estou calmo. Ainda. entao, ja te mandei ate os exemplos de como usar o memcache tanto no mysql como no session, quer que eu faca pra voce ? me da o ssh Não fiz essa mudança ainda por alguns motivos: 1º o site não é meu é desse programador burro de quem você falou. Já passei pra ele tudo que você me colocou. Mas não depende só de mim a mudança. O que ele coloca é que no Debian estava funcionando e em uma máquina inferior e com kernel generico. 2º temos pouco tempo pra por no ar e já estamos alguns dias fora. Mas estou tentando convencer eles da gente fazer o teste do memcache. Assim cara na boa, voce devia ouvir os outros, tem um site de alto trafego, dinheiro pra investir em host e maquina e ta aperreado por IMATURIDADE do
Re: [FUG-BR] Servidor com load altíssimo
Em 07/07/12, Marcelo Gondimgon...@bsdinfo.com.br escreveu: Em 07/07/2012 13:30, Saul Figueiredo escreveu: Dale dale... Esse 9.0 ta uma coisa Te falei q dava certo no 8.2 :p Emergencialmente falando, consegue deixar os 2 servers funcionando? Usa inicialmente apenas o mysql do SO anterior enquanto ajusta o mysql do FreeBSD. -- Wenderson Souza - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
falándo serio agora, essa nada de tablet envia mingas msgs pela metade. ja entendi que a culpa nao e sua, o freebsd tem varios tunings a fazer tb para funcionar com high load, tcp, filesystem, etc. o linux talvez funcionasse pq ja tava com memcache ou algo do tipo pordefault, pq la ele instala os pacotes tudo pro cara e a coisa toda ja e feita pra funcionar bem, pq ninguem la recompila kernel e packages. pois e impossivel linux ser melhor que freebsd no mesmo hardware, tudo configutado certo. nunca foi, nunca vai ser. mais uma coisa que denota ser problema de setup. e assim cara, eu to a 1 mes de cama com hernia de disco esperando uma briga na justica pro plano aprovar a cirurgia, to chapado de tylex, tramal e lyrica pra suportar a dor, to num tablet enviando essas msgs pra tentar ajudar, nao leve pro lado pessoal meus comentarios, tudo isso que digo: dar cabecada na parede, tiro de 12, se matar e afins, sao justamente pra descontrair, mas vc nao pode ler achando que é pessoal ou coisa do tipo, aí vc vai se sentir ofendido, de longe quis fazer tal coisa. os exageros sao pra chamar a atencao, so isso. quando o iradofuriosocomtudo(que deus o tenha) me ajudava, a gente sempre falava assim, e ria que se mijava. pior que to vendo que os caras la vao acabar botando a culpa disso tudo em vc por estar usando bsd. vao dizer assim: ta vendo, se fosse linux funcionava, kkk pega uma 12 dai e arranca a cabeca deles. se eu pudesse me sentar pra usar um console, eu resolvia o teu problema, tu me dava um jail nessa maquina e no maximo em 2h eu instalava tudo tunado, e colocava 2 script php acessando o mysql, um com e o outro sem memcache/apc para vc mostrar pros cabeca de porongo que isso faz toda a diferenca. (lol) e relaxa cara, nao leva pro lado pessoal, vc tb ja le com angustia pq ja ta estressado, ai tudo parece agressivo, entendo. depois que resolver tudo e ler os emails desde o comeco, vai achar engracado, pois vai ver que no comeco eu tava bem normal, depois fui avacalhando pq vi que testavam 200 coisas e nada de memcache, hehe bom se precisar de help com o memcache avisa, usar o fastcgi, tirar o php do apache e uma boa tambem, ideal e tu criar uns jails pra testar(ezjail) leonardo - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
essa historia de ja ter usado memcache e nao ter feito diferenca, so prova que os caras nao sabem usar ou nao usaram direito. eu tinha um server com 4 cpus onde o mysql estava em 220%, isso mesmo, ocupava 2 cpu e pouco, apos o memcache ser usado, caiu pra menos de 17%, isso quando ele da as caras no top, e o memcache nem a 20% chega, isso foi a 4 anos e ainda nao mudei o hardware. ainda é um bsd 7.2, era um 6.1 que foi atualizado o memcache so nao faria muita diferenca se fosse uma tabela myisam toda em ram sem joins e sem nenhuma funcao executada no select como date_format por exemplo. do contrario, algum mau uso esta sendo feito. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
Em 07/07/2012 15:37, Leonardo Augusto escreveu: falándo serio agora, essa nada de tablet envia mingas msgs pela metade. ja entendi que a culpa nao e sua, o freebsd tem varios tunings a fazer tb para funcionar com high load, tcp, filesystem, etc. o linux talvez funcionasse pq ja tava com memcache ou algo do tipo pordefault, pq la ele instala os pacotes tudo pro cara e a coisa toda ja e feita pra funcionar bem, pq ninguem la recompila kernel e packages. pois e impossivel linux ser melhor que freebsd no mesmo hardware, tudo configutado certo. nunca foi, nunca vai ser. mais uma coisa que denota ser problema de setup. e assim cara, eu to a 1 mes de cama com hernia de disco esperando uma briga na justica pro plano aprovar a cirurgia, to chapado de tylex, tramal e lyrica pra suportar a dor, to num tablet enviando essas msgs pra tentar ajudar, nao leve pro lado pessoal meus comentarios, tudo isso que digo: dar cabecada na parede, tiro de 12, se matar e afins, sao justamente pra descontrair, mas vc nao pode ler achando que é pessoal ou coisa do tipo, aí vc vai se sentir ofendido, de longe quis fazer tal coisa. os exageros sao pra chamar a atencao, so isso. quando o iradofuriosocomtudo(que deus o tenha) me ajudava, a gente sempre falava assim, e ria que se mijava. pior que to vendo que os caras la vao acabar botando a culpa disso tudo em vc por estar usando bsd. vao dizer assim: ta vendo, se fosse linux funcionava, kkk pega uma 12 dai e arranca a cabeca deles. se eu pudesse me sentar pra usar um console, eu resolvia o teu problema, tu me dava um jail nessa maquina e no maximo em 2h eu instalava tudo tunado, e colocava 2 script php acessando o mysql, um com e o outro sem memcache/apc para vc mostrar pros cabeca de porongo que isso faz toda a diferenca. (lol) e relaxa cara, nao leva pro lado pessoal, vc tb ja le com angustia pq ja ta estressado, ai tudo parece agressivo, entendo. depois que resolver tudo e ler os emails desde o comeco, vai achar engracado, pois vai ver que no comeco eu tava bem normal, depois fui avacalhando pq vi que testavam 200 coisas e nada de memcache, hehe bom se precisar de help com o memcache avisa, usar o fastcgi, tirar o php do apache e uma boa tambem, ideal e tu criar uns jails pra testar(ezjail) Eu concordo contigo, também acho que vai resolver mas tipo o programador me respondeu isso saca só: - nao tem como colocar cache em update e insert e nem em delete Mas tranquilo, mais pra frente vamos alugar uma outra máquina pra gente colocar com calma e deixar tudo redondo. Se quiser ajudar eu te mando uma mensagem em pvt. :) E tipo melhoras aí pra ti e não fiquei chateado não. Só um pouco, rsrsrsr mas agora vejo que foi só zoação :D Vou tentar fazer isso que você passou num outro servidor pra ver as melhorias, lá o programador eu mando ahahahahah - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
ah o site tem mais update/insert/delete do que select ? estranho isso... nesse caso o memcache nao ajuda mesmo. usa myisam ou innodb? o que o status do mysql diz? tem como mandar o status que o phpmyadmin mostra? pra ver o rate disso? no caso de inserts e afins, tem muita coisa que pode inluenciar, raid zero e uma delas, raid zero so presta pra read, melhor um raid 10 ou 5, o ideal pra read e write acho que e o 10. qual o cache da controladora? ta muito estranho esse papo do cabeça de bagre que o xabu ta nos inserts, kozada isso, pede o status do mysql pra gente ver. e pq o site tem tanto insert? ele loga cada acesso no mysql? - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
Em 07/07/2012 16:10, Leonardo Augusto escreveu: ah o site tem mais update/insert/delete do que select ? estranho isso... nesse caso o memcache nao ajuda mesmo. usa myisam ou innodb? Opa Leonardo, Sim foi isso que ele me disse, tem mais update/insert/delete. Quando carrega o tal announce.php que começa os updates e tal aí a coisa começa à ficar preta. :) O announce é aquele cara que coleta e atualiza quem tá compartilhando os torrents se eu não estou enganado rsrsrs o que o status do mysql diz? tem como mandar o status que o phpmyadmin mostra? pra ver o rate disso? eu vou pedir pra ele habilitar o announce novamente e aí coleto isso pra passar aqui. no caso de inserts e afins, tem muita coisa que pode inluenciar, raid zero e uma delas, raid zero so presta pra read, melhor um raid 10 ou 5, o ideal pra read e write acho que e o 10. qual o cache da controladora? É tá com raid 0 da própria controladora SAS. São 4 discos SAS de 147Gb em raid 0 ta muito estranho esse papo do cabeça de bagre que o xabu ta nos inserts, kozada isso, pede o status do mysql pra gente ver. e pq o site tem tanto insert? ele loga cada acesso no mysql? Uma coisa que reparei. Quando liga o announce pelo mytop dá pra ver uma enxurrada de inserts e updates e tipo o número de conexões com o mysql sobe rapidamente e passa dos 4000. Levando em conta que o announce está ligado aos torrents e temos 500mil peers. é gente pacas. rsrsrsr - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
Ummm se tem um loop no php com select todos peers e update pra cad um seus seguidores ou coisa do tipo, complica se, esse anunce e chamado a cada requisicao? Ou esta no crontab? Se for a cada request clacla bum tiro de 12 no php man, Pergunta qual a condicao que dispara esse anince e tambem o que ele faz no banco com mais detalnes, talvez tenja que mudar essa logica, tem caminhos pra isso. O que nao pode e fazer uma atyalizacao geral a cada loco qud entra, pq entram 3 vai rodar em paralelo isso tudo e detona mesmo, tem que ser um processo unico pra isso Em 07/07/2012 19:18, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Em 07/07/2012 16:10, Leonardo Augusto escreveu: ah o site tem mais update/insert/delete do que select ? estranho isso... nesse caso o memcache nao ajuda mesmo. usa myisam ou innodb? Opa Leonardo, Sim foi isso que ele me disse, tem mais update/insert/delete. Quando carrega o tal announce.php que começa os updates e tal aí a coisa começa à ficar preta. :) O announce é aquele cara que coleta e atualiza quem tá compartilhando os torrents se eu não estou enganado rsrsrs o que o status do mysql diz? tem como mandar o status que o phpmyadmin mostra? pra ver o rate disso? eu vou pedir pra ele habilitar o announce novamente e aí coleto isso pra passar aqui. no caso de inserts e afins, tem muita coisa que pode inluenciar, raid zero e uma delas, raid zero so presta pra read, melhor um raid 10 ou 5, o ideal pra read e write acho que e o 10. qual o cache da controladora? É tá com raid 0 da própria controladora SAS. São 4 discos SAS de 147Gb em raid 0 ta muito estranho esse papo do cabeça de bagre que o xabu ta nos inserts, kozada isso, pede o status do mysql pra gente ver. e pq o site tem tanto insert? ele loga cada acesso no mysql? Uma coisa que reparei. Quando liga o announce pelo mytop dá pra ver uma enxurrada de inserts e updates e tipo o número de conexões com o mysql sobe rapidamente e passa dos 4000. Levando em conta que o announce está ligado aos torrents e temos 500mil peers. é gente pacas. rsrsrsr - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
Em 7 de julho de 2012 20:14, Leonardo Augusto lalin...@gmail.com escreveu: Ummm se tem um loop no php com select todos peers e update pra cad um seus seguidores ou coisa do tipo, complica se, esse anunce e chamado a cada requisicao? Ou esta no crontab? Se for a cada request clacla bum tiro de 12 no php man, Pergunta qual a condicao que dispara esse anince e tambem o que ele faz no banco com mais detalnes, talvez tenja que mudar essa logica, tem caminhos pra isso. O que nao pode e fazer uma atyalizacao geral a cada loco qud entra, pq entram 3 vai rodar em paralelo isso tudo e detona mesmo, tem que ser um processo unico pra isso Em 07/07/2012 19:18, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Em 07/07/2012 16:10, Leonardo Augusto escreveu: ah o site tem mais update/insert/delete do que select ? estranho isso... nesse caso o memcache nao ajuda mesmo. usa myisam ou innodb? Opa Leonardo, Sim foi isso que ele me disse, tem mais update/insert/delete. Quando carrega o tal announce.php que começa os updates e tal aí a coisa começa à ficar preta. :) O announce é aquele cara que coleta e atualiza quem tá compartilhando os torrents se eu não estou enganado rsrsrs o que o status do mysql diz? tem como mandar o status que o phpmyadmin mostra? pra ver o rate disso? eu vou pedir pra ele habilitar o announce novamente e aí coleto isso pra passar aqui. no caso de inserts e afins, tem muita coisa que pode inluenciar, raid zero e uma delas, raid zero so presta pra read, melhor um raid 10 ou 5, o ideal pra read e write acho que e o 10. qual o cache da controladora? É tá com raid 0 da própria controladora SAS. São 4 discos SAS de 147Gb em raid 0 ta muito estranho esse papo do cabeça de bagre que o xabu ta nos inserts, kozada isso, pede o status do mysql pra gente ver. e pq o site tem tanto insert? ele loga cada acesso no mysql? Uma coisa que reparei. Quando liga o announce pelo mytop dá pra ver uma enxurrada de inserts e updates e tipo o número de conexões com o mysql sobe rapidamente e passa dos 4000. Levando em conta que o announce está ligado aos torrents e temos 500mil peers. é gente pacas. rsrsrsr - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Por mais que a lógica do php esteja ferrada e as queries completamente bichadas não há como justificar que essa mesma bosta funcionava no GNU/Linux e não dá nem pro gasto no BSD. Já testou portar para o windows server? :P -- Ricardo Carlini Sperandio Analista/Consultor Linux Sênior LPIC-3 Connectcom - GISUT / CEF GEDEL: Grupo Especializado em Desenvolvimento Linux VIPLAB/PUC-MG mestrando em informática DCC/UFMG - Bacharel em Ciência da Computação Computers are like air conditioners. They don't work when you open Windows. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
Em 07/07/2012 15:13, Wenderson Souza escreveu: Em 07/07/12, Marcelo Gondimgon...@bsdinfo.com.br escreveu: Em 07/07/2012 13:30, Saul Figueiredo escreveu: Dale dale... Esse 9.0 ta uma coisa Te falei q dava certo no 8.2 :p Emergencialmente falando, consegue deixar os 2 servers funcionando? Usa inicialmente apenas o mysql do SO anterior enquanto ajusta o mysql do FreeBSD. Ummm acho difícil porque aí nesse caso deveríamos ter pego 2 servidores de menor capacidade e interligar eles. Mas entendi a idéia e não seria ruim não. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
Em 07/07/2012 20:14, Leonardo Augusto escreveu: Ummm se tem um loop no php com select todos peers e update pra cad um seus seguidores ou coisa do tipo, complica se, esse anunce e chamado a cada requisicao? Ou esta no crontab? Se for a cada request clacla bum tiro de 12 no php man, Pergunta qual a condicao que dispara esse anince e tambem o que ele faz no banco com mais detalnes, talvez tenja que mudar essa logica, tem caminhos pra isso. O que nao pode e fazer uma atyalizacao geral a cada loco qud entra, pq entram 3 vai rodar em paralelo isso tudo e detona mesmo, tem que ser um processo unico pra isso Vou pegar com ele o esquema como acontece certinho pra te dizer Em 07/07/2012 19:18, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Em 07/07/2012 16:10, Leonardo Augusto escreveu: ah o site tem mais update/insert/delete do que select ? estranho isso... nesse caso o memcache nao ajuda mesmo. usa myisam ou innodb? Opa Leonardo, Sim foi isso que ele me disse, tem mais update/insert/delete. Quando carrega o tal announce.php que começa os updates e tal aí a coisa começa à ficar preta. :) O announce é aquele cara que coleta e atualiza quem tá compartilhando os torrents se eu não estou enganado rsrsrs o que o status do mysql diz? tem como mandar o status que o phpmyadmin mostra? pra ver o rate disso? eu vou pedir pra ele habilitar o announce novamente e aí coleto isso pra passar aqui. no caso de inserts e afins, tem muita coisa que pode inluenciar, raid zero e uma delas, raid zero so presta pra read, melhor um raid 10 ou 5, o ideal pra read e write acho que e o 10. qual o cache da controladora? É tá com raid 0 da própria controladora SAS. São 4 discos SAS de 147Gb em raid 0 ta muito estranho esse papo do cabeça de bagre que o xabu ta nos inserts, kozada isso, pede o status do mysql pra gente ver. e pq o site tem tanto insert? ele loga cada acesso no mysql? Uma coisa que reparei. Quando liga o announce pelo mytop dá pra ver uma enxurrada de inserts e updates e tipo o número de conexões com o mysql sobe rapidamente e passa dos 4000. Levando em conta que o announce está ligado aos torrents e temos 500mil peers. é gente pacas. rsrsrsr - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
Ok.. eu tentaria, na sequencia. 1) pkg_delete -a 2) portsnap fetch extract 3) cd /usr/ports/ports-mgmt/portmaster 4) make install clean 5) portmaster shells/bash www/apache22 lang/php5-extensions 6) editar arquivos de configureacao de boot/runtime = /etc/sysctl,conf e /boot/loader.conf 7) reboot comentarios: pkg_delete -a REMOVE TODOS OS PACKAGES Parece ser um problema de thread (lock...) eu colocaria no kernel (no source... as opcoes: options NO_ADAPTIVE_MUTEXES e construiria um kernel a partir dai... recompilando o software na maquina que esta rodando, faz com que o sistema compile com as opcoes certas do sistema operacional em uma maquina destas, vai demora uns 20 minutos... Preste atencao as opcoes que o portmaster vai pedindo a media que configura o sistema.. configure sómente o necessário Veja no sistema operacional se nao falta semaforos, ou shared memory no meu sysctl.conf está assim: kern.ipc.shmmax=4294967296 kern.ipc.shmall=1048576 kern.maxfiles=12 == no loader.conf. kern.ipc.semmap= 256 kern.ipc.shmmni=1024 kern.ipc.semmni=1024 kern.ipc.semmns= 10240 kern.ipc.semmnu= 4800 kern.ipc.semmsl= 256 kern.ipc.semume= 128 vfs.zfs.prefetch_disable=1 === Atente para o fato tb que eu desligaria o read ahead do ZFS... (sysctl.conf, opcao vfs.zfs.prefetch_disable=1) espero que ajude... - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
Em 06/07/2012 03:27, nervoso escreveu: Ok.. eu tentaria, na sequencia. 1) pkg_delete -a 2) portsnap fetch extract 3) cd /usr/ports/ports-mgmt/portmaster Opa já uso o portmaster :) 4) make install clean 5) portmaster shells/bash www/apache22 lang/php5-extensions 6) editar arquivos de configureacao de boot/runtime = /etc/sysctl,conf e /boot/loader.conf 7) reboot comentarios: pkg_delete -a REMOVE TODOS OS PACKAGES Parece ser um problema de thread (lock...) eu colocaria no kernel (no source... as opcoes: options NO_ADAPTIVE_MUTEXES Perfeito vou tentar com essa opção. e construiria um kernel a partir dai... recompilando o software na maquina que esta rodando, faz com que o sistema compile com as opcoes certas do sistema operacional Eu instalei via ports mesmo não usei os binários não. :) Mas vou refazer e dar mais uma secada nos pacotes. em uma maquina destas, vai demora uns 20 minutos... Preste atencao as opcoes que o portmaster vai pedindo a media que configura o sistema.. configure sómente o necessário Isso vou dar mais uma secada aqui. Veja no sistema operacional se nao falta semaforos, ou shared memory no meu sysctl.conf está assim: kern.ipc.shmmax=4294967296 kern.ipc.shmall=1048576 kern.maxfiles=12 No meu estava assim: kern.ipc.somaxconn=10240 net.inet.tcp.msl=3000 net.inet.icmp.icmplim=0 net.inet.icmp.icmplim_output=0 kern.dirdelay=6 kern.metadelay=5 kern.filedelay=7 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.ip.forwarding=0 net.inet.ip.fastforwarding=0 vfs.zfs.prefetch_disable=1 == no loader.conf. kern.ipc.semmap= 256 kern.ipc.shmmni=1024 kern.ipc.semmni=1024 kern.ipc.semmns= 10240 kern.ipc.semmnu= 4800 kern.ipc.semmsl= 256 kern.ipc.semume= 128 vfs.zfs.prefetch_disable=1 O meu está assim: zfs_load=YES vfs.root.mountfrom=zfs:zroot vfs.zfs.prefetch_disable=1 vfs.zfs.txg.timeout=5 kern.ipc.shmmaxpgs=65536 kern.ipc.semmni=315 kern.ipc.semmns=240 kern.ipc.semume=315 kern.ipc.semmnu=120 kern.maxusers=1024 === Atente para o fato tb que eu desligaria o read ahead do ZFS... (sysctl.conf, opcao vfs.zfs.prefetch_disable=1) Fiz também :) fazia parte do tunning do ZFS. espero que ajude... Nervoso, mesmo que não funcione a sua ajuda já valeu só pela troca de conhecimento. :) Muito obrigado e depois posto aqui os resultados. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
Em 5 de julho de 2012 23:14, Marcelo Gondim gon...@bsdinfo.com.brescreveu: Olá pessoal, Primeiramente... socorr! hahahahah Gostaria de ouvir e discutir com vocês, um problema que estou tendo. Olá Marcelo. Só por curiosidade, roda alguma aplicação java related neste server? Se sim, não poderia ser aquele problema do Leap Second? Tem muita gente reclamando disso, mas creio que no FreeBSD isso não aconteça... Mas enfim, tudo é possível... Se não for, /dev/null Abraços. -- Att, Alexandre Silva Nano Tecnólogo em Gestão de Redes de Computadores, UNIFACS Enterasys Security Systems Engineer - IPS/SIEM Enterasys Certified Specialist - NAC www.ideiadigital.com.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] Servidor com load altíssimo
Como só o fato do serviço subir já deixa o sistema nesta situação, quando não existem nem clientes o consumindo para esgotar recursos, acredito que não seja questão de limites (ou seja, solucionável com tunings). Eu colocaria o sistema no estado original e confirmaria que o problema não é no serviço web, testando o nginx ou lighttpd com a aplicação (depois do citado pkg_delete -a). Persistindo o problema, partiria para a personalização do kernel e tunings. -- 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] Servidor com load altíssimo
Em 06/07/2012 08:25, Alexandre Silva Nano escreveu: Em 5 de julho de 2012 23:14, Marcelo Gondim gon...@bsdinfo.com.brescreveu: Olá pessoal, Primeiramente... socorr! hahahahah Gostaria de ouvir e discutir com vocês, um problema que estou tendo. Olá Marcelo. Só por curiosidade, roda alguma aplicação java related neste server? Se sim, não poderia ser aquele problema do Leap Second? Tem muita gente reclamando disso, mas creio que no FreeBSD isso não aconteça... Mas enfim, tudo é possível... Opa Alexandre, Não, pior que não tem nada java. Tem ajax. :) Quem me disse foi o programador. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
Bom dia, pelo o pouco que li ai nas mensagens, isso tá com cara de ser aplicação, algum script mal programado ou algo assim, fazendo loop em banco, etc isso pode ser feito em php, perl, python, etc da alguma atenção a logs e/ou debugar apache, se não tem conexão externa, é aplicação mesmo. Em Sex, 2012-07-06 às 08:31 -0300, Marcelo Gondim escreveu: Em 06/07/2012 08:25, Alexandre Silva Nano escreveu: Em 5 de julho de 2012 23:14, Marcelo Gondim gon...@bsdinfo.com.brescreveu: Olá pessoal, Primeiramente... socorr! hahahahah Gostaria de ouvir e discutir com vocês, um problema que estou tendo. Olá Marcelo. Só por curiosidade, roda alguma aplicação java related neste server? Se sim, não poderia ser aquele problema do Leap Second? Tem muita gente reclamando disso, mas creio que no FreeBSD isso não aconteça... Mas enfim, tudo é possível... Opa Alexandre, Não, pior que não tem nada java. Tem ajax. :) Quem me disse foi o programador. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- 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] Servidor com load altíssimo
2012/7/6 Luiz Gustavo luizgust...@luizgustavo.pro.br: Bom dia, pelo o pouco que li ai nas mensagens, isso tá com cara de ser aplicação, algum script mal programado ou algo assim, fazendo loop em banco, etc isso pode ser feito em php, perl, python, etc da alguma atenção a logs e/ou debugar apache, se não tem conexão externa, é aplicação mesmo. Mas se essa mesma aplicação funcionava sem problema em outro servidor não justificaria, a não ser que o desenvolvedor tenha atualizado a aplicação justamente durante a migração do servidor, mascarando a real causa do problema. -- 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] Servidor com load altíssimo
Em 06/07/2012 08:27, Antônio Pessoa escreveu: Como só o fato do serviço subir já deixa o sistema nesta situação, quando não existem nem clientes o consumindo para esgotar recursos, acredito que não seja questão de limites (ou seja, solucionável com tunings). Eu colocaria o sistema no estado original e confirmaria que o problema não é no serviço web, testando o nginx ou lighttpd com a aplicação (depois do citado pkg_delete -a). Persistindo o problema, partiria para a personalização do kernel e tunings. Opa Antonio, Pois é to dando mais uma enxugada aqui e fiz uma alteração no kernel sugerida pelo nosso amigo nervoso. :) Todo os pacotes estão sendo compilados, eu até prefiro porque além de ganhar uma performance dá pra gente selecionar o que quer. -- 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 - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
Em 06/07/2012 03:27, nervoso escreveu: Ok.. eu tentaria, na sequencia. 1) pkg_delete -a 2) portsnap fetch extract 3) cd /usr/ports/ports-mgmt/portmaster 4) make install clean 5) portmaster shells/bash www/apache22 lang/php5-extensions 6) editar arquivos de configureacao de boot/runtime = /etc/sysctl,conf e /boot/loader.conf 7) reboot comentarios: pkg_delete -a REMOVE TODOS OS PACKAGES Parece ser um problema de thread (lock...) eu colocaria no kernel (no source... as opcoes: options NO_ADAPTIVE_MUTEXES e construiria um kernel a partir dai... recompilando o software na maquina que esta rodando, faz com que o sistema compile com as opcoes certas do sistema operacional em uma maquina destas, vai demora uns 20 minutos... Preste atencao as opcoes que o portmaster vai pedindo a media que configura o sistema.. configure sómente o necessário Veja no sistema operacional se nao falta semaforos, ou shared memory no meu sysctl.conf está assim: kern.ipc.shmmax=4294967296 kern.ipc.shmall=1048576 kern.maxfiles=12 == no loader.conf. kern.ipc.semmap= 256 kern.ipc.shmmni=1024 kern.ipc.semmni=1024 kern.ipc.semmns= 10240 kern.ipc.semmnu= 4800 kern.ipc.semmsl= 256 kern.ipc.semume= 128 vfs.zfs.prefetch_disable=1 === Atente para o fato tb que eu desligaria o read ahead do ZFS... (sysctl.conf, opcao vfs.zfs.prefetch_disable=1) espero que ajude... - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Nervoso nada ainda. :( last pid: 5701; load averages: 61.84, 41.24, 37.29 up 0+00:37:34 09:38:39 1537 processes:11 running, 1526 sleeping CPU: 0.3% user, 0.0% nice, 95.3% system, 0.1% interrupt, 4.2% idle Mem: 1833M Active, 2337M Inact, 1831M Wired, 84K Cache, 17G Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 3354 www 1 200 260M 15296K ls_loc 16 0:24 19.29% httpd 5128 www 1 200 260M 15272K ls_loc 8 0:02 16.26% httpd 5673 www 1 200 260M 15080K ls_loc 18 0:04 16.06% httpd 4552 www 1 200 260M 15340K ls_loc 21 0:13 15.87% httpd 3737 www 1 200 260M 15696K ls_loc 16 0:20 15.58% httpd 5188 www 1 200 260M 16120K ls_loc 10 0:03 15.58% httpd 5414 www 1 200 260M 15196K ls_loc 6 0:02 15.58% httpd 5213 www 1 200 260M 15104K ls_loc 19 0:03 15.38% httpd 3107 www 1 200 260M 15376K lockf 14 0:23 14.36% httpd 3383 www 1 200 260M 15620K ls_loc 21 0:24 13.87% httpd 4543 www 1 200 260M 15712K ls_loc 19 0:13 13.87% httpd 5568 www 1 200 260M 15340K ls_loc 22 0:02 13.77% httpd 2630 www 1 410 139M 12604K ls_loc 2 0:19 13.57% httpd 5244 www 1 200 260M 15136K ls_loc 8 0:02 13.28% httpd 5148 www 1 200 260M 15108K ls_loc 1 0:02 13.28% httpd 5070 www 1 200 260M 15264K ls_loc 17 0:02 12.79% httpd 2869 www 1 200 260M 15876K lockf 3 0:23 12.60% httpd 5221 www 1 200 260M 15104K ls_loc 15 0:03 12.26% httpd 2313 www 1 200 260M 15828K ls_loc 2 0:19 12.16% httpd 4912 www 1 200 260M 15316K ls_loc 21 0:08 12.16% httpd 5654 www 1 200 260M 15252K ls_loc 12 0:02 11.67% httpd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
Em 06/07/2012 08:43, Luiz Gustavo escreveu: Bom dia, pelo o pouco que li ai nas mensagens, isso tá com cara de ser aplicação, algum script mal programado ou algo assim, fazendo loop em banco, etc isso pode ser feito em php, perl, python, etc da alguma atenção a logs e/ou debugar apache, se não tem conexão externa, é aplicação mesmo. Opa Guga, que tem problema na aplicação concordo contigo porque até no outro server com Debian ficava uns loads altos e abaixava mas mesmo com todo o problema o site ainda sim rodava bem e detalhe que o kernel do outro server nem era optimizado era o Default do debian. Eu acho o debian mais enxuto que muita distribuição linux mas puts queria tanto colocar o site no FreeBSD. :) Em Sex, 2012-07-06 às 08:31 -0300, Marcelo Gondim escreveu: Em 06/07/2012 08:25, Alexandre Silva Nano escreveu: Em 5 de julho de 2012 23:14, Marcelo Gondim gon...@bsdinfo.com.brescreveu: Olá pessoal, Primeiramente... socorr! hahahahah Gostaria de ouvir e discutir com vocês, um problema que estou tendo. Olá Marcelo. Só por curiosidade, roda alguma aplicação java related neste server? Se sim, não poderia ser aquele problema do Leap Second? Tem muita gente reclamando disso, mas creio que no FreeBSD isso não aconteça... Mas enfim, tudo é possível... Opa Alexandre, Não, pior que não tem nada java. Tem ajax. :) Quem me disse foi o programador. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
Em 06/07/2012 08:57, Antônio Pessoa escreveu: 2012/7/6 Luiz Gustavo luizgust...@luizgustavo.pro.br: Bom dia, pelo o pouco que li ai nas mensagens, isso tá com cara de ser aplicação, algum script mal programado ou algo assim, fazendo loop em banco, etc isso pode ser feito em php, perl, python, etc da alguma atenção a logs e/ou debugar apache, se não tem conexão externa, é aplicação mesmo. Mas se essa mesma aplicação funcionava sem problema em outro servidor não justificaria, a não ser que o desenvolvedor tenha atualizado a aplicação justamente durante a migração do servidor, mascarando a real causa do problema. Pois é Antonio, não atualizou nadinha. Apenas jogamos de um para o outro servidor. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
Pois é Antonio, não atualizou nadinha. Apenas jogamos de um para o outro servidor. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Bom dia, Tem algum limite (ro,nosuid,noexec no /tmp, /var, algo do tipo?) o que o procstat -kk PID te diz? Abraço, - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
sistema debian vc ta rodando isso num linux ??? é o que ta escrito la na descricao... vamos mudar isso pra freebsd... depois a gente conversa... linSUX eu nao posso ajudar, mas bsd eu posso, ainda mais se for apache com mysql - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
Bom dia Gomdim, Já que você citou o exemplo do Debian com kernel genérico, faz um teste também com o kernel padrão do FreeBSD (caso seja interessante o teste). Vai por eliminação de erros. Boa sorte ae meu amigo. Espero que você consiga identificar/resolver o problema o quanto antes.. Atenciosamente, Ricardo Tweeg De: Marcelo Gondim gon...@bsdinfo.com.br Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Enviadas: Sexta-feira, 6 de Julho de 2012 9:42 Assunto: Re: [FUG-BR] Servidor com load altíssimo Em 06/07/2012 08:43, Luiz Gustavo escreveu: Bom dia, pelo o pouco que li ai nas mensagens, isso tá com cara de ser aplicação, algum script mal programado ou algo assim, fazendo loop em banco, etc isso pode ser feito em php, perl, python, etc da alguma atenção a logs e/ou debugar apache, se não tem conexão externa, é aplicação mesmo. Opa Guga, que tem problema na aplicação concordo contigo porque até no outro server com Debian ficava uns loads altos e abaixava mas mesmo com todo o problema o site ainda sim rodava bem e detalhe que o kernel do outro server nem era optimizado era o Default do debian. Eu acho o debian mais enxuto que muita distribuição linux mas puts queria tanto colocar o site no FreeBSD. :) Em Sex, 2012-07-06 às 08:31 -0300, Marcelo Gondim escreveu: Em 06/07/2012 08:25, Alexandre Silva Nano escreveu: Em 5 de julho de 2012 23:14, Marcelo Gondim gon...@bsdinfo.com.brescreveu: Olá pessoal, Primeiramente... socorr! hahahahah Gostaria de ouvir e discutir com vocês, um problema que estou tendo. Olá Marcelo. Só por curiosidade, roda alguma aplicação java related neste server? Se sim, não poderia ser aquele problema do Leap Second? Tem muita gente reclamando disso, mas creio que no FreeBSD isso não aconteça... Mas enfim, tudo é possível... Opa Alexandre, Não, pior que não tem nada java. Tem ajax. :) Quem me disse foi o programador. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
2012/7/6 Leonardo Augusto lalin...@gmail.com: sistema debian vc ta rodando isso num linux ??? é o que ta escrito la na descricao... vamos mudar isso pra freebsd... depois a gente conversa... linSUX eu nao posso ajudar, mas bsd eu posso, ainda mais se for apache com mysql Esse é o ponto, ele migrou para FreeBSD e está com problemas. -- 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] Servidor com load altíssimo
Em 06/07/2012 10:19, Leonardo Augusto escreveu: sistema debian vc ta rodando isso num linux ??? é o que ta escrito la na descricao... vamos mudar isso pra freebsd... depois a gente conversa... rsrrs você não leu a thread... ele estava em um Debian rodando bem e agora está num FreeBSD rodando ruim. :) Estou tentando resolver isso. :) - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
Em 06/07/2012 10:36, Antônio Pessoa escreveu: 2012/7/6 Leonardo Augusto lalin...@gmail.com: sistema debian vc ta rodando isso num linux ??? é o que ta escrito la na descricao... vamos mudar isso pra freebsd... depois a gente conversa... linSUX eu nao posso ajudar, mas bsd eu posso, ainda mais se for apache com mysql Esse é o ponto, ele migrou para FreeBSD e está com problemas. Antonio, Consegui resolver os lockf. Tipo foi só remover o Listen 443, ou seja, desabilitei o https e deixei apenas http. Ficou excelente e load caiu pra 1.0, 3.0. Show. Agora parece que estou tendo problemas com o mysql. Alguém já viu essa mensagem de erro? DATABASE: mysql_connect: Can't create a new thread (errno 35); if you are not out of available memory, you can consult the manual for a possible OS-dependent bug Estou ainda buscando a solução. Acho que só falta isso porque o mysql fica em 800%, 500% e por aí vai. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
@leonarndo não tenho outra resposta a não ser mandar você ler a maldita thread. Cara eu NÃO SEI fazer - ainda ... mas poderiamos ver com DTrace ? Em 6 de julho de 2012 10:22, Ricardo Tweeg rtw...@yahoo.com.br escreveu: Bom dia Gomdim, Já que você citou o exemplo do Debian com kernel genérico, faz um teste também com o kernel padrão do FreeBSD (caso seja interessante o teste). Vai por eliminação de erros. Boa sorte ae meu amigo. Espero que você consiga identificar/resolver o problema o quanto antes.. Atenciosamente, Ricardo Tweeg De: Marcelo Gondim gon...@bsdinfo.com.br Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Enviadas: Sexta-feira, 6 de Julho de 2012 9:42 Assunto: Re: [FUG-BR] Servidor com load altíssimo Em 06/07/2012 08:43, Luiz Gustavo escreveu: Bom dia, pelo o pouco que li ai nas mensagens, isso tá com cara de ser aplicação, algum script mal programado ou algo assim, fazendo loop em banco, etc isso pode ser feito em php, perl, python, etc da alguma atenção a logs e/ou debugar apache, se não tem conexão externa, é aplicação mesmo. Opa Guga, que tem problema na aplicação concordo contigo porque até no outro server com Debian ficava uns loads altos e abaixava mas mesmo com todo o problema o site ainda sim rodava bem e detalhe que o kernel do outro server nem era optimizado era o Default do debian. Eu acho o debian mais enxuto que muita distribuição linux mas puts queria tanto colocar o site no FreeBSD. :) Em Sex, 2012-07-06 às 08:31 -0300, Marcelo Gondim escreveu: Em 06/07/2012 08:25, Alexandre Silva Nano escreveu: Em 5 de julho de 2012 23:14, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Olá pessoal, Primeiramente... socorr! hahahahah Gostaria de ouvir e discutir com vocês, um problema que estou tendo. Olá Marcelo. Só por curiosidade, roda alguma aplicação java related neste server? Se sim, não poderia ser aquele problema do Leap Second? Tem muita gente reclamando disso, mas creio que no FreeBSD isso não aconteça... Mas enfim, tudo é possível... Opa Alexandre, Não, pior que não tem nada java. Tem ajax. :) Quem me disse foi o programador. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- João Luis Mancy dos Santos joaocep at gmail.com(msn too) http://joaocep.blogspot.com http://www.istf.com.br/perguntas/ http://www.fug.com.br/content/view/20/69/ uin 82889044 - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
2012/7/6 Marcelo Gondim gon...@bsdinfo.com.br last pid: 5701; load averages: 61.84, 41.24, 37.29 up 0+00:37:34 09:38:39 1537 processes:11 running, 1526 sleeping CPU: 0.3% user, 0.0% nice, 95.3% system, 0.1% interrupt, 4.2% idle Mem: 1833M Active, 2337M Inact, 1831M Wired, 84K Cache, 17G Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 3354 www 1 200 260M 15296K ls_loc 16 0:24 19.29% httpd 5128 www 1 200 260M 15272K ls_loc 8 0:02 16.26% httpd 5673 www 1 200 260M 15080K ls_loc 18 0:04 16.06% httpd 4552 www 1 200 260M 15340K ls_loc 21 0:13 15.87% httpd 3737 www 1 200 260M 15696K ls_loc 16 0:20 15.58% httpd 5188 www 1 200 260M 16120K ls_loc 10 0:03 15.58% httpd 5414 www 1 200 260M 15196K ls_loc 6 0:02 15.58% httpd 5213 www 1 200 260M 15104K ls_loc 19 0:03 15.38% httpd 3107 www 1 200 260M 15376K lockf 14 0:23 14.36% httpd 3383 www 1 200 260M 15620K ls_loc 21 0:24 13.87% httpd 4543 www 1 200 260M 15712K ls_loc 19 0:13 13.87% httpd 5568 www 1 200 260M 15340K ls_loc 22 0:02 13.77% httpd 2630 www 1 410 139M 12604K ls_loc 2 0:19 13.57% httpd 5244 www 1 200 260M 15136K ls_loc 8 0:02 13.28% httpd 5148 www 1 200 260M 15108K ls_loc 1 0:02 13.28% httpd 5070 www 1 200 260M 15264K ls_loc 17 0:02 12.79% httpd 2869 www 1 200 260M 15876K lockf 3 0:23 12.60% httpd 5221 www 1 200 260M 15104K ls_loc 15 0:03 12.26% httpd 2313 www 1 200 260M 15828K ls_loc 2 0:19 12.16% httpd 4912 www 1 200 260M 15316K ls_loc 21 0:08 12.16% httpd 5654 www 1 200 260M 15252K ls_loc 12 0:02 11.67% httpd Você não tem problema de I/O nessa máquina? Tenta meter um disco que não está em ZFS e mover o site para lá. -- Eduardo Schoedler - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
Amigo, Se voce ta rodando no linux, tudo bem, dessa vez passa, ehehe Mas vamos la ao seu caso. Sem nem ver nada, posso afirmar com 100% de certeza o seguinte: Seu problema esta em como sua aplicacao foi escrita e como esta configurada. Pq digo isso ? pq é um site pelo visto com php e mysql. Vou dar umas dicas que vc tem que observar nas duas esferas, da aplicacao e da estrutura onde a mesma roda. 1) a observar na aplicacao: - - suas queryes nao estao mal feitas ? falta de indicies ou joins montados de maneira inversa ? erros de sql DETONAM qualquer sistema, pode por um 300 core que nao vai resolver se sua modelagem estiver errada, isso é a pirmeira coisa a ser vista. o que tem de erros de relacionmento e consultas mal feitas por aí, é impressionante. revise isso e tenha certeza que tudo esta correto. - sua aplicacao é baseada em texto ou imagem ? tem mais acesso ao banco ou a static files ? se for a static files, veja os concerns relacionados ao fs, como desativar o uatime por exemplo, e os tunnings do apache, se for o caso, utiliza o lighttpd para isso. - 99,99% da lerdeza em sites com php/mysql, está relacionada a estrutura relacional utilizadada e as consultas feitas sobre a mesma, é um conjunto, modelo mal feito(falta de indices por exemplo) com SQL errado, detona qualquer coisa cara, volto a dizer, revise isso, nao se engane com a inocencia de um join ou left join, se nao tiver as keys ou a orgem for a errada, ferrou geral 2) a observar na estrutura onde roda a apalicacao --- ( tenha certeza que no item 1 acima seu sql e sua estrutura esta correta, do contrario esquece) - usar o mysql no freebsd sem threads de processo, ou seja, apenas um processo do mysql rodando. - usar myisam ou innodb depende da aplicacao, fazer os tunings relativos a cada caso. (mysql precisa de pelo menos 4G de ram se a base for grande) - tunar o apache corretamente, tem 200 tutoriais na net, proura por apache mysql php tuning e ve se acha algo que melhore teu setup. - utilize um acelerador/cache para o php, como o xcache ou o APC. isso é imprescindivel para o php ! - NAO USE conexoes permanentes entre o php e o mysql, ta ligado ? la no php.ini, fazer com que o apache crie e feche a conexao com o mysql a cada requisicao, acredite, melhora muito o desempenho com muitos acessos, pois faz o mysql se refreshar... ou seja, se nao tiver ninguem acessando o site, deve ter ZERO conexoes no mysql, o apache nao deve manter as conexoes ativas durante os requests. - AGORA VEM O MAIS IMPORTANTE DE TUDO. - USAR O MEMCACHE NA PARADA, - USAR O SESSION DO PHP SALVO NO MEMCACHE !! - USAR O SESSION DO PHP SALVO NO MEMCACHE !! - USAR O SESSION DO PHP SALVO NO MEMCACHE !! - USAR O SESSION DO PHP SALVO NO MEMCACHE !! - USAR O SESSION DO PHP SALVO NO MEMCACHE !! ENTENDEU BEM ISSO ??? (eheh é serio cara vai por mim, isso faz toda a diferenca) Se é um site onde o conteudo da home vem do mysql, e muda pouco ao longo do dia, o memcache vai livrar seu mysql do trabalho, cara, chega a ficar 500 MILHOES de vezes mais rapido se usar o memcache, , pode acreditar nissso, é absurda a diferenca. Provavelmente voce nao esta utilizando o memcache, se esta, nao o esta fazendo corretamente. - voce pode usar o memcache para cache de arquivos estaticos para o apache tambem, o que melhora muito tambem. - nao usar logs no apache, esquece isso, dns do ip de acesso pior ainda, se tiver fazendo isso tem que dar um tiro na cabeca. - se tem muito acesso, so logue os erros mesmo, logacc tem que abolir. - muita ram na sua maquina se faz necessario, 16G pelo menos, ideal é uns 24G, ai coloca uns 16G so pro memcache, quero ver ficar lento - rodar essa tranquera toda num FREEBSD, tunado e com tudo compilado com opcoes de otimizacao no make.conf, -O2 la etc Bem, se voce garantir que isso tudo esta correto e esta sendo feito, e ainda assim ficar lento ou com muito processamento, só se seu sql exige consultas complexas a cada request e que retornem um enorme numero de linhas. Aí só com cluster mesmo cara. Mas em geral o memcache resolve 90% dos problemas de desempenho. RESUMINDO: 1) sql tem que estar correto, indices e joins das consultas. 2) Usar acelerador para php, xcache, apc, etc 3) Tunar o bsd, o apache e o mysql, nao usar conexoes persistentes entre apache e mysql (nada de resolver dns no apache hein) 4) Usar memcache para as QUERYES mais usadas da aplicacao. pode ser usado para static files se for o caso 5) PASSAR O SESSION DO PHP
Re: [FUG-BR] Servidor com load altíssimo
2012/7/6 Marcelo Gondim gon...@bsdinfo.com.br: Em 06/07/2012 10:36, Antônio Pessoa escreveu: 2012/7/6 Leonardo Augusto lalin...@gmail.com: sistema debian vc ta rodando isso num linux ??? é o que ta escrito la na descricao... vamos mudar isso pra freebsd... depois a gente conversa... linSUX eu nao posso ajudar, mas bsd eu posso, ainda mais se for apache com mysql Esse é o ponto, ele migrou para FreeBSD e está com problemas. Antonio, Consegui resolver os lockf. Tipo foi só remover o Listen 443, ou seja, desabilitei o https e deixei apenas http. Ficou excelente e load caiu pra 1.0, 3.0. Show. Agora parece que estou tendo problemas com o mysql. Alguém já viu essa mensagem de erro? DATABASE: mysql_connect: Can't create a new thread (errno 35); if you are not out of available memory, you can consult the manual for a possible OS-dependent bug Estou ainda buscando a solução. Acho que só falta isso porque o mysql fica em 800%, 500% e por aí vai. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Pelo que pude entender, o problema está no limite de memória por processo. Quanto de memória o processo MySQL está consumindo? -- 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] Servidor com load altíssimo
2012/7/6 Marcelo Gondim gon...@bsdinfo.com.br: DATABASE: mysql_connect: Can't create a new thread (errno 35); if you are not out of available memory, you can consult the manual for a possible OS-dependent bug Opa, eu já vi esse erro no meu servidor sim ... o que resolveu no meu caso foi diminuir a quantidade de memória alocada para o MySQL ... o erro era este abaixo: ERROR 1135 (0): Can't create a new thread (errno 35); if you are not out of available memory, you can consult the manual for a possible OS-dependent bug O MySQL era 5.0.95 (com InnoDB) no FreeBSD 8.3 com FS em UFS2 (sem ZFS) abraços. Estou ainda buscando a solução. Acho que só falta isso porque o mysql fica em 800%, 500% e por aí vai. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
A agora que parei pra ler la o hardware do seu servidor atual. MEU AMIGO, seu problema esta no setup da aplicacao sem sombra de duvida, se tu visse o que um servidor meu com quad xeon 3ghz, 8G de ram e um raid 10 faz tu ia chorar. e numa app com php mysql e apache. entao revise bem as dicas que dei tunar o freebsd é NECESSARIO, nao adiante tu por la e nao compilar o kernel, removendo os drivers etc, isso é uma novela e tem trocentros tuts na net sobre isso. se fosse problema de hardware, teu novo hardware ia resolver a situacao, como piorou é OBVIO COM 10% DE CERTEZA, que vc nao tunou o freebsd nem o apache nem o mysql, nem o fs, seu raid foi configurado corretamente ? tem controladora ? isso tem bizu la numas coisas do raid dependendo da disutacao o tuning do sistema como um todo faz diferenca, mas acredito que esteja no php/mysql / FALTA DE MEMCACHE no circuito. 26.000 hits é pouco por dia manda aí seu SQL mais complexo realizado nesses hits pra eu analizar ok. abs - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
Em 06/07/2012 10:45, João Mancy escreveu: @leonarndo não tenho outra resposta a não ser mandar você ler a maldita thread. Cara eu NÃO SEI fazer - ainda ... mas poderiamos ver com DTrace ? João to rodando aquele tuning-primer.sh E tipo olha só isso aqui: MEMORY USAGE Max Memory Ever Allocated : 27.58 G Configured Max Per-thread Buffers : 68.72 G Configured Max Global Buffers : 96 M Configured Max Memory Limit : 68.81 G Physical Memory : 25.75 G nMax memory limit exceeds 90% of physical memory HaHaHah to tentando resolver isso. Se eu conseguir acredito que resolva tudo. :) Em 6 de julho de 2012 10:22, Ricardo Tweeg rtw...@yahoo.com.br escreveu: Bom dia Gomdim, Já que você citou o exemplo do Debian com kernel genérico, faz um teste também com o kernel padrão do FreeBSD (caso seja interessante o teste). Vai por eliminação de erros. Boa sorte ae meu amigo. Espero que você consiga identificar/resolver o problema o quanto antes.. Atenciosamente, Ricardo Tweeg De: Marcelo Gondim gon...@bsdinfo.com.br Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Enviadas: Sexta-feira, 6 de Julho de 2012 9:42 Assunto: Re: [FUG-BR] Servidor com load altíssimo Em 06/07/2012 08:43, Luiz Gustavo escreveu: Bom dia, pelo o pouco que li ai nas mensagens, isso tá com cara de ser aplicação, algum script mal programado ou algo assim, fazendo loop em banco, etc isso pode ser feito em php, perl, python, etc da alguma atenção a logs e/ou debugar apache, se não tem conexão externa, é aplicação mesmo. Opa Guga, que tem problema na aplicação concordo contigo porque até no outro server com Debian ficava uns loads altos e abaixava mas mesmo com todo o problema o site ainda sim rodava bem e detalhe que o kernel do outro server nem era optimizado era o Default do debian. Eu acho o debian mais enxuto que muita distribuição linux mas puts queria tanto colocar o site no FreeBSD. :) Em Sex, 2012-07-06 às 08:31 -0300, Marcelo Gondim escreveu: Em 06/07/2012 08:25, Alexandre Silva Nano escreveu: Em 5 de julho de 2012 23:14, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Olá pessoal, Primeiramente... socorr! hahahahah Gostaria de ouvir e discutir com vocês, um problema que estou tendo. Olá Marcelo. Só por curiosidade, roda alguma aplicação java related neste server? Se sim, não poderia ser aquele problema do Leap Second? Tem muita gente reclamando disso, mas creio que no FreeBSD isso não aconteça... Mas enfim, tudo é possível... Opa Alexandre, Não, pior que não tem nada java. Tem ajax. :) Quem me disse foi o programador. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
2012/7/6 Antônio Pessoa atnpes...@gmail.com: Pelo que pude entender, o problema está no limite de memória por processo. Quanto de memória o processo MySQL está consumindo? -- Atenciosamente, Antônio Pessoa Marcelo, dá uma olhadinha nessas duas fontes [1] [2], as duas falam exatamente do seu problema. http://lists.mysql.com/mysql/217340 http://www.krellis.org/unix-stuff/mysql-freebsd-threads.html -- 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] Servidor com load altíssimo
Em 06/07/2012 10:47, Eduardo Schoedler escreveu: 2012/7/6 Marcelo Gondim gon...@bsdinfo.com.br last pid: 5701; load averages: 61.84, 41.24, 37.29 up 0+00:37:34 09:38:39 1537 processes:11 running, 1526 sleeping CPU: 0.3% user, 0.0% nice, 95.3% system, 0.1% interrupt, 4.2% idle Mem: 1833M Active, 2337M Inact, 1831M Wired, 84K Cache, 17G Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 3354 www 1 200 260M 15296K ls_loc 16 0:24 19.29% httpd 5128 www 1 200 260M 15272K ls_loc 8 0:02 16.26% httpd 5673 www 1 200 260M 15080K ls_loc 18 0:04 16.06% httpd 4552 www 1 200 260M 15340K ls_loc 21 0:13 15.87% httpd 3737 www 1 200 260M 15696K ls_loc 16 0:20 15.58% httpd 5188 www 1 200 260M 16120K ls_loc 10 0:03 15.58% httpd 5414 www 1 200 260M 15196K ls_loc 6 0:02 15.58% httpd 5213 www 1 200 260M 15104K ls_loc 19 0:03 15.38% httpd 3107 www 1 200 260M 15376K lockf 14 0:23 14.36% httpd 3383 www 1 200 260M 15620K ls_loc 21 0:24 13.87% httpd 4543 www 1 200 260M 15712K ls_loc 19 0:13 13.87% httpd 5568 www 1 200 260M 15340K ls_loc 22 0:02 13.77% httpd 2630 www 1 410 139M 12604K ls_loc 2 0:19 13.57% httpd 5244 www 1 200 260M 15136K ls_loc 8 0:02 13.28% httpd 5148 www 1 200 260M 15108K ls_loc 1 0:02 13.28% httpd 5070 www 1 200 260M 15264K ls_loc 17 0:02 12.79% httpd 2869 www 1 200 260M 15876K lockf 3 0:23 12.60% httpd 5221 www 1 200 260M 15104K ls_loc 15 0:03 12.26% httpd 2313 www 1 200 260M 15828K ls_loc 2 0:19 12.16% httpd 4912 www 1 200 260M 15316K ls_loc 21 0:08 12.16% httpd 5654 www 1 200 260M 15252K ls_loc 12 0:02 11.67% httpd Você não tem problema de I/O nessa máquina? Tenta meter um disco que não está em ZFS e mover o site para lá. Opa esse problema já resolvi o pau agora é com o mysql olha o resultado que tive aqui: MEMORY USAGE Max Memory Ever Allocated : 27.58 G Configured Max Per-thread Buffers : 68.72 G Configured Max Global Buffers : 96 M Configured Max Memory Limit : 68.81 G Physical Memory : 25.75 G nMax memory limit exceeds 90% of physical memory To tentando descobrir como diminuir esse consumo no my.cnf, mas confesso que database não é minha praia rsrsrsrs - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
Em 06/07/2012 11:13, Antônio Pessoa escreveu: 2012/7/6 Marcelo Gondim gon...@bsdinfo.com.br: Em 06/07/2012 10:36, Antônio Pessoa escreveu: 2012/7/6 Leonardo Augusto lalin...@gmail.com: sistema debian vc ta rodando isso num linux ??? é o que ta escrito la na descricao... vamos mudar isso pra freebsd... depois a gente conversa... linSUX eu nao posso ajudar, mas bsd eu posso, ainda mais se for apache com mysql Esse é o ponto, ele migrou para FreeBSD e está com problemas. Antonio, Consegui resolver os lockf. Tipo foi só remover o Listen 443, ou seja, desabilitei o https e deixei apenas http. Ficou excelente e load caiu pra 1.0, 3.0. Show. Agora parece que estou tendo problemas com o mysql. Alguém já viu essa mensagem de erro? DATABASE: mysql_connect: Can't create a new thread (errno 35); if you are not out of available memory, you can consult the manual for a possible OS-dependent bug Estou ainda buscando a solução. Acho que só falta isso porque o mysql fica em 800%, 500% e por aí vai. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Pelo que pude entender, o problema está no limite de memória por processo. Quanto de memória o processo MySQL está consumindo? MEMORY USAGE Max Memory Ever Allocated : 27.58 G Configured Max Per-thread Buffers : 68.72 G Configured Max Global Buffers : 96 M Configured Max Memory Limit : 68.81 G Physical Memory : 25.75 G nMax memory limit exceeds 90% of physical memory - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
2012/7/6 Marcelo Gondim gon...@bsdinfo.com.br Em 06/07/2012 10:47, Eduardo Schoedler escreveu: 2012/7/6 Marcelo Gondim gon...@bsdinfo.com.br last pid: 5701; load averages: 61.84, 41.24, 37.29 up 0+00:37:34 09:38:39 1537 processes:11 running, 1526 sleeping CPU: 0.3% user, 0.0% nice, 95.3% system, 0.1% interrupt, 4.2% idle Mem: 1833M Active, 2337M Inact, 1831M Wired, 84K Cache, 17G Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 3354 www 1 200 260M 15296K ls_loc 16 0:24 19.29% httpd 5128 www 1 200 260M 15272K ls_loc 8 0:02 16.26% httpd 5673 www 1 200 260M 15080K ls_loc 18 0:04 16.06% httpd 4552 www 1 200 260M 15340K ls_loc 21 0:13 15.87% httpd 3737 www 1 200 260M 15696K ls_loc 16 0:20 15.58% httpd 5188 www 1 200 260M 16120K ls_loc 10 0:03 15.58% httpd 5414 www 1 200 260M 15196K ls_loc 6 0:02 15.58% httpd 5213 www 1 200 260M 15104K ls_loc 19 0:03 15.38% httpd 3107 www 1 200 260M 15376K lockf 14 0:23 14.36% httpd 3383 www 1 200 260M 15620K ls_loc 21 0:24 13.87% httpd 4543 www 1 200 260M 15712K ls_loc 19 0:13 13.87% httpd 5568 www 1 200 260M 15340K ls_loc 22 0:02 13.77% httpd 2630 www 1 410 139M 12604K ls_loc 2 0:19 13.57% httpd 5244 www 1 200 260M 15136K ls_loc 8 0:02 13.28% httpd 5148 www 1 200 260M 15108K ls_loc 1 0:02 13.28% httpd 5070 www 1 200 260M 15264K ls_loc 17 0:02 12.79% httpd 2869 www 1 200 260M 15876K lockf 3 0:23 12.60% httpd 5221 www 1 200 260M 15104K ls_loc 15 0:03 12.26% httpd 2313 www 1 200 260M 15828K ls_loc 2 0:19 12.16% httpd 4912 www 1 200 260M 15316K ls_loc 21 0:08 12.16% httpd 5654 www 1 200 260M 15252K ls_loc 12 0:02 11.67% httpd Você não tem problema de I/O nessa máquina? Tenta meter um disco que não está em ZFS e mover o site para lá. Opa esse problema já resolvi o pau agora é com o mysql olha o resultado que tive aqui: MEMORY USAGE Max Memory Ever Allocated : 27.58 G Configured Max Per-thread Buffers : 68.72 G Configured Max Global Buffers : 96 M Configured Max Memory Limit : 68.81 G Physical Memory : 25.75 G nMax memory limit exceeds 90% of physical memory To tentando descobrir como diminuir esse consumo no my.cnf, mas confesso que database não é minha praia rsrsrsrs http://mysqltuner.pl Baixa e roda ele té dá um norte para configurar o MySQL. Você está usando innodb? -- Eduardo Schoedler - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
Em 06/07/2012 11:14, Eduardo escreveu: 2012/7/6 Marcelo Gondim gon...@bsdinfo.com.br: DATABASE: mysql_connect: Can't create a new thread (errno 35); if you are not out of available memory, you can consult the manual for a possible OS-dependent bug Opa, eu já vi esse erro no meu servidor sim ... o que resolveu no meu caso foi diminuir a quantidade de memória alocada para o MySQL ... o erro era este abaixo: ERROR 1135 (0): Can't create a new thread (errno 35); if you are not out of available memory, you can consult the manual for a possible OS-dependent bug Opa Eduardo, eu to tentando é fazer isso mesmo rsrsrsrs Tens os parâmetros pra isso ou alguma doc ou link? Saca só como tá e o sistema só tem 24Gb de ram: MEMORY USAGE Max Memory Ever Allocated : 27.58 G Configured Max Per-thread Buffers : 68.72 G Configured Max Global Buffers : 96 M Configured Max Memory Limit : 68.81 G Physical Memory : 25.75 G nMax memory limit exceeds 90% of physical memory O MySQL era 5.0.95 (com InnoDB) no FreeBSD 8.3 com FS em UFS2 (sem ZFS) abraços. Estou ainda buscando a solução. Acho que só falta isso porque o mysql fica em 800%, 500% e por aí vai. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
Em 06/07/2012 11:22, Leonardo Augusto escreveu: A agora que parei pra ler la o hardware do seu servidor atual. MEU AMIGO, seu problema esta no setup da aplicacao sem sombra de duvida, se tu visse o que um servidor meu com quad xeon 3ghz, 8G de ram e um raid 10 faz tu ia chorar. e numa app com php mysql e apache. entao revise bem as dicas que dei tunar o freebsd é NECESSARIO, nao adiante tu por la e nao compilar o kernel, removendo os drivers etc, isso é uma novela e tem trocentros tuts na net sobre isso. Fiz isso de cara. Também tunei o loader.conf e o sysctl.conf. o kernel não é o GENERIC não. :) mas o lance do apache eu já resolvi agora é só o mysql. Eu usei a conf anterior do servidor mas mesmo assim tá estourando a ram. skip-name-resolve key_buffer = 1500M max_allowed_packet = 256M thread_stack= 2M thread_cache_size = 128 myisam-recover = BACKUP max_connections= 4000 query_cache_limit = 4096M query_cache_size= 16M expire_logs_days= 10 max_binlog_size = 100M Mas já andei mexendo nisso aí pra ajustar e até agora não consegui: MEMORY USAGE Max Memory Ever Allocated : 27.58 G Configured Max Per-thread Buffers : 68.72 G Configured Max Global Buffers : 96 M Configured Max Memory Limit : 68.81 G Physical Memory : 25.75 G nMax memory limit exceeds 90% of physical memory se fosse problema de hardware, teu novo hardware ia resolver a situacao, como piorou é OBVIO COM 10% DE CERTEZA, que vc nao tunou o freebsd nem o apache nem o mysql, nem o fs, seu raid foi configurado corretamente ? tem controladora ? isso tem bizu Raid feito na controladora pelo Datacenter mesmo. la numas coisas do raid dependendo da disutacao o tuning do sistema como um todo faz diferenca, mas acredito que esteja no php/mysql / FALTA DE MEMCACHE no circuito. 26.000 hits é pouco por dia manda aí seu SQL mais complexo realizado nesses hits pra eu analizar ok. abs - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
Em 06/07/2012 11:24, Eduardo Schoedler escreveu: 2012/7/6 Marcelo Gondim gon...@bsdinfo.com.br Em 06/07/2012 10:47, Eduardo Schoedler escreveu: 2012/7/6 Marcelo Gondim gon...@bsdinfo.com.br last pid: 5701; load averages: 61.84, 41.24, 37.29 up 0+00:37:34 09:38:39 1537 processes:11 running, 1526 sleeping CPU: 0.3% user, 0.0% nice, 95.3% system, 0.1% interrupt, 4.2% idle Mem: 1833M Active, 2337M Inact, 1831M Wired, 84K Cache, 17G Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 3354 www 1 200 260M 15296K ls_loc 16 0:24 19.29% httpd 5128 www 1 200 260M 15272K ls_loc 8 0:02 16.26% httpd 5673 www 1 200 260M 15080K ls_loc 18 0:04 16.06% httpd 4552 www 1 200 260M 15340K ls_loc 21 0:13 15.87% httpd 3737 www 1 200 260M 15696K ls_loc 16 0:20 15.58% httpd 5188 www 1 200 260M 16120K ls_loc 10 0:03 15.58% httpd 5414 www 1 200 260M 15196K ls_loc 6 0:02 15.58% httpd 5213 www 1 200 260M 15104K ls_loc 19 0:03 15.38% httpd 3107 www 1 200 260M 15376K lockf 14 0:23 14.36% httpd 3383 www 1 200 260M 15620K ls_loc 21 0:24 13.87% httpd 4543 www 1 200 260M 15712K ls_loc 19 0:13 13.87% httpd 5568 www 1 200 260M 15340K ls_loc 22 0:02 13.77% httpd 2630 www 1 410 139M 12604K ls_loc 2 0:19 13.57% httpd 5244 www 1 200 260M 15136K ls_loc 8 0:02 13.28% httpd 5148 www 1 200 260M 15108K ls_loc 1 0:02 13.28% httpd 5070 www 1 200 260M 15264K ls_loc 17 0:02 12.79% httpd 2869 www 1 200 260M 15876K lockf 3 0:23 12.60% httpd 5221 www 1 200 260M 15104K ls_loc 15 0:03 12.26% httpd 2313 www 1 200 260M 15828K ls_loc 2 0:19 12.16% httpd 4912 www 1 200 260M 15316K ls_loc 21 0:08 12.16% httpd 5654 www 1 200 260M 15252K ls_loc 12 0:02 11.67% httpd Você não tem problema de I/O nessa máquina? Tenta meter um disco que não está em ZFS e mover o site para lá. Opa esse problema já resolvi o pau agora é com o mysql olha o resultado que tive aqui: MEMORY USAGE Max Memory Ever Allocated : 27.58 G Configured Max Per-thread Buffers : 68.72 G Configured Max Global Buffers : 96 M Configured Max Memory Limit : 68.81 G Physical Memory : 25.75 G nMax memory limit exceeds 90% of physical memory To tentando descobrir como diminuir esse consumo no my.cnf, mas confesso que database não é minha praia rsrsrsrs http://mysqltuner.pl Baixa e roda ele té dá um norte para configurar o MySQL. Você está usando innodb? Show vou testar com ele. Tentei com e sem o innodb. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
Em 6 de julho de 2012 11:36, Marcelo Gondim gon...@bsdinfo.com.brescreveu: Em 06/07/2012 11:24, Eduardo Schoedler escreveu: http://mysqltuner.pl Baixa e roda ele té dá um norte para configurar o MySQL. Você está usando innodb? Show vou testar com ele. Tentei com e sem o innodb. Mas as tabelas, são innodb ou myisam? Se forem todas myisam, pode desativar o resto tudo (Archive, BDB, Federated, NDBCluster). -- Eduardo Schoedler - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
Em 06/07/2012 11:22, Antônio Pessoa escreveu: 2012/7/6 Antônio Pessoa atnpes...@gmail.com: Pelo que pude entender, o problema está no limite de memória por processo. Quanto de memória o processo MySQL está consumindo? -- Atenciosamente, Antônio Pessoa Marcelo, dá uma olhadinha nessas duas fontes [1] [2], as duas falam exatamente do seu problema. http://lists.mysql.com/mysql/217340 http://www.krellis.org/unix-stuff/mysql-freebsd-threads.html Opa Antonio a solução de |linuxthreads não rolou porque tá marcado como quebrado no ports. :(| - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
ta usando mysql com linux threads no freebsd quer se matar mesmo saca só, nao adianta tu tentar limitar a quantidade de ram que o teu mysql come cara, se ele estiver comendo muita ram, pode ter algo errado, como ja mencinei. desative o persistent conections cara. outra, que demonho essas tuas queryes tao fazendo como te disse, pro mysql ficar comendo ram desse jeito, so pode ser pq tu ta usando persistent conections e pq teu sql pode ter algo errado, ta usando o memcache ? - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
Em 2012-07-06 11:35, Marcelo Gondim escreveu:
Fiz isso de cara. Também tunei o loader.conf e o sysctl.conf. o
kernel
não é o GENERIC não. :)
mas o lance do apache eu já resolvi agora é só o mysql. Eu usei a
conf
anterior do servidor mas mesmo assim tá estourando a ram.
skip-name-resolve
key_buffer = 1500M
max_allowed_packet = 256M
thread_stack= 2M
thread_cache_size = 128
myisam-recover = BACKUP
max_connections= 4000
query_cache_limit = 4096M
query_cache_size= 16M
expire_logs_days= 10
max_binlog_size = 100M
Mas já andei mexendo nisso aí pra ajustar e até agora não consegui:
MEMORY USAGE
Max Memory Ever Allocated : 27.58 G
Configured Max Per-thread Buffers : 68.72 G
Configured Max Global Buffers : 96 M
Configured Max Memory Limit : 68.81 G
Physical Memory : 25.75 G
nMax memory limit exceeds 90% of physical memory
Faz o seguinte, tenta usar o /usr/local/share/mysql/my-huge.cnf como o
my.cnf.
Outra coisa, como você importou o banco? Copiou os arquivos ou fez um
dump e restaurou no servidor novo?
Se você copiou os arquivos, tente executar find /var/db/mysql -iname
*.MYI -exec myisamchk -r {} \;
--
vic
http://choppnerd.com
http://donttrack.us | http://dontbubble.us
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
Não é o mysql o problema, pois o processo que estava matando a máquina era o 'httpd'. O site tem muito acesso a disco? Você pode habilitar o mod_cache no apache. -- Eduardo Schoedler Em 6 de julho de 2012 12:00, Leonardo Augusto lalin...@gmail.com escreveu: ta usando mysql com linux threads no freebsd quer se matar mesmo saca só, nao adianta tu tentar limitar a quantidade de ram que o teu mysql come cara, se ele estiver comendo muita ram, pode ter algo errado, como ja mencinei. desative o persistent conections cara. outra, que demonho essas tuas queryes tao fazendo como te disse, pro mysql ficar comendo ram desse jeito, so pode ser pq tu ta usando persistent conections e pq teu sql pode ter algo errado, ta usando o memcache ? - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
Em Sex, 2012-07-06 às 08:57 -0300, Antônio Pessoa escreveu: Mas se essa mesma aplicação funcionava sem problema em outro servidor não justificaria, a não ser que o desenvolvedor tenha atualizado a aplicação justamente durante a migração do servidor, mascarando a real causa do problema. Eu tinha um caso justamente com php e mysql o php fazia loop no banco, o que acabava com a cpu, pois ficava em loop ao adquirir mutex. solucao foi colocar um sleep de uns 100ms no loop de aquisicao de mutex, e tomar cuidado para se o mutex for em cima de I/O aberto, quando der I/O error (close do socket, por exemplo) em uma thread, o mutex (que estava associado ao socket...) entra em loop... Mysql, sendo um BANDO de dados e multithread, se nao for bem programado no php, ele realmente come toda a cpu Parece que tem loop de php em cima do banco de dados mysql... veja com o programador onde está o loop... Compile o kernel com a opcao KTRACE execute a coisa... pegue uma task (PID) do apache que esta em loop, consumindo tudo.. vai em um filesystem com BASTANTE ESPACO... e dá o comando... ktrace -di -p PID deixe rodar por uns 20 segundos comando: ktrace -c -p PID (pára o trace)... comando: kdump trace.log (cria o arquivo de log...) depois use o vi para olhar o trace.log e veja se o sistema nao esta em loop de socket ou mutex. (vai nas ultimas linhas e vai voltando...). No linux funciona??? Sim por que o sistema de threads do linux é diferente... coisa com recursive mutex Nos BSDs (freebsd, netbsd, openbsd e até no OSX!!!) tem problema com isso... ele entra em loop quando nao configurado a opcao de mutex no codigo do programa... - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
Tem ainda o TUNE =kern.threads.max_threads_per_proc: no meu sistema ele vai de 1500 o que significa que um mysql poderia criar até 1500 threads... Ve o que informa o teu sistema ai - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
Em 06/07/2012 12:45, nervoso escreveu: Tem ainda o TUNE =kern.threads.max_threads_per_proc: no meu sistema ele vai de 1500 Opa nervoso no meu já por default em 1500: # sysctl kern.threads.max_threads_per_proc kern.threads.max_threads_per_proc: 1500 o que significa que um mysql poderia criar até 1500 threads... Ve o que informa o teu sistema ai - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
Em 06/07/2012 12:09, vic escreveu:
Em 2012-07-06 11:35, Marcelo Gondim escreveu:
Fiz isso de cara. Também tunei o loader.conf e o sysctl.conf. o
kernel
não é o GENERIC não. :)
mas o lance do apache eu já resolvi agora é só o mysql. Eu usei a
conf
anterior do servidor mas mesmo assim tá estourando a ram.
skip-name-resolve
key_buffer = 1500M
max_allowed_packet = 256M
thread_stack= 2M
thread_cache_size = 128
myisam-recover = BACKUP
max_connections= 4000
query_cache_limit = 4096M
query_cache_size= 16M
expire_logs_days= 10
max_binlog_size = 100M
Mas já andei mexendo nisso aí pra ajustar e até agora não consegui:
MEMORY USAGE
Max Memory Ever Allocated : 27.58 G
Configured Max Per-thread Buffers : 68.72 G
Configured Max Global Buffers : 96 M
Configured Max Memory Limit : 68.81 G
Physical Memory : 25.75 G
nMax memory limit exceeds 90% of physical memory
Faz o seguinte, tenta usar o /usr/local/share/mysql/my-huge.cnf como o
my.cnf.
Opa vic :)tentei usar sim o my-huge mas não surtiu muito efeito.
Parece que pode ser o que o nervoso falou. Mas puts mexer na aplicação
na altura do campeonato vamos perder a taça e ficar como vice ahahahahahah
Outra coisa, como você importou o banco? Copiou os arquivos ou fez um
dump e restaurou no servidor novo?
eu fiz um dump dela pelo mysqldump mesmo e depois importei o sql.
Se você copiou os arquivos, tente executar find /var/db/mysql -iname
*.MYI -exec myisamchk -r {} \;
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
Em 06/07/2012 12:00, Leonardo Augusto escreveu: ta usando mysql com linux threads no freebsd quer se matar mesmo Não fio rsrsrs não to usando linux threads não :) minha instalação do mysql no FreeBSD: portmaster -m BUILD_OPTIMIZED=yes databases/mysql51-server :) não tenho nada de Linux hahah vc cismou que to usando Linux mesmo hahahaha eu estou tentando não ter que voltar pra ele. :D saca só, nao adianta tu tentar limitar a quantidade de ram que o teu mysql come cara, se ele estiver comendo muita ram, pode ter algo errado, como ja mencinei. Estou começando à perceber isso. Que tem problema na aplicação eu também acredito e também acredito que esse problema acontece de forma diferente em ambos os sistemas talvez pelo que o nervoso comentou. desative o persistent conections cara. Pelo que vi nos fontes não está sendo usado o mysql_pconnect() e sim o mysql_connect() outra, que demonho essas tuas queryes tao fazendo demonho mesmo hahahahah como te disse, pro mysql ficar comendo ram desse jeito, so pode ser pq tu ta usando persistent conections e pq teu sql pode ter algo errado, pconnect não tá usando não. ta usando o memcache ? não. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
Em 06/07/2012 12:45, nervoso escreveu: Tem ainda o TUNE =kern.threads.max_threads_per_proc: no meu sistema ele vai de 1500 o que significa que um mysql poderia criar até 1500 threads... Ve o que informa o teu sistema ai - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Nervoso será que se eu compilasse o MySQL com essas opções ajudaria? WITH_PROC_SCOPE_PTH=yes Use process scope threads WITH_FAST_MUTEXES=yes Replace mutexes with spinlocks eu já uso essa BUILD_OPTIMIZED=yes - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
cara o lance do mysql persistente connections é no php.ini.
(php.ini)
mysql.allow_persistent = Off (voce deve estar com ON ali, bota off !! e testa )
E PELO AMOR DO BSD, INSTALA O MEMCACHE E COLOCA LA NAS QUERYES E NO
SESSION DO PHP.
CARA, SE O MALUCO QUE FUTRICA COM PHP AI, NAO FEZ ISSO, PEGA UM 12 E
ATIRA BEM NA TESTA DO INFELIZ, kkk
mas pra nao dizer que so falo e nao ajudo, pro php usar o memcache
como session handler é so por la no php.ini
; Use memcache as a session handler
session.save_handler=memcache
; Defines a comma separated of server urls to use for session storage
;session.save_path=tcp://localhost:11211?persistent=1weight=1timeout=1retry_interval=15
session.save_path=tcp://localhost:11211?persistent=1retry_interval=15
- pra usar o memcahce no php, tem que instalar o php memcache lib la
ou coisa do tipo...
mas um exemplo de query, gera o hash do sql ve se ja tem, se nao tem
get from mysql and put into memcache, else get from memcache, sacou ?
conectando...
public function connect() // (obvio que é apenas um metodo de uma
classe extensa)
{
$ok = false;
try
{
//if( $this-mode == TCP )
//$this-dbh = new mysqli( $this-dbhost, $this-user,
$this-pass, $this-dbname, null, 'mysql' );
$this-dbh = new mysqli( $this-dbhost, $this-user,
$this-pass, $this-dbname );
if( mysqli_connect_errno() )
{
throw new Exception( sprintf(FALHA: %s\n, mysqli_connect_error() ) );
}
mysqli_set_charset($this-dbh, 'utf8');
//mysql_query(SET CHARACTER SET utf8, $this-dbh );
//mysql_query(SET NAMES utf8);
//mysql_query(SET NAMES 'utf8' COLLATE 'utf8_general_ci'); //
medida extrema, opcional
/*
# Aqui está o segredo
mysql_query(SET NAMES 'utf8');
mysql_query('SET character_set_connection=utf8');
mysql_query('SET character_set_client=utf8');
mysql_query('SET character_set_results=utf8');
conx = mysql_connect(xxx);
// dica para shared hosting
mysql_query(SET CHARACTER SET utf8);
//mysql_query(SET NAMES utf8);
//mysql_query(SET NAMES 'utf8' COLLATE 'utf8_general_ci'); //
medida extrema, opcional
*/
//-
//--- Conecta ao memcached
//-
$this-memcacheOK = false;
if( class_exists(Memcache) )
{
$this-memcache = new Memcache();
if( $this-memcache-connect( SYS_CFG(MCHOST), SYS_CFG(MCPORT) ) )
{
$this-memcacheOK = true;
}
}
$ok = true;
}
catch( Exception $e )
{
$this-errorMsg = Connect Error (File: .$e-getFile()., Line
.$e-getLine().): .$e-getMessage();
echo $this-errorMsg;
}
return $ok;
}
// a consulta propriamente dita
public function queryMC( $query, $timeout=600 ) // timeout==0 = no cache
{
$this-errorClear();
$data = false;
try
{
if( $this-memcacheOK (int)$timeout 0 )// Se timeout==0
nao usa o cache
{
$key = md5( $query );
$data = $this-memcache-get( $key );
//echo !-- ## PEGOU DO MEMCACHE::: ;
//if( $data == false ) echo DATA RETURN FALSE---;
//echo $query.--\n;
}
if( $data == false )
{
//echo !-- NAO PEGOU DO MEMCACHE::: .$query.--\n;
$result = $this-dbh-query( $query, MYSQLI_STORE_RESULT );
if( $result == false )
{
throw new Exception( $this-dbh-error );
}
else
{
$data = array();
while( $row = $result-fetch_array( MYSQLI_BOTH ) )
{
$data[] = $row;
}
}
if( $this-memcacheOK (int)$timeout 0 ) // Se
timeout==0 nao usa o cache
{
$this-memcache-set( $key, $data, 0, $timeout );
}
$result-close();
unset( $result);
}
}
catch( Exception $e )
{
$this-errorMsg .=
DBQueryMC(.sysUtil::SYS_GS(last_sysaction).):
.$e-getMessage(). = .$query. [.$e-getTraceAsString().] );
$this-errorCode = $e-getCode();
$this-saveLogError();
$data = array();
}
return $data;
}
AH LEMBREI DE OUTRA COISA
usar o php com fast_cgi separado do apache(retirando o mod_php de
dentro dele) é melhor.
MAS USA O MEMCACHE CARA, do contrario pula da ponte... eheheh
boa sorte
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
2012/7/6 Marcelo Gondim gon...@bsdinfo.com.br: Em 06/07/2012 12:45, nervoso escreveu: Tem ainda o TUNE =kern.threads.max_threads_per_proc: no meu sistema ele vai de 1500 o que significa que um mysql poderia criar até 1500 threads... Ve o que informa o teu sistema ai - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Nervoso será que se eu compilasse o MySQL com essas opções ajudaria? WITH_PROC_SCOPE_PTH=yes Use process scope threads WITH_FAST_MUTEXES=yes Replace mutexes with spinlocks eu já uso essa BUILD_OPTIMIZED=yes - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Caros colegas, nao adianta ficar tentando achar chifre em cabeca de cavalo, sem saber se nao tem erro no modelo das queryes do sistema nao adianta, pode tunar fazer o que for que vai continuar sentando na graxa. Como eu ja disse (umas 4x hoje ja) se colocar o memcache, e melhorar, a prova esta que é a query o problema, pois o memcache vai cachear o resultado da query, liberando o mysql boa sorte (denovo) - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
Em 06/07/2012 12:09, Eduardo Schoedler escreveu: Não é o mysql o problema, pois o processo que estava matando a máquina era o 'httpd'. O site tem muito acesso a disco? Você pode habilitar o mod_cache no apache. O mod_cache já tava em uso. É um site de torrents tem muito acesso ao mysql pelo visto. rsrsrs - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
On Fri, Jul 6, 2012 at 2:29 PM, Leonardo Augusto lalin...@gmail.com wrote:
cara o lance do mysql persistente connections é no php.ini.
(php.ini)
mysql.allow_persistent = Off (voce deve estar com ON ali, bota off !! e
testa )
E PELO AMOR DO BSD, INSTALA O MEMCACHE E COLOCA LA NAS QUERYES E NO
SESSION DO PHP.
CARA, SE O MALUCO QUE FUTRICA COM PHP AI, NAO FEZ ISSO, PEGA UM 12 E
ATIRA BEM NA TESTA DO INFELIZ, kkk
mas pra nao dizer que so falo e nao ajudo, pro php usar o memcache
como session handler é so por la no php.ini
; Use memcache as a session handler
session.save_handler=memcache
; Defines a comma separated of server urls to use for session storage
;session.save_path=tcp://localhost:11211?persistent=1weight=1timeout=1retry_interval=15
session.save_path=tcp://localhost:11211?persistent=1retry_interval=15
- pra usar o memcahce no php, tem que instalar o php memcache lib la
ou coisa do tipo...
mas um exemplo de query, gera o hash do sql ve se ja tem, se nao tem
get from mysql and put into memcache, else get from memcache, sacou ?
conectando...
public function connect() // (obvio que é apenas um metodo de uma
classe extensa)
{
$ok = false;
try
{
//if( $this-mode == TCP )
//$this-dbh = new mysqli( $this-dbhost, $this-user,
$this-pass, $this-dbname, null, 'mysql' );
$this-dbh = new mysqli( $this-dbhost, $this-user,
$this-pass, $this-dbname );
if( mysqli_connect_errno() )
{
throw new Exception( sprintf(FALHA: %s\n, mysqli_connect_error() )
);
}
mysqli_set_charset($this-dbh, 'utf8');
//mysql_query(SET CHARACTER SET utf8, $this-dbh );
//mysql_query(SET NAMES utf8);
//mysql_query(SET NAMES 'utf8' COLLATE 'utf8_general_ci'); //
medida extrema, opcional
/*
# Aqui está o segredo
mysql_query(SET NAMES 'utf8');
mysql_query('SET character_set_connection=utf8');
mysql_query('SET character_set_client=utf8');
mysql_query('SET character_set_results=utf8');
conx = mysql_connect(xxx);
// dica para shared hosting
mysql_query(SET CHARACTER SET utf8);
//mysql_query(SET NAMES utf8);
//mysql_query(SET NAMES 'utf8' COLLATE 'utf8_general_ci'); //
medida extrema, opcional
*/
//-
//--- Conecta ao memcached
//-
$this-memcacheOK = false;
if( class_exists(Memcache) )
{
$this-memcache = new Memcache();
if( $this-memcache-connect( SYS_CFG(MCHOST), SYS_CFG(MCPORT) ) )
{
$this-memcacheOK = true;
}
}
$ok = true;
}
catch( Exception $e )
{
$this-errorMsg = Connect Error (File: .$e-getFile()., Line
.$e-getLine().): .$e-getMessage();
echo $this-errorMsg;
}
return $ok;
}
// a consulta propriamente dita
public function queryMC( $query, $timeout=600 ) // timeout==0 = no cache
{
$this-errorClear();
$data = false;
try
{
if( $this-memcacheOK (int)$timeout 0 )// Se timeout==0
nao usa o cache
{
$key = md5( $query );
$data = $this-memcache-get( $key );
//echo !-- ## PEGOU DO MEMCACHE::: ;
//if( $data == false ) echo DATA RETURN FALSE---;
//echo $query.--\n;
}
if( $data == false )
{
//echo !-- NAO PEGOU DO MEMCACHE::: .$query.--\n;
$result = $this-dbh-query( $query, MYSQLI_STORE_RESULT );
if( $result == false )
{
throw new Exception( $this-dbh-error );
}
else
{
$data = array();
while( $row = $result-fetch_array( MYSQLI_BOTH ) )
{
$data[] = $row;
}
}
if( $this-memcacheOK (int)$timeout 0 ) // Se
timeout==0 nao usa o cache
{
$this-memcache-set( $key, $data, 0, $timeout );
}
$result-close();
unset( $result);
}
}
catch( Exception $e )
{
$this-errorMsg .=
DBQueryMC(.sysUtil::SYS_GS(last_sysaction).):
.$e-getMessage(). = .$query. [.$e-getTraceAsString().] );
$this-errorCode = $e-getCode();
$this-saveLogError();
$data = array();
}
return $data;
}
AH LEMBREI DE OUTRA COISA
usar o php com fast_cgi separado do apache(retirando o mod_php de
dentro dele) é melhor.
MAS USA O MEMCACHE CARA, do contrario pula da ponte... eheheh
boa sorte
AH LEMBREI TAMBEM:
--
- estao usando xcache, apc, ou coisa do tipo para o php ?
- e o memcache ? vai ou ta dificil ?
se nao usar cache e o memcache, faz o que eu disse, pega a 12 e se mata,
senao daqui a pouco tao falando que o mysql e o php nao presta.
nem comento dai ne.. problema de BIOS
-
Re: [FUG-BR] Servidor com load altíssimo
Em Sex, 2012-07-06 às 14:29 -0300, Leonardo Augusto escreveu: cara o lance do mysql persistente connections é no php.ini. (php.ini) mysql.allow_persistent = Off (voce deve estar com ON ali, bota off !! e testa ) E PELO AMOR DO BSD, INSTALA O MEMCACHE E COLOCA LA NAS QUERYES E NO SESSION DO PHP. e se o cara INCESTE que nao dá??? Tenta montar o /tmp na memoria. no /etc/rc.conf. tmpfms=YES tmpsize=512M boot na maquina... - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
Em Sex, 2012-07-06 às 14:24 -0300, Marcelo Gondim escreveu: Nervoso será que se eu compilasse o MySQL com essas opções ajudaria? WITH_PROC_SCOPE_PTH=yes Use process scope threads WITH_FAST_MUTEXES=yes Replace mutexes with spinlocks Humm pode ser... se v. tem thread swith muito rapido, o spinlock é uma boa... so testando - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
Mais uma Dá uma olhada no acesso aos discos. a luz de acesso ao disco tem que ficar PISCANDO e nao acesa... se estiver acesa, coloca no loader.conf a opcao: vm.kmem_size=16G (nao se esqueça das =) sendo 16G o dobro da memoria real... site de torrent mirror do TPB??? solta para nóis ai a url que o final de semana já está ai e um bom filme sempre é uma opcao... principalmente se for em portugues e dublado para as criancas... - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
Em 06/07/2012 15:07, nervoso escreveu: Mais uma Dá uma olhada no acesso aos discos. a luz de acesso ao disco tem que ficar PISCANDO e nao acesa... se estiver acesa, coloca no loader.conf a opcao: vm.kmem_size=16G (nao se esqueça das =) sendo 16G o dobro da memoria real... site de torrent mirror do TPB??? solta para nóis ai a url que o final de semana já está ai e um bom filme sempre é uma opcao... principalmente se for em portugues e dublado para as criancas... hehehe assim que estiver no ar posto aí pro pessoal. É um dos sites mais acessados e conhecidos ;) Na verdade a gente tá migrando ele da Holanda para a Russia porque fomos obrigados à deixar o Datacenter por ser um server de torrents. Na Russia só não podemos compartilhar conteúdo russo. Olha o status, mais um dado: Current Time: Friday, 06-Jul-2012 15:15:25 BRT Restart Time: Friday, 06-Jul-2012 15:14:16 BRT Parent Server Generation: 0 Server uptime: 1 minute 9 seconds Total accesses: 9468 - Total Traffic: 8.0 MB CPU Usage: u12.0781 s11.3594 cu0 cs0 - 34% CPU load 137 requests/sec - 118.0 kB/second - 880 B/request 1557 requests currently being processed, 86 idle workers WWCWWWCWWCCWCCWW W.WWWKWW_WWWK_WW _WWW_WWW_WWK_WCWW__WCWWWKWWW CWCWCWWWCWKWWWCW_WWC CW_WWCWC WW_WWC.W_WCCWWWC CCWCWWCWWWCWWC_WWWCC KWCWWKWCKWKKWWWC WWWKCW..WWWCWWWC KWWCWWWCWWW_CWK_CWWW K.W__KWWRCWWWKKWKWWK WKWWCWWWCWWWCWKCWWCW_WWWCWW_ WWWKWWWCWWWCWWCW WWKWCKWWWCCWCWWW WWWCKWWCCWWW WWCWWCWWWKWWW_CWWKKWWWCWWWCWWWKW WWWCWWWCWWWKWCWWCWW_ _KWCWW_WWWCCCWWW CWW_WKCC_WWW CCKWWCCWWKWWCWWW WCWWWKKWWWKWWCCC.WWKWKWW WWCWWCW_WWW.W_WKWWKWCCWW WWWKCWCWWCWWWKCWWWCW WWCWWC_WW.WWWCWC WWCWCWWW.CWK_W_WK_CWW_WW__WW_WWW_W__W_WW WW_WW___W___ Scoreboard Key: *|_|* Waiting for Connection, *|S|* Starting up, *|R|* Reading Request, *|W|* Sending Reply, *|K|* Keepalive (read), *|D|* DNS Lookup, *|C|* Closing connection, *|L|* Logging, *|G|* Gracefully finishing, *|I|* Idle cleanup of worker, *|.|* Open slot with no current process - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
BJ-Share !!! Em 6 de julho de 2012 15:20, Marcelo Gondim gon...@bsdinfo.com.brescreveu: Em 06/07/2012 15:07, nervoso escreveu: Mais uma Dá uma olhada no acesso aos discos. a luz de acesso ao disco tem que ficar PISCANDO e nao acesa... se estiver acesa, coloca no loader.conf a opcao: vm.kmem_size=16G (nao se esqueça das =) sendo 16G o dobro da memoria real... site de torrent mirror do TPB??? solta para nóis ai a url que o final de semana já está ai e um bom filme sempre é uma opcao... principalmente se for em portugues e dublado para as criancas... hehehe assim que estiver no ar posto aí pro pessoal. É um dos sites mais acessados e conhecidos ;) Na verdade a gente tá migrando ele da Holanda para a Russia porque fomos obrigados à deixar o Datacenter por ser um server de torrents. Na Russia só não podemos compartilhar conteúdo russo. Olha o status, mais um dado: Current Time: Friday, 06-Jul-2012 15:15:25 BRT Restart Time: Friday, 06-Jul-2012 15:14:16 BRT Parent Server Generation: 0 Server uptime: 1 minute 9 seconds Total accesses: 9468 - Total Traffic: 8.0 MB CPU Usage: u12.0781 s11.3594 cu0 cs0 - 34% CPU load 137 requests/sec - 118.0 kB/second - 880 B/request 1557 requests currently being processed, 86 idle workers WWCWWWCWWCCWCCWW W.WWWKWW_WWWK_WW _WWW_WWW_WWK_WCWW__WCWWWKWWW CWCWCWWWCWKWWWCW_WWC CW_WWCWC WW_WWC.W_WCCWWWC CCWCWWCWWWCWWC_WWWCC KWCWWKWCKWKKWWWC WWWKCW..WWWCWWWC KWWCWWWCWWW_CWK_CWWW K.W__KWWRCWWWKKWKWWK WKWWCWWWCWWWCWKCWWCW_WWWCWW_ WWWKWWWCWWWCWWCW WWKWCKWWWCCWCWWW WWWCKWWCCWWW WWCWWCWWWKWWW_CWWKKWWWCWWWCWWWKW WWWCWWWCWWWKWCWWCWW_ _KWCWW_WWWCCCWWW CWW_WKCC_WWW CCKWWCCWWKWWCWWW WCWWWKKWWWKWWCCC.WWKWKWW WWCWWCW_WWW.W_WKWWKWCCWW WWWKCWCWWCWWWKCWWWCW WWCWWC_WW.WWWCWC WWCWCWWW.CWK_W_WK_CWW_WW__WW_WWW_W__W_WW WW_WW___W___ Scoreboard Key: *|_|* Waiting for Connection, *|S|* Starting up, *|R|* Reading Request, *|W|* Sending Reply, *|K|* Keepalive (read), *|D|* DNS Lookup, *|C|* Closing connection, *|L|* Logging, *|G|* Gracefully finishing, *|I|* Idle cleanup of worker, *|.|* Open slot with no current process - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- Felipe N. Oliva * * *If 386BSD had been available when I started on Linux, Linux would probably never had happened. *Linus Torvalds - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
Em 06/07/2012 15:23, Felipe Nogueira Oliva escreveu: BJ-Share !!! Nada. Conheço eles também. Foram os primeiros à rodar. Até agora eles não voltaram. A gente até já migrou mas esse pau tá matando a gente. ahahahah Se eu não conseguir hoje resolver isso, infelizmente vou ter que jogar o Debian lá no servidor novo. :( Bem vou falar, é o manicomio-share.com ;) Em 6 de julho de 2012 15:20, Marcelo Gondim gon...@bsdinfo.com.brescreveu: Em 06/07/2012 15:07, nervoso escreveu: Mais uma Dá uma olhada no acesso aos discos. a luz de acesso ao disco tem que ficar PISCANDO e nao acesa... se estiver acesa, coloca no loader.conf a opcao: vm.kmem_size=16G (nao se esqueça das =) sendo 16G o dobro da memoria real... site de torrent mirror do TPB??? solta para nóis ai a url que o final de semana já está ai e um bom filme sempre é uma opcao... principalmente se for em portugues e dublado para as criancas... hehehe assim que estiver no ar posto aí pro pessoal. É um dos sites mais acessados e conhecidos ;) Na verdade a gente tá migrando ele da Holanda para a Russia porque fomos obrigados à deixar o Datacenter por ser um server de torrents. Na Russia só não podemos compartilhar conteúdo russo. Olha o status, mais um dado: Current Time: Friday, 06-Jul-2012 15:15:25 BRT Restart Time: Friday, 06-Jul-2012 15:14:16 BRT Parent Server Generation: 0 Server uptime: 1 minute 9 seconds Total accesses: 9468 - Total Traffic: 8.0 MB CPU Usage: u12.0781 s11.3594 cu0 cs0 - 34% CPU load 137 requests/sec - 118.0 kB/second - 880 B/request 1557 requests currently being processed, 86 idle workers WWCWWWCWWCCWCCWW W.WWWKWW_WWWK_WW _WWW_WWW_WWK_WCWW__WCWWWKWWW CWCWCWWWCWKWWWCW_WWC CW_WWCWC WW_WWC.W_WCCWWWC CCWCWWCWWWCWWC_WWWCC KWCWWKWCKWKKWWWC WWWKCW..WWWCWWWC KWWCWWWCWWW_CWK_CWWW K.W__KWWRCWWWKKWKWWK WKWWCWWWCWWWCWKCWWCW_WWWCWW_ WWWKWWWCWWWCWWCW WWKWCKWWWCCWCWWW WWWCKWWCCWWW WWCWWCWWWKWWW_CWWKKWWWCWWWCWWWKW WWWCWWWCWWWKWCWWCWW_ _KWCWW_WWWCCCWWW CWW_WKCC_WWW CCKWWCCWWKWWCWWW WCWWWKKWWWKWWCCC.WWKWKWW WWCWWCW_WWW.W_WKWWKWCCWW WWWKCWCWWCWWWKCWWWCW WWCWWC_WW.WWWCWC WWCWCWWW.CWK_W_WK_CWW_WW__WW_WWW_W__W_WW WW_WW___W___ Scoreboard Key: *|_|* Waiting for Connection, *|S|* Starting up, *|R|* Reading Request, *|W|* Sending Reply, *|K|* Keepalive (read), *|D|* DNS Lookup, *|C|* Closing connection, *|L|* Logging, *|G|* Gracefully finishing, *|I|* Idle cleanup of worker, *|.|* Open slot with no current process - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
Em 6 de julho de 2012 15:20, Marcelo Gondim gon...@bsdinfo.com.brescreveu: WWCWWWCWWCCWCCWW W.WWWKWW_WWWK_WW _WWW_WWW_WWK_WCWW__WCWWWKWWW CWCWCWWWCWKWWWCW_WWC CW_WWCWC WW_WWC.W_WCCWWWC CCWCWWCWWWCWWC_WWWCC KWCWWKWCKWKKWWWC WWWKCW..WWWCWWWC KWWCWWWCWWW_CWK_CWWW K.W__KWWRCWWWKKWKWWK WKWWCWWWCWWWCWKCWWCW_WWWCWW_ WWWKWWWCWWWCWWCW WWKWCKWWWCCWCWWW WWWCKWWCCWWW WWCWWCWWWKWWW_CWWKKWWWCWWWCWWWKW WWWCWWWCWWWKWCWWCWW_ _KWCWW_WWWCCCWWW CWW_WKCC_WWW CCKWWCCWWKWWCWWW WCWWWKKWWWKWWCCC.WWKWKWW WWCWWCW_WWW.W_WKWWKWCCWW WWWKCWCWWCWWWKCWWWCW WWCWWC_WW.WWWCWC WWCWCWWW.CWK_W_WK_CWW_WW__WW_WWW_W__W_WW WW_WW___W___ Bem carregado esse server aí, hein! Está usando Keep-alive? KeepAlive On MaxKeepAliveRequests 500 KeepAliveTimeout 2 -- Eduardo Schoedler - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
Em 06/07/2012 15:30, Eduardo Schoedler escreveu: Em 6 de julho de 2012 15:20, Marcelo Gondim gon...@bsdinfo.com.brescreveu: WWCWWWCWWCCWCCWW W.WWWKWW_WWWK_WW _WWW_WWW_WWK_WCWW__WCWWWKWWW CWCWCWWWCWKWWWCW_WWC CW_WWCWC WW_WWC.W_WCCWWWC CCWCWWCWWWCWWC_WWWCC KWCWWKWCKWKKWWWC WWWKCW..WWWCWWWC KWWCWWWCWWW_CWK_CWWW K.W__KWWRCWWWKKWKWWK WKWWCWWWCWWWCWKCWWCW_WWWCWW_ WWWKWWWCWWWCWWCW WWKWCKWWWCCWCWWW WWWCKWWCCWWW WWCWWCWWWKWWW_CWWKKWWWCWWWCWWWKW WWWCWWWCWWWKWCWWCWW_ _KWCWW_WWWCCCWWW CWW_WKCC_WWW CCKWWCCWWKWWCWWW WCWWWKKWWWKWWCCC.WWKWKWW WWCWWCW_WWW.W_WKWWKWCCWW WWWKCWCWWCWWWKCWWWCW WWCWWC_WW.WWWCWC WWCWCWWW.CWK_W_WK_CWW_WW__WW_WWW_W__W_WW WW_WW___W___ Bem carregado esse server aí, hein! Está usando Keep-alive? KeepAlive On MaxKeepAliveRequests 500 KeepAliveTimeout 2 Opa Eduardo :) Timeout 45 KeepAlive On MaxKeepAliveRequests 3000 KeepAliveTimeout 5 Achas que devo abaixar o MaxKeepAliveRequests e o KeepAliveTimeout? - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
2012/7/6 Marcelo Gondim gon...@bsdinfo.com.br Em 06/07/2012 15:30, Eduardo Schoedler escreveu: Em 6 de julho de 2012 15:20, Marcelo Gondim gon...@bsdinfo.com.br escreveu: WWCWWWCWWCCWCCWW W.WWWKWW_WWWK_WW _WWW_WWW_WWK_WCWW__WCWWWKWWW CWCWCWWWCWKWWWCW_WWC CW_WWCWC WW_WWC.W_WCCWWWC CCWCWWCWWWCWWC_WWWCC KWCWWKWCKWKKWWWC WWWKCW..WWWCWWWC KWWCWWWCWWW_CWK_CWWW K.W__KWWRCWWWKKWKWWK WKWWCWWWCWWWCWKCWWCW_WWWCWW_ WWWKWWWCWWWCWWCW WWKWCKWWWCCWCWWW WWWCKWWCCWWW WWCWWCWWWKWWW_CWWKKWWWCWWWCWWWKW WWWCWWWCWWWKWCWWCWW_ _KWCWW_WWWCCCWWW CWW_WKCC_WWW CCKWWCCWWKWWCWWW WCWWWKKWWWKWWCCC.WWKWKWW WWCWWCW_WWW.W_WKWWKWCCWW WWWKCWCWWCWWWKCWWWCW WWCWWC_WW.WWWCWC WWCWCWWW.CWK_W_WK_CWW_WW__WW_WWW_W__W_WW WW_WW___W___ Bem carregado esse server aí, hein! Está usando Keep-alive? KeepAlive On MaxKeepAliveRequests 500 KeepAliveTimeout 2 Opa Eduardo :) Timeout 45 KeepAlive On MaxKeepAliveRequests 3000 KeepAliveTimeout 5 Achas que devo abaixar o MaxKeepAliveRequests e o KeepAliveTimeout? Toda tentativa é válida! =) Ainda é o apache que está matando sua CPU? ou agora tem outro processo? -- Eduardo Schoedler - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidor com load altíssimo
Em 06/07/2012 16:03, Eduardo Schoedler escreveu: 2012/7/6 Marcelo Gondim gon...@bsdinfo.com.br Em 06/07/2012 15:30, Eduardo Schoedler escreveu: Em 6 de julho de 2012 15:20, Marcelo Gondim gon...@bsdinfo.com.br escreveu: WWCWWWCWWCCWCCWW W.WWWKWW_WWWK_WW _WWW_WWW_WWK_WCWW__WCWWWKWWW CWCWCWWWCWKWWWCW_WWC CW_WWCWC WW_WWC.W_WCCWWWC CCWCWWCWWWCWWC_WWWCC KWCWWKWCKWKKWWWC WWWKCW..WWWCWWWC KWWCWWWCWWW_CWK_CWWW K.W__KWWRCWWWKKWKWWK WKWWCWWWCWWWCWKCWWCW_WWWCWW_ WWWKWWWCWWWCWWCW WWKWCKWWWCCWCWWW WWWCKWWCCWWW WWCWWCWWWKWWW_CWWKKWWWCWWWCWWWKW WWWCWWWCWWWKWCWWCWW_ _KWCWW_WWWCCCWWW CWW_WKCC_WWW CCKWWCCWWKWWCWWW WCWWWKKWWWKWWCCC.WWKWKWW WWCWWCW_WWW.W_WKWWKWCCWW WWWKCWCWWCWWWKCWWWCW WWCWWC_WW.WWWCWC WWCWCWWW.CWK_W_WK_CWW_WW__WW_WWW_W__W_WW WW_WW___W___ Bem carregado esse server aí, hein! Está usando Keep-alive? KeepAlive On MaxKeepAliveRequests 500 KeepAliveTimeout 2 Opa Eduardo :) Timeout 45 KeepAlive On MaxKeepAliveRequests 3000 KeepAliveTimeout 5 Achas que devo abaixar o MaxKeepAliveRequests e o KeepAliveTimeout? Toda tentativa é válida! =) Ainda é o apache que está matando sua CPU? ou agora tem outro processo? O apache já aliviou quando eu desabilitei o ssl e deixei só o http. Mas tipo quando habilitamos o chamado announce dos torrents aí que o bicho pega rsrsrsr Além disso o bicho pega quando abre a porteira e todo mundo acessa o site ahahahaha Mas estamos aqui na batalha. :D - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
