Re: [FUG-BR] Dúvida ZFS

[Tiago Drumond]

On 06-11-2014 16:23, Samuel Peres wrote:


On 11/4/2014 2:45 PM, Jorge Petry wrote:

Olá Sasmuel.

Você pode add sim.
Use  o comando:
zpool add -f  POOL /dev/NOVOHD

Abraço.

Em 27 de outubro de 2014 11:55, Samuel Peres 


escreveu:


Saudações a todos,

Tenho um pool ZFS configurado em raidz-1 com 7 HDs, precisava adicionar
mais HDs a  esse pool. Vi que tem o comando zpool add, mas pelo que 
vi na
documentação, não consigo adicionar, vou ter que recriar o pool ou 
criar um

novo pool com os HDs recém adicionados. É isso mesmo?

Obrigado!

Samuel Peres
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd






Olá Jorge,

Desculpe pela eterna demora, vou dar uma olhada no parâmetro "-f".

Obrigado!

Samuel Peres
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd


Olá pessoal.

Até onde eu sei pra você adicionar discos a um pool raidz você terá de 
adicionar multiplos da quantidade de discos atuais.

Se você tem 7 discos, só conseguiria adicionar se fosse mais 7 discos.

--

Att,
Tiago Drumond
Analista de Suporte
ti...@freebsdbrasil.com.br
31 3516 0800

-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] [Off-topic] pf não redireciona com route-to

[Renato Botelho]

> On Nov 6, 2014, at 16:05, spiderslack  wrote:
> 
> 
> 
> >Certo, então na minha opinião você deveria usar uma regra de rdr pra fazer 
> >esse redirect, e tem que lembrar de negar o IP do proxy, seria algo mais ou 
> >menos assim:
> 
>> rdr pass on re1 inet proto tcp from re1:network to ! IP_DO_PROXY port 80 -> 
>> IP_DO_PROXY port 80
> 
> --
> Obrigado por responder Renato, Mas não funciona o redirecioamento até 
> funciona,porém ele muda o destino do pacote vai com destino ao mara cache e 
> nao ao site o site vai no header htttp
> 
> Eu acho que descobri a razão do problema, mas e apenas uma teoria. Imaginemos 
> que um cliente faz um request na porta 80 com destino ao google
> 
> O mara cache fica em modo transparente ou seja como o modulo tproxy funciona,
> Quando o request passa pelo meu freebsd com destino ao google e porta de 
> destino a 80 ele usa o "route-to" redireciona para o mara cache porque o 
> destino do pacote NÃO está diretamente conectado.
> O mara cache faz o spoofing do ip do google e fecha o three way handshake com 
> o cliente.
> A partir dai o Mara cache não possuir o objeto em cache abre uma nova conexão 
> para o google para buscar este objeto.
> O mara cache envia um SYN para o google com origem no ip do cliente não no 
> seu proprio IP(isso para quando o pacote voltar com destino ao cliente e não 
> ter um unico ip acessando a internet)
> O google responde com um SYN/ACK para o ip cliente "spoofado" pelo mara cache.
> Quando esse SYN/ACK chega no freeBSD ele possue a regra para o retorno 
> devolver ao mara cache conforme abaixo.
> 
> pass in log quick on re0route-to (alc0 200.1.1.1) proto tcp from any port 
> 80 to $rede_lan
> 
> A minha teoria e aqui meu freebsd esta diretamente conectado ao cliente então 
> nao usa o "route-to", o "route-to" somente seria usado para destino não 
> diretamente conectado(estou preparando um ambiente para testar isso, assim 
> que tiver resposta retorno) e o pacote SYN/ACK chega ao cliente(chega porque 
> monitorei via tcpdump).
> E o cliente recebe um pacote fora de contexto/ordem tipo ele anteriormente 
> fechou o three way handshake com o google spoofado pelo mara cache e ai chega 
> outro SYN/ACK ai ele Reseta a conexão.
> 
> Tudo que eu descrevi acima eu constatei olhando os logs do tcpdump. E na 
> interface onde esta o proxy mara cache vejo varios pacotes SYN saindo e os 
> SYN/ACK indo direto para o cliente.
> 
> Nao uso o rdr porque não tenho nat nesse freebsd somente ip's válidos. Se 
> alguém tiver alguma dica ou passou por algo parecido desde já agradeço.

Não tinha me ligado que vc tava usando TPROXY, falha minha. Essa fico devendo 
pq nunca pus a mão.

--
Renato Botelho

-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] Dúvida ZFS

[Samuel Peres]

On 11/4/2014 2:45 PM, Jorge Petry wrote:

Olá Sasmuel.

Você pode add sim.
Use  o comando:
zpool add -f  POOL /dev/NOVOHD

Abraço.

Em 27 de outubro de 2014 11:55, Samuel Peres 
escreveu:


Saudações a todos,

Tenho um pool ZFS configurado em raidz-1 com 7 HDs, precisava adicionar
mais HDs a  esse pool. Vi que tem o comando zpool add, mas pelo que vi na
documentação, não consigo adicionar, vou ter que recriar o pool ou criar um
novo pool com os HDs recém adicionados. É isso mesmo?

