Чому об’єкти плит не відновлюються автоматично

17

ОНОВЛЕННЯ : У мене більше немає проблеми з 4.9. * Не знаю, коли вона була виправлена.

Щодня після повного резервного копіювання системи різні програми виходять з ладу з помилками читання, поки я echo 2 > /proc/sys/vm/drop_cachesне переходжу до вільних відновлюваних плитних об'єктів.

Наприклад, ось результат sudo apt-get updateпісля резервного копіювання.

$ 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)

Ще одна помилка вибірки, на цей раз із 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)

Інші програми виходять з ладу і з помилками читання, це не лише apt-get і gulp / node.js.

вихід на плиті:

$ 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

вільний вихід:

$ 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

Після запуску echo 2 > /proc/sys/vm/drop_cachesпомилки більше не з’являються. apt-get та інші програми працюють нормально.

вихід на плиті:

$ 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

вільний вихід:

$ 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

Я запускаю Debian Sid на btrfs, але у мене була та сама проблема з ext4, тому я не думаю, що це проблема з файловою системою.

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

Я також намагався встановити vfs_cache_pressure на високе значення.

vm.vfs_cache_pressure=[ 100 | 1000 | 100000 ]

Я отримую менше помилок читання при 100000, але використання процесора зростає, а чутливість системи стає жахливою, тому я шукаю альтернативне рішення.

Я міг би приєднатись echo 2 > /proc/sys/vm/drop_cachesдо роботи з хроном, але це не вирішує проблему, це просто вирішення.

Ось dmesg

linux-kernel  memory  cache 
— Річард Айотт
джерело
Те саме думаю тут. Раніше працював у Solaris, я просто приймаю як належне раніше виділені кеші не повертаються у вільну пам'ять для оптимізації / прискорення викликів при розподілі пам'яті. Однак, хоча це має сенс у фізичній машині, це вже не має сенсу на фермах ВМ.
— Rui F Ribeiro
5
Це звучить як помилка. Об'єкти сляби залишаються на деякий час - це сенс кешу, але якщо для чогось потрібні ресурси, то їх слід відновити.
— Жил 'SO- перестань бути злим'
Чи є повідомлення про помилки / помилки в dmesg, файлах журналу повідомлень?
— VenkatC
Ніяких незвичайних помилок перед резервною копією. Додано посилання Pastebin до мого dmesg.
— Річард Айотт
1
Святі чмоки, я щойно зіткнувся з тим, що npm run watchнаступні операції не вдалися з цією неописаною помилкою читання. Ніколи б не думав про це самостійно. drop_cachesвідновлені операції миттєво, але що, до біса, відбувається тут? Я на ядрі 4.4.4.
— lkraav

Відповіді:

2

kernel/mm/slab.cпровели купу останніх патчів (січень, лютий 2017), які стосуються, серед іншого, повільного знищення кешу; у певних випадках операція знищення кешу може тривати протягом багатьох годин. Сама операція теж була дорогою.

Це говорить про те, що не дуже часто бачити високі показники, якщо у вас є велика активність вводу / виводу диска. Хоча, ваші рахунки були, ймовірно, на високій стороні, і, можливо, постраждали від однієї з адресних помилок щодо повільного знищення.

— Ерік Б
джерело
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.