O xanmod kernel pareceu ajudar. Eu estava rodando 16.04 com o ssd boot drive, gnome 3.2. Eu achava que o programador de prazos faria isso, mas não parecia ajudar muito. Isso é o que eu segui: link
Eu tenho uma tarefa semi-regular que eu faço na minha estação de trabalho Ubuntu 16.04: Ele tem um segundo disco com o Windows 7 nele. Basicamente é uma instalação simples, que às vezes eu inicializo e deixo o Windows Update rodar. A ideia é usá-lo para jogos, mas, bem, acontece que raramente tenho tempo. Eu ainda mantenho isso atualizado.
Esta tarefa semi-regular é clonar o disco usando ntfsclone depois de fazer essa atualização. Veja-o como um instantâneo de "baixa tecnologia", porque o Windows -alas não pode viver dentro de um volume LVM. (Bem, pode, se está sendo virtualizado.) Eu escrevi um script para fazer isso (e mais algumas coisas), porque eu sou preguiçoso, mas o comando que leva mais tempo e causa o problema é:
ntfsclone -s -o /home/jorg/Images/$(date +%F).ntfsclone /dev/sdc2
Em que /dev/sdc2 é a partição do Windows e /home/jorg/Images/ é um volume LVM, em um RAID1 composto por /dev/sda e /dev/sdb . Todos esses discos são discos rígidos normais, conectados usando SATA.
O problema que surge: quando faço isso, minha estação de trabalho se torna totalmente inutilizável. A responsividade é simplesmente horrível. Mesmo a troca e o login em um console virtual ( Ctrl - Alt - F1 ) é insuportavelmente lento.
Isso não está apenas usando ntfsclone e é por isso que eu suspeito de E / S de disco. Quando eu faço dd , uma ferramenta que costumo usar para ajudar pessoas com discos defeituosos, o mesmo acontece. É ainda pior com dd , porque isso geralmente passa por USB. Dito isso, usei dd em vez de ntfsclone como um teste com a configuração acima, ou seja, somente SATA e é tão ruim quanto. Sim, eu uso o parâmetro bs em dd para que o buffer seja feito corretamente.
A coisa é: enquanto o computador abrandou em 14.04, não se tornou inutilizável. Foi apenas "um pouco mais lento", mas navegação, e-mail, terminal todos ainda eram suportáveis para usar.
Até agora, eu também já joguei com os diferentes agendadores de disco. Os agendadores suportados são:
cat /sys/block/sda/queue/scheduler
noop [deadline] cfq
Mudar para cfq ou noop não ajudou. ( echo cfq > /sys/block/sda/queue/scheduler ).
Algumas informações sobre minha máquina:
root@tiger:~# uname -a
Linux tiger 4.4.0-34-generic #53-Ubuntu SMP Wed Jul 27 16:06:39 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
root@tiger:~# dmidecode -t baseboard | grep -e Product -e Manufacturer
Manufacturer: ASUSTeK COMPUTER INC.
Product Name: F1A75-V PRO
root@tiger:~# free -mh
total used free shared buff/cache available
Mem: 15G 1,7G 2,9G 154M 11G 13G
Swap: 31G 0B 31G
root@tiger:~# for disk in a b c ; do echo \[ Disk informatoin for \/dev\/sd$disk \] ; hdparm -I /dev/sd$disk | grep -e Model -e Transport ; done
[ Disk informatoin for /dev/sda ]
Model Number: ST1500DL003-9VT16L
Transport: Serial, SATA Rev 3.0
* SMART Command Transport (SCT) feature set
[ Disk informatoin for /dev/sdb ]
Model Number: ST1500DL003-9VT16L
Transport: Serial, SATA Rev 3.0
* SMART Command Transport (SCT) feature set
[ Disk informatoin for /dev/sdc ]
Model Number: WDC WD1002FAEX-00Z3A0
Transport: Serial, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6
* SMART Command Transport (SCT) feature set
Eu percebo que minhas /dev/sda e /dev/sdb não são potentes, mas elas ficaram bem abaixo de 14.04.
Alguém também está vendo um desempenho abismal ao fazer alta E / S? Em caso afirmativo, você encontrou uma solução alternativa?
O xanmod kernel pareceu ajudar. Eu estava rodando 16.04 com o ssd boot drive, gnome 3.2. Eu achava que o programador de prazos faria isso, mas não parecia ajudar muito. Isso é o que eu segui: link