Obrigado!

Samuel Peres
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd






Olá Jorge,

Desculpe pela eterna demora, vou dar uma olhada no parâmetro "-f".

Obrigado!

Samuel Peres
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

[FUG-BR] Fwd: Re: [Off-topic] pf não redireciona com route-to

[spiderslack]

 >Certo, então na minha opinião você deveria usar uma regra de rdr pra fazer 
esse redirect, e tem que lembrar de negar o IP do proxy, seria algo mais ou menos 
assim:


rdr pass on re1 inet proto tcp from re1:network to ! IP_DO_PROXY port 80 -> 
IP_DO_PROXY port 80


--
Obrigado por responder Renato, Mas não funciona o redirecioamento até 
funciona,porém ele muda o destino do pacote vai com destino ao mara cache e nao 
ao site o site vai no header htttp

Eu acho que descobri a razão do problema, mas e apenas uma teoria. Imaginemos 
que um cliente faz um request na porta 80 com destino ao google

O mara cache fica em modo transparente ou seja como o modulo tproxy funciona,
Quando o request passa pelo meu freebsd com destino ao google e porta de destino a 80 ele 
usa o "route-to" redireciona para o mara cache porque o destino do pacote NÃO 
está diretamente conectado.
O mara cache faz o spoofing do ip do google e fecha o three way handshake com o 
cliente.
A partir dai o Mara cache não possuir o objeto em cache abre uma nova conexão 
para o google para buscar este objeto.
O mara cache envia um SYN para o google com origem no ip do cliente não no seu 
proprio IP(isso para quando o pacote voltar com destino ao cliente e não ter um 
unico ip acessando a internet)
O google responde com um SYN/ACK para o ip cliente "spoofado" pelo mara cache.
Quando esse SYN/ACK chega no freeBSD ele possue a regra para o retorno devolver 
ao mara cache conforme abaixo.

pass in log quick on re0route-to (alc0 200.1.1.1) proto tcp from any port 
80 to $rede_lan

A minha teoria e aqui meu freebsd esta diretamente conectado ao cliente então nao usa o 
"route-to", o "route-to" somente seria usado para destino não diretamente 
conectado(estou preparando um ambiente para testar isso, assim que tiver resposta retorno) e o 
pacote SYN/ACK chega ao cliente(chega porque monitorei via tcpdump).
E o cliente recebe um pacote fora de contexto/ordem tipo ele anteriormente 
fechou o three way handshake com o google spoofado pelo mara cache e ai chega 
outro SYN/ACK ai ele Reseta a conexão.

Tudo que eu descrevi acima eu constatei olhando os logs do tcpdump. E na 
interface onde esta o proxy mara cache vejo varios pacotes SYN saindo e os 
SYN/ACK indo direto para o cliente.

Nao uso o rdr porque não tenho nat nesse freebsd somente ip's válidos. Se 
alguém tiver alguma dica ou passou por algo parecido desde já agradeço.

Att.




-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] Valor aconselhavel para variável HZ

[Luiz Otavio O Souza]

On 6 November 2014 12:13, Fabricio Lima wrote:
> + ab (apache bench)
>
> Lembrando q para maquinas virtuais, reduzem este parametro.

Correto.

>
> Veja isso tb:
>
> However, in FreeBSD 9, the "dynamic tick mode" (aka "tickless mode") is the
> default, controlled by the kern.eventtimer.periodic setting which defaults
> to 0 (read: tickless mode).
>
> This year FreeBSD 10-HEAD got a new reincarnation of the kernel event
> timers backend callout(9)
> , no more
> limited by or even related to Hz rate.

FreeBSD head é o 11 :)

E essa alteração não tem relação direta com o valor do HZ.

callout(9) é só uma implementação de timers utilizada no kernel, que
antes se baseava no valor do HZ para os cálculos (internos) de
timeout. Ex.: execute a seguinte rotina/função após 0.5 segundos.
Nesse caso o tempo era convertido em ticks levando em conta o valor de
HZ do sistema. Isso era simples mas limitava o menor tempo 'util' para
1 tick (se HZ = 100, 1 tick = 1 seg / 100, se HZ=1000, 1 tick = 1 seg
/ 1000, ...).

O novo sistema de callout é mais preciso, permite o uso de frações de
tempo muito pequenas e por isso o valor de HZ do sistema não serve
mais para descrever esses pequenos valores.

O tickless ajuda na ecomonia. Ative o periodic e veja a diferença com
o systat -vm 1. No tickless o sistema só acorda quando existe alguma
coisa para ser feita (mesmo com alto valor de HZ) e com o periodic o
interrupt handler do timer vai rodar na freqüência determinada por HZ
(em geral um desperdício - esse knob so existe para contornar bugs em
determinados chipsets).

Att.,
Luiz
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] Valor aconselhavel para variável HZ

[Luiz Otavio O Souza]

