Забивается кэш, как с этим бороться?

Ты сам запилил кэш в оперативку, ибо по дефолту(емнип) такого нигде нет. Что за система? Своп включен?

ох уж эти мамкины оптимизаторы. сначала кэш браузера в рам цепляют, а потом удивляются, что рама заканчивается и всё дичайше свопится.

то ОЗУ забивается кэшем загруженных файлов

лол. Ты сначала определись или внеси в студию информацию о том, какой именно кеш имеется ввиду.

Дисковый кеш ОС? Кеш браузера? Если браузера, то ты ССЗБ, и ораторы выше всё правильно сказали.

Ораторы выше очень ошибаются. Пихать кэш браузера в tmpfs - имхо - верх идиотизма. И, я думаю, несложно догадаться, что подразумевается дисковый кэш ос, т.к. sudo sync; echo 3 | sudo tee /proc/sys/vm/drop_caches на кэш браузера в tmpfs ну вот совсем никак не влияет. Есть какие-нибудь еще предположения? Мб это одно из проявлений 12309?

По поводу кэша - сообщение чуть выше. Конкретно сейчас archlinux, но эта проблема проявляет себя и на других дистрибутивах. Включение/отключение swap раздела/файла/zram никаким образом не помогает. Ещё немного понаблюдав, я заметил, что проблема проявляется наиболее ярко, когда загружается множество файлов по несколько мегабайт, например mp3 при прослушивании плейлиста ВК, или фрагменты HLS потока (привет moonwalk). По идее кэш браузера храниться в множестве файлов в специальном формате в определённой директории. И эти файлы ещё и кэшируются ядром в ram, при обращении к ним (дисковый кэш). По идее после истечения определённого таймаута дисковый кэш должен сбрасываться на диск. Вероятно, этого почему-то не происходит (потому-то мне и помогает ручной сброс кэша на диск), но ведь другие программы работают нормально: если тот-же HLS смотреть в mpv - система не будет люто зависать даже через 10 часов просмотра.

Мда уж... Все дружненько поумничали, перефразировав друг друга, в попытках повысить своё ЧСВ по отношению к топик-стартеру (мне), но никто ничего толкового так и сказать не смог. Эх, ЛОР такой ЛОР... Смешно, стыдно и обидно, что такой важный и популярный ресурс, а подобных пользователей - большинство.

Пихать кэш браузера в tmpfs - имхо - верх идиотизма.

А мне нравится. Майор опять же в кэше копаться не будет. И загрузки в tmpfs, чтобы мусор не скапливался.

Загрузки в tmpfs? Похоже на троллинг :D

>2017
>троллинг

Пихать кэш браузера в tmpfs - имхо - верх идиотизма

Нщеброды с 2мя гигами озу забавны своими мантрами

Ты понтоваться пришел? Разумного что-то можешь сказать?

интересная проблема.

как воркэраунд - создай скрипт и кинь на крон, пусть запускает раз в час.

вообще говоря странное поведение, кажется что у тебя какие-то параметры наоптимизированы, но я не разбираюсь в этом вопросе. это надо попробовать спросить в админе конкретно про параметры кэша фс и/или пробовать писать в какие то живые чисто технические рассылки (может быть твоего дистрибутива).

Ограничить кэш браузера пробовал?

А смысл?) Даже если постоянно очищать кэш браузера или ограничивать его - проблема не исчезает. В той же windows подобной проблемы не наблюдаю, хотя кэш браузера не чистил уж пол года (только на windows).

Проблема до сих пор не решена.

В той же windows подобной проблемы не наблюдаю

В Linux тоже не наблюдаю.

Дай чуток подробностей как именно ты настраиваешь свою систему.. (Что накрутил в sysctl? Что накрутил с zramговномвсяким? Странные файловые системы типа zfs? Свои сборки ядра со своими конфигами?)

