The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]



"yandex-disk лиоб приводит к OOM Killer, либо вешает Рабочую ста"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Открытые системы на сервере (Резервное копирование / Linux)
Изначальное сообщение [ Отслеживать ]

"yandex-disk лиоб приводит к OOM Killer, либо вешает Рабочую ста"  +/
Сообщение от Inspirraemail (ok), 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

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

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

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


1. "yandex-disk лиоб приводит к OOM Killer, либо вешает Рабочую ста"  +1 +/
Сообщение от муу (?), 24-Июл-22, 15:29 
> Можно ли как-то решить эту проблему?

22.04?

1) отключи (mask) systemd-oomd, оно ниначто не годится в том виде что оно сейчас есть
и/или
2) не используй продукты жизнедеятельности яндекса

Ответить | Правка | Наверх | Cообщить модератору

2. "yandex-disk лиоб приводит к OOM Killer, либо вешает Рабочую ста"  +/
Сообщение от Inspirraemail (ok), 24-Июл-22, 16:07 
> 22.04?

Да. Особых требований не было, поэтому не заморачивался. По хорошему нужно было FreeBSD на NAS поставить, но я уже давно от этих дел отошел, уже лет пятнадцать как и лениво было вспоминать тонкости. А т.к. убунта у меня на рабочей станции, то и не стал долго мудрствовать...


> 1) отключи (mask) systemd-oomd, оно ниначто не годится в том виде что
> оно сейчас есть

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


Тут еще попробовал для эксперимента отключить своп. Без него оом-килер не отработал и система повисла на четыре часа пока yandex-disk сам не завершился из за "Ошибка: не удалось подключиться к демону". Но пока ЯД сам не повесился системе было очень плохо (даже наложились zfs-auto-snapshot, но вроде без последствий) и доступ по сети был не возможен.
Честно говоря я думал что система уже не оживет, но т.к. перезагрузить в воскресенье ночью было некому, то утром обнаружил что ЯД самоубился часа через четыре, судя по логу.


> 2) не используй продукты жизнедеятельности яндекса

Там домен привязан, почта сотрудников и оплачены услуги. До этого десять лет юзали "Google Workspace", но в связи с невозможностью (геморройностью) оплаты пришлось перетащить в яндекс.
Администрировать что-то свое у организации нет средств, да и избыточно это для конторки из четырех-пяти человек. Размазывать сервис (домен,почта,облако) по разным ресурсам тоже не лучший вариант. Как бы организую все это дело им почти по дружбе (и старой памяти) и возможности с этим потом возится и поддерживать нету.

А на своей личной рабочей станции яндекс используется потому, что самое дешевое пространство. Т.к. я уже давно живу в деревне, поменял IT на козоводство. (-: А за такую свободу и естественный быт и самореализацию приходится платить нищeбрoдствoм. (-:

Ответить | Правка | Наверх | Cообщить модератору

3. "yandex-disk лиоб приводит к OOM Killer, либо вешает Рабочую ста"  +/
Сообщение от Inspirraemail (ok), 24-Июл-22, 16:08 
> 1) отключи (mask) systemd-oomd, оно ниначто не годится в том виде что
> оно сейчас есть

Подумалось - если yandex-disk ограничить через Cgroup?..

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

11. "yandex-disk лиоб приводит к OOM Killer, либо вешает Рабочую ста"  +/
Сообщение от Онаним (?), 25-Июл-22, 13:22 
> 2) не используй продукты жизнедеятельности яндекса

Удваиваю.

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

4. "yandex-disk лиоб приводит к OOM Killer, либо вешает Рабочую ста"  +/
Сообщение от ACCA (ok), 24-Июл-22, 20:12 
Попробуй выбросить yandex-disk и цепляться с помощью mount.davfs из пакета davfs2.
Ответить | Правка | Наверх | Cообщить модератору