2014-11-06 12:29 GMT-02:00 Eduardo Schoedler:
> 2014-11-06 11:55 GMT-02:00 Paulo Henrique - BSDs Brasil
> :
>> Pessoal,  pelo que compreendi, quanto mais alto o valor do HZ, mais rápido o 
>> sistema vai responder requisições de tarefas do kernel e do hardware.
>> Embora como negativamente menor será o tempo disponível para limpar a 
>> sujeira de outro processo.
>> Diminui a latência da rede e o tempo de resposta a uma requisição.
>>
>> Nesse sábado vou fazer uns testes aumentando o hz o máximo possível e ver 
>> como será o comportamento do sistema, depois posto os resultados.
>>
>> Contudo estou na dúvida de como fazer para verificar isso, o unixbench seria 
>> uma alternativa?
>
> Se não estou enganado, o aumento de HZ auxilia também no shaping, pois
> há maior quantidade de ciclos.
>

O HZ em geral diminui a latencia, pois como seu processo vai rodar
mais vezes por segundo as chances de você atender uma interrupção mais
rapidamente aumenta.

Porém há um tradeoff que você precisa analisar aqui, pois o context
switch é um processo lento e caro para o sistema, então a performance
não escala na mesmo proporção que você aumenta o HZ (chega um momento
onde sua CPU vai estar mais ocupada fazendo context switch do que
trabalhando com seus processos).

Por isso em aplicações onde o context switch é ainda mais dispendioso
para o sistema (como em guest virtualizados), diminuir o HZ ajuda.

Att.,
Luiz
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] Intencionalmente derrubando desempenho de CPU.

[Luiz Otavio O Souza]

2014-11-05 23:40 GMT-02:00 Joao Rocha Braga Filho:
> Dando uma pesquisada no powerd descobri algumas coisas interessantes.
>
> Tem como diminuir o clock do processador à mão.
>
> Com o seguinte comando vi o clock atual e as possibilidades:
>
> root:[748] sysctl -a | grep dev.cpu...freq
> dev.cpu.0.freq: 1093
> dev.cpu.0.freq_levels: 2500/30940 2187/27072 1875/23205 1562/19337
> 1250/18480 1093/16170
>
>
> Note que já reduzi ao mínimo. Como fiz isto? Assim:
>
> root:[747] sysctl dev.cpu.0.freq=1093
> dev.cpu.0.freq: 1093 -> 1093


Joao,

Existem duas partes trabalhando juntas aqui para fazer isso funcionar.

A primeira é baseada no cpufreq(4), uma interface definida no FreeBSD
para exportar as funcionalidades relacionadas a controle de clock da
CPU (freqüências suportadas, freqüência atual e a possibilidade de
setar a freqüência para um novo valor) e isso de uma maneira
independente da tecnologia, marca ou modelo da CPU.

A segunda parte é o powerd(8), um daemon que captura as informações
relevantes do seu sistema para ajustar dinamicamente a freqüência da
CPU (utilizando as funções exportadas pelo cpufreq(4)).

Então, para um ajuste manual, apenas o suporte do cpufreq(4) é o
bastante para que você possa configurar a freqüência da CPU 'na mão '
via sysctl(8).

Já o powerd(8) vai tentar fazer as coisas por você de acordo com o
perfil que você selecionar.

O uso de C-states (citado em outra resposta) aumenta a latencia do
sistema (o tempo que leva entre uma interrupção e a respectiva
resposta do sistema), mas pode ser interessante quando tudo o que se
quer é economia.

>
>
> Como verifiquei se funcionou? Pelo top, vendo o tempo de idle diminuir, pelo
> barulho do ventilador de CPU diminuir, e pela temperatura do processador
> cair
> mais de 10 graus C.
>
> root:[749] sysctl -a | grep dev.cpu...temperature:
> dev.cpu.0.temperature: 47,0C
> dev.cpu.1.temperature: 47,0C
> dev.cpu.2.temperature: 47,0C
> dev.cpu.3.temperature: 47,0C
>
> Em geral o meu computador já tem desempenho mais do que o suficiente
> para o meu dia a dia. Eu gostaria de ter mais memória.
>
> O powerd parece fazer besteira, pois parece não entender que se tratam
> de 4 núcleos.

Não foi porque você setou manualmente a freqüência da cpu 0 ?


>
>
> Eu também brinquei um pouco de parar HDs:
>
> root:[773] atacontrol spindown ad8 60
> root:[774] atacontrol spindown ad8
> ad8: spin down after 60 seconds idle
>
>
>
> Bibliografia:
>
> https://forums.freebsd.org/threads/howto-freebsd-cpu-scaling-and-power-saving.172/
>
> man pages.
>
>
> Será que vou baixar a conta de luz?

Provavelmente... se você rodar tempo suficiente usando um perfil bem
econômico. Se o valor vai ser perceptível na conta  é outra conversa.

Um micro comum (básico) gasta cerca de R$ 40,00 por mês de energia
(ligado 24 x 7), talvez você consiga reduzir um pouco esse valor.

