Opa, nada, máquina roda no vmware, foi metade do kernel fora + add pf e ipfw, uso o driver de rede enhanced + openvm-tools, então praticamente só precisa suporte a usb, à placa vmxnet e ao da/cdrom.
Mas parece que é algo mesmo lá na conexão ao storage via iscsi, dei um deny na 80 e 3306 e o snmp está aceitável, o load em 1.... dando o deny parou de servir pagina e banco, que sao os que mais usam o disco. A cada 5min o script fica fazendo query neste disco, então se estiver com problema, vai ocupar cpu até morrer ou sair o processo. Agora é jogar a bomba em quem comprou este storage, eu chamo de "torre com disco", pois é uma porqueira que vem um linux embeed, 4 placas de rede para fazer jumbo frame/aggregation, suporte a iscsi e nfs. Particularmente um FREENAS em um servidor de grife com HDS SAS + ZFS atenderia. Mas antes vou mandar o vmware criar um disco local no host que roda o ESX e clonar o iscsi usando dump/restore ou tar. Se tudo funcionar, o que falei acima está provado. Agradeço as dicas, sempre bom ouvir opções :) Renato Frederick Consultor em TI http://about.me/renatofrederick Skype: renatofrederick +55 31 99123 - 3006 +55 31 2523 - 0686 Em 16 de novembro de 2016 16:36, Vinícius Zavam <egyp...@googlemail.com> escreveu: > 2016-11-16 12:26 GMT-03:00 Renato Frederick <ren...@frederick.eti.br>: > > > Opa Otacilio, vou olhar. > > > > Por enquanto o que vi aqui é que do nada os scripts shell que fazem a > saida > > lá no snmp fazem ele ocupar cpu. > > Se eu comento todas as mibs personalizadas, deixo o snmp padrao lá do > > BSD(cpu, disco, rede, ram) fica OK. > > Claro que prá complicar todos os scripts(nada demais, é por ex, ver > tamanho > > de processos em zombie, roda um ps ax, uns greps, etc.... ver num de > > conexao na porta 1234, roda netstat, cut, greop....) rodam manualmente > > normal. > > Estou vendo se é algo no i/o do storage que pode estar levando os > scripts a > > ficarem em state D(esperando retorno do disco), quando em produção. > > Só isto que penso que do nada faz 2 máquinas ficarem com ele usando alta > > cpu. > > > > > > > > Renato Frederick > > Consultor em TI > > http://about.me/renatofrederick > > Skype: renatofrederick > > +55 31 99123 - 3006 > > +55 31 2523 - 0686 > > > > Em 15 de novembro de 2016 00:47, Otacílio de Araújo Ramos Neto < > > otacilio.n...@bsd.com.br> escreveu: > > > > > De uma olhada na manpage do rctl . Talvez o parâmetro pcpu eh o que > você > > > procura. > > > > > > []'s > > > -Otacilio > > > > > > Em seg, 14 de nov de 2016 23:33, Renato Frederick < > > ren...@frederick.eti.br > > > > > > > escreveu: > > > > > > > Pessoal, boa noite. > > > > > > > > Eu estou temporariamente com um problema no SNMP, que está usando > toda > > a > > > > CPU. > > > > Preciso temporariamente dar uma segurada em quanto da CPU ela vai > usar, > > > > pois preciso do monitoramento, porém não consigo analisar o problema, > > > > deixar a máquina rodando e o snmp. > > > > > > > > 12216 root 1 93 0 83784K 42268K CPU0 0 6:54 > > 67.96% > > > > bsnmpd > > > > > > > > Tem como eu limitar, no exemplo acima, que o PID 12216 use 20% das > CPU? > > > > > > > > Ou eu vou ter que criar classe lá no login.conf, etc etc? Queria algo > > > > simples, na mão mesmo segurar o quanto de cpu ele vai usar, ate eu > ver > > > se é > > > > algum script que ele chama. > > > > > > > > O caso é meio chato pois eu criei diversas MIBS, tem script que por > > > exemplo > > > > analisa o spool de email, ai o cacti remoto lê esta MIB, joga para um > > > > template e gera gráfico. > > > > > > > > Fico agradecido se puderem me ajudar e desejo bom feriado(prá quem > > puder > > > > descansar né). > > > > > > > > > > > > > > > > > > > > Renato Frederick > > > > espero que não tenhas personalizado demais essa máquina; rctl(8) pede > opções adicionais/compiladas em kernel, por exemplo. > > salvo minha ignorância, e com todo respeito, não creio que tu [frederick] > terias problema para isolar o processo em jail, SE FOSSE NECESSÁRIO. quando > recomendei a utilização do cpuset(1) como maneira de aplicar *limitações* > no processo, eu já tinha conciência de que não é algo mandatório que fosse > algo numa jail. > > boa sorte :) > > aos que se doeram pelo cpuset(1), sinto muito se não utilizei o termo *cpu > affinity* pra ser algo mais "cult bacaninha". lapdm. > > > -- > Vinícius Zavam > keybase.io/egypcio/key.asc > ------------------------- > 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
