Tunando a transferência de dados com o nr_request e o read_ahead_kb!

galactus · 22 de Setembro de 2011, 01:48

Atenção: As dicas a seguir servem para melhorar sua transferência de dados e uso em geral do seu sistema de arquivos em muitos casos. Por favor leia todo o tutorial antes de realizar quaisquer mudanças. Os comandos a seguir não implicam em risco de perda de dados! O tutorial foi testado em várias configurações diferentes, de um Atom 525 a um Core i72600k entre outros, com um único disco rígido ou vários discos rígidos e nas seguintes distros: Ubuntu, Mint Linux, OpenSuse, Mandriva e Centos! Se algo estiver errado ou você tiver novidades para contribuir, esteja a vontade para me avisar!

1) Melhorando as requisições ao disco!

É possível modificar o número de requisições que o seu disco rígido pode fazer ao ler ou gravar seus dados! Esses valores podem ser aumentados ou diminuídos e vão depender principalmente do tipo de uso que você faz do seu sistema de arquivos. Com esses valores alterados você pode aumentar ou diminuir a taxa de transferência dos dados. Fiz testes com o ext4, mas você pode fazer essas alterações no ext3, no JFS, no XFS e no NTFS também!

Resumindo, não existe um valor geral que vai ser bom para todos os casos. Você terá que fazer os seus testes, eu vou colocar aqui as minhas sugestões de acordo com meus testes pessoais!

Em geral valores mais altos tendem a ajudar na gravação dos dados, contudo se o seu sistema tiver muitos dados pequenos a latência do sistema pode aumentar, ou seja, o tempo de leitura aumenta e você vai sentir o sistema mais lento.

Esse valor é dado pelo nr_requests. O nr_requests fica na pasta /sys/block/sdx/queue/nr_requests.

Onde o sdx vai depender da letra do seu disco rígido. Isso mesmo, você pode alterar esse valor de acordo com cada disco rígido do seu sistema. Essa modificação portanto vale para o disco inteiro e para todas as partições dentro dele.

O valor é dado em KB e pode variar entre: 4 / 8 / 16 / 32 / 64 / 128 / 256 / 512 / 1024 / 2048

O valor padrão é 128. Nos testes que eu li e nos realizados por mim em algumas máquinas o valor de 512 é o que apresentou melhores resultados no geral. Em um disco em que praticamente só vai ser usado para atividades de gravação você deve conseguir melhores resultados com 1024 ou 2048.

Para descobrir o valor do seu nr_requests siga o exemplo:

Código Selecionar

$ cat /sys/block/sdx/queue/nr_requests

Para alterá-lo você faz como root:

Código Selecionar

# echo 512 > /sys/block/sdx/queue/nr_requests

Essa alteração já passa a valer imediatamente! Você pode fazer seus testes e verificar se isso ajuda ou não. Se usar apenas o comando echo, todas as vezes que reiniciar a máquina o valor padrão volta a vigorar, ou seja, 128. Se quiser que o valor ideal para você esteja sempre ativo, coloque essa linha de comando dentro do arquivo /etc/rc.local antes do exit 0. Para cada disco uma linha de comando!

2) Melhorando o Buffer de leitura!

Outra opção de tunagem, entre inúmeras, para transferência de arquivos é alterar os valores do read_ahead_kb. Alterar esse valor para mais melhora as taxas de leitura sequenciais. Portanto na maioria dos casos um valor aumentado não vai melhorar o desempenho do sistema, isso porque a maioria de nossos sistemas faz leituras randômicas quando em uso geral. O valor padrão é 128 e novamente para verificar o seu valor use o comando cat. O read_ahead_kb também se encontra na pasta /sys/block/sdx/queue/read_ahead_kb. O exemplo então fica:

Código Selecionar

$ cat /sys/block/sdx/queue/read_ahead_kb

Para alterá-lo você usa o echo, os valores possíveis são:

4 / 8 / 16 / 32 / 64 / 128 / 256 / 512 / 1024 / 2048 / 4096 / 8192 / 16384

Para máximo desempenho de leitura sequencial use 16384! Esse valor define o quão grande uma atividade de leitura pode ter. Como usuário root:

Código Selecionar

# echo 16384 > /sys/block/sdx/queue/read_ahead_kb

Essa alteração já passa a valer imediatamente! Você pode fazer seus testes e verificar se isso ajuda ou não. Se usar apenas o comando echo, todas as vezes que reiniciar a máquina o valor padrão volta a vigorar, ou seja, 128. Se quiser que o valor ideal para você esteja sempre ativo, coloque essa linha de comando dentro do arquivo /etc/rc.local antes do exit 0. Para cada disco uma linha de comando!

