MISE À JOUR : Je n'ai plus ce problème sur 4.9. * Je ne sais pas quand il a été corrigé.
Tous les jours après une sauvegarde complète du système, divers programmes échouent avec des erreurs de lecture jusqu'à ce que je cours echo 2 > /proc/sys/vm/drop_cachespour libérer des objets de dalle récupérables.
Par exemple, voici la sortie sudo apt-get updateaprès une sauvegarde.
$ sudo apt-get update
Hit http://ftp.ca.debian.org unstable InRelease
Hit http://ftp.ca.debian.org experimental InRelease
Ign http://dl.google.com stable InRelease
Get:1 http://ftp.ca.debian.org unstable/contrib amd64 Packages/DiffIndex [7,819 B]
Hit http://dl.google.com stable Release.gpg
Hit http://ppa.launchpad.net wily InRelease
Get:2 http://ftp.ca.debian.org unstable/non-free amd64 Packages/DiffIndex [6,577 B]
Hit http://dl.google.com stable Release
Hit http://ppa.launchpad.net wily InRelease
Get:3 http://ftp.ca.debian.org unstable/main amd64 Packages/DiffIndex [7,876 B]
Get:4 http://ftp.ca.debian.org unstable/contrib i386 Packages/DiffIndex [7,819 B]
Get:5 http://ppa.launchpad.net wily/main amd64 Packages [4,559 B]
Get:6 http://ftp.ca.debian.org unstable/non-free i386 Packages/DiffIndex [6,715 B]
Get:7 http://ppa.launchpad.net wily/main i386 Packages [4,608 B]
Get:8 http://ftp.ca.debian.org unstable/main i386 Packages/DiffIndex [7,876 B]
Hit http://dl.google.com stable/main amd64 Packages
Get:9 http://ftp.ca.debian.org unstable/contrib Translation-en/DiffIndex [2,161 B]
Get:10 http://ppa.launchpad.net wily/main Translation-en [1,663 B]
Hit http://dl.google.com stable/main i386 Packages
E: Read error - read (5: Input/output error)
Un autre exemple d'erreur, cette fois avec gulp / node.js
$ gulp watch
fs.js:651
var r = binding.read(fd, buffer, offset, length, position);
^
Error: EIO: i/o error, read
at Error (native)
at Object.fs.readSync (fs.js:651:19)
at Object.fs.readFileSync (fs.js:467:24)
at Object.Module._extensions..js (module.js:431:20)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:313:12)
at Module.require (module.js:366:17)
at require (module.js:385:17)
at Object.<anonymous> (/usr/local/lib/node_modules/gulp/node_modules/liftoff/node_modules/findup-sync/lib/findup-sync.js:15:12)
at Module._compile (module.js:425:26)
D'autres programmes échouent également avec des erreurs de lecture, ce n'est pas seulement apt-get et gulp / node.js.
sortie sur dalle:
$ sudo slabtop -o
Active / Total Objects (% used) : 7244650 / 7322302 (98.9%)
Active / Total Slabs (% used) : 882626 / 882697 (100.0%)
Active / Total Caches (% used) : 78 / 122 (63.9%)
Active / Total Size (% used) : 3423174.16K / 3434416.86K (99.7%)
Minimum / Average / Maximum Object : 0.02K / 0.47K / 4096.00K
OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME
2419584 2418888 99% 0.97K 604896 4 2419584K btrfs_inode
2249163 2249125 99% 0.19K 107103 21 428412K dentry
1271127 1270067 99% 0.30K 97779 13 391116K btrfs_delayed_node
306243 299649 97% 0.06K 4861 63 19444K kmalloc-64
241556 230494 95% 0.27K 17254 14 69016K btrfs_extent_buffer
215068 212777 98% 0.14K 7681 28 30724K btrfs_path
186102 185989 99% 0.56K 26586 7 106344K radix_tree_node
174650 144422 82% 0.08K 3493 50 13972K btrfs_extent_state
37170 34869 93% 0.06K 590 63 2360K btrfs_free_space
37149 33473 90% 0.19K 1769 21 7076K kmalloc-192
32891 32382 98% 0.12K 1061 31 4244K kmalloc-96
26536 19327 72% 0.03K 214 124 856K kmalloc-32
24123 24015 99% 0.12K 731 33 2924K kernfs_node_cache
19656 19631 99% 0.07K 351 56 1404K Acpi-ParseExt
13728 11523 83% 0.25K 858 16 3432K kmalloc-256
11648 10783 92% 0.55K 1664 7 6656K inode_cache
11160 7283 65% 0.12K 360 31 1440K kmalloc-node
10696 9398 87% 0.07K 191 56 764K anon_vma
7059 6714 95% 0.10K 181 39 724K blkdev_ioc
3735 3615 96% 0.05K 45 83 180K ftrace_event_field
3696 3574 96% 0.50K 462 8 1848K kmalloc-512
3018 2871 95% 0.60K 503 6 2012K proc_inode_cache
1584 1503 94% 0.04K 16 99 64K Acpi-Namespace
1464 1418 96% 0.63K 244 6 976K shmem_inode_cache
1426 1348 94% 0.09K 31 46 124K trace_event_file
1400 1382 98% 1.00K 350 4 1400K kmalloc-1024
1311 1248 95% 4.00K 1311 1 5244K kmalloc-4096
1074 985 91% 0.62K 179 6 716K sock_inode_cache
852 806 94% 0.88K 213 4 852K RAW
726 718 98% 2.94K 363 2 2904K task_struct
612 608 99% 2.00K 306 2 1224K kmalloc-2048
462 447 96% 2.05K 154 3 1232K idr_layer_cache
462 210 45% 0.18K 21 22 84K btrfs_trans_handle
429 157 36% 0.10K 11 39 44K buffer_head
384 181 47% 0.31K 32 12 128K bio-1
355 217 61% 0.05K 5 71 20K file_lock_ctx
350 307 87% 1.12K 50 7 400K signal_cache
327 307 93% 2.06K 109 3 872K sighand_cache
289 211 73% 0.23K 17 17 68K cfq_queue
280 156 55% 0.38K 28 10 112K mnt_cache
sortie libre:
$ sudo free -h
total used free shared buff/cache available
Mem: 15G 2.3G 292M 28M 13G 13G
Swap: 7.5G 4.9M 7.4G
Après l'exécution, echo 2 > /proc/sys/vm/drop_cachesles erreurs n'apparaissent plus. apt-get et d'autres programmes fonctionnent correctement.
sortie sur dalle:
$ sudo slabtop -o
Active / Total Objects (% used) : 586239 / 777567 (75.4%)
Active / Total Slabs (% used) : 57059 / 57123 (99.9%)
Active / Total Caches (% used) : 79 / 122 (64.8%)
Active / Total Size (% used) : 180630.05K / 229256.91K (78.8%)
Minimum / Average / Maximum Object : 0.02K / 0.29K / 4096.00K
OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME
241556 230586 95% 0.27K 17254 14 69016K btrfs_extent_buffer
146251 100390 68% 0.56K 20893 7 83572K radix_tree_node
50967 26035 51% 0.06K 809 63 3236K kmalloc-64
37170 34866 93% 0.06K 590 63 2360K btrfs_free_space
37149 33440 90% 0.19K 1769 21 7076K kmalloc-192
37016 7054 19% 0.14K 1322 28 5288K btrfs_path
35889 13681 38% 0.19K 1709 21 6836K dentry
27700 1805 6% 0.08K 554 50 2216K btrfs_extent_state
26412 19384 73% 0.03K 213 124 852K kmalloc-32
24123 24067 99% 0.12K 731 33 2924K kernfs_node_cache
19656 19637 99% 0.07K 351 56 1404K Acpi-ParseExt
13712 11542 84% 0.25K 857 16 3428K kmalloc-256
12152 8791 72% 0.97K 3038 4 12152K btrfs_inode
10696 9414 88% 0.07K 191 56 764K anon_vma
9632 8948 92% 0.55K 1376 7 5504K inode_cache
8742 4845 55% 0.12K 282 31 1128K kmalloc-node
7059 6794 96% 0.10K 181 39 724K blkdev_ioc
4867 2606 53% 0.12K 157 31 628K kmalloc-96
3735 3710 99% 0.05K 45 83 180K ftrace_event_field
3688 3525 95% 0.50K 461 8 1844K kmalloc-512
1794 498 27% 0.30K 138 13 552K btrfs_delayed_node
1584 1521 96% 0.04K 16 99 64K Acpi-Namespace
1464 1418 96% 0.63K 244 6 976K shmem_inode_cache
1426 1348 94% 0.09K 31 46 124K trace_event_file
1420 1357 95% 1.00K 355 4 1420K kmalloc-1024
1310 1252 95% 4.00K 1310 1 5240K kmalloc-4096
1074 1016 94% 0.62K 179 6 716K sock_inode_cache
852 807 94% 0.88K 213 4 852K RAW
726 713 98% 2.94K 363 2 2904K task_struct
648 254 39% 0.60K 108 6 432K proc_inode_cache
636 635 99% 2.00K 318 2 1272K kmalloc-2048
506 240 47% 0.18K 23 22 92K btrfs_trans_handle
468 190 40% 0.10K 12 39 48K buffer_head
462 447 96% 2.05K 154 3 1232K idr_layer_cache
408 250 61% 0.31K 34 12 136K bio-1
355 161 45% 0.05K 5 71 20K file_lock_ctx
350 307 87% 1.12K 50 7 400K signal_cache
327 307 93% 2.06K 109 3 872K sighand_cache
300 286 95% 0.38K 30 10 120K mnt_cache
297 85 28% 0.04K 3 99 12K btrfs_delayed_extent_op
sortie libre:
$ sudo free -h
total used free shared buff/cache available
Mem: 15G 2.3G 6.1G 28M 7.3G 13G
Swap: 7.5G 4.8M 7.4G
J'utilise Debian Sid sur un btrfs mais j'ai eu le même problème avec ext4 donc je ne pense pas que ce soit un problème spécifique au système de fichiers.
$ uname -v
#1 SMP Debian 4.2.6-1 (2015-11-10)
J'ai également essayé de définir vfs_cache_pressure sur une valeur élevée.
vm.vfs_cache_pressure=[ 100 | 1000 | 100000 ]
J'obtiens moins d'erreurs de lecture à 100 000, mais l'utilisation du processeur augmente et la réactivité du système devient terrible, donc je cherche une solution alternative.
Je pourrais m'en tenir echo 2 > /proc/sys/vm/drop_cachesà un travail cron mais cela ne résout pas le problème, c'est juste une solution de contournement.
Voici dmesg
linux-kernel
memory
cache
Richard Ayotte
la source
la source
npm run watchopérations de suivi qui ont échoué avec cette erreur de lecture non descriptive. Je n'aurais jamais pensé à ça tout seul.drop_cachesrestauré les opérations instantanément, mais qu'est-ce qui se passe ici? Je suis sur le noyau4.4.4.Réponses:
kernel/mm/slab.cont eu un tas de correctifs récents (janvier, février 2017) traitant, entre autres, de la destruction lente du cache; dans certains cas, l'opération de destruction du cache peut durer plusieurs heures. L'opération elle-même était également coûteuse en performances.Cela dit, il n'est pas inhabituel de voir des chiffres élevés si vous avez beaucoup d'activité d'E / S sur disque. Cependant, vos comptes étaient probablement élevés, et peuvent avoir souffert de l'un des bogues corrigés concernant la destruction lente.
la source