Configuração: SSD criptografado com luks aes-xts 512 bits (chave AES de 256 bits), sistema de arquivos ext4
dd desempenho de gravação de 138 MB/s , uso da CPU 97-100%
dd if=/dev/zero of=testfile status=progress bs=32M count=128
4294967296 bytes (4,3 GB, 4,0 GiB) copied, 31 s, 138 MB/s
128+0 Datensätze ein
128+0 Datensätze aus
4294967296 bytes (4,3 GB, 4,0 GiB) copied, 31,0463 s, 138 MB/s
dd desempenho de leitura de 110 MB/s , o uso da CPU começa com > 90 %, depois cai para cerca de 50-60 % e, no final da leitura do arquivo, sobe para > 90 % novamente.
#crop cache before
sudo sh -c "echo 1 > /proc/sys/vm/drop_caches"
Agora faça o teste:
dd if=testfile of=/dev/null status=progress bs=32M
4261412864 bytes (4,3 GB, 4,0 GiB) copied, 39 s, 109 MB/s
128+0 Datensätze ein
128+0 Datensätze aus
4294967296 bytes (4,3 GB, 4,0 GiB) copied, 39,1345 s, 110 MB/s
Agora vamos dar uma olhada no samba:
Gravar um arquivo de 1 GB em um compartilhamento de samba no disco comparado acima fornece cerca de 73 MB/s , o uso da CPU é de apenas cerca de 70%.
Ler um arquivo de 1 GB do compartilhamento do samba fornece apenas cerca de 64 MB/s , o uso da CPU é de cerca de 55%. Observe também este gráfico: Ele começa devagar e depois a velocidade sobe e desce, gerando algum tipo de forma de onda.
Copiando este arquivo imediatamente novamente, quando ele estiver em cache , então ele será copiado com 112 MB/s , portanto, velocidade GigabitEthernet completa como deveria.
Compare com a unidade não criptografada :
dd velocidade de gravação 133 MB/s
dd velocidade de leitura 207 MB/s
Gravação do Samba: 112 MB/s
Leitura do Samba: 112 MB/s
Portanto, a criptografia LUKS por si só fornece velocidade suficiente, o Samba sozinho também tem velocidade suficiente. Em combinação, há uma grande queda de desempenho, enquanto ainda há muitos recursos de CPU disponíveis que são usados quando apenas o dd é usado.
O que está errado aqui? Por que a CPU não é totalmente usada ao fazer operações para o samba enquanto está com o dd? O que pode ser feito para ter também desempenho total / uso da CPU com criptografia smb e luks?
Eu cavei mais fundo nisso.
Parece uma exibição errada do uso da CPU.
Lendo com samba de uma unidade não criptografada dando 112 MB/s exigindo cerca de 38% de uso da CPU em todo o sistema
O uso da CPU está flutuando entre 29% e às vezes até 94% durante a leitura de uma unidade não criptografada.
Agora, reduzindo o desempenho de leitura de criptografia de 110 MB/s em 38%, obtém-se 68,2 MB/s. Isso é bem próximo dos 64 MB/s.
Então, de um ponto de vista lógico: o próprio Samba requer relativamente muita CPU e, em combinação com a criptografia, a velocidade resultante parece fazer sentido agora.
BTW: O sistema feito esses testes é um Rasperry PI 400 com CPU de 4 núcleos com clock padrão de 1,8 GHz.
cryptsetup benchmark
relatórios para aes-xts com chave de 512 bits (portanto, criptografia AES de 256 bits) 77 MB/s para criptografia e 66,9 MB/s para descriptografia. No entanto, o cryptsetup faz esses testes com apenas uma CPU utilizada, então acho que o gerenciamento de energia reduz o clock da CPU, por isso, com criptografia e descriptografia reais, há muito mais desempenho como dd shows.Eu também fiz alguns outros testes de desempenho.
Também aumentei o tamanho de leitura antecipada em /dev/mapper e /dev/sdd de 256 para 65536 via
sudo blockdev --setra 65536 /dev/sdd
e,sudo blockdev --setra 65536 /dev/mapper/sdd_crypt
no entanto, isso não fez nenhuma diferença perceptível.Indo ainda mais fundo, encontrei este artigo muito interessante https://blog.cloudflare.com/speeding-up-linux-disk-encryption/
Sua pesquisa levou
no_read_workqueue
eno_write_workqueue
começou com o Kernel versão 5.9. Felizmente, o Rasperry PI OS atual está na versão 5.10.11-v7l+, portanto, o dmcrypt suporta essas opções.No entanto, a versão mais recente do cryptsetup 2.1.0 no Raspberry PI OS Buster não oferece suporte a essas opções. Então eu compilei o cryptsetup 2.3.4 para usar no_read_workqueue e no_write_workqueue (veja https://www.kernel.org/doc/html/latest/admin-guide/device-mapper/dm-crypt.html ) e montei via
no entanto, o desempenho foi enormemente reduzido nessa leitura de configuração específica do dispositivo e não do disco RAM.
Em conclusão: Como as velocidades resultantes são plausíveis, parece uma exibição errada do uso da CPU.