Improving performance (Português)

Status de tradução: Esse artigo é uma tradução de Improving performance. Data da última tradução: 2020-08-31. Você pode ajudar a sincronizar a tradução, se houver alterações na versão em inglês.

Este artigo oferece informação sobre diagnósticos básicos do sistema relacionados com desempenho e também passos que podem ser tomados para reduzir o consumo de recursos ou otimizar o sistema com o objetivo final de melhorias perceptíveis ou documentadas.

O básico

Conheça o seu sistema

A melhor maneira de aprimorar um sistema é ter como alvo os gargalos, ou subsistemas que limitam o desempenho médio. As especificações do sistema podem ajudar a identificá-las.

Se o computador se torna lento quando aplicações grandes (como LibreOffice e Firefox) rodam ao mesmo tempo, verifique se a quantidade de RAM é suficiente. Use o seguinte comando e verifique a coluna "available" (ou "disponível" em português):

$ free -h

Se a inicialização é lenta, e programas demoram muito tempo para carregar na primeira vez (apenas) que são executados, então possivelmente é culpa do disco rígido. A velocidade dele pode ser mensurada com o comando hdparm:

Nota: hdparm indica somente a velocidade de escrita e leitura pura de um disco rígido, e não é um benchmark válido. Um valor maior que 40MB/s (enquanto ocioso) é aceitável em um sistema mediano.

# hdparm -t /dev/sdX

Se o carregamento da CPU é consistemente alto até mesmo com bastante RAM disponível, tente diminuir o uso da CPU ao desabilitar daemons que estão rodando e/ou processos. Isto pode ser monitorado de algumas formas, por exemplo com htop, pstree ou qualquer outra ferramenta de monitoração do sistema:

$ htop

Se aplicações usam renderização direta estão lentas (exemplo, estas que usam a GPU, tais como players de vídeo, jogos, ou até mesmo um gerenciador de janelas), então melhorar o desempenho da GPU deve ajudar. O primeiro passo é verificar se a renderização direta está habilitada. Isto é indicado pelo comando glxinfo, parte do pacote mesa-utils:

$ glxinfo | grep "direct rendering"

direct rendering: Yes

Ao usar um ambiente de desktop, desabilitar efeitos visuais (não usados) pode reduzir o uso da GPU. Use um ambiente mais leve ou crie um personalizado, se o atual não é compatível com seu hardware e/ou preferências pessoais.

Fazer benchmark

Os efeitos de otimização são normalmente dificieis de julgar. No entanto estes podem ser mensurados por ferramentas de benchmark.

Dispositivos de armazenamento

Múltiplas conexões de hardware

This article or section needs language, wiki syntax or style improvements. See Help:Style for reference.

Reason: Escrita subjetiva (Discuss in talk:improving perfomance)

Um caminho interno do hardware é como o dispositivo de armazenamento é conectado para sua placa-mãe. Existem diferentes maneiras de se conectar a ela como: TCP/IP atravês de uma NIC, plugado diretamente com PCIe/PCI, Fireware, Raid Card, USB, etc. Ao espalhar seus dispositivos de armazenamento por estes múltiplos pontos de conexão, você maximiza as capacidades de sua placa-mãe, por exemplo 6 discos rígidos conectados por USB devem ser bem mais lentos que 3 pelo USB e 3 pelo Firewire. O motivo disso é que cada conexão de entrada na placa-mãe é como um tubo, e existe um limite de quanto você pode transmitir por vez. A boa notícia é que ela normalmente tem vários tubos.

Mais exemplos

Diretamente na placa-mãe usando PCI/PCIe/ATA
Usando uma capa externa para guardar o disco por USB/Firewire
Jogar o dispositivo no dispositivo de armazenamento da rede ao conectar com TCP/IP

Note também que se você tem duas portas USB na frente da sua máquina, e 4 portas USB atrás, e possui 4 discos, deve ser mais rápido/eficiente colocar 2 na frente e 2 atrás do que 3 atrás e 1 na frente. Devido a portas da frente provavelmente possuírem um Hub USB separado, significando que você pode enviar duas vezes mais dados do que somente usar 1. Use os seguintes comandos para determinar as várias conexões de hardware de sua máquina.