Agora se você quer economia de verdade e caso seja possível para o seu
perfil de uso, mude seu 'home' server pra ARM ou MIPS e veja o consumo
cair para um decimo do que você usa hoje (consumo aproximado de 5W -
tenho uma RPi no alarme de casa que no ultimo teste rodou mais de 6
horas numa bateria de 12V 7Ah).

Att.,
Luiz
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] Valor aconselhavel para variável HZ

[Eduardo Schoedler]

2014-11-06 11:55 GMT-02:00 Paulo Henrique - BSDs Brasil
:
> Pessoal,  pelo que compreendi, quanto mais alto o valor do HZ, mais rápido o 
> sistema vai responder requisições de tarefas do kernel e do hardware.
> Embora como negativamente menor será o tempo disponível para limpar a sujeira 
> de outro processo.
> Diminui a latência da rede e o tempo de resposta a uma requisição.
>
> Nesse sábado vou fazer uns testes aumentando o hz o máximo possível e ver 
> como será o comportamento do sistema, depois posto os resultados.
>
> Contudo estou na dúvida de como fazer para verificar isso, o unixbench seria 
> uma alternativa?

Se não estou enganado, o aumento de HZ auxilia também no shaping, pois
há maior quantidade de ciclos.

-- 
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] Valor aconselhavel para variável HZ

[Fabricio Lima]

+ ab (apache bench)

Lembrando q para maquinas virtuais, reduzem este parametro.

Veja isso tb:

However, in FreeBSD 9, the "dynamic tick mode" (aka "tickless mode") is the
default, controlled by the kern.eventtimer.periodic setting which defaults
to 0 (read: tickless mode).

This year FreeBSD 10-HEAD got a new reincarnation of the kernel event
timers backend callout(9)
, no more
limited by or even related to Hz rate.

[ ]'s
Fabricio Lima
When your hammer is C++, everything begins to look like a thumb.

2014-11-06 11:55 GMT-02:00 Paulo Henrique - BSDs Brasil <
paulo.rd...@bsd.com.br>:

>
>
> Enviado do meu smartphone Sony Xperia™
>
>  Fabricio Lima escreveu 
>
> > Edinilson, vc está certo...
> > eu tb mexia mais nisso na epoca do 6, 7, 8..
> >
> > Hj eles ajustaram tanta coisa (9 e 10)
> > q talvez o default seja melhor q um 7 tunado...
> >
> > (minha documentaçao caducou)
> >
> > testar, testar, testar...
> >
> > [ ]'s
> > Fabricio Lima
> > When your hammer is C++, everything begins to look like a thumb.
> >
> > 2014-11-05 16:44 GMT-02:00 Edinilson - ATINET :
> >
> > > - Original Message - From: "Paulo Henrique - BSDs" <
> > >> paulo.rd...@bsd.com.br>
> > >> To: ""Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)"" <
> > >> freebsd@fug.com.br>
> > >> Sent: Wednesday, November 05, 2014 3:58 PM
> > >> Subject: [FUG-BR] Valor aconselhavel para variável HZ
> > >>
> > >> Saudações,
> > >>
> > >> Gostaria de saber se alguém trabalha com a variável HZ com o valor
> > >> superior a 2000, caso sim o ambiente fica estável, há uma melhora no
> > >> desempenho do sistema e da rede ?
> > >> Sei que a mesma interfere quanto ao uso da bateria em portáteis
> contudo a
> > >> duvida é restrita a servidores.
> > >> Aumentar o valor da mesma em um servidor com 12 Cores / 24 Threads com
> > >> 32Gbytes de ram melhorará o desempenho.
> > >> Abaixo tem os dados do sistema atualmente.
> > >> O HZ do sistema está em 2000.
> > >>
> > >> uname -a
> > >> FreeBSD x 10.0-STABLE FreeBSD 10.0-STABLE #0 r269344: Thu Jul 31
> > >> 14:39:46 BRT 2014
> > >> netstat -m
> > >> yyy@x:/usr/obj/usr/src/sys/XXX amd64
> > >> 11204/15571/26775 mbufs in use (current/cache/total)
> > >> 1023/9825/10848/2036062 mbuf clusters in use (current/cache/total/max)
> > >> 1023/9512 mbuf+clusters out of packet secondary zone in use
> > >> (current/cache)
> > >> 0/548/548/1018031 4k (page size) jumbo clusters in use
> > >> (current/cache/total/max)
> > >> 0/0/0/301638 9k jumbo clusters in use (current/cache/total/max)
> > >> 0/0/0/169671 16k jumbo clusters in use (current/cache/total/max)
> > >> 4847K/25734K/30581K bytes allocated to network (current/cache/total)
> > >> 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
> > >> 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters)
> > >> 0/0/0 requests for jumbo clusters delayed (4k/9k/16k)
> > >> 0/0/0 requests for jumbo clusters denied (4k/9k/16k)
> > >> 0 requests for sfbufs denied
> > >> 0 requests for sfbufs delayed
> > >> 9966280 requests for I/O initiated by sendfile
> > >>
> > >> uptime
> > >> 15:47 up 86 days, 19:40, 1 user, load averages: 8,15 8,86 9,27
> > >>
> > >>
> > >> Alguns tunnings que já foi feito no sistema.
> > >>
> > >> # $FreeBSD: stable/10/etc/sysctl.conf 112200 2003-03-13 18:43:50Z mux
> $
> > >> #
> > >> # This file is read when going to multi-user and its contents piped
> thru
> > >> # ``sysctl'' to adjust kernel values. ``man 5 sysctl.conf'' for
> details.
> > >> #
> > >>
> > >> # Uncomment this to prevent users from seeing information about
> processes
> > >> that
> > >> # are being run under another UID.
> > >> #security.bsd.see_other_uids=0
> > >>
> > >> kern.maxfiles=100
> > >>
> > >> # Otimizacoes de rede.
> > >> #kern.ipc.nmbclusters=131072 # 128Mb para buffer de rede - Ficou
> instavel
> > >> valor definido pelo sistema.
> > >> kern.ipc.maxsockbuf=33554432
> > >> net.inet.tcp.sendbuf_max=33554432
> > >> net.inet.tcp.recvbuf_max=33554432
> > >> net.inet.tcp.sendspace=1048576 # default 65536
> > >> net.inet.tcp.recvspace=1048576 # default 32768
> > >> net.inet.tcp.sendbuf_inc=1048576 # 8192 default
> > >> net.inet.tcp.recvbuf_inc=1048576 # 16384 default
> > >> kern.ipc.somaxconn=4096 # 128 default
> > >> net.inet.tcp.syncache.rexmtlimit=1
> > >> net.inet.tcp.syncookies=1
> > >>
> > >> # COnfigura▒▒es de Seguran▒a
> > >> # General Security and DoS mitigation.
> > >> net.inet.ip.check_interface=1 # verify packet arrives on correct
> interface
> > >> net.inet.ip.portrange.randomized=1 # randomize outgoing upper ports
> > >> net.inet.ip.process_options=0 # IP options in the incoming packets
> will
> > >> be ignored
> > >> net.inet.ip.random_id=1 # assign a random IP_ID to each packet leaving
> > >> the system
> > >> net.inet.ip.redirect=0 # do not send IP redirects
> > >> net.inet.ip.accept_sourceroute=0 # drop source routed packets since
> they
> > >> can no

