Jupyter на ноутбуке: ядра, память и работа с большими данными

Прямой ответ

Главная особенность Jupyter — состояние живёт в ядре: каждый открытый notebook с запущенным kernel держит в памяти все созданные переменные, даже если вы «давно закончили» ячейку. Три практических следствия: завершайте неиспользуемые ядра; проверяйте реальный размер переменных магией %whos; данные, превышающие половину доступной ОЗУ, обрабатывайте чанками или колоночными движками (DuckDB/Polars), а не «в лоб» через pandas. На 16 ГБ ноутбуке комфортный потолок одного DataFrame — 3–4 ГБ с учётом промежуточных копий.

Жизненный цикл ядра: что происходит с памятью

Ядро (kernel) — отдельный Python-процесс. Он не освобождает память «сам», пока переменная жива в области видимости. Типичные утечки сессии:

десять экспериментов подряд создали десять копий датасета с разными именами — в памяти все десять;
перезапись df = pd.read_csv(...) в той же ячейке не освобождает старую копию мгновенно во время выполнения (пик = обе копии);
del df освобождает ссылку, но сборка мусора больших массивов занимает время и не всегда возвращает память ОС сразу.

Дисциплина сессии:

%whos — таблица живых переменных с размерами; запускайте перед «тяжёлой» ячейкой.
Закончили ветку экспериментов — Restart Kernel and Clear Outputs, затем выборочный перезапуск нужных ячеек.
Долгая сессия — периодический рестарт ядра: состояние можно восстановить за минуты, если notebook написан как последовательность воспроизводимых шагов (это же защищает от «работает только в моём ноутбуке»).

Контроль потребления: инструменты внутри notebook

%whos / sys.getsizeof() — быстрые оценки; для DataFrame точнее df.info(memory_usage='deep').
%memit (расширение memory_profiler) — потребление конкретной ячейки; установка: %pip install memory_profiler, затем %load_ext memory_profiler.
Внешний взгляд: htop/Диспетчер задач покажут процесс ipykernel_launcher — по нему видно, сколько ядро держит на самом деле.
Признак приближающегося OOM-killer (Linux/WSL): ядро «умирает» без traceback с сообщением Kernel Restarting — почти всегда это память; уменьшайте датасет до перезапуска, а не после.

Данные больше ОЗУ: три рабочих подхода

Чанки в pandas:

total = 0
for chunk in pd.read_csv("huge.csv", chunksize=500_000,
                         usecols=["id", "amount"], dtype={"id": "int32"}):
    total += chunk["amount"].sum()

Пик памяти — один чанк, а не весь файл. usecols и dtype сокращают объём в разы ещё на чтении.

DuckDB — SQL по файлу без загрузки:

import duckdb
duckdb.sql("SELECT region, SUM(amount) FROM 'huge.parquet' GROUP BY 1").df()

Читает parquet/CSV потоково, агрегирует на диске, возвращает только результат — на ноутбуке обрабатывает файлы в десятки ГБ при 16 ГБ ОЗУ.

Polars — ленивые вычисления (scan_parquet + collect): план запроса оптимизируется, в память попадает минимум. Для новых пайплайнов в 2026 году — дефолтная рекомендация наравне с DuckDB.

Формат хранения промежуточных результатов — parquet, не CSV: сжатие в 5–10 раз и сохранение типов; обоснование и сравнение дисков — в статье про стек Power BI/SQL/Pandas.

Окружения и запуск: частые грабли

Ядро должно указывать на окружение проекта: из активированного venv выполните python -m ipykernel install --user --name proj. Симптом ошибки — «в терминале импортируется, в notebook ModuleNotFoundError»; устройство окружений — в статье про venv/conda/uv.
%pip install внутри notebook ставит пакет в окружение текущего ядра — это корректный способ, в отличие от системного pip из другого терминала.
JupyterLab 4 держит несколько вкладок-ноутбуков в одном процессе браузера, но каждый notebook = своё ядро: три открытых ноутбука с данными — это тройная память.
Автозапуск ядер после перезапуска Lab отключён по умолчанию — и правильно: не позволяйте десяти ядрам воскресать утром.

Организация работы: ноутбук как воспроизводимый документ

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

Структурируйте ячейки по фазам: загрузка → очистка → преобразования → анализ → выводы. Между фазами — промежуточные сохранения в parquet. После перезапуска ядра вы восстанавливаете состояние за секунды (pd.read_parquet), а не повторным прогоном тяжёлых ячеек.
Тяжёлое — в функции, не в глобальные переменные: локальные объекты освобождаются при выходе из функции; десяток глобальных df_temp_* живут до рестарта ядра.
Отчётность: jupyter nbconvert --to script/--to html превращает notebook в скрипт или читаемый отчёт; финальную версию пайплайна держите в .py — notebook остаётся документацией разведки.
Параллельные ветки экспериментов — разные notebook'и, но с общим промежуточным parquet-слоем: меньше соблазна держать всё в одном раздутом ядре.

Эта дисциплина напрямую снижает требования к железу: вместо «нужно 32 ГБ, потому что ядро держит всё» получается «16 ГБ хватает, потому что в памяти только текущая фаза». Расчёт памяти под весь стек аналитика (Power BI + SQL + Python) — в статье про выбор SSD и ОЗУ для аналитики.

FAQ

Сколько ОЗУ нужно для комфортной работы в Jupyter? 16 ГБ — стандарт: ядро с датасетом 2–3 ГБ, браузер, IDE. Для регулярной работы с файлами 5+ ГБ берите 32 ГБ или переходите на DuckDB/Polars.

Почему после удаления переменной память не вернулась? Python не всегда немедленно возвращает страницы ОС. Внутри процесса память переиспользуется следующими вычислениями — это нормально; «вернуть хосту» помогает только рестарт ядра.

Jupyter или скрипты — что использовать для продакшн-обработки? Notebook — для разведки и прототипов; финальный пайплайн переносите в .py с параметрами: воспроизводимость, code review и планировщик важнее интерактивности. Профилирование перенесённого кода — в статье про профилирование Python.

Стоит ли ставить Anaconda «целиком»? Нет: полный дистрибутив — это 3+ ГБ на диске и сотни ненужных пакетов. Miniforge или venv+pip/uv покрывают задачи с меньшим следом.

Как ограничить память одного ядра, чтобы оно не роняло ноутбук? Штатного лимита у Jupyter нет; на Linux/WSL помогает systemd-скоуп или ulimit -v перед запуском, в Docker — --memory. Проще всего дисциплина чанков: если обработка спроектирована под поток данных, ядру физически нечего раздувать.

Источники: документация JupyterLab, IPython magics, руководство пользователя pandas (ссылки в шапке).

Jupyter на ноутбуке: как ядра съедают память и что делать с данными больше ОЗУ