Если это не от ОТключеного свопа, тогда это классические тормоза от background writeback. Пробуй echo 2097152 >/proc/sys/vm/dirty_bytes (работает пока не перезагрузишься).

Проблема до сих пор не решена.

На ядре 4.10 — проявляется?

Там они сделали тротлинг фоновой записи

Ничего из перечисленного не влияет. Проблема проявляется даже на абсолютно дефолтной сыежеустановленной системе.

Крутить этот параметр и связанные с ним уже пробовал. К сожалению, кэш все-равно забивается.

Проблема проявляется даже на абсолютно дефолтной

Значит проблема в чрезвычайно медленном устройстве /dev/sda (в сочитании с плохим алгоритмом фоновой записи в Linux).

Если в 4.10 это полечится — значит 100% тому подтверждение :-)

Ещё не прилетело в репы. Но там ведь изменения, касающиеся работы со съемными носителями, разве нет?

Крутить этот параметр и связанные с ним уже пробовал. К сожалению, кэш все-равно забивается.

Разумеется забивается. Для этого кэш и нужен. :-) ..

Только это не может быть проблемой.

То что он забивается — это хорошо.

А то что у тебя что-то там с тормозами — вот это плохо

Ещё не прилетело в репы

Ды вот же --

https://www.archlinux.org/packages/testing/x86_64/linux/

Но там ведь изменения, касающиеся работы со съемными носителями, разве нет?

Если твой /dev/sda работает так же медленно как съёмные носители :-) , то думаю это тебя тож коснётся

А разные tmpfs в df -h озу как раз не занимают? И ещё ipcs -m

И ещё slabtop

Ды вот же --

Ну нее, это ж тестовая репа :D

Если твой /dev/sda работает так же медленно как съёмные носители

От 40 до 170 Мб/с (btrfs с включенным CoW и LZO). И, дабы сразу убрать btrfs из подозрений, проблема и на ext4 тоже воспроизводится.

df -h:

Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        975M     0  975M   0% /dev
tmpfs           983M  5.7M  978M   1% /dev/shm
tmpfs           983M   16M  968M   2% /run
tmpfs           983M     0  983M   0% /sys/fs/cgroup
/dev/sda1        30G   11G   17G  39% /
tmpfs           983M  8.0K  983M   1% /tmp
tmpfs           197M   12K  197M   1% /run/user/1000

ipcs -m:

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status      
0x00000000 425984     hsnbrg     600        4194304    2          dest         
0x00000000 327681     hsnbrg     600        524288     2          dest         

