web-dev-qa-db-fra.com

Performances aberrantes d'E / S après la mise à niveau vers 16.04

J'ai une tâche semi-régulière que je fais sur mon poste de travail Ubuntu 16.04: il comporte un deuxième disque avec Windows 7. Il s’agit d’une installation nue, que j’initialise parfois et laisse Windows Update s'exécuter. L'idée est de l'utiliser pour les jeux, mais bon, j'ai rarement le temps. Je le tiens toujours à jour.

Cette tâche semi-régulière consiste à cloner le disque à l'aide de ntfsclone après une telle mise à jour. Considérez-le comme une capture instantanée "low-tech", car -alas- Windows ne peut pas vivre dans un volume LVM. (Eh bien, c'est possible si la virtualisation est en cours.) J'ai écrit un script pour le faire (et quelques autres choses), car je suis paresseux, mais la commande qui prend le plus de temps et cause le problème est la suivante:

ntfsclone -s -o /home/jorg/Images/$(date +%F).ntfsclone /dev/sdc2

/dev/sdc2 est la partition Windows et /home/jorg/Images/ est un volume LVM sur un RAID1 constitué de /dev/sda et /dev/sdb. Tous ces disques sont des disques durs normaux, connectés via SATA.

Le problème qui se pose: lorsque je le fais, mon poste de travail devient totalement et totalement inutilisable. La réactivité est simplement horrible. Même la commutation et la connexion à une console virtuelle (Ctrl-Alt-F1) sont trop lentes.

Ceci n’utilise pas seulement ntfsclone et c’est pourquoi je soupçonne des E/S de disque. Quand je fais dd, un outil que j'utilise souvent pour aider les gens avec des disques défectueux, la même chose se produit. C'est encore pire avec dd, parce que cela passe souvent par USB. Cela dit, j’ai utilisé dd au lieu de ntfsclone comme test avec la configuration ci-dessus, c’est-à-dire uniquement SATA, et c’est tout aussi mauvais. Oui, j'utilise le paramètre bs dans dd pour que la mise en mémoire tampon soit correctement effectuée.

Le problème est que, bien que l'ordinateur ait ralenti en 14.04, il n'est pas devenu inutilisable. C'était juste "un peu plus lent", mais la navigation, les e-mails, les terminaux étaient encore supportables.

À ce jour, j'ai également joué avec les différents ordonnanceurs de disques. Les planificateurs supportés sont:

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

Passer à cfq ou noop n'a pas aidé. (echo cfq > /sys/block/sda/queue/scheduler).

Quelques informations sur ma machine:

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

Je réalise que mes /dev/sda et /dev/sdb ne sont pas des centrales électriques, mais ils se sont bien comportés en 14.04.

Est-ce que quelqu'un voit également des performances abyssales quand on fait de fortes E/S? Si oui, avez-vous trouvé une solution de contournement?

2
jawtheshark

Le noyau xanmod a semblé aider. Je courais 16.04 avec le lecteur de démarrage ssd, gnome 3.2. Je pensais que le planificateur de délais ferait l'affaire, mais cela ne semblait pas beaucoup aider. Voici ce que j’ai suivi: http://www.hecticgeek.com/2016/09/supercharge-ubuntu-16-04-lts-xanmod-kernel/

1
Doug Twyman