werwolfby/monitorrent

Fork 0

mirror of https://github.com/werwolfby/monitorrent.git synced 2026-10-14 21:39:03 +00:00

[GH-ISSUE #413] Странная статистика по потреблению ресурсов контейнером с monitorrent #327

New issue

Open

opened 2026-10-13 19:55:44 +00:00 by bsakaguchi · 5 comments

bsakaguchi commented

2026-10-13 19:55:44 +00:00

Owner

Originally created by @zalessky on GitHub (Aug 29, 2025).
Original GitHub issue: https://github.com/werwolfby/monitorrent/issues/413

Веб-морда unraid и Portainer считают, что monitorrent потребляет более 3Gb оперативы, что, как по мне, овер черезчур. При этом сам docker stats в консоли показывает крайне скромные 25Mb. Кому верить?
P.S. Есть предположение, что виной тому мои изменения в lostfilm.py, написанные в соавторстве с целым букетом ИИ. И Хост залипает у меня, возможно, из-за утечки памяти в этом скрипте. Но это лишь предположения...

Originally created by @zalessky on GitHub (Aug 29, 2025). Original GitHub issue: https://github.com/werwolfby/monitorrent/issues/413 Веб-морда unraid и Portainer считают, что monitorrent потребляет более 3Gb оперативы, что, как по мне, овер черезчур. При этом сам docker stats в консоли показывает крайне скромные 25Mb. Кому верить? P.S. Есть предположение, что виной тому мои изменения в lostfilm.py, написанные в соавторстве с целым букетом ИИ. И Хост залипает у меня, возможно, из-за утечки памяти в этом скрипте. Но это лишь предположения... <img width="1790" height="384" alt="Image" src="https://github.com/user-attachments/assets/c4c29e24-35f2-4f4f-b175-5986c2f320ce" /> <img width="1428" height="795" alt="Image" src="https://github.com/user-attachments/assets/705e5f4d-13f4-454e-87c1-f9bf4b939bda" /> <img width="1099" height="221" alt="Image" src="https://github.com/user-attachments/assets/d90c7735-05e7-49b7-b700-f8b59102f372" />

bsakaguchi commented

2026-10-13 19:55:46 +00:00

Author

Owner

@werwolfby commented on GitHub (Aug 30, 2025):

Это очень хороший вопрос, но есть одно но!

Там зашит chromium внутри чтобы иногда капчу обходить. Он не всегда запущен, потому большую часть времени monitorrent действительно должен жарть в районе 100Мб. Но иногда может стартануть хром попытаться решить капчу, всё такое... и уже после его закрыть. А кром никогда не скромничал, и мог жрать сколько угодно. Так что виртуального рама там действительн может быть выделено гигабайты, но по факту будет не много.

У меня он запускается в кубике с лимитами:

resources:
  requests:
    cpu: 20m
    memory: 128Mi
  limits:
    cpu: 2000m
    memory: 1024Mi

Так что по умолчанию я ему даю 128Мб, но разрешаю съесть до 1Гб. Проблем ещё замечено не было.

Жрет сейчас 325Мб, что больше чем хотелось бы, но приемлемо, питону сложно сказать не жрать, хотя он и не сильно прожорливый.

@werwolfby commented on GitHub (Aug 30, 2025): Это очень хороший вопрос, но есть одно но! Там зашит chromium внутри чтобы иногда капчу обходить. Он не всегда запущен, потому большую часть времени monitorrent действительно должен жарть в районе 100Мб. Но иногда может стартануть хром попытаться решить капчу, всё такое... и уже после его закрыть. А кром никогда не скромничал, и мог жрать сколько угодно. Так что виртуального рама там действительн может быть выделено гигабайты, но по факту будет не много. У меня он запускается в кубике с лимитами: ```yaml resources: requests: cpu: 20m memory: 128Mi limits: cpu: 2000m memory: 1024Mi ``` Так что по умолчанию я ему даю 128Мб, но разрешаю съесть до 1Гб. Проблем ещё замечено не было. Жрет сейчас 325Мб, что больше чем хотелось бы, но приемлемо, питону сложно сказать не жрать, хотя он и не сильно прожорливый. <img width="1771" height="210" alt="Image" src="https://github.com/user-attachments/assets/23d30654-501e-43bf-8028-4411fdbc1f51" />

bsakaguchi commented

2026-10-13 19:55:46 +00:00

Author

Owner

@zalessky commented on GitHub (Aug 30, 2025):

Не. в моем случае все же утечка, пожалуй. Я сейчас еще щедрее на ресурсы:

deploy: resources: limits: memory: 2048m reservations: memory: 512m
Вчера до введения лимитов он сожрал 6 из 8 Гб памяти на сервере и положил его.
После введения - обожрался до лимита и умер сам.

Так что вайбкодинг с ИИ пока еще не торт. Где-то утечка в новом коде. Поэтому жду обнову от автора

@zalessky commented on GitHub (Aug 30, 2025): Не. в моем случае все же утечка, пожалуй. Я сейчас еще щедрее на ресурсы: ` deploy: resources: limits: memory: 2048m reservations: memory: 512m ` Вчера до введения лимитов он сожрал 6 из 8 Гб памяти на сервере и положил его. После введения - обожрался до лимита и умер сам. Так что вайбкодинг с ИИ пока еще не торт. Где-то утечка в новом коде. Поэтому жду обнову от автора

bsakaguchi commented

2026-10-13 19:55:46 +00:00

Author

Owner

@zalessky commented on GitHub (Sep 6, 2025):

lostfilm.py

gemini полностью переписал класс LostFilmTVTracker для устранения утечек. Больше не вызывает get_download_info бесконечно в цикле
В init: Создается self.scraper, который является экземпляром cloudscraper (по сути, улучшенная сессия requests, которая уже использовалась в коде миграции).
Во всех методах (login, verify, parse_url, get_download_info): Вместо requests.post(...) или requests.get(...) теперь используется self.scraper.post(...) и self.scraper.get(...).
Из get_download_info: Строка session = requests.session() полностью удалена.

Что бы это ни значило... :-)

Остальные изменения, внесенные ранее для парсинга новых сериалов остались и работают. Потребление памяти снизилось

@zalessky commented on GitHub (Sep 6, 2025): [lostfilm.py](https://github.com/user-attachments/files/22063459/lostfilm.py) gemini полностью переписал класс `LostFilmTVTracker` для устранения утечек. Больше не вызывает get_download_info бесконечно в цикле В __init__: Создается self.scraper, который является экземпляром cloudscraper (по сути, улучшенная сессия requests, которая уже использовалась в коде миграции). Во всех методах (login, verify, parse_url, get_download_info): Вместо requests.post(...) или requests.get(...) теперь используется self.scraper.post(...) и self.scraper.get(...). Из get_download_info: Строка session = requests.session() полностью удалена. Что бы это ни значило... :-) Остальные изменения, внесенные ранее для парсинга новых сериалов остались и работают. Потребление памяти снизилось

bsakaguchi commented

2026-10-13 19:55:47 +00:00

Author

Owner

@zalessky commented on GitHub (Sep 6, 2025):

Полностью переписал логику плагина. (gemini взял на себя всю работу, я только пинал.) Теперь памяти жрет гораздо меньше, lostfilm распарсивается в разы быстрее и находит сериалы и с новыми, и со старыми форматированиями.

lostfilm.py

@zalessky commented on GitHub (Sep 6, 2025): Полностью переписал логику плагина. (gemini взял на себя всю работу, я только пинал.) Теперь памяти жрет гораздо меньше, lostfilm распарсивается в разы быстрее и находит сериалы и с новыми, и со старыми форматированиями. [lostfilm.py](https://github.com/user-attachments/files/22184917/lostfilm.py)

bsakaguchi commented

2026-10-13 19:55:47 +00:00

Author

Owner

@werwolfby commented on GitHub (Sep 7, 2025):

@zalessky спасибо за проделанную работу :) Отдельное спасибо Gemini, но давать AI рефакторить работает очень плохо. Как человек который платит за них я знаю о чем говорю, Клод Код тоже справляется плохо даже на Опусе, Гемини в этом плане ещё хуже.

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

@werwolfby commented on GitHub (Sep 7, 2025): @zalessky спасибо за проделанную работу :) Отдельное спасибо Gemini, но давать AI рефакторить работает очень плохо. Как человек который платит за них я знаю о чем говорю, Клод Код тоже справляется плохо даже на Опусе, Гемини в этом плане ещё хуже. А полностью переписанная логика может сломать тесты. Я конечно посмотрю на ченджи, но пока это звучит не очень хорошо.