web-dev-qa-db-ja.com

キャッシュの使用量が非常に多いために速度が低下する

私のパソコンが極端に遅くなる原因を特定しようとしています。最大の容疑者は記憶です。コンピューターが高速で実行されている場合、キャッシュメモリは正常に見えます。ただし、実行速度が遅い場合は次のようになります。

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

この:

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

すべてのプログラムが閉じられ、実行後に、キャッシュが8GBのメモリの5.5GBを占有している

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

それらを強制的にクリアする必要があります。コンピュータがスワップに浸り始めるとすぐに、使用可能な速度でゲームオーバーします。シャットダウンは一時的に問題を修正しますが、最終的には戻ってきて、何が原因なのかわかりません。スラブトップは犯人についてもう少し明らかにしますが、それが何を意味するのか分かりません。なぜ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
2
Luke Shirley

あなたのコメントに基づいて、echo 3 > /proc/sys/vm/drop_cachesをしようとしてもキャッシュの使用量が著しく低下しないと言います。

これは、これが書き込み用のキャッシュである場合にのみ発生します。一部のファイルに5 GBを書き込むと、データはすぐにキャッシュに格納され、プログラムが続行されます。キャッシュは、可能な限り高速でバックグラウンドでストレージに実際に書き込まれます。あなたの場合、ストレージは劇的に遅いようで、すべてのRAMを使い果たしてすべてをプッシュしてスワップを開始するまで、書き込まれていないキャッシュを蓄積します。

カーネルはキャッシュをスワップパーティションに書き込みません。宛先に安全に書き込まれるまで、RAMに保持します。

カーネルは、データの損失(ファイルを保存しているため、データが永続ストレージに格納されることを期待します)になるため、未書き込みのキャッシュをドロップしません。

ストレージを高速化することによってのみ解決できます。この問題は、ネットワーク経由でマウントされたストレージ(mountの種類cifsnfssshfsなどを確認)または遅いUSB1デバイスでよく見られます。

また、ダーティキャッシュが大きくなりすぎる前に、sysctl vm.dirty_ratio=10でダーティキャッシュを制限することにより、システムに対する問題の劇的性を大幅に抑えることができます。

dirty_ratio

空きページと再生可能ページを含む使用可能なメモリの合計の割合として、ディスク書き込みを生成しているプロセスがダーティデータの書き込みを開始するページ数が含まれます。

使用可能なメモリの合計は、システムメモリの合計と等しくありません。

それが正しい診断である場合、キャッシュは簡単に(少なくとも90%)ドロップされ、これらのギガバイトを書き込むプロセスは非常に遅くなることがわかります。システムの残りの部分の応答性が向上します。

4
kubanczyk

空きメモリがディスクキャッシュに割り当てられます。それは正常です。

スワップの使用によるスローダウンも正常です。ただし、スワップは必要なサイズの約2倍です。

vm.swappinessパラメータを設定して、スワップの使用とディスクキャッシュの使用のバランスをとることができます。

リブート直後に、terminalタイプでオンザフライで試してください:

Sudo sysctl -w vm.swappiness=10

それが役立つ場合は、編集して永続化します:

gksudo gedit /etc/sysctl.conf

追加:

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

ファイルの最後まで保存して終了し、再起動します。

1
heynnema