Ivan Yakushenko

Я не специалист по пайтону, но присматриваюсь и ваш код меня заинтересовал. Немного погуглив я нашел такой похожий вопрос на SO ( https://stackoverflow.com/questions/39100971/how-d... ), но c более простым кодом:

import pandas
df = pandas.read_csv('large_txt_file.txt')
del df

Уже этого достаточно, что бы память не возвращалась в ОС. Автор вопроса подозревал Pandas, но как пояснили в ответах, это особенность самого пайтона:

Reducing memory usage in Python is difficult, because Python does not actually release memory back to the operating system. If you delete objects, then the memory is available to new Python objects, but not free()'d back to the system (see this question).

Т е если вы смотрите количество используемой процессом памяти, то оно будет только увеличиваться. Первое, что я бы попробовал, это поменять ваш код так:

for station in config.STATIONS_LIST:
    sql_query = f"select * from table where  where station = '{station}'"
    df = pd.read_sql(sql_query, con=connection_pg)
    filename = f'data_{station}'
    filename_with_path = os.path.join(config.OUTPUT_PATH, filename)
    compression_options = dict(method='zip', archive_name=f'{filename}.csv')
    df.to_csv(f'{filename_with_path}.zip', compression=compression_options, index=False)
    <b>df = ' '</b>
    gc.collect()

Т е не удалять переменную, а переприсвоить. Некоторые говорят, что это помогает (если честно, мне в такое с трудом верится, но я не знаю пайтона) Среди других рекомендаций: загружать данные меньшими порциями и офлоудить работу другому процессу, который затем убивается и память освобождается ОС. (на мой взгляд способ хороший, хоть и не слишком архитектурно-правильный, но гарантировано добавит стабильности и застрахует даже от будущих утечек, если они появятся либо в вашем коде либо в новых версиях библиотек)
Другой вопрос, почему это увеличение не останавливается. Если это всё дело происходит на linux то я бы попробовал ограничить пайтону память (первое что нагуглилось: https://www.geeksforgeeks.org/python-how-to-put-li...) и посмотрел будет ли при этом интерпретатор умирать по причине недостатка памяти. Если будет, то на SO рекомендовали такое средство: https://mg.pov.lt/objgraph/ Этим можно посмотреть что именно потребляет память.

Эта элементарная задача называется "генерирование дискретных случайных величин с заданным законом распределения". Решается классическим образом.
Сначала разбиваем наш диапазон от 1 до 100 на следующие интервалы:
1-35,36-60,61-85,86-95,96-100.
Затем генерируем число, равномерно распределенное в диапазоне от 1 до 100. Номер интервала, в который это число попадает дает ваши генерируемые цифры - от 1 до 5, причем распределены они в точности по вашей таблице распределения.

Несколько лет назад я (видимо, как и ты) уверовал в logging. Ведь не зря же там такие дикие и глубокие настройки: и форматтеры есть, и хэндлеры есть, да и фильтры какие-то. И подумал я: крутые программисты всё это используют, а я на задворках рынка побираюсь.

И начал с тех пор настраивать все мыслимые и немыслимые настройки logging. Все ошибки у меня были в соответствующих файлах для ошибок. Также, был лог с дебаговой инфой. Всё это группировалось по файлам. Дебаг форматировался одним форматтером, ошибочный лог — другим форматтером, более подробным. И всё это росло, цвело и пахло.

Реальность оказалась жестокой. Все эти форматтеры оказались абузой — грепать логи стало сложней. Отдельные файлы с дебагом и ошибками оказались абузой — ведь проще грепнуть по уровню лога ( | grep ERROR). В куче файлов логов — чёрт ногу сломит. Да и вообще, логи почти всегда оказывались ненужными — ошибки летят в Sentry, а статистика собирается другими механизмами (prometheus). А ротацию и архивирование логов сделали девопсы.

А вот хорошие практики, которые я вынес:
1. Возьми loguru, которому буквально не нужны настройки:

from loguru import logger
...
# Где-то настроил sink-файл (либо будет только stdout)
...
logger.debug("hello")

2. Иногда удобно логи вести в JSON-формате. Отпадает необходимость придумывать хитрые grep'ы, всё отлично фильтруется с помощью jq

3. Ошибки надо не логировать, а слать в Sentry. Желательно, если Sentry настроен на веб-хуки в какой-нибудь slack/discord, чтобы ты видел ошибку в ту же секунду, как она произошла. В Sentry должен быть порядок.

4. Статистику по логам не стоит строить. Для этого есть куда более удобные и быстрые инструменты от обычных баз данных до prometheus + grafana

5. Куча файлов логов — в топку. Один файл

6. Ротация логов желательно должна быть извне

7. Используй ELK

8. Используй тесты и дебаггер

Если резюмировать: на логи возлагают слишком большие надежды и ожидания. Логи — это побочный продукт, который ОЧЕНЬ РЕДКО помогает расследовать неожиданное поведение, причём, очень неудобным способом. Чаще всего, логами обкладывается недостаточно нужной информации и много ненужной информации. И в момент аварии логов не хватает, на то ведь она и авария — её нельзя предусмотреть. Вместо логгирования в большинстве случаев удобнее использовать другие инструменты. Также, советую ознакомиться с этим https://sobolevn.me/2020/03/do-not-log

есть схожая проблема в Майкрософтовском гите https://github.com/Microsoft/WSL/issues/1688
там внизу есть есть способы решить эту проблему. Посмотрите, может вам чтото подойдет из них

await Promise.all(list.map(funcOne)); // Если в случае ошибки в одной итерации нужно остановить все остальное

await Promise.allSettled(list.map(funcOne)); // Если в случае ошибки в одной итерации остальные должны продолжить работу

Но вы должны учитывать разницу:

• Если использовать стандартный for то все асинхронные вызовы будут выполняться последовательно, один за другим.
  
• Если вызывать асинхронную функцию в map, то все вызовы будут запущены параллельно, и итоговый Promise.all нужен, чтобы дождаться пока они все будут выполнены. Это эквивалентно примерно такому коду:
  

  const promises = []
  for (const item of list) {
        promises.push(funcOne(item));
  }
  await Promise.all(promises)

  
  

RabbitMQ

Если даешь доступ только к одной определенной папке, где нужно только там работать, фрилансеры просят доступ ко всему исходнику, тоже самое если ты отправляешь один файл ему, в котором нужно сделать правки.

Приходишь в автосервис, говоришь, что автомобиль не заводится, на предложение притащить автомобиль к ним в бокс выдаёшь открученную педаль газа.

Боитесь слива, наймите в штат разработчиков и взращивайте в них высокий уровень лояльности.