Бот для телеги на python, как лучше оптимизировать?

Question

[Антон Вебсайтовский]

Еще учусь писать на python.
Бот очень простой, добавляет посты он от аккаунта, юзербот, для сбора ссылок с канала ютуба, я использую апи ютуба, для скачивание видео по собранным ссылкам я использую yt_dlp.

Схема простая, собираю сначала ссылки за определенные дни, ссылки на видео, на одном ютуб канале в день по 150-170 видео выходит, пока идет сбор, ссылки хранятся в оперативной памяти, по завершению сбора, выгрузка ссылок идет в файл, далее идет обработка ссылок, заходит по ним и закачка видео и формирование поста и выгрузка юзерботом.

Что использую для бота:
pip install -r requirements.txt
hachoir==3.2.0
pandas==2.1.3
Telethon==1.32.1
yt_dlp>=2023.10.13
cryptg==0.4.0
google-api-python-client==2.108.0

Чем больше бот работает, тем больше он начинает есть оперативной памяти, но и процесс жрет 14%, а судя по скрину из ssh, оперативу жрет в данный момент 9.5%.

Вопрос, много ли? он кушает ресурсов?


Как бы вы оптимизировали? может не стоит записывать сбор ссылок в оперативную память, а как-то сразу в файл?

Comments

[GavriKos]

9.5% от чего? Это же относительная величина. Может у вас там 128 mb, и от них 9%

[Everything_is_bad]

еще бы от root перестал запускать ботов

[Антон Вебсайтовский]

GavriKos, от 3000

[Антон Вебсайтовский]

Everything_is_bad, а как правильно? учусь

[Everything_is_bad]

Антон Вебсайтовский, учись гуглить такие основы, правильно создать отдельного юзера

[Антон Вебсайтовский]

Everything_is_bad, то есть, нужно создать пользователя, выдать ему какие-то права и под ним работать.

[Антон Вебсайтовский]

Everything_is_bad, такой еще вопрос, для каждого бота лучше создавать свою учетную запись?

Answer 1

[Сергей П]

И как вы предлагаете провести аудит вашего кода без публикации этого кода?
Не понятно же что и как вы там храните в памяти.
Правильная архитектура и логирование легко позволяют отслеживать и находить утечки памяти. Часто потенциальные места видно по коду. Я так понимаю кроме утечек памяти у вас там не мало и других проблем, например ненадежное хранение состояния длительных процессов в случае перезапуска сервиса.
Если правильно построить архитектуру вашего сервиса и использовать персистентные хранилища (например БД) для промежуточных состояний, то даже утечки в сторонних внешних библиотеках для вас не будут проблемой, поскольку вы всегда можете ограничить ресурсы и безопасно перезагружать сервис на любом этапе его работы при недостатке памяти.

Comments

[Антон Вебсайтовский]

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

[Сергей П]

Антон Вебсайтовский, проблема не в "жрать", а в "не освобождать" после использования. Может быть память у вас там течет вовсе не в том, что вы можете сохранить в БД, а в других местах, например связанных с pandas или загрузкой видеороликов, или еще с чем-то

[Сергей П]

Антон Вебсайтовский, ух, столько бессмысленного велосипедного кода, столько странных конструкций.
Почитайте про стандартный logginig. Он замечательный, не надо ничего колхозить в этом плане.
Можно переписать прозрачнее и компактнее раза в три без потери функциональности.
Попробуйте разделить ваш скрипт на два микросервиса. Один формирует задачи на закачку, а второй при наличии задач качает и кладёт куда нужно.
Для ваших нужд какую-то специальную очередь можно не городить, а воспользоваться самой простой БД, она же буде и состояние у вас хранить, чтобы перезапуск микросервисов не ломал всего процесса.

[Антон Вебсайтовский]

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