LINUX.ORG.RU

Что-то странное с кэшем в Linux-дистрибутивах

 , , , ,


3

5

Я не знаю, как вы, но я давно заметил, что некоторые дистрибутивы (Ubuntu, Fedora, Linux Mint) не умеют обращаться с кэшем памяти. Я не шибко знаток этой темы, но кэш просто заполняется до отказа, пока система не фризится жёстко (только перезагрузка помогает). Есть ли хотя бы какие-то вменяемые костыли, чтобы это не происходило? Знаю про решение с освобождением кэша командой «sudo sync; echo 3 > /proc/sys/vm/drop_caches», но оно настолько костыльное, что просто ощущаешь себя реальным инвалидом.

Решение

Не рекомендую делать реиндексацию. Комп тупо не справится (у меня 8 ядер, 16 Гб ОЗУ - не потянул). Проще скачать блокчейн заново.

Ответ на: комментарий от anonymous

Спасибо тебе добрый анонимус. Похоже, это то, что я искал … сейчас попробую. Если оно рабочее, странно, что по дефолту не пихают этот пакет в релизы.

P. S. К сожалению, не помогло. Столбик free в «free -m -h» неумолимо продолжает двигаться к нулю. Перезагрузка, игра с ключами -m, -s, -M, -S ничего не дала. Пока только команда «sync; echo 3 > /proc/sys/vm/drop_caches» спасает. Наверное, придётся её в крон положить.

Desmond_Hume ★★★★★ ()
Последнее исправление: Desmond_Hume (всего исправлений: 3)
Ответ на: комментарий от Desmond_Hume

завалилась система (качаю блокчейн битка)

А сколько гигов нынче блокчейн весит?

А кошель как работает? Пока можно, грузит в RAM, а как помещаться перестает, резко и мощно сбрасывает (пытается сбрасывать и тогда всё клинит) на диск?

А у кошеля настройки есть, чтобы он или оперативку меньше жрал, или с диском лучше общался? Или внешним способом кошелю доступную память ограничить?

На форуме активно обсуждалось, как ограничить браузеры. Кошелек - не браузер. Но, похоже, проблема похожая.

Dementy ()
Ответ на: комментарий от Dementy

Размер папки битка под 290 Гб. Именно так, грузит в раму, потом сбрасывает, и так по циклу. Рецепты выше помогли на первых этапах, но потом, где-то, клин и всё. На каком-то этапе цикл не срабатывает и происходит жёсткий фриз. В самом кошельке нет ничего, что указывало бы на размер кэша. Есть размер базы данных. Попробовал увеличить. Было 450 Мб, сделал 8192 Мб.

Desmond_Hume ★★★★★ ()
Ответ на: комментарий от Desmond_Hume

У меня похожее было, и вообще, и с конкретной программой.

«Вообще» решилось так же, подковыром vm.dirty и vm.swappiness. Eще отказом от zram и zswap. Еще включением планировщика ввода/вывода, который я, начитавшись дурного, отключил.

Оставались фризы в момент начала работы виртуальной машины. Тогда я просто ограничил ей ресурсы, настройкой самого virtualbox.

Мне тогда советовали cgroups. У меня просто получилось и без этого, и я не стал. А после завершения тех своих экспериментов тупо RAM докупил.

В сабжевой ситуации, как подозреваю, сколько памяти не дай - мало будет. Я бы в такой ситуации попробовал разобраться с cgroups. Сделать группу с лимитом по памяти и сослать в нее кошель.

А может, просто «повезло» и сейчас версия кошеля баговатая...

Dementy ()
Ответ на: комментарий от anonymous

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

P.S. 94% …

Desmond_Hume ★★★★★ ()
Ответ на: комментарий от anonymous

В моих тестах больше ничто от зависонов при кончающейся памяти не помогает

Вы ничего не пробовали, если вы не пробовали nohang.

Летом был тред о неспособности ядра обрабатывать нехватку памяти: Линукс ядро не может мягко обрабатывать ситуации с нехваткой памяти

Пришло время продемонстрировать элегантное решение: https://youtu.be/G0FYDIKVPYI

