LINUX.ORG.RU
Форум — General  

yandex-disk лиоб приводит к OOM Killer, либо вешает Рабочую станцию без OOMK

 , ,


2

1

Приветствую коллективный разум!

Не возможно синхронизировать каталог с Яндекс Диском, т.к. systemd-oomd через пять часов убивает либо процесс yandex-disk либо консольную сессию в которой он запущен.

Это происходит на NAS под Ubuntu (16Гб ОЗУ, ZFS+RIDEZ2). Соответственно, доступ к NAS (через smb) через какое-то время (часа два) становится очень затруднителен, пока не убит yandex-disk.

  1. ================

Вот картина с памятью перед запуском:

#free -h
               total        used        free      shared  buff/cache   available
Память:       13Gi       4,9Gi       8,5Gi       2,0Mi       135Mi       8,3Gi
Подкачка:      4,0Gi       726Mi       3,3Gi
  1. ================

Вот через полчаса работы:

ps -eo rss,vsz,%mem,comm | grep ya ; free -h

1514840 2938020 10.6 yandex-disk 

               total        used        free      shared  buff/cache   available
Память:       13Gi        10Gi       2,3Gi       2,0Mi       314Mi       2,2Gi
Подкачка:      4,0Gi       726Mi       3,3Gi
  1. ================

И вот через пять часов работы:

# journalctl -f -u yandex-disk
июл 23 12:20:03 fileserver systemd[1]: Starting Yandex Disk console client...
июл 23 12:20:04 fileserver yandex-disk[2994644]: Запуск демона...Готово
июл 23 12:20:04 fileserver systemd[1]: Started Yandex Disk console client.
июл 23 17:28:41 fileserver systemd[1]: yandex-disk.service: systemd-oomd killed 3 process(es) in this unit.
июл 23 17:28:41 fileserver systemd[1]: yandex-disk.service: Main process exited, code=killed, status=9/KILL
июл 23 17:28:41 fileserver systemd[1]: yandex-disk.service: Failed with result 'signal'.
июл 23 17:28:41 fileserver systemd[1]: yandex-disk.service: Consumed 2h 53min 35.659s CPU time.

# journalctl -f -u systemd-oomd

июл 23 11:23:34 fileserver systemd-oomd[1610]: Killed /user.slice/user-1000.slice/session-2.scope due to memory used (14492499968) / total (14565728256) and swap used (3865747456) / total (4294963200) being more than 90.00%
июл 23 17:28:40 fileserver systemd-oomd[1610]: Killed /system.slice/yandex-disk.service due to memory used (14119120896) / total (14565728256) and swap used (3867000832) / total (4294963200) being more than 90.00%
  1. =======================

Так же еще использую yandex-disk на рабочей станции под Ubuntu (19 Гб ОЗУ), но т.к. там нет «systemd-oomd», то система через какое то время попросту зависает. Не совсем уверен, но возможно частично проблема на рабочей станции решилась через.

vm.swappiness=10

vm.min_free_kbytes=262144

Но возможно это совпадение. К сожалению на большее моего навыка не хватает.

Можно ли как-то решить эту проблему?



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

К сожалению, в сервисе публичной техподдержки на сайте linux.org.ru услуг по диагностике и технической поддержки яндексовой блоатвари не предусмотрено.

no-dashi-v2 ★★
()

ZFS

Честно говоря, не знаком с этой ФС, здесь подскажут, кто в теме. А так, все выглядит, как-будто копирование происходит в виртуальную папку, которая находится в RAM, тем самым ее ‘сжирая’ и следствием зависание системы.
Имхо, с ext4 не было бы таких проблем.

Могу только ссылку дать для ознакомления, ZFS использует слишком много оперативной памяти

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

Судя по всему яндекс ограничивает скорость для webdav.

Как вариант ydcmd.
Консольный клиент Linux/FreeBSD для работы с облачным хранилищем Яндекс.Диск посредством REST API

Если только яндекс не режет все сторонние приложения.

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

Сколько файлов и какой объем синхронизируется? У меня на NAS (16Гб ОЗУ) - 700000 файлов и примерно 600Гб. на рабочей станции (19 Гб ОЗУ) - 100000 файлов и примерно 400Гб Файлы в основном odt, pdf и изображения.

inspirra
() автор топика

Я бы начал диагностику с мониторинга показателей при работе ЯД:

  • mem2log - логироввать размеры кэшей, анонимки, свопа
  • psi2log - давление io и memory. Psi2log входит в состав nohang Все инструменты на главной: https://github.com/hakavlad

Стандартные меры:

  • юзерспейсный киллер, например nohang
  • swap on zram
  • ограничение макс размера ARC и vm.dirty_bytes
hakavlad ★★★
()
Ответ на: комментарий от inspirra

Отключил подкачку и оом-килер не сработал

Ядерный вообще хрен дождешься, а оомд и системд-оомд нуждаются в подкачке. earlyoom и nohang не нуждаются в подкачке. nohang позволяет проводить минимальную отладку - логировать показатели доступной памяти с заданным интервалом, например.

Спрашивай еще ответы, если хочешь.

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

Думаю 16 гигов оперативки вполне достаточно для zfs, без изысков, деупликации, сжатия или шифрования.

Для того как идет zfs из коробки в убунту, маловато памяти

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

На вскидку, не особо вникая в настройки попробовал nohang. Он на всем протяжении видел ЯД как жертву, но когда пришел писец, он так и не прибил ЯД. Машина ушла в ступор и кроме пинга ни на что не реагировала, все демоны подвисли на четыре часа, после чего ЯД сам себя убил сообщив «Ошибка: не удалось подключиться к демону». Я тогда и подумал, что nohang’у помешал своп.

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

Сейчас уже экспериментировать не могу, т.к. NAS уже в работе, разве что на выходные, но и тогда, если что, перегрузить уже будет некому.

Вышел из положение как посоветовали выше - каждые десять минут смотрю по крону:

$(cat /proc/meminfo | grep -i ‘MemAvailable’ | grep -o ‘[[:digit:]]*’) -lt 1000000 ] && /usr/bin/yandex-disk stop

а в системд поставил

RestartSec=180
Restart=always

На старте ЯД свободной где-то 4Гб. До остановки он часа полтора отрабатывает.

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

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

Попробуйте убить systemd-oomd, активировать zswap для увеличения отзывчивости, нарастить физический своп до скажем 50 гектар, причём желательно на ссд и пронаблюдайте как долго и упорно яндексовский говнокод будет растекаться.

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

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

Всё равно не кисло так. Это же не какой то там профессиональный софт, они его наверняка на коленке слепили из того что было, оптимизация это вообще не про яндекс, короче почему бы ему не держать все 80 гектар в оперативке, да ещё с метданными? Дропбокс одно время именно так и делал.

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

Или ещё, есть же механизмы лимитов в cgrops. Я на 99,99% уверен, там есть не только принудительный свопинг процесса при превышении лимита, но и вариант с его убийством.

kirill_rrr ★★★★★
()
General