Очень высокое замедление порождения использования кэша
Я пытаюсь идентифицировать преступника того, что заставляет мой персональный компьютер быть чрезвычайно вялым. Крупнейший подозреваемый является памятью. Когда компьютер работает быстро, моя кэш-память выглядит нормальной. Однако, когда это отстает, это похоже на это:
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
Кэши поднимают 5.5 ГБ моих 8 ГБ памяти, когда все программы закрываются, и после выполнения
echo "echo 3 > /proc/sys/vm/drop_caches"
который должен быть силой, очищающей их. Как только запуски компьютера, опускающиеся в подкачку игра закончена для применимой скорости. Завершение работы временно решает проблему, но это в конечном счете возвращается, и я не могу выяснить то, что вызывает его. Slabtop показывает немного больше о преступнике, но я не уверен, что он подразумевает. Почему 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 ответа
На основе Ваших комментариев Вы говорите, что использование кэша заметно не отбрасывает, когда Вы пробуете к echo 3 > /proc/sys/vm/drop_caches
, Это может только произойти, если это - кэш для записи. Если Вы пишете 5 ГБ в некоторые файлы, данные сразу приземляются в кэше, и Ваша программа продолжается. Кэш на самом деле записан в устройство хранения данных в фоновом режиме максимально быстро. В Вашем случае устройство хранения данных кажется существенно медленным, и Вы накапливаете незаписанный кэш, пока это не истощает всю Вашу RAM и начинает выставлять все для свопинга.
Ядро никогда не будет писать кэш для свопинга раздела. Это сохраняет его в RAM, пока это безопасно не записано в место назначения.
Ядро никогда не будет отбрасывать незаписанный кэш, потому что это была бы потеря данных (Вы сохранили файл, таким образом, Вы ожидаете, что данные приземлятся на постоянное хранение).
можно только решить его путем ускорения устройства хранения данных. Эта проблема часто замечается на устройстве хранения данных, смонтированном через сеть (проверьте Ваш mount на типы cifs, nfs, sshfs, и т.д.), или замедлите устройства USB1.
Вы могли также сделать проблему намного менее поразительной к системе путем ограничения грязного кэша с sysctl vm.dirty_ratio=10, прежде чем это вырастет слишком много.
dirty_ratio
Содержит как процент общей доступной памяти, которая содержит свободные страницы и исправимые страницы, число страниц, на уровне которых процесс, который генерирует записи на диск, самостоятельно начнет выписывать грязные данные.
общая доступная память не равна общей системной памяти.
, Если это - корректный диагноз, Вы будете видеть, что кэш может быть легко отброшен (по крайней мере 90% из него) и что процесс, который пишет эти гигабайты, становится очень медленным. Остальная часть системы станет более быстро реагирующей.
Свободная память выделяется дисковому кэшу. Это нормально.
Замедление, вызванное использованием подкачки, также нормально. Тем не менее Ваша подкачка о дважды необходимом размере.
можно попытаться установить vm.swappiness параметр, чтобы попытаться сбалансировать использование подкачки по сравнению с дисковым кэшем.
Сразу после перезагрузки, для попытки его на лету, в terminal тип:
sudo sysctl -w vm.swappiness=10
, Если это помогает, сделайте это постоянным путем редактирования:
gksudo gedit /etc/sysctl.conf
и добавление:
# adjust swap vs ram ratio, default=60
vm.swappinesss=10
в конец файла, сохраните и выйдите, перезагрузка.