Você pode então se perguntar quando aumentar esse valor é útil afinal? Quando você vai fazer uma grande transferência de dados de um disco para o outro! Nos meus testes com um pobre Atom as taxas de transferências aumentaram em até 10MB/s. Em ambientes de grandes servidores os ganhos podem alcançar até 400MB/s!

3) Dicas em Geral de quando e como usar esses parâmetros!

Ao utilizar 512 no nr_requests e 16384 no read_ahead_kb , consegui diminuir em pouco mais de 34 segundos a transferência de arquivos dentro do próprio HD do meu Atom 525 do trabalho. Isso com um grande volume de dados e num Atom com apenas um HD! Seus ganhos podem ser maiores com um processador mais potente e com mais de um disco envolvido. A má notícia é que se usar esses valores no disco onde o seu sistema está instalado, você só conseguirá fazer a transferência de arquivos!!! Tentar fazer outra coisa será praticamente impossível num Atom, no Corei7 eu ainda consegui usar outra coisa, mas muito lento.

O ideal é usar esses valores em um disco que só vai servir para dados e não vai ser usado com o sistema. Como a tunagem pode ser feita para cada disco e se você tiver vários discos no sistema, acaba sendo uma boa idéia!

Outra boa dica é se você vai fazer uma transferência grande de arquivos que envolve um HD externo ou até mesmo um novo HD que você precisa fazer backup de uma montanha de dados.
Você pode usar o echo para tunar os dois arquivos, faz a transferência e depois pode voltar tudo ao normal ao reiniciar a sua máquina.

Em meus testes, quando usei o nr_requests e o read_ahead_kb tunados em 512 e 16384 respectivamente, de maneira temporária e depois voltei aos valores originais de 128, o sistema não ficou legal. Ficou lento! Só voltou ao normal depois de reiniciar.

Tenho usado apenas o nr_requests com 512 em várias máquinas de configurações diferentes com bons resultados em uso diário! Com apenas o nr_requests tunado é perfeitamente possível fazer até três transferências de arquivos ao mesmo tempo e usar o sistema, isso num Atom 525. O read_ahead_kb eu deixo padrão, só altero quando preciso fazer uma grande transferência de dados.

Ao utilizar o nr_requests e o read_ahead_kb tunados em meu servidor de arquivos e na minha máquina de casa para transferir dados pela rede gigabit com o Samba consegui até 71MB/s de taxa de transferência sustentada com 3 arquivos ao mesmo tempo, notem a foto abaixo como exemplo:

Com o nr_requests e o read_ahead_kb tunados, você poderá ver as taxas de transferências aumentarem com o tempo e não ir caindo como de costume!

Então era isso pessoal!

Espero ter ajudado mais do que complicado!

Andreson Goveia · 22 de Setembro de 2011, 02:13

Grande galactus, nunca para não é mesmo, e cheio de surpresas boas.
Chegando em casa vou testar com certeza, e polo que li vou usar somente a opção nr_requests por padrão

Acho que se tivermos coragem de encarar todas as suas dicar o sistema vai ficar um jato.
hehe.

Parabéns, e aguardo a próxima.

vampire_thunder · 22 de Setembro de 2011, 04:47

Lá vem o Galactus com suas dicas de tunning

Vou testar depois.

platao · 22 de Setembro de 2011, 11:08

Mais um excelente post do Galactus, assim nao dá!!!!!

Ja foi para os favoritos e nao vai faltar oportunidade para testar essa dica.

Parabens.

Creto · 22 de Setembro de 2011, 12:04

Citação de: Andry online 22 de Setembro de 2011, 02:13
Acho que se tivermos coragem de encarar todas as suas dicar o sistema vai ficar um jato.

Um dia crio essa coragem, por enquanto vou acompanhando e estudando.

Parabéns Galactus.

vampire_thunder · 22 de Setembro de 2011, 16:01

Citação de: Creto online 22 de Setembro de 2011, 12:04
Citação de: Andry online 22 de Setembro de 2011, 02:13
Acho que se tivermos coragem de encarar todas as suas dicar o sistema vai ficar um jato.

Um dia crio essa coragem, por enquanto vou acompanhando e estudando.

Parabéns Galactus.

E o que falta para criarem coragem? Já usei todas as dicas do Galactus. Nunca tive problemas.

Acabei de testar essa nova dica e... me decepcionei $:-\$

Citação de: galactus
Outra boa dica é se você vai fazer uma transferência grande de arquivos que envolve um HD externo ou até mesmo um novo HD que você precisa fazer backup de uma montanha de dados.