5. "yandex-disk лиоб приводит к OOM Killer, либо вешает Рабочую ста"  +/
Сообщение от Inspirraemail (ok), 24-Июл-22, 20:15 
> Попробуй выбросить yandex-disk и цепляться с помощью mount.davfs из пакета davfs2.

Пробовал. Скорость работы не превышает мегабита. Вероятно принудительное ограничение яндекса.

терабайт на такой скорости закинуть невозможно.

Ответить | Правка | Наверх | Cообщить модератору

6. "yandex-disk лиоб приводит к OOM Killer, либо вешает Рабочую ста"  +/
Сообщение от alexey (??), 24-Июл-22, 21:59 
Попробуй rclone
Ответить | Правка | Наверх | Cообщить модератору

7. "yandex-disk лиоб приводит к OOM Killer, либо вешает Рабочую ста"  +/
Сообщение от ACCA (ok), 25-Июл-22, 03:48 
> терабайт на такой скорости закинуть невозможно.

Ты что-то не то делаешь. Полный backup через Internet - это плохая идея.

Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

8. "yandex-disk лиоб приводит к OOM Killer, либо вешает Рабочую ста"  +/
Сообщение от ACCA (ok), 25-Июл-22, 07:39 
Как hack-around - по cron убивай процесс раз в час. Пусть эти бандерлоги сами разбираются.
Как-то так.
Ответить | Правка | Наверх | Cообщить модератору

9. "yandex-disk лиоб приводит к OOM Killer, либо вешает Рабочую ста"  +/
Сообщение от Inspirraemail (ok), 25-Июл-22, 09:32 
>> терабайт на такой скорости закинуть невозможно.
> Ты что-то не то делаешь. Полный backup через Internet - это плохая
> идея.

Это не совсем бекап. Это задумано как реалтайм синхронизация с возможностью работать удаленно в облаке и одновременно своеобразный бекап. Основа безопасности в комплексе с raidZ2 на шести дисках с рекурсивными снепшотами (15 мин, дни, недели, месяцы).

Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

10. "yandex-disk лиоб приводит к OOM Killer, либо вешает Рабочую ста"  +1 +/
Сообщение от ACCA (ok), 25-Июл-22, 12:37 
На мой взгляд - типичная XY проблема.

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

Ответить | Правка | Наверх | Cообщить модератору

12. "yandex-disk лиоб приводит к OOM Killer, либо вешает Рабочую ста"  +/
Сообщение от Alladin (?), 05-Авг-22, 00:20 
>[оверквотинг удален]
> (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.

Ответить | Правка | Наверх | Cообщить модератору

13. "yandex-disk лиоб приводит к OOM Killer, либо вешает Рабочую ста"  +/
Сообщение от Inspirraemail (ok), 05-Авг-22, 00:33 
> Сам пользовался диском, то что вы говорите это не проблема.. вообще не
> проблема. Он у меня иногда требует 38Gb Озу, может и 64Gb
> во время синхронизации.
> Ответ решения простой.. или прокачиваеие озу до требуемого обьема)) или ТУПО увеличивай
> SWAP.

Свап не помогает. В свап вытесняется все кроме ЯД и система встает колом.
Сколько нужно ОЗУ для 700 тыс. файлов? Учитывая что у меня память с ecc (для zfs) то это слишком дорогое удовольствие, для NAS сервера обслуживающего всего две рабочие станции. Тогда уж проще купить облачное хранилище с возможностью смонтировать монтировать, лет на пять-десять вперед.

На самом деле решение еще проще. В крон пишем вот это:
[ $(cat /proc/meminfo | grep -i 'MemAvailable' | grep -o '[[:digit:]]*') -lt 1000000 ] && /usr/bin/yandex-disk stop

с исполнением каждые минут пять-десять.
А загрузку ЯД пихаем в системд с ключом релоад. Перезагрузка ни как не влияет на синхронизацию. А уже после полного переноса данных, процесс синхронизации уже вполне работоспособен и не занимает много памяти.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Спонсоры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2022 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру