Ответы, понравившиеся пользователю Ivan Yakushenko

Если jit так хорош, то зачем вообще нужна интерпретация?

Roman K @deliro

1. JIT сложно и долго писать
2. JIT не только ускоряет выполнение, но и замедляет (потому что нужно тратить время на анализ, компиляцию, деоптимизацию и т.п.). Далеко не всегда (RoR тому пример и почти любые скрипты, которые выполняются один раз и умирают) JIT позитивно влияет на время исполнения
3. JIT дороже по памяти

Ответ написан более двух лет назад

Комментировать

Python, postgress, pandas - куда утекает память?

Александр @Arlekcangp

Разработчик, Лид, Архитектор ПО

Я не специалист по пайтону, но присматриваюсь и ваш код меня заинтересовал. Немного погуглив я нашел такой похожий вопрос на 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/ Этим можно посмотреть что именно потребляет память.

Ответ написан более двух лет назад

5 комментариев

Как защититься от двойного списания в многопоточном приложении?

Станислав Макаров @Nipheris

если проверка прошла, то обе выполнятся

Кто сказал что СУБД позволит выполнить обе транзакции с одними и теми же исходными данными?
Если обе транзакции начали исполняться параллельно, прочитали одни и те же данные, и пытаются их перезаписать, как СУБД будет себя вести? Позволит ли она вообще отработать обеим транзакциям? Или одна их них подождёт, пока не закончит работу другая? Вопрос гораздо интереснее, чем кажется. И, что самое главное, неглупые люди уже подумали над ним. Очень хорошо подумали.

В доках постгреса написано ещё лучше.

Или лучше каждый раз пересчитыапть из истории?

Запаритесь пересчитывать, это не масштабируется, сложность расчёта будет всё время расти. Если считаете, что можете накосячить с текущим балансом - сделайте возможность его пересчёта согласно истории пополнений/трат. Это называется денормализованными данными. Это один из тех случаев, когда оправдано применение хранимых процедур для актуализации таких данных. Т.е. вместо непосредственной записи одновременно и в историю пополнений/трат и в актуальный баланс прямо из приложения, вы вместо этого вызываете хранимую процедуру, которая атомарно как пишет новую операцию - это ваши основные данные - так и меняет нужным образом ваши денормализованные данные - т.е. ваш баланс. Заодно в этой же хранимке можно дополнительно проверить возможность списания. Это решение не очень хорошо масштабируется, и вообще хранимки это антипаттерн для современных модных-молодёжных распределённых приложений, но судя по вашим вопросам врядли вы отвечаете за разработку сервиса, где таких списаний десятки тысяч в секунду, так что вам хватит.

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

Войдите на сайт