[FUG-BR] Limitar um Processo

[Renato Frederick]

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 <egypcio em googlemail.com>
escreveu:

> 2016-11-16 12:26 GMT-03:00 Renato Frederick <renato em 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.neto em 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 <
> > renato em 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
>