Categorykernel

Linux Increase Networking Performance Tuning Network Stack (Buffers Size)

Starting a Stress Test to improve performance, I reach some limits when the system was under intense fire up. By default the Linux network stack is not configured for high speed large file transfer across WAN links. This is done to save memory resources. You can easily tune Linux network stack by increasing network buffers size for high-speed networks that connect server systems to handle more network packets.

The default maximum Linux TCP buffer sizes are way too small. TCP memory is calculated automatically based on system memory; you can find the actual values by typing the following commands:

The default and maximum amount for the receive socket memory:

The default and maximum amount for the send socket memory:

The maximum amount of option memory buffers:

 Tuning the Values

Set the max OS send buffer size (wmem) and receive buffer size (rmem) to 12 MB for queues on all protocols. In other words set the amount of memory that is allocated for each TCP socket when it is opened or created while transferring files:

WARNING! The default value of rmem_max and wmem_max is about 128 KB in most Linux distributions, which may be enough for a low-latency general purpose network environment or for apps such as DNS / Web server. However, if the latency is large, the default size might be too small. Please note that the following settings going to increase memory usage on your server.

Now, as root user…

You also need to set minimum size, initial size, and maximum size in bytes:

Turn on window scaling which can be an option to enlarge the transfer window:

Enable timestamps as defined in RFC1323:

Enable select acknowledgments:

By default, TCP saves various connection metrics in the route cache when the connection closes, so that connections established in the near future can use these to set initial conditions. Usually, this increases overall performance, but may sometimes cause performance degradation. If set, TCP will not cache metrics on closing connections.

Set maximum number of packets, queued on the INPUT side, when the interface receives packets faster than kernel can process them.

Now reload the changes:

Use tcpdump to view changes for eth0, eth1 or wlan0, or…

See the results, enjoy it!

 

 

 

 

Linus Jumps Kernel Ahead to 3.0

Last week it looked like we were, finally, going to get a version bump from 2.6 to 2.8. Instead, Linus Torvalds has bitten the bullet and tagged the first release candidate of the next kernel to 3.0.

That’s right — it looks like the next kernel release is going to go all the way to 11, er, 3.0. If you missed the discussion last week, this isn’t because the kernel is gaining massive new functionality (as it did from the 1.x to 2.0.x series), but because “it will get released close enough to the 20-year mark, which is excuse enough for me.” Sounds like a good enough reason here, too.

To be clear, 3.0 will not be a radical change. According to Torvalds, “Sure, we have the usual two thirds driver changes, and a lot of random fixes, but the point is that 3.0 is *just* about renumbering, we are very much *not* doing a KDE-4 or a Gnome-3 here. No breakage, no special scary new features, nothing at all like that. We’ve been doing time-based releases for many years now, this is in no way about features. If you want an excuse for the renumbering, you really should look at the time-based one (“20 years”) instead.”

Want to test the new kernel, check for it in the /pub/linux/kernel/v3.0 directory, though the git tree is still linux-2.6.git for now.

If we follow the “once per decade” model, it looks like we’ll have Linux 4.0 sometime in 2020.

 

I Hack’n Rio

Divulgando – origem: http://www.riojug.org/?p=195

O maior evento de software livre do Rio de Janeiro: I Hack’n Rio

Aproveitando toda força e união que as comunidades de Software Livre têm de promover eventos no estado do Rio, a SL-RJ (Comunidade de Software Livre do Rio de Janeiro), em conjunto com as comunidades ArduInRio, Android In Rio, DojoRio, PHP Rio, PythOnRio, Rio.pm, RioJUG, RubyOnRio e Ubuntu-RJ, vêm apresentar o I Hack’n Rio !

Apesar da palavra “hacker” atualmente estar associada a uma pessoa que explora falhas de segurança em computadores e tenta prejudicar outros, no sentido original da palavra, ela designa alguém que é profundo conhecedor de algum assunto e utiliza maneiras criativas de resolver problemas. Por isso, o Hack’n Rio não é um encontro de usuários malignos de computador, mas sim de profundos estudiosos de computação, mais especificamente software livre, e pessoas que estão buscando este conhecimento.

A idéia do I Hack’n Rio surgiu quando os entusiastas de diversas comunidades de Software Livre se encontravam nos eventos promovidos pelo nosso estado, e sempre chegavam a uma mesma conclusão: está na hora de convergir. Convergir todos os eventos específicos de cada comunidade em um só grande evento, falar e fazer sobre tudo que se vê de novidades em cada tecnologia livre adotada em nosso estado.