Re: [FUG-BR] Valor aconselhavel para variável HZ

[Paulo Henrique - BSDs Brasil]

Enviado do meu smartphone Sony Xperia™

 Fabricio Lima escreveu 

> Edinilson, vc está certo...
> eu tb mexia mais nisso na epoca do 6, 7, 8..
> 
> Hj eles ajustaram tanta coisa (9 e 10)
> q talvez o default seja melhor q um 7 tunado...
> 
> (minha documentaçao caducou)
> 
> testar, testar, testar...
> 
> [ ]'s
> Fabricio Lima
> When your hammer is C++, everything begins to look like a thumb.
> 
> 2014-11-05 16:44 GMT-02:00 Edinilson - ATINET :
> 
> > - Original Message - From: "Paulo Henrique - BSDs" <
> >> paulo.rd...@bsd.com.br>
> >> To: ""Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)"" <
> >> freebsd@fug.com.br>
> >> Sent: Wednesday, November 05, 2014 3:58 PM
> >> Subject: [FUG-BR] Valor aconselhavel para variável HZ
> >>
> >> Saudações,
> >>
> >> Gostaria de saber se alguém trabalha com a variável HZ com o valor
> >> superior a 2000, caso sim o ambiente fica estável, há uma melhora no
> >> desempenho do sistema e da rede ?
> >> Sei que a mesma interfere quanto ao uso da bateria em portáteis contudo a
> >> duvida é restrita a servidores.
> >> Aumentar o valor da mesma em um servidor com 12 Cores / 24 Threads com
> >> 32Gbytes de ram melhorará o desempenho.
> >> Abaixo tem os dados do sistema atualmente.
> >> O HZ do sistema está em 2000.
> >>
> >> uname -a
> >> FreeBSD x 10.0-STABLE FreeBSD 10.0-STABLE #0 r269344: Thu Jul 31
> >> 14:39:46 BRT 2014
> >> netstat -m
> >> yyy@x:/usr/obj/usr/src/sys/XXX amd64
> >> 11204/15571/26775 mbufs in use (current/cache/total)
> >> 1023/9825/10848/2036062 mbuf clusters in use (current/cache/total/max)
> >> 1023/9512 mbuf+clusters out of packet secondary zone in use
> >> (current/cache)
> >> 0/548/548/1018031 4k (page size) jumbo clusters in use
> >> (current/cache/total/max)
> >> 0/0/0/301638 9k jumbo clusters in use (current/cache/total/max)
> >> 0/0/0/169671 16k jumbo clusters in use (current/cache/total/max)
> >> 4847K/25734K/30581K bytes allocated to network (current/cache/total)
> >> 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
> >> 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters)
> >> 0/0/0 requests for jumbo clusters delayed (4k/9k/16k)
> >> 0/0/0 requests for jumbo clusters denied (4k/9k/16k)
> >> 0 requests for sfbufs denied
> >> 0 requests for sfbufs delayed
> >> 9966280 requests for I/O initiated by sendfile
> >>
> >> uptime
> >> 15:47 up 86 days, 19:40, 1 user, load averages: 8,15 8,86 9,27
> >>
> >>
> >> Alguns tunnings que já foi feito no sistema.
> >>
> >> # $FreeBSD: stable/10/etc/sysctl.conf 112200 2003-03-13 18:43:50Z mux $
> >> #
> >> # This file is read when going to multi-user and its contents piped thru
> >> # ``sysctl'' to adjust kernel values. ``man 5 sysctl.conf'' for details.
> >> #
> >>
> >> # Uncomment this to prevent users from seeing information about processes
> >> that
> >> # are being run under another UID.
> >> #security.bsd.see_other_uids=0
> >>
> >> kern.maxfiles=100
> >>
> >> # Otimizacoes de rede.
> >> #kern.ipc.nmbclusters=131072 # 128Mb para buffer de rede - Ficou instavel
> >> valor definido pelo sistema.
> >> kern.ipc.maxsockbuf=33554432
> >> net.inet.tcp.sendbuf_max=33554432
> >> net.inet.tcp.recvbuf_max=33554432
> >> net.inet.tcp.sendspace=1048576 # default 65536
> >> net.inet.tcp.recvspace=1048576 # default 32768
> >> net.inet.tcp.sendbuf_inc=1048576 # 8192 default
> >> net.inet.tcp.recvbuf_inc=1048576 # 16384 default
> >> kern.ipc.somaxconn=4096 # 128 default
> >> net.inet.tcp.syncache.rexmtlimit=1
> >> net.inet.tcp.syncookies=1
> >>
> >> # COnfigura▒▒es de Seguran▒a
> >> # General Security and DoS mitigation.
> >> net.inet.ip.check_interface=1 # verify packet arrives on correct interface
> >> net.inet.ip.portrange.randomized=1 # randomize outgoing upper ports
> >> net.inet.ip.process_options=0 # IP options in the incoming packets will
> >> be ignored
> >> net.inet.ip.random_id=1 # assign a random IP_ID to each packet leaving
> >> the system
> >> net.inet.ip.redirect=0 # do not send IP redirects
> >> net.inet.ip.accept_sourceroute=0 # drop source routed packets since they
> >> can not be trusted
> >> net.inet.ip.sourceroute=0 # if source routed packets are accepted the
> >> route data is ignored
> >> #net.inet.ip.stealth=1 # do not reduce the TTL by one(1) when a packets
> >> goes through the firewall
> >> net.inet.icmp.bmcastecho=0 # do not respond to ICMP packets sent to IP
> >> broadcast addresses
> >> net.inet.icmp.maskfake=0 # do not fake reply to ICMP Address Mask Request
> >> packets
> >> net.inet.icmp.maskrepl=0 # replies are not sent for ICMP address mask
> >> requests
> >> net.inet.icmp.log_redirect=0 # do not log redirected ICMP packet attempts
> >> net.inet.icmp.drop_redirect=1 # no redirected ICMP packets
> >> #net.inet.icmp.icmplim=50 # 50 ICMP packets per second. a reasonable
> >> number for a small office.
> >> #net.inet.tcp.delayed_ack=1 # always employ delayed ack, 6 packets get 1
> >> ack to increase bandwidth
> >> net.inet

