Uso de cache muito alto, causando lentidão

Question

Estou tentando identificar o culpado do que está causando lentidão no meu computador pessoal. O maior suspeito é a memória. Quando o computador está rodando rápido, minha memória cache parece normal. No entanto, quando está lento, parece assim:

luke@Luke-XPS-13:~$ free -m
              total        used        free      shared  buff/cache   available
Mem:           7830        1111        1090         277        5628        1257
Swap:         16077         665       15412

e isso:

luke@Luke-XPS-13:~$ vmstat -S M
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 3  0    665   1065     67   5562    0    0    34    88   43   23 13  4 82  0  0

Os caches estão ocupando 5,5 GB da minha memória de 8 GB, quando todos os programas estão fechados e após a execução

echo "echo 3 > /proc/sys/vm/drop_caches"

que deve ser força para limpá-los. Assim que o computador começar a mergulhar na troca, o jogo acaba para uma velocidade utilizável. O desligamento corrige temporariamente o problema, mas eventualmente ele volta e não consigo descobrir o que está causando isso. Slabtop revela um pouco mais sobre o culpado, mas não tenho certeza do que isso implica. Por que kmalloc-4096 ?

 Active / Total Objects (% used)    : 1554043 / 1607539 (96.7%)
 Active / Total Slabs (% used)      : 167569 / 167569 (100.0%)
 Active / Total Caches (% used)     : 76 / 109 (69.7%)
 Active / Total Size (% used)       : 5091450.96K / 5105920.97K (99.7%)
 Minimum / Average / Maximum Object : 0.01K / 3.18K / 18.50K

  OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME                   
1254755 1254755 100%  4.00K 156847        8   5019104K kmalloc-4096
  5430   5430 100%    2.05K    362       15     11584K idr_layer_cache
 20216   9010  44%    0.57K    722       28     11552K radix_tree_node
  8820   7358  83%    1.05K    294       30      9408K ext4_inode_cache
 38577  25253  65%    0.19K   1837       21      7348K dentry
 12404  11432  92%    0.55K    443       28      7088K inode_cache
 30120  29283  97%    0.20K   1506       20      6024K vm_area_struct
 31722  31722 100%    0.12K    933       34      3732K kernfs_node_cache
 13696  12514  91%    0.25K    856       16      3424K kmalloc-256
 27144  27134  99%    0.10K    696       39      2784K buffer_head
 41088  29789  72%    0.06K    642       64      2568K kmalloc-64
   632    567  89%    3.75K     79        8      2528K task_struct
  2432   2274  93%    1.00K    152       16      2432K kmalloc-1024
  3048   2677  87%    0.64K    127       24      2032K shmem_inode_cache
   912    845  92%    2.00K     57       16      1824K kmalloc-2048
   172    162  94%    8.00K     43        4      1376K kmalloc-8192
  1736   1561  89%    0.56K     62       28       992K ecryptfs_key_record_cache
  5103   4073  79%    0.19K    243       21       972K kmalloc-192
  1792   1626  90%    0.50K    112       16       896K kmalloc-512
  1456   1456 100%    0.61K     56       26       896K proc_inode_cache
 10149   8879  87%    0.08K    199       51       796K anon_vma
 24960  19410  77%    0.03K    195      128       780K kmalloc-32
   360    352  97%    2.06K     24       15       768K sighand_cache

    

Answer 1

Com base nos seus comentários, você diz que o uso do cache não diminui significativamente quando você tenta echo 3 > /proc/sys/vm/drop_caches

Isso só pode acontecer se esse for um cache para gravação. Se você gravar 5 GB em alguns arquivos, os dados aterram imediatamente no cache e o programa continua. O cache é realmente gravado no armazenamento em segundo plano o mais rápido possível. No seu caso, o armazenamento parece dramaticamente lento e você acumula o cache não escrito até que ele drena toda a sua memória RAM e começa a empurrar tudo para fora para trocar.

O kernel nunca irá gravar o cache na partição de swap. Ele o mantém na RAM até que seja gravado com segurança no destino.

O kernel nunca soltará cache não-escrito, porque seria uma perda de dados (você salvou um arquivo, então espera que os dados caiam no armazenamento permanente).

Você só pode resolvê-lo acelerando o armazenamento. Esse problema geralmente é visto no armazenamento montado via rede (verifique seus mount para tipos cifs , nfs , sshfs , etc.) ou dispositivos USB1 lentos.

Você também pode tornar o problema muito menos dramático para o sistema, limitando o cache sujo com sysctl vm.dirty_ratio=10 antes que ele cresça demais.

% bl0ck_qu0te%

Se esse é um diagnóstico correto, você verá que o cache pode ser facilmente descartado (pelo menos 90% dele) e que o processo que grava esses gigabytes se torna muito lento. O restante do sistema se tornará mais responsivo.

    

Answer 2

A memória livre é alocada para o cache de disco. Isso é normal.

Lentidão causada pelo uso de swap também é normal. Dito isso, sua troca é aproximadamente o dobro do tamanho necessário.

Você pode tentar definir o parâmetro vm.swappiness para tentar equilibrar o uso do cache de disco de swap vs.

Imediatamente após a reinicialização, para experimentar imediatamente, em terminal type:

sudo sysctl -w vm.swappiness=10

Se isso ajudar, torne-o permanente editando:

gksudo gedit /etc/sysctl.conf

e adicionando:

# adjust swap vs ram ratio, default=60
vm.swappinesss=10

até o final do arquivo, salve e saia, reinicie.