O grande diferencial deste evento é que ele está sendo feito por todas as comunidades. E isto quer dizer que não há a centralização de tudo numa comissão organizadora só, mas sim a distribuição da organização. Cada comunidade contribuinte terá seu espaço no evento, para utilizar do melhor jeito que a mesma souber fazer.

O nosso objetivo é realizar um evento de elevado grau técnico onde todos os participantes tenham oportunidade de aprender como as tecnologias livres funcionam a fundo e também como contribuir para sua evolução.

Por isso, planejamos a seguinte estrutura:

  • Quando? 8 e 9 de abril de 2011
  • Onde? Cidade Universitária da UFRJ, na Ilha do Fundão
  • Quantas palestras? 28
  • Quantos mini-cursos? 8
  • E o que mais? Muita mão na massa com 2 salas abertas para hackfests, como Arduino Hack Day!

Você faz parte de uma das comunidades de software livre do estado? Então você também é parte do I Hack’n Rio !

Ajude a tornar o evento um sucesso procurando por patrocinadores, buscando por conteúdo relevante e chamando pessoas que fazem as coisas acontecerem – seja construindo coisas novas, seja contribuindo com projetos já existentes.

Algumas sugestões:

  • Patrocinadores: empresas que usam software livre e querem contribuir para sua evolução; empresas prestadoras de serviço ou desenvolvedoras de softwares livres que querem encontrar talentos para contratarem (as empresas podem até mesmo fazer uma espécie de “O Aprendiz” e oferecer vagas de empregos, se desejarem) e divulgar seu nome e serviços.
  • Conteúdo: não pense só em palestras e mini-cursos, pois isso temos em qualquer evento. Pense em encontros técnicos para correções de bugs ou desenvolvimento de novas aplicações ou novas funcionalidades para aplicações já existentes.

Ubuntu 11.04: Natty Narwhal Alpha 1 Released

Alpha 1 is the first in a series of milestone CD images that will be released throughout the Natty development cycle.  The Alpha images are known to be reasonably free of showstopper CD build or installer bugs, while representing a very recent snapshot of Natty. You can download it here:

http://cdimage.ubuntu.com/releases/natty/alpha-1/ (Ubuntu Desktop, Server)

Additional ISOs and torrents are also available.
https://lists.ubuntu.com/archives/ubuntu-devel-announce/2010-December/000793.html

As novidades do kernel 2.6.36

No dia 20 de outubro de 2010, o finlandês agora cidadão americano Linus Torvalds apresentou ao mundo a versão mais recente de seu kernel livre, o Linux 2.6.36. Com o codinome Flesh-Eating Bats with Fangs em homenagem a um morcego que recentemente invadiu a residência dos Torvalds — alguém comentou no blog de Linus que “o Batman finalmente invadiu a casa do Pinguim” — esta nova versão do Linux foi completada em 80 dias, precisamente a duração média dos últimos lançamentos de versões estáveis do kernel. Porém, com uma versão -rc a mais — recentemente, essas versões só chegavam até -rc7, mas alcançaram -rc8 desta vez — a versão estável “pareceu demorar mais do que de costume”, alegaram alguns desenvolvedores.

O kernel encolheu??? Que bom!

Pela primeira vez nos últimos vários anos, uma nova versão do kernel Linux traz menos linhas de código do que a anterior: 13,49 milhões, contra 13,54 milhões na versão 2.6.35 e 13,32 milhões no Linux 2.6.34. Curiosamente, o número de arquivos aumentou de 33,3 mil na versão anterior para 34,3 mil no Flesh-Eating Bats. Além disso, pela terceira vez consecutiva o número de commits que compõem o kernel ficou abaixo dos 10 mil, mais precisamente em 9501.

A redução no tamanho do kernel se explica pelo admirável trabalho de faxina que vem sendo feito na base de código em constante evolução. Os avanços na remoção da BKL (Big Kernel Lock), por exemplo, foram significativos nesta versão.

Vamos às novidades!

AppArmor, finalmente

AppArmor é um sistema de “controle de acesso obrigatório” (Mandatory Access Control ou simplesmente MAC). Desenvolvido pela empresa Immunix nos idos de 1998, ele foi mantido pela Novell — que adquiriu a Immunix — de 2005 a 2007, quando a fabricante do SUSE Linux Enterprise dispensou seus desenvolvedores.

