it-swarm.com.de

Sehr hohe Cache-Auslastung führt zu Verlangsamung

Ich versuche, den Schuldigen zu identifizieren, der dazu führt, dass mein PC extrem träge ist. Der größte Verdächtige ist die Erinnerung. Wenn der Computer schnell läuft, sieht mein Cache-Speicher normal aus. Wenn es jedoch langsam läuft, sieht es so aus:

[email protected]:~$ free -m
              total        used        free      shared  buff/cache   available
Mem:           7830        1111        1090         277        5628        1257
Swap:         16077         665       15412

und das:

[email protected]:~$ 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

Caches belegen 5,5 GB meines 8-GB-Speichers, wenn alle Programme geschlossen sind und nachdem sie ausgeführt wurden

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

das sollte zwingen, sie zu löschen. Sobald der Computer in den Swap eintaucht, ist das Spiel für die nutzbare Geschwindigkeit beendet. Das Herunterfahren behebt vorübergehend das Problem, aber es kommt schließlich wieder und ich kann nicht herausfinden, was es verursacht. Slabtop verrät etwas mehr über den Täter, aber ich bin mir nicht sicher, was er impliziert. Warum 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

Basierend auf Ihren Kommentaren sagen Sie, dass die Cache-Nutzung nicht merklich abnimmt, wenn Sie versuchen, echo 3 > /proc/sys/vm/drop_caches

Dies kann nur passieren, wenn dies ein Cache zum Schreiben ist. Wenn Sie 5 GB in einige Dateien schreiben, landen die Daten sofort im Cache und Ihr Programm wird fortgesetzt. Der Cache wird tatsächlich so schnell wie möglich im Hintergrund gespeichert. In Ihrem Fall scheint der Speicher dramatisch langsam zu sein, und Sie akkumulieren den ungeschriebenen Cache, bis Ihr gesamtes RAM leer ist und Sie anfangen, alles auszutauschen.

Der Kernel schreibt niemals Cache, um die Partition auszutauschen. Es behält es in RAM, bis es sicher zum Ziel geschrieben wird.

Der Kernel löscht niemals den nicht geschriebenen Cache, da dies zu einem Datenverlust führen würde (Sie haben eine Datei gespeichert, und Sie erwarten, dass die Daten auf dem permanenten Speicher landen).

Sie können es nur lösen, indem Sie den Speicher beschleunigen. Dieses Problem tritt häufig bei Speichern auf, die über ein Netzwerk gemountet wurden (überprüfen Sie Ihre mount auf Typen cifs, nfs, sshfs usw.) oder langsamen USB1-Geräten.

Sie können das Problem für das System auch viel weniger dramatisch gestalten, indem Sie den fehlerhaften Cache mit sysctl vm.dirty_ratio=10 abdecken, bevor er zu groß wird.

dirty_ratio

Enthält als Prozentsatz des gesamten verfügbaren Speichers, der freie Seiten und wiederherstellbare Seiten enthält, die Anzahl der Seiten, bei denen ein Prozess, der Festplattenschreibvorgänge generiert, selbst mit dem Schreiben von fehlerhaften Daten beginnt.

Der insgesamt verfügbare Speicher entspricht nicht dem gesamten Systemspeicher.

Wenn dies eine korrekte Diagnose ist, werden Sie feststellen, dass der Cache leicht gelöscht werden kann (mindestens 90%) und der Prozess, der diese Gigabyte schreibt, sehr langsam wird. Der Rest des Systems wird reaktionsschneller.

4
kubanczyk

Freier Speicher wird dem Festplatten-Cache zugewiesen. Das ist normal.

Langsamkeit durch Swap-Nutzung ist ebenfalls normal. Das heißt, Ihr Swap ist etwa doppelt so groß wie nötig.

Sie können versuchen, den Parameter vm.swappiness festzulegen, um die Verwendung von Swap- und Festplatten-Cache auszugleichen.

Um es sofort nach einem Neustart zu versuchen, geben Sie terminal ein:

Sudo sysctl -w vm.swappiness=10

Wenn das hilft, machen Sie es dauerhaft durch Bearbeiten:

gksudo gedit /etc/sysctl.conf

und Hinzufügen:

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

speichern und beenden Sie die Datei und starten Sie sie neu.

1
heynnema