Era exatamente o meu caso. Comprei um HD de 2TB para o trabalho e estou fazendo o backup dos dados do Mac para ele, pois deu problema no sistema e será preciso formatar. Usei a dica de tunar o EXT4 e, de quebra, ainda coloquei o journal externo no mesmo HD, com 400MB. Estou rodando o Lineduc Live a partir da memória RAM (toram), com o kernel 3.0 compilado com BFQ e BFS no Mac. Usei as dicas deste site nos 2 HDs, o da máquina e o de 2TB e, com tudo isso, esperava uma transferência exorbitante. Mas veja:
https://lh5.googleusercontent.com/-0tSA8fwwqGo/TnuAtagA6jI/AAAAAAAABEg/StWMQFMSYv4/s800/Captura_de_tela.png

Só tem duas explicações: o a case onde está o HD não presta ou a opção "nomodeset" que eu habilitei para dar boot no Mac acaba com o desempenho.

Creto · 22 de Setembro de 2011, 17:55

Meu caro vampire_thunder,

O que falta para mim é conhecer mais o sistema, com isso vem o bom senso de conhecer as "minhas" limitações.

Como minhas maquinas precisam estar eficientes quase 18 Hs por dia, as quatro restantes tem o estudo sobre o sistema, para se eu fizer alguma burrada posso corrigir.

Isso é coragem para mim, ter a consciência de que um senhor de 40 ainda pode aprender.

T+

havocz · 22 de Setembro de 2011, 20:05

Usando o recomendado e já está aprovado !

Certamente farei isso no disco de dados do servidor samba e no disco de cache o servidor squid do meu serviço.

galactus · 22 de Setembro de 2011, 22:10

Obrigado a todos!

Espero que as dicas ajudem a todos como a mim!

Vampire, eu achei estranho num primeiro momento essas suas taxas de transferências. Aí peguei o meu HD externo de 2TB, um Western Digital Green, formatado em NTFS e fiz testes aqui com e sem a tunagem! O resultado foi que a velocidade de pico inicial aumentou um pouco mas a velocidade vai caindo da mesma maneira.

Olha as fotos:

Aqui começa com 35,6 MB/s. Configuração padrão: 128 e 128.

Aqui começa com 40,2 MB/s. Tunado para 512 e 16384.

Depois nos dois modos as taxas vão caindo para o mesmo patamar, estabilizando em 20-21 MB/s, mas no caso do teste tunado, demora um pouco mais para as taxas caírem até a mesma velocidade.

Ainda sim com taxas bem mais altas que a sua. Acho que aqui temos uma limitação de hardware. A sua porta USB não vai mais do que isso! No seu caso eu ainda acredito que sua configuração deve ter portas PS2, serial e IDE, não? Isso ajuda a perder cerca de 12% nas taxas de transferências. Essa é comprovada por testes de hardware. Minha placa não tem portas antigas e ainda por cima é uma ASUS de boa linhagem, as ASUS boas sempre dão mais gás nas transmissões de dados. Isso é uma opinião puramente de usuário final! No que eu já vi, não tenho dados técnicos quanto a essa última afirmação.

Já pensou em outra coisa?

vampire_thunder · 22 de Setembro de 2011, 22:55

Citação de: galactus online 22 de Setembro de 2011, 22:10
(...)

Ainda sim com taxas bem mais altas que a sua. Acho que aqui temos uma limitação de hardware. A sua porta USB não vai mais do que isso! No seu caso eu ainda acredito que sua configuração deve ter portas PS2, serial e IDE, não? Isso ajuda a perder cerca de 12% nas taxas de transferências. Essa é comprovada por testes de hardware. Minha placa não tem portas antigas e ainda por cima é uma ASUS de boa linhagem, as ASUS boas sempre dão mais gás nas transmissões de dados. Isso é uma opinião puramente de usuário final! No que eu já vi, não tenho dados técnicos quanto a essa última afirmação.

Já pensou em outra coisa?

Rapaz, estou falando de um iMac. Não tem nada disso, não. Depois que eu reinstalar o MacOS e voltar a usar o Ubuntu que está instalado, sem o monodeset, eu volto a testar. Afinal, tem muito arquivo para passar para o HD.

galactus · 23 de Setembro de 2011, 06:50

Citação de: vampire_thunder online 22 de Setembro de 2011, 22:55
Citação de: galactus online 22 de Setembro de 2011, 22:10
(...)

Ainda sim com taxas bem mais altas que a sua. Acho que aqui temos uma limitação de hardware. A sua porta USB não vai mais do que isso! No seu caso eu ainda acredito que sua configuração deve ter portas PS2, serial e IDE, não? Isso ajuda a perder cerca de 12% nas taxas de transferências. Essa é comprovada por testes de hardware. Minha placa não tem portas antigas e ainda por cima é uma ASUS de boa linhagem, as ASUS boas sempre dão mais gás nas transmissões de dados. Isso é uma opinião puramente de usuário final! No que eu já vi, não tenho dados técnicos quanto a essa última afirmação.