O AppArmor é ativado por padrão em diversas distribuições, sendo os principais exemplos Ubuntu e SUSE Linux Enterprise (Desktop e Server). Incluído no kernel, ele passa a fazer companhia aos demais residentes SELinuxTOMOYOSMACK.

Desktops mais rápidos, mesmo sob pressão

Na área dos desktops, uma série de patches tornam o escalonador mais competente com relação à redução da latência máxima dos processos — nenhuma relação com os patches de Con Kolivas. Juntamente com as novas workqueues implementadas no kernel, o uso de múltiplas tarefas concorrentes num único sistema poderá ser significativamente mais rápido. Por último, um conjunto de patches finalmente dá alento aos pobres coitados que possuem dispositivos de bloco muito lentos. A partir do kernel 2.6.36, os sistemas conectados a esses dispositivos não mais ficarão praticamente incapacitados de reagir quando seus dispositivos — mesmo os USB — demorarem a responder.

Vídeo

Se você possui uma GPU integrada a seu processador Core i3 ou i5, poderá utilizar todos os benefícios do suporte ao Intel Intelligent Power Sharing, recurso presente nesses hardwares que permite um melhor uso — compartilhado, como sempre deveria ser — entre esses dois componentes do “pacote” presente na pastilha de silício. Os benefícios são uma espécie de “overclock” automático da GPU quando a CPU não está a todo vapor, ou então CPU e GPU mais frias e economia de energia quando não estiverem ambas sendo usadas ao máximo.

Ao trabalhar com GPUs AMD Radeon, o Linux enfim se tornou capaz de ler os sensores de temperatura dessas GPUs, entre outras novidades.

Já no campo da concorrente Nvidia, o driver KMS Nouveau passa a incluir suporte — embora ainda básico — às GPUs Fermi presentes na recente série GeForce 400.

Controle remoto via infravermelho

O uso de dispositivos infravermelhos no Linux é, historicamente, trabalhoso. Porém, isto finalmente está mudando. Com os avanços iniciados no Linux 2.6.35, o kernel agora oferece interfaces utilizáveis pelo utilitário LIRC, que por sua vez faz a interface com transmissores e receptores infravermelhos. Com isso, os drivers, antes mantidos no espaço do usuário junto ao próprio LIRC, estão sendo migrados, pouco a pouco, para dentro do kernel.

Compressão de memória mudou de nome novamente

Compcache? Não, o nome mudou para Ramzswap. E quando finalmente foi incorporado ao kernel 2.6.36, o dispositivos de blocos compactado na memória RAM recebeu um novo nome: Zram.

Para usar o Zram, basta ativá-lo nos drivers staging e carregá-lo (chama-se zram). Com isso, cria-se ao menos um dispositivo de blocos compactado, em /dev/zram0. É possível encomendar mais dispositivos por meio de uma opção de carregamento do módulo zram. Para definir seu tamanho, não é mais necessário um utilitário, pois seus controles mudaram dos ioctls para o sysfs. O resultado: basta usar echo 100000 > /sys/block/zram0/size para definir um tamanho de 100 MB para o dispositivo zram0.

Nota: em testes na minha própria máquina, este método não funcionou, pois o sysfs não permitiu a gravação de novos dados no arquivo /sys/block/zram0/size.

Matador mais competente

Quando seu sistema utiliza toda a memória RAM disponível, ele passa a recorrer ao espaço de swap. Quando acaba o swap… alguém (algum processo, é claro!) precisa morrer. O matador de processos se chama OOM (out-of-memory) Killer, e não é sempre tão inteligente. Porém, seus desenvolvedores perceberam que é sempre bom ter um pouco mais de inteligência, mesmo que seu trabalho seja apenas apertar um gatilho. O OOM Killer agora é capaz de tomar melhores decisões a respeito de quais processos matar a fim de liberar a tão valiosa memória.

Novos processadores, nova arquitetura

Uma nova arquitetura de CPU, que ainda nem existe na prática, chamada Tilera, já conta com suporte oficial do Linux. É mais um caso que demonstra a rapidez de evolução e adoção de novas tecnologias típica do Software Livre e, em particular, do kernel Linux. Se a Tilera entregar o que promete, poderemos ter um salto interessante no poder computacional disponível em máquinas comuns.

Já nas arquiteturas tradicionalmente suportadas, o Linux agora funciona com CPUs Tegra da Nvidia, baseadas em ARM.

Novas opções de compilação