Re: [FUG-BR] Intencionalmente derrubando desempenho de CPU.

[Fabricio Lima]

No windows, isso é gerenciado automaticamente, e sempre a maquina opera no
clock mais baixo (qndo idle, obvio).
AMD PowerNOW faz isso, por exemplo.

O powerd, ja deve se beneficiar disso e usar o clock baixo e subir
dinamicamente, reduzindo assim a energia.

hint.acpi_throttle

Através dos Pstates, ACPI e Cstates.

(claro q LIMITAR, seria algo mais bruto e vai reduzir mais ainda a energia,
mas vai tb te limitar processamento)

(se nao estiver ajustando dinamicamente, merece investigarmos a razao, ou
recompilar o kernel...)

Mas sua descoberta é legal, da pra pensarmos em algo interessante.. como
crontab para durante a noite, reduzir um pouco a potencia enquanto idle.

[ ]'s
Fabricio Lima
When your hammer is C++, everything begins to look like a thumb.

Em 6 de novembro de 2014 10:38, Paulo Henrique - BSDs Brasil <
paulo.rd...@bsd.com.br> escreveu:

>
> Em 05/11/2014 23:40, Joao Rocha Braga Filho escreveu:
>
>  Dando uma pesquisada no powerd descobri algumas coisas interessantes.
>>
>> Tem como diminuir o clock do processador à mão.
>>
>> Com o seguinte comando vi o clock atual e as possibilidades:
>>
>> root:[748] sysctl -a | grep dev.cpu...freq
>> dev.cpu.0.freq: 1093
>> dev.cpu.0.freq_levels: 2500/30940 2187/27072 1875/23205 1562/19337
>> 1250/18480 1093/16170
>>
>>
>> Note que já reduzi ao mínimo. Como fiz isto? Assim:
>>
>> root:[747] sysctl dev.cpu.0.freq=1093
>> dev.cpu.0.freq: 1093 -> 1093
>>
>>
>> Como verifiquei se funcionou? Pelo top, vendo o tempo de idle diminuir,
>> pelo
>> barulho do ventilador de CPU diminuir, e pela temperatura do processador
>> cair
>> mais de 10 graus C.
>>
>> root:[749] sysctl -a | grep dev.cpu...temperature:
>> dev.cpu.0.temperature: 47,0C
>> dev.cpu.1.temperature: 47,0C
>> dev.cpu.2.temperature: 47,0C
>> dev.cpu.3.temperature: 47,0C
>>
>> Em geral o meu computador já tem desempenho mais do que o suficiente
>> para o meu dia a dia. Eu gostaria de ter mais memória.
>>
>> O powerd parece fazer besteira, pois parece não entender que se tratam
>> de 4 núcleos.
>>
>>
>> Eu também brinquei um pouco de parar HDs:
>>
>> root:[773] atacontrol spindown ad8 60
>> root:[774] atacontrol spindown ad8
>> ad8: spin down after 60 seconds idle
>>
>>
>>
>> Bibliografia:
>>
>> https://forums.freebsd.org/threads/howto-freebsd-cpu-
>> scaling-and-power-saving.172/
>>
>> man pages.
>>
>>
>> Será que vou baixar a conta de luz?
>>
>>
>> João Rocha.
>>
>>  No passado se alterava o clock da CPU o driver da Nvidia ( 172.alguma
> coisa ) dava kernel panic !!
>
> Att.
>
> --
> Paulo Henrique.
> Grupo de Usuários do FreeBSD no Brasil.
> Fone: (21) 96713-5042
>
>
> -
> 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] [Off-topic] pf não redireciona com route-to

