Por que os objetos de laje não são recuperados automaticamente


17

ATUALIZAÇÃO : Não tenho mais esse problema no 4.9. * Não tenho certeza de quando foi corrigido.

Todos os dias após um backup completo do sistema, vários programas falham com erros de leitura até que eu corra echo 2 > /proc/sys/vm/drop_cachespara liberar objetos recuperáveis ​​da laje.

Por exemplo, aqui está a saída de sudo apt-get updatedepois de um backup.

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

Outro erro de amostra, desta vez com 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)

Outros programas falham com erros de leitura também, não é apenas o apt-get e o gulp / node.js.

saída slabtop:

$ 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              

saída livre:

$ 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

Após a execução, echo 2 > /proc/sys/vm/drop_cachesos erros não aparecem mais. O apt-get e outros programas funcionam bem.

saída slabtop:

$ 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

saída livre:

$ 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

Estou executando o Debian Sid em um btrfs, mas tive o mesmo problema com o ext4, então não acho que seja um problema específico do sistema de arquivos.

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

Eu também tentei definir vfs_cache_pressure para um valor alto.

vm.vfs_cache_pressure=[ 100 | 1000 | 100000 ]

Recebo menos erros de leitura em 100000, mas o uso da CPU aumenta e a capacidade de resposta do sistema se torna terrível, por isso estou procurando uma solução alternativa.

Eu poderia ficar echo 2 > /proc/sys/vm/drop_cachesem um trabalho cron, mas isso não está resolvendo o problema, é apenas uma solução alternativa.

Aqui está o dmesg


O mesmo pensa aqui. Tendo trabalhado no Solaris anteriormente, apenas considero que os caches alocados anteriormente concedidos não são retornados à memória livre para otimizar / acelerar as chamadas de alocação de memória. No entanto, embora isso faça sentido em uma máquina física, não faz mais sentido em farms de VM.
Rui F Ribeiro

5
Isso soa como um bug. Objetos de laje permanecem por um tempo - esse é o objetivo de um cache - mas se algo precisar dos recursos, eles deverão ser recuperados.
Gilles 'SO- stop be evil'

Existem mensagens de erro / bug no dmesg, arquivos de log de mensagens?
VenkatC

Sem erros incomuns antes do backup. Pastebin link para o meu dmesg adicionado.
precisa

1
Puta merda, acabei de encontrar hoje as npm run watchoperações de acompanhamento que falharam com esse erro de leitura não descritivo. Nunca teria pensado nisso sozinha. drop_cachesoperações restauradas instantaneamente, mas o que diabos está acontecendo aqui? Estou no kernel 4.4.4.
lkraav

Respostas:


2

kernel/mm/slab.cteve vários patches recentes (janeiro, fevereiro de 2017) que abordavam, entre outras coisas, a lenta destruição do cache; em certos casos, a operação de destruição do cache pode ser executada por muitas horas. A operação em si também foi um desempenho caro.

Dito isto, não é incomum ver alguns números altos se você tiver muita atividade de E / S de disco. No entanto, suas contagens provavelmente estavam no lado alto e podem ter sofrido com um dos erros corrigidos relacionados à destruição lenta.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.