Проблема: https://lkml.org/lkml/2019/8/4/15.

Решение: https://github.com/hakavlad/nohang.

Обсуждение в r/linux: https://www.reddit.com/r/linux/comments/ee6szk/killing_the_elephant_in_the_room_the_userspace/.

anonymous ()
Ответ на: комментарий от Desmond_Hume

В диагностических целях рекомендовал бы воспользоваться сценарием psi2log из пакета nohang.

Он позволяет логировать метрики PSI.

PSI - новая ядерная метрика, появилась в ядре 4.20, позволяет оценивать процент временных задержек при получении процессами ресурсов: io, memory, cpu.

Хотелось бы увидеть вышщ лог PSI перед зависанием, чтоб определить причину - проблема ли с IO или с memory.

https://github.com/hakavlad/nohang/blob/master/tools/psi2log

О пси: https://lwn.net/Articles/759658/ https://facebookmicrosites.github.io/psi/

После получения логов можем продолжить разговор.

anonymous ()
Ответ на: комментарий от ValdikSS

https://bugzilla.kernel.org/show_bug.cgi?id=196729

Удивительный человек:

vm.swappiness = 1
vm.min_free_kbytes = 32768

– сам сломал настройки памяти, а потом жалуется, что все плохо и система становится невосприимчивой.

Вместо повышения дефолтов swappiness и vm.min_free_kbytes он понизил значения до отвратительного уровня вместо повышения до приемлемого уровня, например:

vm.swappiness = 80
vm.min_free_kbytes = 300000

чем и стал сам себе ЗБ.

anonymous ()
Ответ на: комментарий от teod0r

vm.swappiness лучше в 0 выставить

Трудно придумать более идиотскую идею. Своп не запрещен, но если закончится рама, споппинг будет крайне медленным, и система потому будет сильнее тормозить, чем при дефолтном свопинес.

anonymous ()

Мужики, решение нашёл. Выручили коллеги из-за рубежа. Прошёл большую часть индексации, то есть он уже прошел гораздо дальше, чем раньше и зависать не собирается. А решение, как обычно, до безобразия простое. В этом весь линукс, который раз убеждаюсь). Напишу позже решение в теле темы, хочу убедиться, что оно окончательное и рабочее. Если вкратце, то в конфиге кошелька прописываются 2 (два!!) параметра. Один отвечает за использование количества ядер процессора кошельком, а второй -за размер кэша базы данных. Но, думаю, погоду сделал именно параметр с количеством ядер, т. к. с кэшем я уже «играл», не помогало.

Desmond_Hume ★★★★★ ()
Ответ на: комментарий от ArkaDOSik

Отчасти и линукс виноват: мог бы в принудительном порядке ограничить приложение в использовании ядер, либо предупредить пользователя о рисках. Но, по большому счёту, Bitcoin core кривовато написали. Надо было, по умолчанию, хотя бы половину ядер процессора прописывать в конфиги приложения, а не валить процессор, вытряхивая из него всё, на что он способен.

Desmond_Hume ★★★★★ ()
Ответ на: комментарий от Desmond_Hume

половину ядер процессора прописывать в конфиги приложения, а не валить процессор, вытряхивая из него всё, на что он способен.

Нормальные дистры этому не подвержены, потому что автогруп включен (но только если через терминал запускать преступника).

set

/proc/sys/kernel/sched_autogroup_enabled = 1

https://www.opennet.ru/opennews/art.shtml?num=29919

В состав ядра интегрирован патч с реализацией идеи автоматической группировки задач для повышения интерактивности на десктопе. Патч специальным образом разбивает выполняемые задачи на группы в привязке к идентификатору сессии, в дальнейшем планировщик задач оперирует данными группами как единым целым. Номер сессии изменяется при выполнении системной функции setsid(), которая, например, вызывается для каждого нового сеанса командной оболочки (тем не менее, при запуске десктоп приложений идентификатор сессии не меняется, т.е. если запустить в терминале «make -j 20», влияние на десктоп-приложения будет минимально, но если выполнять какую-то ресурсоёмкую операцию в gimp, интерактивность понизится). Посмотреть распределение сессий можно командой «ps -eo session,pid,cmd». Для активации режима автоматической группировки задач в /proc/sys/kernel/sched_autogroup_enabled необходимо записать 1;