sudo slabtop --once:

 Active / Total Objects (% used)    : 298063 / 302599 (98.5%)
 Active / Total Slabs (% used)      : 11719 / 11719 (100.0%)
 Active / Total Caches (% used)     : 75 / 97 (77.3%)
 Active / Total Size (% used)       : 75863.89K / 77789.97K (97.5%)
 Minimum / Average / Maximum Object : 0.01K / 0.26K / 8.00K

  OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME                   
 51366  49875   0%    0.19K   2446       21      9784K dentry                 
 43350  42884   0%    0.12K   1275       34      5100K kernfs_node_cache      
 24384  24384 100%    0.06K    381       64      1524K anon_vma_chain         
 24339  24085   0%    0.19K   1159       21      4636K cred_jar               
 16576  16376   0%    0.06K    259       64      1036K kmalloc-64             
 15165  15001   0%    1.06K   1011       15     16176K btrfs_inode            
 13923  13787   0%    0.58K   1071       13      8568K inode_cache            
 13300  13300 100%    0.14K    475       28      1900K btrfs_extent_map       
 11781  11613   0%    0.08K    231       51       924K anon_vma               
 10368  10368 100%    0.03K     81      128       324K kmalloc-32             
  8134   7905   0%    0.57K    581       14      4648K radix_tree_node        
  7088   6976   0%    0.25K    443       16      1772K kmalloc-256            
  6144   6144 100%    0.01K     12      512        48K kmalloc-8              
  6144   6144 100%    0.02K     24      256        96K kmalloc-16             
  5406   5198   0%    0.08K    106       51       424K Acpi-State             
  3864   3864 100%    0.07K     69       56       276K Acpi-Operand           
  3528   3303   0%    0.63K    294       12      2352K proc_inode_cache       
  3485   3485 100%    0.05K     41       85       164K ftrace_event_field     
  3332   3275   0%    0.27K    238       14       952K btrfs_extent_buffer    
  2814   2814 100%    0.09K     67       42       268K kmalloc-96             
  2714   2541   0%    0.68K    118       23      1888K shmem_inode_cache      
  2604   2348   0%    0.19K    124       21       496K kmalloc-192            
  2096   2040   0%    0.50K    131       16      1048K kmalloc-512            
  2048   2048 100%    0.12K     64       32       256K kmalloc-128            
  1968   1968 100%    1.00K    123       16      1968K kmalloc-1024           
  1564   1564 100%    0.09K     34       46       136K trace_event_file       
  1428   1428 100%    0.04K     14      102        56K Acpi-Namespace         
  1152   1100   0%    0.62K     96       12       768K task_group             
  1088   1088 100%    0.12K     34       32       136K pid                    
  1001   1001 100%    0.30K     77       13       308K btrfs_delayed_node     
   912    912 100%    0.62K     76       12       608K sock_inode_cache       
   880    854   0%    2.00K     55       16      1760K kmalloc-2048           
   832    832 100%    0.06K     13       64        52K kmem_cache_node        
   744    744 100%    0.31K     62       12       248K kmem_cache             
   666    573   0%    3.31K     74        9      2368K task_struct            
   646    646 100%    0.20K     34       19       136K file_lock_cache        
   585    585 100%    0.10K     15       39        60K blkdev_ioc             
   480    399   0%    2.06K     32       15      1024K sighand_cache          
   465    405   0%    1.06K     31       15       496K signal_cache           
   420    420 100%    0.38K     20       21       160K mnt_cache              
   405    405 100%    2.05K     27       15       864K idr_layer_cache        

Но это после запуска системы минут 10 от силы прошло.

cool story, bro. Лор ни разу не важный и уж точно не популярный ресурс.

Ну нее, это ж тестовая репа :D

И в чём же тут возникла проблема?

> Если твой /dev/sda работает так же медленно как съёмные носители

От 40 до 170 Мб/с (btrfs с включенным CoW и LZO)

40~170 MB/s это конечно похвально — но тормознутость я имел ввиду не мегобайтно-секундно-линуйную, а создающую блокировки ввода-вывода в момент операции большой записи..

USB-флешки в момент записи — тоже это делают.. И твой /dev/sda похоже тоже :-)

И это очень странно. Буквально в мае прошлого года такого не вообще было...

Еще вариант - фрагментация памяти.
"Проблема 1"

Точно! Добавил в sysctl vm.min_free_kbytes=65536. Погоняю пару дней, возможно именно это поможет.

Уже в core, обновляюсь. Опять же, тут надо будет пару дней погонять. Потом отпишу.

В общем, нашёл в чём причина. Сегодня в очередной раз произошло жёсткое зависание. Только не после нескольких часов работы, а практически сразу, что довольно странно, ведь под подозрением была virtual_memory. В этом-то я и заподозрил неладное :) Решил всё-таки внимательно перечитать все логи, авось чего полезного найду. И нашёл строчку, на которую изначально не было подозрений:

Mar 14 21:27:33 chromium.desktop[4537]: [30:76:0314/212733.110185:ERROR:render_media_log.cc(30)] MediaEvent: MEDIA_ERROR_LOG_ENTRY {"error":"FFmpegDemuxer: data source error"}

Что ж, всем спасибо. Думаю теперь можно отметить тему как решённую.

В chromium 58 данный баг исправлен.