scheduler: como ajustar a cfq para favorecer processos interativos

0

Problema: o agendador não parece favorecer processos interativos:

Em um sistema desktop com backups agendados cron automaticamente de um ( btrfs ) disco para outro ( ext4 ). O processo de backup monta o disco ocioso ( /dev/sda<X> ), faz backups e finalmente o desmonta.

Toda vez que o processo de backup entra em ação, o sistema se torna inutilizável. O agendador parece estar falhando em fazer seu trabalho mais básico de favorecer processos interativos em vez de processos em lote. Enquanto os processos de backup são executados, há muita IO em andamento e todo o resto congela. O ponteiro do teclado e do mouse pára de responder. Eco quando as teclas são pressionadas em qualquer terminal / shell é atrasado por vários segundos.

Assim que o backup é concluído, a resposta interativa volta ao normal.

Mais detalhes sobre a configuração e configurações:

O processo de backup usa rsnapshot (que chama rsync e cp -al ) e é executado com prioridade mais baixa (a tarefa de backup é precedida por nice ), assim:

nice /usr/bin/rsnapshot -VD -c /etc/my-rsnapshot.conf daily

A execução do backup em nice parece não ajudar. Durante os backups, todos os processos interativos parecem estar sofrendo com o pesado CPU e IO dos processos rsync e cp .

Este é um sistema IA-64, iCore-7, que deve ser capaz de executar 8 processos em paralelo. A memória é de 16 GB e parte é gratuita. Desmatado mount output (quando o disco adicional é montado) é:

/dev/sdb2 on / type btrfs (rw,relatime,subvol=@,thread_pool=4)
/dev/sdb3 on /home type btrfs (rw,relatime,subvol=@home,thread_pool=4)

/dev/sda2 on /media/idisk/root ext4 (rw,relatime)
/dev/sda3 on /media/idisk/home ext4 (rw,relatime)

none on /sys/fs/cgroup type tmpfs (rw)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,relatime,cpuset,release_agent=/run/cgmanager/agents/cgm-release-agent.cpuset,clone_children)
cgroup on /sys/fs/cgroup/cpu type cgroup (rw,relatime,cpu,release_agent=/run/cgmanager/agents/cgm-release-agent.cpu)
cgroup on /sys/fs/cgroup/cpuacct type cgroup (rw,relatime,cpuacct,release_agent=/run/cgmanager/agents/cgm-release-agent.cpuacct)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,relatime,memory,release_agent=/run/cgmanager/agents/cgm-release-agent.memory)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,relatime,devices,release_agent=/run/cgmanager/agents/cgm-release-agent.devices)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,relatime,freezer,release_agent=/run/cgmanager/agents/cgm-release-agent.freezer)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,relatime,blkio,release_agent=/run/cgmanager/agents/cgm-release-agent.blkio)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,relatime,perf_event,release_agent=/run/cgmanager/agents/cgm-release-agent.perf_event)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,relatime,hugetlb,release_agent=/run/cgmanager/agents/cgm-release-agent.hugetlb)

Isso está em um sistema 14.04 LTS atualizado. O agendador, por padrão, está configurado para fila completamente justa ( cfq ):

# cat /sys/block/sda/queue/scheduler
noop deadline [cfq]
# cat /sys/block/sdb/queue/scheduler
noop deadline [cfq]

Consegui encontrar uma questão relacionada. o planejador morre os processos , o que sugere usar nice , mas eu já estou fazendo isso.

Outra questão relacionada com informações relevantes é: Como faço para alterar o noop scheduler

Como posso tornar o teclado, o mouse e os shells interativos mais responsivos quando o backup está em execução?

Obrigado antecipadamente.

    
por arielf 01.05.2016 / 04:03

1 resposta

0

Apenas uma resposta parcial, fiz mais pesquisas e experimentos desde perguntar quais resolveram meu problema, e vendo que não há respostas

Existem problemas / bugs conhecidos nos agendadores de kernel do Linux desde o início de 2016.

O breve resumo é que, sob diferentes circunstâncias, os núcleos permanecem inativos, embora haja processos executáveis na fila do processo.

Referências:

Uma mudança de btrfs para ext4 pode aliviar esses problemas:

Eu pessoalmente mudei de btrfs para ext4. O desempenho de E / S melhorou notavelmente.

Uma mudança para o SSD pode aliviar ainda mais o desempenho do IO

Os SSDs caíram significativamente em preço e confiabilidade. Um Samsung SSD de 2 TB (EVO 850) custa agora um pouco mais de $ 600. Mudar o sistema (root e home) para SSD agora torna a atividade intensiva de backup completamente imperceptível (o SSD do sistema é ágil enquanto grava pesado em um disco regular no formato ext4 no mesmo sistema).

Finalmente: com o SSD, o benefício de planejadores complexos no kernel parece se tornar questionável. Eu mudei meu padrão para noop sem degradação perceptível no desempenho. Na verdade, com um escalonador noop, vejo uma redução na carga do sistema, números mais baixos de escalonamento da CPU e temperaturas de hardware mais baixas.

$ cat /sys/block/sda/queue/scheduler
[noop] deadline cfq

$ cat /proc/cpuinfo | grep  Hz
model name      : Intel(R) Core(TM) i7-4771 CPU @ 3.50GHz
cpu MHz         : 836.308
model name      : Intel(R) Core(TM) i7-4771 CPU @ 3.50GHz
cpu MHz         : 990.253
... similar low actual frequency scaling for all cores ...
    
por arielf 11.05.2016 / 20:33