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

Quarta Novembro 5 18:47:25 BRST 2014

Em 05/11/2014 16:53, 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 <edinilson em atinet.com.br>:
>
>> ----- Original Message ----- From: "Paulo Henrique - BSDs" <
>>> paulo.rddck em bsd.com.br>
>>> To: ""Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)"" <
>>> freebsd em 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 xxxxx 10.0-STABLE FreeBSD 10.0-STABLE #0 r269344: Thu Jul 31
>>> 14:39:46 BRT 2014
>>> netstat -m
>>> yyyyyyy em xxxxx:/usr/obj/usr/src/sys/XXXXXXXXXXX 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=1000000
>>>
>>> # 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.tcp.drop_synfin=1 # SYN/FIN packets get dropped on initial
>>> connection
>>> net.inet.tcp.ecn.enable=1 # explicit congestion notification (ecn)
>>> warning: some ISP routers abuse it
>>> net.inet.tcp.fast_finwait2_recycle=1 # recycle FIN/WAIT states quickly
>>> (helps against DoS, but may cause false RST)
>>> net.inet.tcp.icmp_may_rst=0 # icmp may not send RST to avoid spoofed
>>> icmp/udp floods
>>> net.inet.tcp.maxtcptw=15000 # max number of tcp time_wait states for
>>> closing connections
>>> net.inet.tcp.msl=5000 # 5 second maximum segment life waiting for an ACK
>>> in reply to a SYN-ACK or FIN-ACK
>>> net.inet.tcp.path_mtu_discovery=0 # disable MTU discovery since most
>>> ICMP packets are dropped by others
>>> net.inet.tcp.rfc3042=0 # disable the limited transmit mechanism which can
>>> slow burst transmissions
>>> #net.inet.tcp.sack.enable=1 # sack disabled? http://www.ibm.com/
>>> developerworks/linux/library/l-tcp-sack/index.html
>>> net.inet.udp.blackhole=1 # drop udp packets destined for closed sockets
>>> net.inet.tcp.blackhole=2 # drop tcp packets destined for closed ports
>>> #net.route.netisr_maxqlen=4096 # route queue length defaults 4096 (rtsock
>>> using "netstat -Q")
>>> security.bsd.see_other_uids=0 # hide processes for root from user uid's
>>>
>>> ## Configuracoes de envio
>>>
>>> net.local.stream.sendspace=164240
>>> net.local.stream.recvspace=164240
>>>
>>> ## Configuracoes contra spoof
>>>
>>> net.inet.ip.rtexpire=60 # 3600 secs
>>> net.inet.ip.rtminexpire=2 # 10 secs
>>> net.inet.ip.rtmaxcache=1024 # 128 entries
>>>
>>> Qualquer orientação é bem vinda.
>>>
>>>
>> Ate o FreeBSD 7 eu ate que me preocupava em ficar mexendo no hz. Apos
>> isto, e com estas interfaces de rede modernas da Intel, nao me preocupo
>> mais (nem com hz nem com polling) pois PARECE nao mudar muito coisa.
>>
>> Veja uma discussao de 2005 sobre o hz onde ja se discutia isto:
>> http://lists.freebsd.org/pipermail/freebsd-questions/
>> 2005-April/083482.html
>>
>> e veja tambem este link, na parte onde esta o hz o que ele diz:
>> https://calomel.org/freebsd_network_tuning.html
>>
>>
>> Edinilson
>> ------------------------------------------
>> ATINET
>> Tel Voz: (0xx11) 4412-0876
>> http://www.atinet.com.br
>>
Edinilson, li superficialmente os links no momento contudo mais tarde 
irei me dedicar a uma leitura mais aprofundada.
Esse servidor em questão ele é meio que um faz tudo da empresa, é o 
servidor principal de arquivos com samba-3.6, dns, ldap, zabbix e ftp 
assim como o principal na tarefa de backup que diariamente manipula algo 
proximo de 360gbytes de dados, essas são suas funções principais porém 
todos os demais serviços que executam em outros servidores  a 
redundância estar sobre esse mesmo servidor, o que inclui, postgresql, 8 
estações virtuais sobre VirtualBox e jabber.

Tive alguns problemas com arquivos sendo corrompido no passado usando o 
scp nele e resolvi ampliando o buffers de rede.
Quando a variável HZ=2000 foi o padrão que adotei para todos os 
servidores que monto desde a 6.2 Release, e a duvida era se melhora 
alguma coisa caso aumente ainda mais ela. Nos links que mandou deve ter 
a duvida respondida então vou ler primeiro.

Irei providenciar uma janela de manutenção para poder analisar o que 
melhora ou não com a variavel mais alta e também mais baixa e depois 
disponibilizo o resultado para o Marcelo Gondim poder postar no 
bsdinfo.com.br e para alguém que mantém o fug.com.br.

Valeu pelas orientações.

Att. Paulo Henrique.

-- 
Paulo Henrique.
Grupo de Usuários de Sistemas BSDs no Brasil.
Fone: +55 21 96713-5042

Não importa o que faça, sempre haverá alguém em algum lugar do mundo que será sempre melhor do que você.