Já pensou em outra coisa?
Rapaz, estou falando de um iMac. Não tem nada disso, não. Depois que eu reinstalar o MacOS e voltar a usar o Ubuntu que está instalado, sem o monodeset, eu volto a testar. Afinal, tem muito arquivo para passar para o HD.

Baum, o iMac não tem portas PS2, IDE e nem Serial? Eu realmente não fiz testes com um iMac, só com PCs e com Linux instalados nas máquinas. Pelo menos vamos ter certeza se isso funciona para iMacs!

vampire_thunder · 23 de Setembro de 2011, 11:08

Citação de: galactus online 23 de Setembro de 2011, 06:50

Baum, o iMac não tem portas PS2, IDE e nem Serial? Eu realmente não fiz testes com um iMac, só com PCs e com Linux instalados nas máquinas. Pelo menos vamos ter certeza se isso funciona para iMacs!

Tem, não:

Código Selecionar

13:54:15 lineduc@lineduc:~/Área de Trabalho$ lspci
00:00.0 Host bridge: nVidia Corporation MCP79 Host Bridge (rev b1)
00:00.1 RAM memory: nVidia Corporation MCP79 Memory Controller (rev b1)
00:03.0 ISA bridge: nVidia Corporation MCP79 LPC Bridge (rev b2)
00:03.1 RAM memory: nVidia Corporation MCP79 Memory Controller (rev b1)
00:03.2 SMBus: nVidia Corporation MCP79 SMBus (rev b1)
00:03.3 RAM memory: nVidia Corporation MCP79 Memory Controller (rev b1)
00:03.4 RAM memory: nVidia Corporation Device 0a98 (rev b1)
00:03.5 Co-processor: nVidia Corporation MCP79 Co-processor (rev b1)
00:04.0 USB Controller: nVidia Corporation MCP79 OHCI USB 1.1 Controller (rev b1)
00:04.1 USB Controller: nVidia Corporation MCP79 EHCI USB 2.0 Controller (rev b1)
00:06.0 USB Controller: nVidia Corporation MCP79 OHCI USB 1.1 Controller (rev b1)
00:06.1 USB Controller: nVidia Corporation MCP79 EHCI USB 2.0 Controller (rev b1)
00:08.0 Audio device: nVidia Corporation MCP79 High Definition Audio (rev b1)
00:09.0 PCI bridge: nVidia Corporation MCP79 PCI Bridge (rev b1)
00:0a.0 Ethernet controller: nVidia Corporation MCP79 Ethernet (rev b1)
00:0b.0 IDE interface: nVidia Corporation MCP79 SATA Controller (rev b1)
00:0c.0 PCI bridge: nVidia Corporation MCP79 PCI Express Bridge (rev b1)
00:15.0 PCI bridge: nVidia Corporation MCP79 PCI Express Bridge (rev b1)
00:16.0 PCI bridge: nVidia Corporation MCP79 PCI Express Bridge (rev b1)
02:00.0 VGA compatible controller: nVidia Corporation Device 0655 (rev a1)
03:00.0 Network controller: Broadcom Corporation BCM4322 802.11a/b/g/n Wireless LAN Controller (rev 01)
04:00.0 FireWire (IEEE 1394): Agere Systems FW643 PCI Express1394b Controller (PHY/Link) (rev 07)

Lá atrás só tem 4 USBs, a rede, a entrada firewire e uma saída para monitor (proprietária), tipo isso:
http://km.support.apple.com/library/APPLE/APPLECARE_ALLGEOS/HT4619/HT4619-imac_mid2011-ports-001-pt_BR.png

Ainda estou fazendo o bendido backup. Dessa vez iniciei pelo toram mas não apliquei as dicas. Está com o padrão (128) e a taxa é a mesma. Estou ancioso para testar com o sistema instalado.

lotavio · 18 de Julho de 2014, 01:41

Nos parágrafos inicias deste artigo você informa que não foi feito teste com xfs e informa que teria que haver uma mudança no fstab para o teste acontecer quais seriam as modificações no caso ?

galactus · 18 de Julho de 2014, 19:14

Citação de: lotavio online 18 de Julho de 2014, 01:41
Nos parágrafos inicias deste artigo você informa que não foi feito teste com xfs e informa que teria que haver uma mudança no fstab para o teste acontecer quais seriam as modificações no caso ?

Olá, muito obrigado pela lembrança do tópico. Já corrigi, pode alterar os valores no HD com XFS sem precisar alterar nada no fstab!