Desvantagens de definir um tempo limite de E/S alto?

A maioria das gravações, sendo armazenadas em cache no pagecache sujo do sistema operacional, já são concluídas de forma assíncrona. Em outras palavras, eles geralmente não têm nada a ver com o tempo limite do dispositivo.

No entanto, leituras e gravações sincronizadas requerem atenção imediata do dispositivo de bloco subjacente, e esta é a razão pela qual seu sistema de arquivos muda para o modo somente leitura (ele não pode gravar seu diário no disco).

Aumentar o tempo de espera de E/S não deve ter nenhum impacto ruim, mas não é uma bala de prata. Por exemplo, um banco de dados pode entrar no modo somente leitura, mesmo que o sistema de arquivos subjacente permaneça no modo leitura/gravação.

Observe que o tempo limite SCSI padrão já é de 30 segundos. Isso já é bastante tempo em termos de computador :-P.

As solicitações de IO (por exemplo, gravações assíncronas) são limitadas por /sys/class/block/$DEV/nr_requests, e /sys/class/block/$DEV/max_sectors_kb. Na antiga camada de bloco de fila única, diz-se que o uso total de memória é 2*nr_requests*max_sectors_kb. O fator de 2 é porque leituras e gravações são contadas separadamente. Embora você também precise levar em consideração as solicitações na fila de hardware, consulte, por exemplo, cat /sys/class/block/sda/device/queue_depth. Geralmente, espera-se que você certifique-se de que a profundidade máxima da fila de hardware não seja maior que a metade de nr_requests.

1) Está escrito que, se suas solicitações de IO precisarem de muito espaço, você terá erros de falta de memória. Então você pode dar uma olhada nos valores acima em seu sistema específico. Normalmente eles não são um problema. nr_requestso padrão é 128. O valor padrão max_sectors_kbdepende da versão do seu kernel.

Se você usar a nova camada de bloco multifila (blk-mq), leituras e gravações não serão contadas separadamente. Portanto, a parte "multiplicar por dois" da equação desaparece e nr-requestso padrão é 256. Não tenho certeza de como a fila de hardware (ou filas) é tratada no blk-mq.

Quando a fila de solicitações está cheia, as gravações assíncronas podem se acumular no cache da página até atingirem o "limite sujo". Historicamente, o limite sujo padrão é descrito como 20% da RAM, embora a determinação exata seja um pouco mais complexa hoje em dia.

Quando você atinge o limite sujo, é só esperar. O kernel não tem outro limite de tempo além do tempo limite SCSI. Nesse sentido, os documentos comuns sobre esse tópico, incluindo o VMware KB, são suficientes. Embora você deva procurar a documentação específica que se aplica ao seu NAS :-P. Diferentes safras de NAS foram projetadas para fornecer tempos de pior caso diferentes.

2) Dito isso, se um processo estiver esperando pelo disco IO por mais de 120 segundos, o kernel imprimirá um aviso de "tarefa travada". (Provavelmente. Esse é o padrão usual. Exceto na minha versão do Fedora Linux, onde o kernel parece ter sido construído sem CONFIG_DETECT_HUNG_TEST. O Fedora parece ser um estranho estranho aqui).

A mensagem de tarefa travada não é uma falha e não define o sinalizador "contaminado" do kernel.

Após 10 avisos de tarefa travada (ou o que você definir sys.kernel.hung_task_warnings), o kernel parará de imprimi-los. Pensando nisso, na minha opinião você também deve aumentar o sysctl sys.kernel.hung_task_timeout_secspara que fique acima do tempo limite do SCSI, por exemplo, 480 segundos.

3) Aplicativos individuais podem ter seus próprios limites de tempo. Você provavelmente prefere ver um tempo limite do aplicativo, em vez de o kernel retornar um erro de E/S! Os erros de E/S do sistema de arquivos são comumente considerados fatais. O próprio sistema de arquivos pode remontar somente leitura após um erro de IO, dependendo da configuração. Erros de IO em dispositivos de troca ou arquivos mapeados em memória enviarão o sinal SIGBUS para o processo afetado, que geralmente encerrará o processo.

4) Se estiver usando systemd, os serviços que possuem um cronômetro de vigilância configurado podem ser reiniciados à força. Nas versões atuais do systemd, você pode ver, por exemplo, um tempo limite de 3 minutos se executar systemctl show -p WatchdogUSec systemd-udevd. Isso foi aumentado há quatro anos por um motivo diferente ; parece ser apenas uma coincidência que isso corresponda ao tempo limite de SCSI sugerido pela VMware :-). Essas reinicializações podem gerar ruído de log alarmante. systemdmata o processo com o SIGABRT, com a ideia de fazer um core dump para mostrar onde o processo travou. No entanto, coisas como udev e até journald devem ficar muito felizes em serem reiniciadas hoje em dia.

A principal preocupação seria certificar-se de que você não configurou um watchdog de reinicialização do espaço do usuário muito curto, por exemplo, RuntimeWatchdogSec=em /etc/systemd-system.conf. Mesmo se você não usar swap, seria possível systemdficar bloqueado pelo disco IO, por uma alocação de memória que entra no kernel "recuperação direta".