USB Device Tree

$ lsusb -t

PCI Device Tree

$ lspci -tv

Particionamento

Garanta que suas partições estão apropriadamente alinhadas.

Múltiplas unidades de armazenamento

Se você têm múltiplos discos disponíveis, você pode configurar um RAID de software para sérias melhorias na velocidade.

Criar uma swap em um disco separado pode ajudar, especialmente se sua máquina envia dados frequentemente para a swap.

Particionamento em HDDs

Se você está usando o tradicional HDD rotacional, seu particionamento pode influenciar a performance do sistema. Setores no começo do disco (mais próximos de fora do disco) são mais rápidos que estes no fim. Também, uma menor partição precisa de menos movimentos da cabeça da unidade de armazenamento, e consequentemente acelera as operações no disco. É recomendado criar partições menores (10GB, mais ou menos dependendo de suas necessidades) somente para seu sistema, tão próximo do começo do disco quanto possível. Outros dados (imagens, vídeos) devem ser mantidos em uma partição separada, isto normalmente é feito ao separar o diretório home (/home/usuário) do sistema (/).

Escolhendo e aumentando o desempenho do seu sistema de arquivos

Escolher o melhor sistema de arquivos para seu sistema específico é muito importante, pois cada um tem suas especificidades. Os artigos dos sistemas de arquivos oferecem um pequeno sumário dos mais populares. Você pode também encontrar artigos relevantes em Category:File systems (Português).

Opções de montagem

A opção noatime é conhecida por melhorar o desempenho de sistemas de arquivos.

Outras opções são específicas para cada sistema de arquivos, então veja os artigos relevantes de cada um deles:

Reiserfs

A opção de montagem data=writeback melhora a velocidade, mas pode corromper dados durante uma queda de energia. A opção de montagem notail aumenta o espaço usado pelo sistema de arquivos por volta de 5%, mas melhora o desempenho geral. Você pode reduzir o carregamento do disco ao colocar o journal e dados em unidades de armazenamento separadas. Isto é feito ao criar o sistema de arquivos:

# mkreiserfs –j /dev/sda1 /dev/sdb1

Substitua o /dev/sda1 com a partição reservada para o journal, e /dev/sdb1 com a partição para dados. Você pode aprender mais sobre reiserfs com este artigo.

Parâmetros do kernel que melhoram o desempenho

Existem algumas chaves habilitáveis que afetam positivamente o desempenho de dispositivos de bloco, veja sysctl#Virtual memory para mais informações.

Escalonador de entrada/saída

Informações básicas

O escalonador (scheduler) de entrada/saída (E/S) (input/output ou I/O, em inglês) é o componente do kernel que decide em que ordem as operações de bloco de E/S são submetidas para dispositivos de armazenamento. É útil se lembrar de algumas especificações dos dois principais tipos de unidades de armazenamento devido ao objetivo do escalonador de E/S, que é otimizar a maneira de lidar com os pedidos de leitura:

Um HDD tem discos giratórios e uma cabeça que se move fisicamente para a localização solicitada. Latência randômica é muito alta estando entre 3 e 12ms (não importando se é um dispositivo de armazenamento de um servidor de última geração ou de notebook e ignorando o buffer de escrita controlador do disco) enquanto o acesso sequencial oferece uma taxa de transferência muito maior. O HDD típico faz em torno de 200 operações de E/S por segundo (IOPS, I/O operations per second).

Um SSD não tem partes móveis, acesso randômico é tão rápido quanto sequencial, tipicamente abaixo de 0.1ms, e pode manusear múltiplas solicitações concorrentes. A velocidade de saída do SSD típico é maior que 10.000 IOPS, que é mais do que o necessário para situações comuns de grande trabalho.

Se existem muitos processos fazendo solicitações de E/S para diferentes partes do armazenamento, milhares de IOPS podem ser gerados enquanto o HDD típico pode manusear em torno de somente 200 IOPS. Existe uma fila de solicitações que terão de esperar para acessar o disco. Esta situação é onde escalonadores de E/S entram com a tarefa de otimização.