Запускаешь клиент в терминале, и он не отнимет процессор у других процессов других автогрупп.

anonymous ()
Ответ на: комментарий от Desmond_Hume

Один отвечает за использование количества ядер процессора кошельком

Чует мое сердце, что дело тут не в процессоре, а в нагрузке на ввод-вывод. Большем ядер задействуется - больше ввод-выдод соответственно напрягается.

Аналлогичный пример с ninja.

ninja -j4 - будет нормально.

ninja -j64 - система в итоге зависнет. Но не из-за нагрузки на CPU, а из-за конкуренции за memory and IO при исчерпании памяти и активном своппинге.

Так что запуск в терминале имхо не повлияет на отзывчивость.

кСТАТИ, РЕШЕНИЕ ДЛЯ NINJA ПРЕДЛОЖЕНО https://github.com/ninja-build/ninja/issues/1706

hakavlad ()
Последнее исправление: hakavlad (всего исправлений: 2)

Опять фриз словил. Надоело. Буду качать заново блокчейн, раз такое дело с реиндексацией. А всё из-за дурацкого BitсoinABC, у которого в конфигах по умолчанию папка .bitcoin прописана, попортила мне блокчейн … вот не пойму, зачем так делать? 2 дня возился, жуть. Вы хоть не попадайтесь на такую фигню!)

Desmond_Hume ★★★★★ ()
Ответ на: комментарий от Desmond_Hume

Буду качать заново блокчейн, раз такое дело с реиндексацией.

Кстати, похожее поймал с baloo на совсем свежей системе. Прямо после первой загрузки всё обновил и sudo reboot. И Балу так жрать стал, что как он не лопнул только:) Получилось, он сразу свою базу стал делать, а этим sudo reboot я ему перебил, а он пытался починить. Удалил его файлы, дал ему спокойно поработать - и всё хорошо.

Dementy ()
Ответ на: комментарий от Dementy

Да, что-то исправлять или перепроверять - это как двойная работа, двойная нагрузка. Сейчас качаю блокчейн, ничего не фризится. Лучше уж 7-8 часов на скачку потратить, чем 2 дня пытаться переиндексировать и ничего в итоге не сделать. Похоже, эту фичу даже не надо трогать в битке. Проще скачать блоки заново.

Desmond_Hume ★★★★★ ()
Ответ на: комментарий от anonymous

Человек из того тикета вовсе не имеет swap, поэтому параметр swappiness влиять не должен.

Я пытался разобраться в причинах этого бага или хотя бы надёжно повторить его: на отдельном ноутбуке поставил 2 ГБ памяти, проводил различные тесты с разной комбинацией параметров. За 2 дня так и не добился надёжного воспроизведения.

На своём ноутбуке использую vm.swappiness=100 (у меня SSD), vm.watermark_scale_factor=200 (чтобы сразу много выгружалось/загружалось). Изменение vm.min_free_kbytes ни к чему хорошему не приводит, обычно делает только хуже.

ValdikSS ★★★★★ ()
Ответ на: комментарий от ValdikSS

Удалил нафиг папку blocks из кошелька и закачал блокчейн часов за 10. Всё работает без проблем. Просто пришел к выводу, что не линукс кривой, а писатели биткоин кошелька чего-то не учли. По крайней мере, не учли чего-то для линукс-пользователей. И конкретно не учли чего-то с реиндексацией. Поэтому, для себя выделил решение: ни в коем случае не реиндексировать ничего, ибо фича не работает в линуксе нормально, лучше заново закачать блокчейн.

Desmond_Hume ★★★★★ ()
Ответ на: комментарий от anonymous

в форматировании дискеток что-то не учли, потому подожди пока доформатируется

Так ведь как раз учли. Во время вызова функций форматирования в Windows 95 специально отключали всё, чтобы BIOS случайно не напортачил с таймингами. Как было в Linux, не видел, я под ним дискеты не форматировал уже.

i-rinat ★★★★★ ()