Eu tenho um executável compilado em C++, programque pode ser executado como um processo em segundo plano via systemd.
Também pode ser executado como um processo regular através da linha de comando (usado principalmente para depuração).
O processo realiza operações regulares de E/S entre outros aplicativos e um dispositivo externo. A comunicação do dispositivo acontece via Ethernet TCP/IP, enquanto as comunicações da aplicação são todas comunicações entre processos.
O problema é que o aplicativo, quando executado como um executável independente, é executado com um uso de CPU de cerca de 0,7% a 1,3%.
Quando o mesmo aplicativo é executado como um processo em segundo plano do systemd, a% de uso da CPU salta para ser executada aproximadamente no máximo CPUQuotapermitido nas configurações. Neste caso, definimos para 5%.
Por que é isso? Há algo acontecendo no systemd causando esse problema? A única diferença, do ponto de vista do código, entre executar como um aplicativo ou como um daemon é que, quando executado como um daemon, enviamos uma pulsação em intervalos de envio.
Responder1
Aplique estes ajustes:
1. Altere seu agendador de E/S para mq-deadline, conforme mostrado:
Certifique-se de que oagendador de prazo mqé carregado na inicialização adicionando uma entrada para ele em /etc/modules-load.d/modules.conf:
echo mq-deadline >> /etc/modules-load.d/modules.conf
Em seguida, edite /etc/default/grube certifique-se de que o agendador de prazos multiqueue esteja habilitado:
GRUB_CMDLINE_LINUX_DEFAULT="scsi_mod.use_blk_mq=1 elevator=mq-deadline"
Quando terminar, emita:
sudo update-grub
Em seguida, reinicie. Observe queagendadores de fila única foram removidos a partir do Linux 5.x.
O objetivo disso é garantir que o CFQ (Completely Fair Queuing) seja substituído. Este pode ser o agendador padrão em sua distribuição Linux, embora ultimamente, ogosta de OpenSUSEcomeçamos a definir o agendador de prazos multifilas como padrão. A principal vantagem do agendador de prazo de múltiplas filas é a sobrecarga de CPU muito baixa.
2. Mais importante:Desative o recurso de grupo automático (que é ativado por padrão) e ajuste os valores da variável sched_migration_cost em /etc/sysctl.conf.
Insira estas linhas em /etc/sysctl.conf:
kernel.sched_autogroup_enabled=0
kernel.sched_migration_cost_ns = 5000000
Em seguida, execute sysctl -pe reinicie.
Encontrei um problema semelhante há algum tempo na produção, que foi corrigido com os ajustes acima. As explicações para as diversas opções emessetópico foram extremamente úteis, assim como o acompanhamento de umcaso semelhante com Proxmox.