Os algoritmos de escalonamento de processos

Uma maneira de melhorar a taxa de transferência é linearizar o acesso: ao ordenar as solicitações ociosas por seu endereço lógico e agrupar os mais próximos. Historicamente isto foi o primeiro escalonador de E/S chamado elevator (elevador).

Um problema com o algoritmo elevator é sua falta de otimização para processos que fazem acessos sequenciais: lê um bloco de dados, o processa por alguns microssegundos, e então vai para o próximo. O elevator não sabe que o processo vai ler outro bloco próximo e, então, vai para a próxima solicitação de outro processo em outra localização. O escalonador de E/S anticipatory (antecipatório) supera este problema: pausa por alguns milissegundos em antecipação de outra operação de leitura próxima antes de lidar com outras solicitações.

Enquanto estes escalonadores tentam melhorar a taxa de transferência total, eles podem deixar algumas solicitações sem sorte em espera por um longo período de tempo. Por exemplo, imagine que a maioria do processos fazem solicitações no começo do espaço de armazenamento enquanto um processo sem sorte faz um no final do espaço. O processo pode potencialmente ser adiado infinitamente, isto é chamado de inanição ou "starvation", em inglês. Pensando nesse problema, o algoritmo de deadline foi desenvolvido. Existe uma fila ordenada por endereço, similar ao elevator, mas se a solicitação fica em espera por muito tempo, ela é movida para a fila "expired", ordenada pelo tempo de expiração. O escalonador verifica a fila "expired" primeiro e processa os seus pedidos e somente então vai para a fila elevator. Note que isto tem um efeito negativo na taxa de transferência geral.

O Completely Fair Queuing (CFQ) (fila completamente justa) aborda o problema diferentemente ao alocar um período fixo de tempo e um número de solicitações permitidas por vez dependendo da prioridade do processo submetendo elas. Suporta o cgroup que permite a reserva de alguma quantidade de E/S para um grupo específico de processos. É particularmente útil para hosting compartilhado e nuvem: usuários que pagam por alguns IOPS querem sua parte quando necessários. Além disso, ele fica ocioso no final da E/S síncrona, aguardando outras operações próximas, assumindo esse recurso do escalonador anticipatory e trazendo algumas melhorias. Ambos, anticipatory e elevator foram descomissionados do kernel Linux e substituídos pelas alternativas mais avançadas apresentadas nesta seção.

O Budget Fair Queuing (BFQ)^{[link inativo 2024-12-15 ⓘ]} (carteira de fila justa) é baseado no código do CFQ e trás algumas melhorias. Não garante o disco para cada processo por um período fixo de tempo mas uma "budget" (carteira) mensurada no número de setores para os processos e usa heurísticas. É relativamente complexo, pode ser mais adaptado a unidades de armazenamento rotacionais e SSDs lentos por causa de seu alto uso de recursos por operação, especialmente se associado com uma CPU lenta, pode diminuir o desempenho de dispositivos rápidos. O objetivo do BFQ em sistemas pessoais é esse, em tarefas interativas, o dispositivo de armazenamento é virtualmente tão responsivo quanto se estivesse ocioso. Na configuração padrão se foca em entregar a latência mais baixa do que a taxa de transferência máxima.

Kyber é um escalonador recente inspirado pelas técnicas de gerenciamento ativo de fila usado para roteamento de rede. A implementação é baseada em "tokens" que servem como um mecanismo para limitar solicitações. Um token de fila é necessário para alocar uma solicitação, para prevenir a inanição de solicitações. Um token de despacho é também necessário e limita as operações de certa prioridade para dado dispositivo. Finalmente, uma latência alvo de leitura é definida e o escalonador se otimiza para chegar nela. A implementação do algoritmo é relativamente simples e é considerada eficiente para dispositivos rápidos.

Escalonadores de E/S do kernel

Enquanto alguns algoritmos iniciais já foram descomissionados, o kernel oficial do Linux suporta um número de escalonadores de E/S que podem ser divididos em duas categorias:

