Eu executo este comando em um servidor Debian com unidades SSD configuradas como RAID 1:
ionice -c 3 find . -type f -amin -1440 -mmin +1441 -not -path custom/ -print0
em um caminho que contém mais de 1,7 milhões de arquivos e diretórios.
Eu notei que toda vez que eu executo esse comando, a carga do servidor aumenta e eu estava pensando
se houver alguma maneira, eu posso diminuir find da velocidade para não gerar cargas tão altas.
Também fiquei me perguntando se aqui estão as opções específicas do SSD para permitir menos geração de carga find
Não faz sentido tentar manter a carga baixa a todo custo. O importante é que o seu processo volte atrás se algo mais importante precisar usar os recursos oferecidos pelo seu sistema.
ionice e nice / renice podem ser usados para reduzir a prioridade, para que ela seja executada apenas quando o sistema estiver inativo.
Isso se resume ao sistema de arquivos e ao ajuste de procfs. O que você explica como 'alta' carga é a situação em que outros processos normais no sistema são privados de leituras e eles são forçados a esperar.
A situação é caracterizada por
Usar o noop scheduler não ajuda aqui, já que o noop é um escalonador FIFO simples e não pode ajudá-lo a trazer mais justiça ao jogo de acesso ao disco. Então eu sugiro ir com o agendador de prazo.
A ideia do agendador de prazo é projetar o prazo final para a operação de I / O do disco e, ao mesmo tempo, manter duas filas simples - uma para leitura e outra para gravação; você pode ajustar a afinidade de leituras sobre gravações e, por quanto tempo, pode tolerar que alguma leitura / gravação fique na fila antes que a operação atual seja interrompida e a tarefa de IO expirada esteja satisfeita.
Além disso, o que você quer é ter muitos dados de entradas de diretórios e inode de arquivos na RAM, armazenados em cache. Esse tipo de cache economizará muito o disco IO ao atravessar essa estrutura de diretório / arquivo tão grande.
grep ^Slab /proc/meminfo
Isso lhe dirá quanto de memória é totalmente dedicada à entrada de diretório e ao cache de arquivos. Detalhes sobre o que e como essa memória Slab é dividida / usada podem ser encontrados em
/proc/slabinfo
Você pode executar slabtop para obter estatísticas de uso interativas.
Por fim, se você decidir aumentar mais esse tipo de cache, você quer reduzir o valor de
sysctl -w vm.vfs_cache_pressure=20
Por padrão, isso é definido como 100, que ocorre em situações em que o sistema está com pouca memória tentando reduzir bastante a quantidade de memória usada para armazenar em cache d_entry um arquivo inodes vs cache de páginas (por exemplo, cache de dados de arquivo / programa na RAM) Ao reduzir o valor, você preferirá manter esses cache de inode do arquivo / d_entry e, portanto, exigir menos operações de leitura para reler os mesmos dados do disco, caso ele tenha sido removido do cache devido à pressão da memória.
Além disso, para melhorar seus recursos de leitura de disco, recomendo aumentar a leitura antecipada.
blockdev --getra /dev/sda
blockdev --setra 2048 /dev/sda
Isso deve ajudá-lo a extrair algumas IOPS extras, especialmente se o seu sistema estiver fazendo mais leituras do que gravações. (para verificar se o iostat pode ajudar; a primeira linha é sempre um uso agregado desde o tempo de inicialização, tão fácil de conceber proporções a partir disso)
Em seguida, o que eu consideraria o ajuste ser o downsizing é nr_requests
echo 32 > /sys/block/sda/queue/nr_requests
Ao fazer isso, você terá essencialmente lotes mais curtos, que permitirão mais latência à custa de alguma taxa de transferência que obtivemos até lá. Sistemas com muitos processos se beneficiarão disso, pois será mais difícil para o processo único dominar a fila de IO, enquanto outros passam fome.
Mais sobre isso pode ser encontrado também aqui: ajuste do controlador RAID de hardware
Outro caso em que você pode ter altas cargas é se as atividades normais do sistema forem interrompidas por algum lote de gravação grande e intermitente, por exemplo, download de arquivos grandes, copiar, descompactar operação. As gravações também podem facilmente saturar o disco IO e combatê-las, eu recomendaria afinam um pouco depois.
vm.dirty_background_ratio
vm.dirty_ratio
Cuidado que você não vá muito baixo. Para obter a idéia, você pode usar a ferramenta atop e verificar as estatísticas do disco, onde você pode ver quantos dados sujos estão normalmente na memória; quanto os processos se beneficiam da sujeira da memória (coluna WCANCL nas estatísticas do disco) e vão um pouco acima dessas taxas de uso.
Isso ajudará a criar mecanismos de kernel para otimização de write-back que tentam retardar processos que afetam o E / S dos sistemas fazendo gravações pesadas. para mais informações, consulte otimização de write-back
Tags ssd find debian linux performance-tuning