Usando e entendendo as opções relacionadas ao agendamento do systemd em um contexto de área de trabalho

Nos arquivos de serviço systemd, é possível definir as seguintes opções relacionadas ao agendamento (na systemd.execpágina de manual , corrija-me se estiver errado):

Agradável Define o nível agradável padrão (prioridade de agendamento) para os processos executados. Leva um número inteiro entre -20 (prioridade mais alta) e 19 (prioridade mais baixa). Veja setpriority (2) para detalhes.

Qual é o bom nível familiar. Parece que seu efeito é 'subvertido' devido ao recurso de 'grupo automático' dos kernels recentes do linux. Portanto, as opções abaixo podem ser o que eu realmente gostaria de definir para manter os processos se comportando bem na minha experiência na área de trabalho.

CPUSchedulingPolicy Define a política de agendamento da CPU para processos executados. Tira um dos outros, lote, inativo, fifo ou rr. Veja sched_setscheduler (2) para detalhes.

CPUSchedulingPriority Define a prioridade de agendamento da CPU para processos executados. O intervalo de prioridade disponível depende da política de agendamento da CPU selecionada (veja acima). Para políticas de agendamento em tempo real, um número inteiro entre 1 (prioridade mais baixa) e 99 (prioridade mais alta) pode ser usado. Veja sched_setscheduler (2) para detalhes.

CPUSchedulingResetOnFork Leva um argumento booleano. Se verdadeiro, as prioridades e políticas de agendamento da CPU elevadas serão redefinidas quando os processos executados se bifurcam e, portanto, não podem vazar para os processos filhos. Veja sched_setscheduler (2) para detalhes. O padrão é false.

Eu entendo a última opção. Concluo da explicação dos dois primeiros que posso escolher uma política de agendamento e, em seguida, dada essa política, uma prioridade. Não está totalmente claro para mim o que devo escolher para que tipo de tarefas. Por exemplo, é seguro escolher 'inativo' para tarefas de backup (relativamente intensivas da CPU, devido à deduplicação) ou é outra mais adequada?

Em geral, é o que estou procurando obter uma visão geral compreensível de cada política, com cada uma de suas prioridades e adequação a finalidades específicas. Também a interação com o bom nível é de interesse.

Ao lado do agendamento da CPU, há agendamento de E / S. Eu acho que isso corresponde a ionice(me corrija se eu estiver errado).

IOSchedulingClass Define a classe de agendamento de E / S para processos executados. Obtém um número inteiro entre 0 e 3 ou uma das seqüências nenhuma, em tempo real, melhor esforço ou inatividade. Veja ioprio_set (2) para detalhes.

IOSchedulingPriority Define a prioridade de agendamento de E / S para os processos executados. Pega um número inteiro entre 0 (prioridade mais alta) e 7 (prioridade mais baixa). As prioridades disponíveis dependem da classe de planejamento de E / S selecionada (veja acima). Veja ioprio_set (2) para detalhes.

Aqui vemos a mesma estrutura do agendamento da CPU. Também estou procurando o mesmo tipo de informação.

Para todas as opções de 'Agendamento', as páginas de manual mencionadas não são claras o suficiente para mim, principalmente na tradução de coisas para o ponto de vista de um usuário de desktop um pouco tecnicamente inclinado.

CPUScheduling {Policy | Priority}

O link diz que CPUSchedulingPrioritysó deve ser definido para fifoou rr( "em tempo real") tarefas. Você não deseja forçar o agendamento em tempo real nos serviços.

CPUSchedulingPolicy=other é o padrão.

Isso sai batche idle. A diferença entre eles é relevante apenas se você tiver várias tarefas de prioridade ociosa consumindo CPU ao mesmo tempo. Em teoria, batchfornece maior rendimento (em troca de latências mais longas). Mas não é uma grande vitória, por isso não é realmente relevante neste caso.

idleliteralmente morre de fome se algo mais quiser a CPU. A prioridade da CPU é bastante menos significativa do que costumava ser, para sistemas UNIX antigos com um único núcleo. Eu ficaria mais feliz começando com nice, por exemplo, bom nível 10 ou 14, antes de recorrer idle. Veja a próxima seção.

No entanto, a maioria dos desktops fica relativamente inativa na maioria das vezes. E quando você tem um porco da CPU que anteciparia a tarefa em segundo plano, é comum que o porco use apenas uma de suas CPUs. Com isso em mente, eu não me sentiria arriscado demais idleno contexto de um desktop ou laptop comum. A menos que tenha uma CPU Atom / Celeron / ARM classificada em ou abaixo de 15 watts ; então eu gostaria de olhar as coisas um pouco mais cuidadosamente.

O nível legal é 'subvertido' pelo recurso de 'grupo automático' do kernel?

Sim.

O agrupamento automático é um pouco estranho. O autor de systemdnão gostou da heurística, mesmo para desktops. Se você quiser testar a desativação autogrouping, você pode definir o sysctl kernel.sched_autogroup_enabled para 0. Eu acho que é melhor testar definindo o sysctl na configuração permanente e reiniciando, para garantir que você se livre de todos os grupos automáticos.

Então você deve conseguir níveis agradáveis ​​para seus serviços sem nenhum problema. Pelo menos nas versões atuais do systemd - consulte a próxima seção.

Por exemplo, o bom nível 10 reduzirá o peso que cada encadeamento possui no agendador de CPU do Linux para cerca de 10%. O bom nível 14 está abaixo de 5%. (Link: fórmula completa )

Apêndice: o nível legal é 'subvertido' pelos systemgr cgroups?

A DefaultCPUAccounting= configuração atual é desativada, a menos que possa ser ativada sem também ativar o controle da CPU por serviço. Então deve ficar bem. Você pode verificar isso na sua documentação atual:man systemd-system.conf

Esteja ciente de que o controle da CPU por serviço também será ativado quando qualquer serviço definir CPUAccounting / CPUWeight / StartupCPUWeight / CPUShares / StartupCPUShares.

O seguinte extrato do blog está desatualizado (mas ainda está online). O comportamento padrão foi alterado e a documentação de referência foi atualizada de acordo.

Como um bom padrão, se o controlador da cpu estiver ativado no kernel, o systemd criará um cgroup para cada serviço ao iniciá-lo. Sem nenhuma configuração adicional, isso já tem um efeito interessante: em um sistema systemd, todo serviço do sistema terá uma quantidade uniforme de CPU, independentemente de quantos processos ele consiste. Ou, em outras palavras: no seu servidor Web, o MySQL terá a mesma quantidade de CPU que o Apache, mesmo se o último consistir em 1000 processos de script CGI, mas o primeiro apenas em algumas tarefas de trabalho. (Esse comportamento pode ser desativado, consulte DefaultControllers = em /etc/systemd/system.conf.)

Além desse padrão, é possível configurar explicitamente os compartilhamentos de CPU que um serviço obtém com a configuração CPUShares =. O valor padrão é 1024; se você aumentar esse número, atribuirá mais CPU a um serviço do que um inalterado em 1024; se diminuir, menos.

http://0pointer.de/blog/projects/resources.html

O conselho de execução clássico é "Não Otimize, Benchmark".

Em vez de se preocupar com conselhos gerais, comece com um caso específico com o qual você tenha se aprimorado e tenha sido comparado com uma preocupação específica de desempenho. Deixe que os dados permitam que você ajuste a diretiva correta. Com os dados, pode ficar claro se o seu processo sofre de uma prioridade ruim, está sobrecarregando a CPU ou tem outro problema.

Os desktops modernos geralmente são muito rápidos para trabalhar, sem qualquer ajuste.