 yandex-disk лиоб приводит к OOM Killer, либо вешает Рабочую ста,  Inspirra, 23-Июл-22, 21:15 [смотреть все]Приветствую коллективный разум!Не возможно синхронизировать каталог с Яндекс Диском, т.к. 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 2. ================
Вот через полчаса работы: 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 3. ================
И вот через пять часов работы: # 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%
4. =======================
Так же еще использую yandex-disk на рабочей станции под Ubuntu (19 Гб ОЗУ), но т.к. там нет «systemd-oomd», то система через какое то время попросту зависает. Не совсем уверен, но возможно частично проблема на рабочей станции решилась через.
vm.swappiness=10
vm.min_free_kbytes=262144 Но возможно это совпадение. К сожалению на большее моего навыка не хватает. Можно ли как-то решить эту проблему?
|
- yandex-disk лиоб приводит к OOM Killer, либо вешает Рабочую ста, муу, 15:29 , 24-Июл-22 (1) +1
> Можно ли как-то решить эту проблему?22.04? 1) отключи (mask) systemd-oomd, оно ниначто не годится в том виде что оно сейчас есть
и/или
2) не используй продукты жизнедеятельности яндекса
- yandex-disk лиоб приводит к OOM Killer, либо вешает Рабочую ста, Inspirra, 16:07 , 24-Июл-22 (2)
> 22.04?Да. Особых требований не было, поэтому не заморачивался. По хорошему нужно было FreeBSD на NAS поставить, но я уже давно от этих дел отошел, уже лет пятнадцать как и лениво было вспоминать тонкости. А т.к. убунта у меня на рабочей станции, то и не стал долго мудрствовать...
> 1) отключи (mask) systemd-oomd, оно ниначто не годится в том виде что
> оно сейчас есть
Ну, оно все же убивает yandex-disk до того как он успеет ввести систему в жесткий ступор. Без него система просто зависает так, что кроме как на пинги больше ни на что не реагирует. Другого решения хотя бы не потерять доступ к NAS находящемуся за пару тысяч км я пока не знаю. На рабочей станции без оом-килера - машина и локально перестает отвечать.
Тут еще попробовал для эксперимента отключить своп. Без него оом-килер не отработал и система повисла на четыре часа пока yandex-disk сам не завершился из за "Ошибка: не удалось подключиться к демону". Но пока ЯД сам не повесился системе было очень плохо (даже наложились zfs-auto-snapshot, но вроде без последствий) и доступ по сети был не возможен.
Честно говоря я думал что система уже не оживет, но т.к. перезагрузить в воскресенье ночью было некому, то утром обнаружил что ЯД самоубился часа через четыре, судя по логу.
> 2) не используй продукты жизнедеятельности яндекса
Там домен привязан, почта сотрудников и оплачены услуги. До этого десять лет юзали "Google Workspace", но в связи с невозможностью (геморройностью) оплаты пришлось перетащить в яндекс.
Администрировать что-то свое у организации нет средств, да и избыточно это для конторки из четырех-пяти человек. Размазывать сервис (домен,почта,облако) по разным ресурсам тоже не лучший вариант. Как бы организую все это дело им почти по дружбе (и старой памяти) и возможности с этим потом возится и поддерживать нету. А на своей личной рабочей станции яндекс используется потому, что самое дешевое пространство. Т.к. я уже давно живу в деревне, поменял IT на козоводство. (-: А за такую свободу и естественный быт и самореализацию приходится платить нищeбрoдствoм. (-:
- yandex-disk лиоб приводит к OOM Killer, либо вешает Рабочую ста, Inspirra, 16:08 , 24-Июл-22 (3)
> 1) отключи (mask) systemd-oomd, оно ниначто не годится в том виде что
> оно сейчас есть Подумалось - если yandex-disk ограничить через Cgroup?..
- yandex-disk лиоб приводит к OOM Killer, либо вешает Рабочую ста, Онаним, 13:22 , 25-Июл-22 (11)
> 2) не используй продукты жизнедеятельности яндекса Удваиваю.
- yandex-disk лиоб приводит к OOM Killer, либо вешает Рабочую ста, ACCA, 20:12 , 24-Июл-22 (4)
Попробуй выбросить yandex-disk и цепляться с помощью mount.davfs из пакета davfs2.
- yandex-disk лиоб приводит к OOM Killer, либо вешает Рабочую ста, Inspirra, 20:15 , 24-Июл-22 (5)
> Попробуй выбросить yandex-disk и цепляться с помощью mount.davfs из пакета davfs2.Пробовал. Скорость работы не превышает мегабита. Вероятно принудительное ограничение яндекса. терабайт на такой скорости закинуть невозможно.
- yandex-disk лиоб приводит к OOM Killer, либо вешает Рабочую ста, alexey, 21:59 , 24-Июл-22 (6)
- yandex-disk лиоб приводит к OOM Killer, либо вешает Рабочую ста, ACCA, 03:48 , 25-Июл-22 (7)
> терабайт на такой скорости закинуть невозможно.Ты что-то не то делаешь. Полный backup через Internet - это плохая идея.
- yandex-disk лиоб приводит к OOM Killer, либо вешает Рабочую ста, ACCA, 07:39 , 25-Июл-22 (8)
Как hack-around - по cron убивай процесс раз в час. Пусть эти бандерлоги сами разбираются.
Как-то так.
- yandex-disk лиоб приводит к OOM Killer, либо вешает Рабочую ста, Inspirra, 09:32 , 25-Июл-22 (9)
>> терабайт на такой скорости закинуть невозможно.
> Ты что-то не то делаешь. Полный backup через Internet - это плохая
> идея.Это не совсем бекап. Это задумано как реалтайм синхронизация с возможностью работать удаленно в облаке и одновременно своеобразный бекап. Основа безопасности в комплексе с raidZ2 на шести дисках с рекурсивными снепшотами (15 мин, дни, недели, месяцы).
- yandex-disk лиоб приводит к OOM Killer, либо вешает Рабочую ста, Alladin, 00:20 , 05-Авг-22 (12)
>[оверквотинг удален]
> (3867000832) / total (4294963200) being more than 90.00%
> 4. =======================
> Так же еще использую yandex-disk на рабочей станции под Ubuntu (19 Гб
> ОЗУ), но т.к. там нет «systemd-oomd», то система через какое то
> время попросту зависает. Не совсем уверен, но возможно частично проблема на
> рабочей станции решилась через.
> vm.swappiness=10
> vm.min_free_kbytes=262144
> Но возможно это совпадение. К сожалению на большее моего навыка не хватает.
> Можно ли как-то решить эту проблему?Сам пользовался диском, то что вы говорите это не проблема.. вообще не проблема. Он у меня иногда требует 38Gb Озу, может и 64Gb во время синхронизации.
Ответ решения простой.. или прокачиваеие озу до требуемого обьема)) или ТУПО увеличивай SWAP.
- yandex-disk лиоб приводит к OOM Killer, либо вешает Рабочую ста, Inspirra, 00:33 , 05-Авг-22 (13)
> Сам пользовался диском, то что вы говорите это не проблема.. вообще не
> проблема. Он у меня иногда требует 38Gb Озу, может и 64Gb
> во время синхронизации.
> Ответ решения простой.. или прокачиваеие озу до требуемого обьема)) или ТУПО увеличивай
> SWAP.Свап не помогает. В свап вытесняется все кроме ЯД и система встает колом.
Сколько нужно ОЗУ для 700 тыс. файлов? Учитывая что у меня память с ecc (для zfs) то это слишком дорогое удовольствие, для NAS сервера обслуживающего всего две рабочие станции. Тогда уж проще купить облачное хранилище с возможностью смонтировать монтировать, лет на пять-десять вперед. На самом деле решение еще проще. В крон пишем вот это:
[ $(cat /proc/meminfo | grep -i 'MemAvailable' | grep -o '[[:digit:]]*') -lt 1000000 ] && /usr/bin/yandex-disk stop с исполнением каждые минут пять-десять.
А загрузку ЯД пихаем в системд с ключом релоад. Перезагрузка ни как не влияет на синхронизацию. А уже после полного переноса данных, процесс синхронизации уже вполне работоспособен и не занимает много памяти.
|
Версия для распечатки
