Скорее всего бот сам выделяет память и не освобождает её. Причём подобного вполне себе легко достичь Ну, например, если все входящие сообщения сохранять в память, то очевидно расход памяти будет расти. Если бот популярный и пишут ему очень много, то логично, что история будет постепенно пухнуть.
Или например если бот втягивает в память содержимое всех присылаемых файлов, то память у него тоже быстро закончится. Особенно если присылают видео.
Или ошибка вообще где-то в неботовой логике.
В общем, профилировать, если нет каких-то очевидных мест утечки.
WSGlebKavash, это как раз не самая проблема, в DVB давно и успешно умеют кодировать каналы. Там другая проблема: придётся брать обязательства на обеспечение сервиса. Мобильным операторам это совершенно не нужно.
Какая реальная задача стоит? Сейчас вопрос выглядит как полная несуразица. S3 это не прокси, а сервис хранения файлов, а Cloudfront это не прокси, а CDN. Соответственно, S3 не будет вообще ни в какой "back domain" обращаться, а Cloudfront будет кэшировать данные и далеко не каждый запрос прокинет, он для того и предназначен, чтобы быстро отдавать контент, не заставляя пользователя ожидать скачивания с оригинального сайта где-то далеко.
Весь этот геморрой не просто так, а в целях борьбы со спамом. И это лишь отчасти предлог (на A2P SMS операторы неплохо так зарабатывают), потому что на практике это реально помогает от засилья SMS-спама. Когда за спам надо выплатить приличную сумму денег, пройти проверку на вшивость (доказательства владения товарным знаком итд) и оправдываться за жалобы от получателей перед оператором, то он становится намного менее выгоден.
Есть более цивилизованные каналы маркетинга. Сайты, группы в соцсетях, каналы в телеграммах, PUSH-сообщения в фирменном мобильном приложении итд итп... Где пользователь более явно выражает своё согласие на получение информации и не менее легко и быстро может его отозвать.
Denis93, эта штуковина - тупая обёртка над библиотекой tdjson. Там кода почти нет. Я заглянул внутрь и очевидно же что там надо создать экземпляр класса и звать от него send/receive/execute. В send или execute передаётся array который внутри сериализуется в json и передаётся в tdjson. Дальше надо смотреть, что делает tdjson и что в него надо передавать. Вроде бы вот это официальный пример: https://github.com/tdlib/td/blob/master/example/py...
PrilForReal, под словом "база данных" иногда подразумевают саму базу с данными, а иногда софт, на которым она крутится (та самая "СУБД"). Да, иногда это может вызывать неопределённость, но крайне редко.
PrilForReal, это крайне стрёмный способ бэкапа, так как для использования бэкапа потребуется база данных такой же версии с таким же конфигом и ещё не факт что нормально взлетит.
Так себе это работает. Особенно с учётом того, что многие из видов "пробива" это даже не серая зона, а самое настоящее уголовное преступление, и на него пойдут только ради сотрудников, которые будут иметь разве что очень высокий уровень доступа к критичным знаниям и данным. А отказывать по причине каких-либо проблем у родственников вообще, скорее всего, нарушает трудовое законодательство (кроме специфических случаев типа гостайны).
Легальные пути тоже есть. Например, могут потребовать предоставить справку о несудимости, которую выдают структуры МВД. Мне довелось работать в бюджетной организации, которую присоединили к другой с наличием в уставе декларации о несудимости сотрудников, пришлось ходить получать. Но это не "пробив", а легальный документ, который человек получает самостоятельно. Точно так же могут потребовать и медицинские справки.
lexstile, там прикол в том что комментарии реализованы так: каждому посту в канале соответствует публикация в группе, а комментарии - это цитирования этой публикации. Есть даже лайфхак как убрать у поста комментарии: надо просто удалить эту публикацию в группе, и комментарии исчезнут.
Естественно, по всем старым постам в канале копии сами по себе не появляются.
Maxwell012, ну у меня браузер на базе хромиума такое съедает (иногда нужно лезть через прокси кой-куда). Единственное что если / на конце поставить то он тихо игнорирует прокси и не ругается, что было для меня неожиданностью.
Никак, это невозможно контролировать. Ссылку на телеграф легко пересылать и невозможно ограничить. Если надо прям защитить-защитить, то это придётся писать свою веб-систему показа скрытого контента с авторизацией через телеграм, чтобы она могла проверять подписки. Очень неудобно для пользователей и никакого особого смысла.
Это нормально, что "рекламные кампании" нацелены не на 100% получение пользователя, а на то, что их будет больше нуля. Тем более в данном предполагаемом сценарии для получения контента достаточно подписаться, скопировать и сразу же отписаться. "Защищать" же единичный контент от распространения и копирования вообще довольно бесперспективно, лучше работать над тем, чтобы в канале постоянно был контент под нужную аудиторию, которая не будет уходить, даже если контент не будет скрываться от окружающих.
Кстати, насчёт отправки изображений. Если они отправляются через передачу результата открытия файла:
функция (open("имя_файла","rb"))То файл не будет закрываться после отправки. Правильно так:
А лучще использовать контекстный менеджер (with):
Тогда файл закроется автоматически при выходе из блока with.
Подобные мелочи вполне могут создавать неожиданные перерасходы памяти.