Pourquoi les objects en dalle ne sont-ils pas récupérés automatiquement

MISE À JOUR : Je n'ai plus ce problème avec la version 4.9. * Je ne suis pas sûr de la date de la correction.

Tous les jours après une sauvegarde complète du système, divers programmes échouent avec des erreurs de lecture jusqu'à ce que echo 2 > /proc/sys/vm/drop_caches pour libérer des objects slab récupérables.

Par exemple, voici la sortie de sudo apt-get update aprè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/consortingb 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/consortingb 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/consortingb 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._comstack (module.js:425:26) 

D'autres programmes échouent aussi avec des erreurs de lecture, ce n'est pas seulement apt-get et gulp / node.js.

sortie 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 avoir exécuté echo 2 > /proc/sys/vm/drop_caches les erreurs n'apparaissent plus. apt-get et d'autres programmes fonctionnent bien.

sortie 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 

Je cours Debian Sid sur un btrfs mais j'ai eu le même problème avec ext4 donc je ne pense pas que c'est un problème de système de files spécifique.

 $ uname -v #1 SMP Debian 4.2.6-1 (2015-11-10) 

J'ai également essayé de définir vfs_cache_pressure à une valeur élevée.

 vm.vfs_cache_pressure=[ 100 | 1000 | 100000 ] 

J'obtiens less d'erreurs de lecture à 100 000, mais l'utilisation du processeur grimpe et la réactivité du système devient terrible, donc je cherche une solution alternative.

Je pourrais coller echo 2 > /proc/sys/vm/drop_caches dans un travail cron, mais ce n'est pas résoudre le problème, il est juste solution de contournement.

Voici dmesg

kernel/mm/slab.c ont eu une série de correctifs récents (jan, fév 2017) portant, entre autres, sur 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 aussi une performance chère.

Cela dit, il n'est pas inhabituel de voir des numbers élevés si vous avez beaucoup d'activité d'E / S de disque. Bien que, vos counts étaient probablement sur le côté élevé, et peuvent avoir souffert de l'un des bugs adressés concernant la destruction lente.