Os novos alvos de compilação oldnoconfiglistnewconfigalldefconfigsavedefconfig já foram usados pelos desenvolvedores para eliminar mais de 200 mil linhas de código referentes a arquivos de configuração padrão para as várias arquiteturas suportadas pelo Linux. De certa forma, é como se eles pudessem agora usar um diff dos arquivos de configuração padrão, em vez de uma cópia completa do arquivo de configuração padrão somada às configurações padrão daquela arquitetura específica. Viu como a redução do código foi boa? 🙂

Virtualização

KVM e Xen são grandes concorrentes, mas cada vez mais semelhantes. Os desenvolvedores do KVM acrescentaram alguns recursos que permitem uma espécie de suporte reduzido à execução do Linux como Dom0. Seria este o começo da união entre os dois principais tipos de hypervisors do kernel Linux? Resultados das atuais discussões na LKML poderão ser vistos em uma versão bem próxima do kernel.

Fanotify

A tão prometida e desejada varredura de arquivos sob demanda — imagine isso num sistema antivírus — está mais próxima: o novo sistema Fanotify entrou, embora “de leve”, no kernel. No entanto, vem desativado por padrão em virtude de discordâncias quanto à sua API. A tendência é que o Fanotify substitua as duas “gambiarras” usadas até o momento (sem grande sucesso) para esse mesmo propósito, fsnotifydnotify. O Fanotify é uma estrutura do subsistema de sistemas de arquivos capaz de enviar mensagens ao espaço de usuário (por exemplo, a um software antivírus) informando sobre a abertura, alteração ou fechamento de arquivos. Assim que ela ficar pronta, podemos esperar que seja muito usada em diversos tipos de programas.

Sistemas de arquivos

Quem acessa compartilhamentos remotos via NFS já testemunhou, a partir do kernel 2.6.30, os benefícios do cache local de sistemas de arquivos remotos. A boa notícia: se você usa CIFS para isso, finalmente sua hora chegou. Sistemas de arquivos CIFS agora já têm suporte a essa estrutura, chamada FS-Cache.

No campo do já antigo sistema de arquivos Ext3, a onda retrô levou os desenvolvedores a tornar padrão, novamente, a opção de montagem data=ordered. Ela oferece maior segurança e menor desempenho do que o “antigo novo padrão”, data=writeback.

De forma genérica, o XFS também recebeu vários patches destinados a “melhorar seu desempenho em vários trechos”.

A redundância de subsistemas para lidar com RAID também está finalmente diminuindo. Enquanto o Btrfs recebeu grandes trechos de código do subsistema MD para acrescentar ao futuro sistema de arquivos padrão recursos de RAID 6, o subsistema DM (device mapper) começa a ceder seu código de RAID 5 para outros trechos, de forma a permitir, no futuro, que o utilitário dmraid gerencie também implementações de RAID em drivers de controladoras etc.

Quem usa discos SSD agora também terá mais uma ajuda do subsistema DM, que ganha suporte ao comando discard, capaz de informar que determinada área de dados está disponível — economizando assim um novo ciclo de leitura em todos os blocos que a compõem e estendendo a vida útil dos dispositivos. Tudo isso depende, todavia, da existência de suporte ao comando discard por parte do disco e de sua respectiva controladora.

KGDB + KDB + KMS

Esta sopa de letrinhas tem um significado especial para os desenvolvedores do kernel. O depurador do kernel, KDB (kernel debugger), agora trabalha em parceria com o driver Intel KMS. Isso significa que, na presença de uma GPU Intel que use esse driver, o KDB pode ser acessado a qualquer momento pressionando as teclas SysRqG(confira o resultado neste vídeo).

Futuro

Está em andamento uma iniciativa para aumentar a escalabilidade do VFS (Virtual Filesystem Switch), que já mostrou frutos nesta atual versão do Linux. Espera-se que haja ainda mais novidades no kernel 2.6.37. Da mesma forma, os grandes e contínuos avanços na remoção da BKL (Big Kernel Lock) sinalizam que o kernel inteiro deve ganhar mais desempenho, tanto na versão 2.6.36 quanto nas próximas.

Pode-se esperar também que a integração do KDB, neste momento restrita ao driver KMS Intel, seja incorporada aos concorrentes Nouveau e Radeon.

Este foi o último lançamento de kernel estável em 2010. A versão 2.6.37 do kernel Linux deve ser lançada em janeiro de 2011.

Post original aqui.

© 2017 Ziben IT Solutions

Theme by Anders NorénUp ↑