[Renato Botelho]

> On Nov 6, 2014, at 10:36, spiderslack  wrote:
> 
> Bom dia Renato
>> Vou fazer umas perguntas, mais pra entender o seu cenário e tentar entender 
>> o que tá dando errado.
>> 
>> 1. O seu proxy roda em um equipamento separado de onde roda o firewall, 
>> certo?
> Sim, mara cache
>> 2. Se a resposta da #1 for sim, em qual rede ele está? na alc0?
> digamos que a rede seja 201.2.2.0/24. E uma rede válida.
>> 3. O seu proxy atende na porta 80?
> Segundo o suporte mara cache sim
>> 4. Você quer que todas as conexões vindas da re1, com destino a qualquer 
>> host na porta 80 seja redirecionado para o proxy, correto?
> Sim correto. Nesse firewall não tenho NAT somente roteamento. Tanto a LAN 
> como a WAN são ips válidos.

Certo, então na minha opinião você deveria usar uma regra de rdr pra fazer esse 
redirect, e tem que lembrar de negar o IP do proxy, seria algo mais ou menos 
assim:

rdr pass on re1 inet proto tcp from re1:network to ! IP_DO_PROXY port 80 -> 
IP_DO_PROXY port 80

--
Renato Botelho

-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] Intencionalmente derrubando desempenho de CPU.

[Paulo Henrique - BSDs Brasil]

Em 05/11/2014 23:40, Joao Rocha Braga Filho escreveu:

Dando uma pesquisada no powerd descobri algumas coisas interessantes.

Tem como diminuir o clock do processador à mão.

Com o seguinte comando vi o clock atual e as possibilidades:

root:[748] sysctl -a | grep dev.cpu...freq
dev.cpu.0.freq: 1093
dev.cpu.0.freq_levels: 2500/30940 2187/27072 1875/23205 1562/19337
1250/18480 1093/16170


Note que já reduzi ao mínimo. Como fiz isto? Assim:

root:[747] sysctl dev.cpu.0.freq=1093
dev.cpu.0.freq: 1093 -> 1093


Como verifiquei se funcionou? Pelo top, vendo o tempo de idle diminuir, pelo
barulho do ventilador de CPU diminuir, e pela temperatura do processador
cair
mais de 10 graus C.

root:[749] sysctl -a | grep dev.cpu...temperature:
dev.cpu.0.temperature: 47,0C
dev.cpu.1.temperature: 47,0C
dev.cpu.2.temperature: 47,0C
dev.cpu.3.temperature: 47,0C

Em geral o meu computador já tem desempenho mais do que o suficiente
para o meu dia a dia. Eu gostaria de ter mais memória.

