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

"yandex-disk лиоб приводит к OOM Killer, либо вешает Рабочую ста"	+/–
Сообщение от Inspirra (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. Сообщение от муу (?), 24-Июл-22, 15:29	+1 +/–
> Можно ли как-то решить эту проблему? 22.04? 1) отключи (mask) systemd-oomd, оно ниначто не годится в том виде что оно сейчас есть и/или 2) не используй продукты жизнедеятельности яндекса
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #2, #3, #11

2. Сообщение от Inspirra (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ообщить модератору
Родитель: #1

3. Сообщение от Inspirra (ok), 24-Июл-22, 16:08	+/–
> 1) отключи (mask) systemd-oomd, оно ниначто не годится в том виде что > оно сейчас есть Подумалось - если yandex-disk ограничить через Cgroup?..
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

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

5. Сообщение от Inspirra (ok), 24-Июл-22, 20:15	+/–
> Попробуй выбросить yandex-disk и цепляться с помощью mount.davfs из пакета davfs2. Пробовал. Скорость работы не превышает мегабита. Вероятно принудительное ограничение яндекса. терабайт на такой скорости закинуть невозможно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #6, #7

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

7. Сообщение от ACCA (ok), 25-Июл-22, 03:48	+/–
> терабайт на такой скорости закинуть невозможно. Ты что-то не то делаешь. Полный backup через Internet - это плохая идея.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #8, #9

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

9. Сообщение от Inspirra (ok), 25-Июл-22, 09:32	+/–
>> терабайт на такой скорости закинуть невозможно. > Ты что-то не то делаешь. Полный backup через Internet - это плохая > идея. Это не совсем бекап. Это задумано как реалтайм синхронизация с возможностью работать удаленно в облаке и одновременно своеобразный бекап. Основа безопасности в комплексе с raidZ2 на шести дисках с рекурсивными снепшотами (15 мин, дни, недели, месяцы).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #10

10. Сообщение от ACCA (ok), 25-Июл-22, 12:37	+1 +/–
На мой взгляд - типичная XY проблема. Ты пытаешься скрутить из говна и палок какое-то решение. Говно воняет, палки ломаются. А что ты ожидал, терабайт в секунду?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

11. Сообщение от Онаним (?), 25-Июл-22, 13:22	+/–
> 2) не используй продукты жизнедеятельности яндекса Удваиваю.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

12. Сообщение от 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

13. Сообщение от Inspirra (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ообщить модератору
Родитель: #12

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

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