Os multi-queue schedulers (escalonadores de filas múltiplas) estão disponíveis por padrão no kernel. O Multi-Queue Block I/O Queuing Mechanism (blk-mq), em português mecanismo de empilhamento de blocos de E/S de várias filas, mapeia solicitações de E/S para múltiplas filas, as tarefas são distribuídas pelas threads, e consequentemente, núcleos da CPU. Os seguintes escalonadores estão disponíveis:
- None, onde nenhum algoritmo de fila é aplicado.
- mq-deadline, o algoritmo do escalonador "deadline" (veja abaixo) para multithreads.
- Kyber
- BFQ

Os single-queue schedulers (escalonadores de única fila) são datados:
- NOOP é o escalonador mais simples, ele insere todas as solicitações que chegam em uma simples fila FIFO e implementa a sua execução. Neste algoritmo, não existe reordenação da solicitação baseada no número do setor. Ela pode ser feita em outra camada, por exemplo no nível do dispositivo, ou se isto não importa, ignorada como em SSDs.
- Deadline
- CFQ

Nota: escalonadores de fila única foram removidos do kernel desde o Linux 5.0.

Mudando o escalonador de E/S

Nota:

A melhor escolha de qual escalonador usar depende de ambos, o dispositivo e o que vai ser utilizado. Também, a taxa de transferência em MB/s não é o único fator para mensurar o desempenho: tempo limite ou igualdade para processos pioram a taxa de transferência geral mas podem melhorar a responsividade do sistema. Fazer benchmark pode ser útil para indicar o desempenho de cada escalonador de E/S.

Para listar os escalonadores disponíveis para um dispositivo e o atualmente ativo (em colchetes):

$ cat /sys/block/sda/queue/scheduler

mq-deadline kyber [bfq] none

Para listar os escalonadores disponíveis para todos os dispositivos:

$ grep "" /sys/block/*/queue/scheduler

/sys/block/pktcdvd0/queue/scheduler:none
/sys/block/sda/queue/scheduler:mq-deadline kyber [bfq] none
/sys/block/sr0/queue/scheduler:[mq-deadline] kyber bfq none

Para mudar o escalonador ativo para bfq no dispositivo sda, execute:

# echo bfq > /sys/block/sda/queue/scheduler

O processo para mudar o escalonador de E/S, dependendo se o disco é rotativo ou não, pode ser automatizado e persistir entre reinicializações. Por exemplo a regra do udev abaixo define o escalonador como none para NVMe, mq-deadline para SSD/eMMC, e bfq para unidades de armazenamento rotativas:

/etc/udev/rules.d/60-ioschedulers.rules

# define o escalonador para NVMe
ACTION=="add|change", KERNEL=="nvme[0-9]*", ATTR{queue/scheduler}="none"
# define o escalonador para SSD e eMMC
ACTION=="add|change", KERNEL=="sd[a-z]|mmcblk[0-9]*", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="mq-deadline"
# define o escalonador para discos rotativos
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="bfq"

Reinicie ou force o udev a carregar as novas regras.

Otimizando o escalonador de E/S

Cada um dos escalonadores de E/S do kernel tem suas próprias variáveis modificáveis, tais como tempo de latência, tempo de expiração ou parâmetros FIFO. Eles ajudam a ajustar o algoritmo para uma combinação particular do dispositivo e carga de trabalho. Isto é tipicamente usado para conseguir uma maior taxa de transferência ou diminuir a latência.

As variáveis modificáveis e suas descrições podem ser encontradas na documentação do kernel.

Para listar as váriaveis modificáveis para um dispositivo, no exemplo abaixo é usado o sdb que está usando o deadline, execute:

$ ls /sys/block/sdb/queue/iosched

fifo_batch  front_merges  read_expire  write_expire  writes_starved

Para melhorar a taxa de transferência do deadline ao custo de latência, você pode aumentar o fifo_batch com o comando:

# echo 32 > /sys/block/sdb/queue/iosched/fifo_batch

Configuração de gerenciamento de energia

Ao lidar com discos rotacionais tradicionais (HDDs) você pode querer diminuir ou desabilitar funcionalidades de economia de energia completamente.

Reduzir leituras/escritas no disco

Evitar acessos desnecessários em unidades de armazenamento lentas é bom para a performance e também aumenta a vida útil dos dispositivos, apesar que em hardware moderno a diferença é normalmente insignificante.

Nota: Um SSD de 32GB com um fator medíocre de amplificação de escrita em 10 vezes, um padrão de 10000 ciclos de escrever/apagar, e 10GB de dados escritos por dia, deve lhe dar uma expectativa de vida útil de 8 anos. Isto melhora com SSDs maiores e controladores modernos com menos amplificação de escrita. Também compare [1]^{[link inativo 2024-12-15 ⓘ]} ao considerar se qualquer estratégia particular para limitar escritas no disco é, de verdade, necessária.

Mostrar escritas no disco

O pacote iotop pode ordenar programas por escritas no disco, e mostrar quanto e quão frequentemente estes estão escrevendo no disco. Veja iotop(8) para detalhes.

Realocar arquivos para tmpfs

Realocar arquivos, tais como perfil do navegador, para um sistema de arquivos tmpfs, melhora a responsividade do programa já que todos os arquivo estão guardados na RAM:

Veja Profile-sync-daemon para sincronizar perfis do navegador. Certos navegadores podem precisar de atenção especial, veja por exemplo Firefox on RAM.
Veja Anything-sync-daemon para sincronizar qualquer diretório específico.
Veja Makepkg#Melhorando os tempos de compilação para melhorar tempo de compilação ao compilar pacotes no tmpfs.

Sistema de arquivos

Veja a página correspondente do seu sistema de arquivos para possíveis instruções que melhoram a performance, exemplo ext4#Melhorando o desempenho e XFS (Português)#Desempenho.

Espaço swap

Veja swap#Desempenho.

Intervalo de writeback e tamanho do buffer

Veja Sysctl#Virtual memory para detalhes.

Agendando tarefas de E/S com ionice

Muitas tarefas como backup não dependem de um pequeno atraso de E/S ou uma grande banda de armazenamento de E/S para seu objetivo, eles podem ser classificados como tarefas de segundo plano. O E/S rápido é necessário para boa responsividade da interface do usuário no desktop. Então, é benéfico reduzir a quantidade de banda de armazenamento disponível para tarefas de segundo plano, enquanto outras precisam de prioridade. Isto pode ser alcançado ao fazer uso do escalonador de E/S CFQ do linux, que permite configurar diferentes prioridades para os processos.

A prioridade de E/S de um processo de segundo plano pode ser reduzida para o nível "idle" (ocioso) com o comando:

# ionice -c 3 seu_comando_aqui

Veja ionice(1) e [2] para mais informação.

CPU

Overclocking

Overclocking melhora a performance computacional da CPU ao aumentar o pico da frequência do clock. A habilidade para fazer overclock depende da combinação do modelo da CPU e placa-mãe. É mais frequentemente feito através da BIOS. Fazer overclock também tem desvantagens e riscos, não é nem recomendado nem desencorajado aqui.

Muitos chips da Intel não vão reportar corretamente a frequência do clock para acpi_cpufreq e a maioria dos utilitários. Isto resulta em excessivas mensagens no dmesg, que podem ser evitados ao descarregar ou colocar o módulo do kernel apcu_cpufreq na blacklist. Para ler a velocidade do seu clock, use i7z do pacote i7z. Para verificar se a CPU com overclock está operando corretamente, é recomendado fazer um teste de estresse.

Escala de frequência

Veja Escala de frequência do CPU.

Escalonadores alternativos da CPU

This article or section needs expansion.

Reason: MuQSS não é o único escalonador alternativo. (Discuss in talk:improving performance)

O escalonador padrão da CPU que está na mainline do kernel Linux é o CFS. Existem alternativas.

Um escalonador alternativo focado na interatividade e responsividade é o MuQSS, desenvolvido por Con Kolivas^{[link inativo 2024-10-12 ⓘ]}. MuQSS está incluído no pacote do kernel linux-zen. Está também disponível como um patch independente ou como parte do conjunto de patches -ck. Veja Linux-ck and Linux-pf para mais informações sobre.

Real-time kernel

Algumas aplicações como usar uma placa sintonizadora de televisão na resolução FULL HD (1080p) podem se beneficiar do uso do realtime kernel.

Ajustando as prioridades dos processos

Veja também nice(1) e renice(1).

Ananicy

Ananicy é um daemon, disponível no pacote ananicy-git^AUR, para auto ajustar o nível nice dos executáveis. Os níveis nice representam a prioridade dos executáveis quando alocam recursos da CPU.

cgroups

Veja cgroups (Português).

Cpulimit

Cpulimit é um programa que limita o uso da CPU de um processo específico. Depois de instalar cpulimit^AUR, você pode limitar o PID de um processo usando uma escala de 0 a 100 vezes o número de núcleos da CPU que o computador têm. Por exemplo, com oito núcleos a porcentagem vai ser de 0 a 800. Uso:

$ cpulimit -l 50 -p 5081

irqbalance

A proposta do irqbalance é distribuir interrupção de hardware entre processadores em um sistema com múltiplos processadores para aumentar o desempenho. Pode ser controlado com irqbalance.service.

Desligar as mitigações das falhas da CPU

Atenção: Não aplique esta configuração sem considerar as vulnerabilidades que isto causa. Veja isto e isto para mais informações.

Desligar as mitigações de falhas da CPU melhoram o desempenho (algumas vezes mais de 50%). Use o parâmetro do kernel abaixo para desabilitá-las:

mitigations=off

A explicação de todos os switches que são passados está no kernel.org. Você pode usar spectre-meltdown-checker^AUR para checar vulnerabilidade.

Gráficos

Configuração do Xorg

O desempenho gráfico pode depender das configurações presentes no xorg.conf(5); veja os artigos da NVIDIA, AMDGPU e Intel. Configurações erradas podem fazer o Xorg deixar de funcionar, tome cuidado.

Configuração do Mesa

O desempenho dos drivers Mesa pode ser configurado com drirc. As seguintes ferramentas gráficas estão disponíveis:

adriconf (Advanced DRI Configurator) — Ferramenta gráfica para configurar os drivers Mesa ao definir opções e escrevê-las para o arquivo drirc padrão.

https://gitlab.freedesktop.org/mesa/adriconf/ || adriconf

DRIconf — Applet de configuração para Direct Rendering Infrastructure, DRI (Inflaestrutura de Renderização Direta, em português). Permite customizar o desempenho e configurações da qualidade visual dos drivers OpenGL em um nível por unidade de armazenamento, por tela e/ou por aplicação.

https://dri.freedesktop.org/wiki/DriConf/ || driconf^AUR^{[link quebrado: package not found]}

Overclocking

Assim como acontece com CPUs, overclocking pode diretamente melhorar o desempenho, mas geralmente não é recomendado. Existem pacotes no AUR, tais como amdoverdrivectrl^AUR^{[link quebrado: package not found]} (placas antigas da AMD/ATI), rocm-smi^AUR^{[link quebrado: package not found]} (placas recentes da AMD), nvclock^AUR (placas antigas da NVIDIA - até o Geforce 9), e nvidia-utils para placas recentes da NVIDIA.

Veja AMDGPU#Overclocking ou NVIDIA/Tips and tricks#Enabling overclocking.

RAM, swap e gerenciamento da falta de memória

Tempos e frequência de clock

A RAM pode rodar em diferentes tempos e clock, isto pode ser configurado na BIOS. O desempenho da memória depende de ambos os valores. Selecionar o valor mais alto presente na BIOS normalmente melhora o desempenho em comparação com o valor padrão. Note que aumentar a frequência para valores maiores que os suportados pelos fabricantes da placa-mãe e RAM é overclocking, riscos e desvantagens similares se aplicam nesse caso, veja #Overclocking.

Raiz na RAM

Se está usando um dispositivo com lenta capacidade de escrita (USB, HDDs rotativos) e os requerimentos de armazenamento são baixos, a raiz pode rodar na RAM em cima de uma raiz somente leitura (no disco). Isto pode aumentar significamente o desempenho ao custo de um limitado espaço modificável na raiz do sistema. Veja liveroot^AUR.

Zram ou zswap

O módulo zram do kernel (antigamente chamado de compcache) oferece um dispositivo de bloco comprimido na RAM. Se você usa isto como um dispositivo swap, A RAM pode guardar muito mais informações mas usa mais CPU. Apesar disso, é muito mais rápido que usar um disco rígido. Se um sistema regularmente recorre a swap, isto pode aumentar a responsividade. Usar zram é também uma boa maneira de reduzir ciclos de leitura/escrita no disco que ocorrem por causa da swap em SSDs.

Benefícios similares (em custos similares) podem ser alcançados usando zswap. Os dois são geralmente similares em intenção mas não em implementação: zswap opera como um cache da RAM comprimida e nem precisa (nem permite) extensiva configuração no userspace.

Exemplo: Para definir um dispositivo zram com capacidade de 32GiB, comprimido com lz4 e prioridade maior que o normal (somente para a atual sessão):

# modprobe zram
# echo lz4 > /sys/block/zram0/comp_algorithm
# echo 32G > /sys/block/zram0/disksize
# mkswap --label zram0 /dev/zram0
# swapon --priority 100 /dev/zram0

Para desabilitá-lo, reinicie o sistema ou execute:

# swapoff /dev/zram0
# rmmod zram

Uma explicação detalhada de todos os passos, opções e potenciais problemas pode ser encontrada na documentação oficial do módulo zram.

O pacote systemd-swap^AUR oferece a unit systemd-swap.service para automaticamente inicializar dispositivos zram. É possível configurar em /etc/systemd/swap.conf.

O pacote zramswap^AUR oferece um script automatizado para configurar uma swap com uma maior prioridade e um tamanho padrão de 20% da RAM do seu sistema. Para fazer isto automaticamente em toda inicialização, habilite o zramswap.service.

Swap na zRAM usando uma regra do udev

O exemplo abaixo descreve como configurar swap na zRAM automaticamente na inicialização com uma única regra do udev. Nenhum pacote precisa ser instalado.

Primeiro, habilite o módulo:

/etc/modules-load.d/zram.conf

zram

Configure o número de células da /dev/zram que você precisa.

/etc/modprobe.d/zram.conf

options zram num_devices=2

Crie a regra do udev como mostrado no exemplo.

/etc/udev/rules.d/99-zram.rules

KERNEL=="zram0", ATTR{disksize}="512M" RUN="/usr/bin/mkswap /dev/zram0", TAG+="systemd"
KERNEL=="zram1", ATTR{disksize}="512M" RUN="/usr/bin/mkswap /dev/zram1", TAG+="systemd"

Adicione /dev/zram para seu fstab.

/etc/fstab

/dev/zram0 none swap defaults 0 0
/dev/zram1 none swap defaults 0 0

Usando a RAM da placa de vídeo

No cenário pouco provável onde você tem pouca RAM e excedente memória de vídeo, você pode usar a última como swap. Veja Swap on video RAM.

Melhorando a responsividade do sistema em condições de baixa memória

Nota: OOM-killer é um processo invocado pelo kernel em situações de baixa memória que mata processos que podem estar usando muita memória.

Em sistemas GNU/Linux tradicionais, especialmente para estações de trabalho gráficas, quando a memória alocada é comprometida, a responsividade média do sistema pode se degradar para um estado quase inusável antes que o OOM-killer do kernel seja ativado ou uma quantidade suficiente de memória for liberada (difícil de acontecer rapidamente quando o sistema está irresponsívo, já que você dificilmente pode fechar uma aplicação pesada que pode continuar a alocar memória). O comportamento também depende de configurações e condições específicas, retornar para um estado responsivo pode demorar desde alguns segundos a mais de meia hora, isto pode ser penoso em cenários sérios como durante uma apresentação de conferência.

Enquanto o comportamento do kernel como também programas do userspace em situações de baixa memória pode melhorar no futuro como discutido nas listas de discussão do kernel[3] e fedora[4], usuários podem usar opções mais viáveis e efetivas que desligar o sistema ou aprimorar os parâmetros do sysctl vm.overcommit_*, como:

Ativar manualmente o OOM-killer do kernel com Magic SysRq key, nomeadamente Alt+SysRq+f.
Usar um serviço de gerenciamento da falta de memória no userspace para derrubar eles automaticamente (ou interativamente).

Atenção: Ativar o OOM killer para matar programas em execução pode levar a perca de seus trabalhos não salvos. Depende da sua escolha, se você é paciente o bastante para aguardar, esperando que programas vão ultimamente liberar memória de forma normal, ou se você quer recuperar um sistema não responsivo o mais rápido possível.

Algumas vezes um usuário pode preferir um serviço OOM ao invês do SysRq porquê com o OOM-killer do kernel você não pode priorizar o processo a ser terminado (ou não). Lista de algumas implementações:

earlyoom — Simples implementação do OOM-killer no userspace escrito em C. Fedora vai usá-lo em sua instalação Workstation padrão [5].

https://github.com/rfjakob/earlyoom || earlyoom

oomd — Implementação do OOM-killer baseado no PSI, precisa da versão 4.20+ do kernel Linux. Configuração é feita em JSON e é muito complexa. Funciona no ambiente de produção do Facebook.

https://github.com/facebookincubator/oomd || oomd^AUR

nohang — Sofisticado gerenciador da falta de memória escrito em Python, com suporte opcional para PSI, mais configurável que o earlyoom.

https://github.com/hakavlad/nohang || nohang-git^AUR

low-memory-monitor — Esforço de um desenvolvedor do GNOME com o objetivo de oferecer melhor comunicação em programas do userspace para indicar estado de baixa memória, pode ser configurado para ativar o OOM-killer do kernel. Baseado no PSI, precisa do Linux 5.2+.

https://gitlab.freedesktop.org/hadess/low-memory-monitor/ || low-memory-monitor-git^AUR

Rede

Gerenciador de rede do Kernel: veja Sysctl#Improving performance
NIC: veja Configuração de rede#Definindo o MTU do dispositivo e o tamanho da fila
DNS: considere usar um servidor de cache do resolvedor DNS, veja Resolução de nome de domínio#Servidores DNS
Samba: veja Samba#Melhorar o desempenho

Watchdogs

De acordo com Wikipedia:Watchdog timer (traduzido):

Um watchdog timer [...] é um temporizador eletrônico que é usado para detectar e recuperar o computador de malfuncionamento. Durante a operação normal, o computador regularmente reseta o watchdog timer [...]. Se, [...], o computador falha para resetar o watchdog, o temporizador vai decorrer e gerar um sinal de timeout [...] usado parar iniciar ações corretivas [...] tipicamente incluindo colocar o sistema do computador em um estado seguro e restaurar a sua operação normal.

Muitos usuários precisam desta funcionalidade devido a cargos críticos do sistema (exemplo, servidores), ou devido a falta de of power reset (exemplo, dispositivos embarcados). Nessas situações, esta funcionalidade é necessária para uma boa operação do sistema. No entanto, usuários normais (exemplo, desktop e notebooks) não precisam disso e podem desabilitá-la.

Para desabilitar temporizadores watchdog (ambos em software e hardware), adicione nowatchdog para seus parâmetros de inicialização.

Para verificar a nova configuração, execute:

# cat /proc/sys/kernel/watchdog

ou use:

# wdctl

Depois que você desabilitou os watchdogs, você pode opcionalmente evitar o carregamento do módulo responsável pelo watchdog de hardware, também. Basta adicionar à lista negra o módulo, por exemplo, iTCO_wdt.

Nota: Alguns usuários reportaram que o parâmetro nowatchdog não funciona como esperado mas eles desabilitaram com sucesso (ao menos o de hardware) ao colocar o módulo citado acima no blacklist.

Qualquer ação vai aumentar a acelerar a inicialização e desligar a máquina, devido a ser um módulo a menos carregado. Também, desabilitar temporizadores do watchdog aumenta a performance e abaixa o consumo de energia.

Veja [6], [7], [8], e [9] para mais informações.

Veja também