O powerd parece fazer besteira, pois parece não entender que se tratam
de 4 núcleos.


Eu também brinquei um pouco de parar HDs:

root:[773] atacontrol spindown ad8 60
root:[774] atacontrol spindown ad8
ad8: spin down after 60 seconds idle



Bibliografia:

https://forums.freebsd.org/threads/howto-freebsd-cpu-scaling-and-power-saving.172/

man pages.


Será que vou baixar a conta de luz?


João Rocha.

No passado se alterava o clock da CPU o driver da Nvidia ( 172.alguma 
coisa ) dava kernel panic !!


Att.

--
Paulo Henrique.
Grupo de Usuários do FreeBSD no Brasil.
Fone: (21) 96713-5042

-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] [Off-topic] pf não redireciona com route-to

[spiderslack]

Bom dia Renato

Vou fazer umas perguntas, mais pra entender o seu cenário e tentar entender o 
que tá dando errado.

1. O seu proxy roda em um equipamento separado de onde roda o firewall, certo?

Sim, mara cache

2. Se a resposta da #1 for sim, em qual rede ele está? na alc0?

digamos que a rede seja 201.2.2.0/24. E uma rede válida.

3. O seu proxy atende na porta 80?

Segundo o suporte mara cache sim

4. Você quer que todas as conexões vindas da re1, com destino a qualquer host 
na porta 80 seja redirecionado para o proxy, correto?
Sim correto. Nesse firewall não tenho NAT somente roteamento. Tanto a 
LAN como a WAN são ips válidos.


Att.
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] [Off-topic] pf não redireciona com route-to

[Renato Botelho]

> On Nov 5, 2014, at 14:10, spiderslack  wrote:
> 
> Ola pessoal.
> 
> Se o assunto for off-topic me desculpe. Por nao se tratar especificamente de 
> FreeBSD. Mas axo já tentei de tudo. Estou tentando fazer um redirecionamento 
> de porta 80 para um proxy. Tenho um FreeBSD com 3 interfaces.
> 
> 1 re0 - wan
> 2 re1 - lan
> 3 alc0 - rede do proxy
> 
> Todas as interfaces são ips válidos não tenho nat nesse FreeBSD. O endereço 
> IP do proxy é 200.1.1.1(IP exemplo)
> 
> pass in quick on re1 route-to (alc0 200.1.1.1) proto tcp from any to any port 
> 80
> pass in quick on re0 route-to (alc0 200.1.1.1) proto tcp from any port 80 to 
> any

Vou fazer umas perguntas, mais pra entender o seu cenário e tentar entender o 
que tá dando errado.

1. O seu proxy roda em um equipamento separado de onde roda o firewall, certo?
2. Se a resposta da #1 for sim, em qual rede ele está? na alc0?
3. O seu proxy atende na porta 80?
4. Você quer que todas as conexões vindas da re1, com destino a qualquer host 
na porta 80 seja redirecionado para o proxy, correto?

[]s
--
Renato Botelho

-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] [Off-topic] pf não redireciona com route-to

[Alessandro de Souza Rocha]

Em 5 de novembro de 2014 16:51, spiderslack  escreveu:
> Em 11/05/2014 03:10 PM, EnioRM escreveu:
>>
>>
>>
>>
>> Senhores!
>>
>> apenas por curiosidade:
>> spiderslack, como está os options do seu pf.conf
>> set state-policy if-bound ou floating (que é o default)?
>>
>> att
>>
>>
> Ola Enio
>
> Ja tentei as duas opções mas esta como default atualmente.
>
>
> Att.
> -
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Bom dia a todos, meu exemplo.

rdr on $ext_if1 proto tcp from any to any port 25255 -> 200.0.0.1
rdr on $ext_if1 proto tcp from any to any port 21 -> 200.0.0.1
rdr on $ext_if1 proto tcp from any to any port 20 -> 200.0.0.1
rdr on $ext_if1 proto tcp from any to any port 48000 -> 200.0.0.1
rdr on $ext_if1 proto tcp from any to any port 49005 -> 200.0.0.1
rdr on $ext_if1 proto tcp from any to any port 6900 -> 200.0.0.6
rdr on $ext_if1 proto tcp from any to any port 5900 -> 200.0.0.90
rdr on $ext_if1 proto tcp from any to any port 5800 -> 200.0.0.139
rdr on $ext_if1 proto tcp from any to any port 3389 -> 200.0.0.66
rdr on $ext_if1 proto tcp from any to any port 5901 -> 200.0.0.17
rdr on $ext_if1 proto tcp from any to any port 49006 -> 200.0.0.1
rdr on $ext_if1 proto tcp from any to any port 35999 -> 200.0.0.20
rdr on $ext_if1 proto tcp from any to any port 35000 -> 200.0.0.20



-- 
Alessandro de Souza Rocha
Administrador de Redes e Sistemas
FreeBSD-BR User #117
 Long live FreeBSD

 Powered by 

  (__)
   \\\'',)
 \/  \ ^
 .\._/_)

 www.FreeBSD.org
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd