Jak zredukować zużycie RAM przez skrypty Python przetwarzające duże pliki CSV i JSON

Błąd MemoryError w środowisku produkcyjnym rzadko pojawia się podczas wstępnych testów na małych próbkach danych. Zwykle ujawnia się dopiero wtedy, gdy wolumen przetwarzanych plików rośnie skokowo, a proces zostaje bez ostrzeżenia zatrzymany przez systemowy mechanizm OOM Killer (Out of Memory Killer). Typowa reakcja polega na zwiększeniu zasobów maszyny wirtualnej lub kontenera. Takie podejście generuje jednak niepotrzebne koszty infrastrukturalne i jedynie odsuwa problem w czasie. Gdy plik wejściowy osiągnie jeszcze większy rozmiar, awaria powróci.

Kluczem do stabilnego działania skryptów jest zmiana paradygmatu: zamiast ładować cały zbiór danych do pamięci operacyjnej, należy traktować dane jak strumień lub zarządzać ich reprezentacją w pamięci w sposób ściśle kontrolowany. Skuteczna optymalizacja wymaga zrozumienia, jak interpreter Pythona i popularne biblioteki alokują pamięć, jakie koszty narzuca dynamiczne typowanie oraz w których momentach kod tworzy ukryte, nadmiarowe kopie struktur.

Skąd bierze się wysokie zużycie RAM przy CSV i JSON

Wielu programistów zakłada, że plik o rozmiarze 2 GB na dysku zajmie po wczytaniu około 2 GB pamięci RAM. W środowisku Pythona to założenie niemal zawsze okazuje się błędne. Rzeczywiste zapotrzebowanie na pamięć operacyjną bywa od 3 do nawet 10 razy większe niż pierwotny rozmiar surowego pliku. Różnica ta nie wynika z błędu interpretera, lecz z fundamentalnej struktury obiektowej języka oraz formatów, w jakich dane są reprezentowane.

Rozmiar pliku na dysku nie oznacza rozmiaru danych w pamięci

Plik CSV na dysku to ciągły strumień bajtów reprezentujących znaki tekstowe. Liczba 12345678 zapisana w formacie ASCII zajmuje 8 bajtów. Kiedy ta sama wartość zostaje wczytana do standardowego obiektu Pythona typu int, interpreter tworzy pełnoprawny obiekt z nagłówkiem, licznikiem referencji oraz wskaźnikiem na typ. W 64-bitowej implementacji CPython pojedyncza liczba całkowita zajmuje minimum 28 bajtów. Jeszcze gorzej sytuacja wygląda w przypadku krótkich łańcuchów znaków – obiekt str niesie za sobą narzut rzędu 49–80 bajtów metadanych niezależnie od długości samego tekstu.

W przypadku formatu JSON narzut pamięciowy jest jeszcze bardziej dotkliwy. Surowy plik JSON o rozmiarze 1 GB po zdeserializowaniu standardowym modułem staje się rozległym grafem obiektów: zagnieżdżonych słowników (dict), list (list), napisów i liczb. Słownik w Pythonie wykorzystuje tablicę haszującą z dynamicznym buforem wolnych slotów, co oznacza, że sama struktura przechowująca klucze i wartości rezerwuje znacznie więcej pamięci, niż wynosi suma bajtów przechowywanych danych. Każdy poziom zagnieżdżenia w dokumencie JSON zwielokrotnia ten narzut. ^[2]

Dodatkowym źródłem problemów są operacje pośrednie. Standardowe techniki transformacji danych – takie jak filtrowanie, sortowanie, łączenie słowników czy tworzenie nowych kolumn w ramkach danych – rzadko modyfikują dane w miejscu (in-place). Częściej tworzą nowe, tymczasowe kopie struktur. Jeśli w pamięci znajduje się już obiekt zajmujący 60% dostępnego RAM-u, a operacja wymaga utworzenia kopii roboczej o zbliżonej wielkości, alokacja zakończy się natychmiastowym błędem braku pamięci.

Najczęstszy antywzorzec: pełne wczytanie pliku

Najprostszą i najbardziej intuicyjną metodą pracy z plikami w Pythonie jest wczytanie całej zawartości za jednym razem przy użyciu open(...).read(), json.load() lub domyślnego wywołania pandas.read_csv(). W kodzie prototypowym lub zadaniach edukacyjnych podejście to sprawdza się znakomicie ze względu na czytelność i prostotę. Jednak w środowisku produkcyjnym staje się bezpośrednią przyczyną niestabilności.

Pełne wczytanie pliku jest uzasadnione wyłącznie wtedy, gdy rozmiar danych wejściowych jest ściśle ograniczony i gwarantowanie mieści się w niewielkim procencie dostępnej pamięci operacyjnej, a przetwarzanie wymaga nieliniowego, losowego dostępu do wszystkich elementów naraz (na przykład w specyficznych algorytmach grafowych). Jeśli zadanie polega na walidacji rekordów, filtracji, przeliczeniu sumy czy konwersji do innego formatu, ładowanie całości danych do pamięci stanowi kardynalny błąd projektowy.

Typowy scenariusz awarii wygląda następująco: serwer dysponuje 8 GB pamięci RAM. Skrypt ma przetworzyć plik CSV o rozmiarze 3,5 GB. Wywołanie pandas.read_csv("dane.csv") uruchamia automatyczne wykrywanie typów. Ponieważ pandas domyślnie tworzy 64-bitowe typy danych i reprezentuje kolumny tekstowe jako wskaźniki do obiektów Pythona, rozmiar ramki danych rośnie do ponad 7 GB. W momencie próby wykonania pierwszej operacji, np. prostej filtracji tworzącej nową ramkę, proces próbuje zaalokować kolejne gigabajty, co powoduje zrzucenie procesu przez system operacyjny. ^[1]

Najpierw zmierz problem, zamiast optymalizować na ślepo

Próby optymalizacji kodu bez uprzedniego pomiaru alokacji pamięci zazwyczaj prowadzą do zaciemnienia logiki biznesowej bez osiągnięcia realnych korzyści wydajnościowych. Programiści często skupiają się na zastępowaniu pętli listami składanymi lub próbach przyspieszenia parsowania tekstu, podczas gdy prawdziwym wąskim gardłem jest pojedyncza, niepozorna instrukcja tworząca pełną kopię zbioru w pamięci podręcznej.

Co obserwować podczas działania skryptu

Efektywna analiza wymaga rozróżnienia trzech pojęć: bieżącego zużycia pamięci, pamięci szczytowej (peak memory) oraz pamięci zatrzymanej przez zarządcę alokacji. Standardowy wskaźnik zużycia RAM w menedżerze zadań lub poleceniu top pokazuje pamięć rezydentną procesu (RSS – Resident Set Size). Wartość ta informuje, ile fizycznej pamięci system operacyjny przydzielił procesowi, ale nie odzwierciedla precyzyjnie tego, co dzieje się wewnątrz interpretera Pythona.

CPython korzysta z własnego menedżera pamięci (pymalloc) dla małych obiektów. Kiedy Python usuwa obiekt, pamięć jest często zwalniana wewnątrz struktur interpretera, lecz nie zawsze zostaje natychmiast zwrócona do jądra systemu operacyjnego z powodu fragmentacji sterty. Obserwowanie wyłącznie wskaźnika RSS z zewnątrz procesu może prowadzić do mylnego wrażenia, że pamięć wycieka, podczas gdy w rzeczywistości interpreter zachowuje zaalokowane bloki na poczet przyszłych obiektów. Aby znaleźć problematyczne fragmenty kodu, należy profilować alokacje bezpośrednio na poziomie wykonywanych instrukcji.

Narzędzia do profilowania pamięci

Do diagnozowania problemów z pamięcią w Pythonie służy kilka narzędzi o różnym poziomie szczegółowości. Podstawowym modułem wbudowanym w bibliotekę standardową jest tracemalloc. Umożliwia on precyzyjne śledzenie alokacji wykonanych przez kod Pythona, wskazuje plik oraz numer linii, w której utworzono najbardziej pamięciożerne struktury, a także pozwala porównywać migawki (snapshots) stanu pamięci przed i po wykonaniu operacji.

import tracemalloc

tracemalloc.start()

# Blok kodu poddawany weryfikacji
dane = [str(i) * 10 for i in range(1_000_000)]

current, peak = tracemalloc.get_traced_memory()
print(f"Bieżące zużycie: {current / 10**6:.2f} MB")
print(f"Zużycie szczytowe: {peak / 10**6:.2f} MB")

tracemalloc.stop()

Warto pamiętać o ograniczeniu tracemalloc: narzędzie to rejestruje wyłącznie alokacje zarządzane bezpośrednio przez środowisko uruchomieniowe Pythona. Jeśli operacja angażuje biblioteki natywne napisane w C lub C++ (takie jak NumPy, Polars czy określone backendy parsowania JSON), alokacje poza stertą Pythona mogą nie zostać w pełni uwzględnione.

Do analizy linijka po linijce przydaje się zewnętrzny pakiet memory_profiler. Poprzez dodanie dekoratora @profile nad funkcją, programista otrzymuje czytelny raport pokazujący przyrost pamięci wywoływany przez każdą instrukcję. Z kolei w długotrwałych procesach wsadowych najlepszym rozwiązaniem jest bezpośrednie monitorowanie procesu za pomocą biblioteki psutil, która pozwala cyklicznie logować metryki RSS oraz VMS (pamięć wirtualna) bez wprowadzania znacznego narzutu na czas wykonania skryptu.

Minimalny plan diagnozy

Diagnoza powinna przebiegać w uporządkowany sposób. Pierwszym krokiem jest uruchomienie profilowania na reprezentatywnej, ograniczonej próbce danych (na przykład 5–10% docelowego pliku), a następnie na pełnym zbiorze. Zachowanie mechanizmów zarządzania pamięcią często zmienia się nieliniowo wraz ze wzrostem wielkości pliku – struktury, które przy małych wolumenach mieszczą się w pamięci podręcznej procesora, przy większych zmuszają system do intensywnej wymiany stron (paging/swapping), co drastycznie degraduje wydajność.

Podczas profilowania kluczowe jest zidentyfikowanie momentu, w którym następuje gwałtowny skok (spike) zużycia pamięci szczytowej. Często okazuje się, że cały skrypt działa stabilnie przy stałym zużyciu 400 MB, po czym jedna linijka – np. nieoptymalne sortowanie lub operacja to_dict() – powoduje nagły impuls rzędu kilku gigabajtów. Precyzyjne zlokalizowanie tego pojedynczego punktu pozwala skupić prace optymalizacyjne dokładnie tam, gdzie przyniosą one realny skutek.

Należy również zdefiniować priorytet optymalizacji. Rzadko udaje się jednocześnie zminimalizować zużycie pamięci, skrócić czas wykonywania skryptu i zachować maksymalną zwięzłość kodu. Zmniejszenie zużycia RAM do absolutnego minimum (np. poprzez sekwencyjne przetwarzanie rekordu po rekordzie) może wydłużyć całkowity czas przetwarzania ze względu na narzut pętli interpretera. Z kolei techniki wektorowe działają najszybciej, lecz wymagają alokowania większych buforów.

Przetwarzanie dużych CSV bez ładowania całości do pamięci

Pliki z wartościami rozdzielanymi przecinkami (CSV) są formatem czysto tekstowym, w którym każdy wiersz stanowi niezależną jednostkę danych (z wyjątkiem pól wielowierszowych ujętych w cudzysłowy). Ta cecha sprawia, że CSV idealnie nadaje się do przetwarzania strumieniowego oraz podziału na niezależne bloki danych.

Moduł csv i iteracja wiersz po wierszu

Najprostszą, wbudowaną w standardową bibliotekę Pythona metodą radzenia sobie z plikami dowolnej wielkości jest użycie modułu csv. Obiekty csv.reader oraz csv.DictReader są iteratorami. Nie wczytują one zawartości pliku na raz, lecz pobierają i parsują pojedyncze linie tekstu w miarę zapotrzebowania.

import csv

def filtruj_transakcje(plik_wejsciowy, plik_wyjsciowy, prog_kwoty):
    with open(plik_wejsciowy, mode="r", encoding="utf-8") as f_in, 
         open(plik_wyjsciowy, mode="w", encoding="utf-8", newline="") as f_out:
        
        reader = csv.DictReader(f_in)
        fieldnames = reader.fieldnames
        writer = csv.DictWriter(f_out, fieldnames=fieldnames)
        
        writer.writeheader()
        for row in reader:
            if float(row["kwota"]) > prog_kwoty:
                row["status"] = "ZNACZACA"
                writer.writerow(row)

Powyższy wzorzec utrzymuje niemal stałe zapotrzebowanie na pamięć RAM – rzędu kilkunastu kilobajtów na bufory wejścia/wyjścia – niezależnie od tego, czy plik wejściowy waży 50 megabajtów, czy 500 gigabajtów. Dane przepływają przez pamięć jak woda przez rurę: pojedynczy wiersz jest wczytywany, weryfikowany, modyfikowany i natychmiast wypychany do pliku docelowego, po czym stary obiekt jest usuwany przez odśmiecanie pamięci (Garbage Collector).

Ograniczeniem tego podejścia jest wydajność obliczeniowa w czystym Pythonie. Przetworzenie dziesiątek milionów wierszy za pomocą pojedynczej pętli for może trwać znacznie dłużej niż w przypadku bibliotek skompilowanych, takich jak pandas czy Polars. Jest to kompromis: zyskujemy niewrażliwość na brak pamięci RAM kosztem dłuższego czasu przetwarzania.

pandas.read_csv() z parametrem chunksize

Jeśli zadanie wymaga operacji wektorowych,

Jeśli zadanie wymaga operacji wektorowych, rozsądnym kompromisem jest odczyt pliku w porcjach za pomocą parametru chunksize. Funkcja pandas.read_csv() zwraca wtedy iterator ramek DataFrame, a nie jedną ramkę zawierającą cały plik. Rozmiar porcji trzeba dobrać do dostępnej pamięci oraz charakteru transformacji; bezpieczna liczba wierszy w jednym bloku nie jest uniwersalna, ponieważ znaczenie mają liczba kolumn, typy danych i długość pól tekstowych. ^[3]

import pandas as pd

suma = 0.0

for chunk in pd.read_csv(
    "transakcje.csv",
    chunksize=100_000,
    usecols=["data", "kwota", "status"],
    dtype={"status": "category"}
):
    kwoty = pd.to_numeric(chunk["kwota"], errors="coerce")
    filtrowane = chunk.loc[kwoty > 1000]

    filtrowane.to_csv(
        "znaczace_transakcje.csv",
        mode="a",
        index=False,
        header=(suma == 0)
    )
    suma += filtrowane["kwota"].sum()

Przetwarzanie porcjami nie rozwiązuje jednak każdego problemu. Operacje globalne, takie jak pełne sortowanie, usuwanie duplikatów dla całego zbioru czy wyliczanie dokładnej mediany, zwykle wymagają dostępu do wszystkich danych albo dodatkowej strategii przechowywania stanu poza RAM-em. Łączenie wielu fragmentów przez pd.concat(chunks) na końcu pętli niweczy też korzyść z użycia chunksize: finalnie powstaje pełna ramka w pamięci, często z kosztownymi kopiami pośrednimi.

Zużycie pamięci można ograniczyć jeszcze przed rozpoczęciem obliczeń. Pomaga wybór wyłącznie potrzebnych kolumn przez usecols, jawne określenie dtype oraz traktowanie dat i identyfikatorów z ostrożnością. Automatyczne rozpoznawanie typów jest wygodne, ale dla szerokich plików potrafi generować obiekty object, które są znacznie cięższe od typów liczbowych lub kategorii. Nie każdy tekst powinien jednak zostać kategorią: przy niemal unikalnych wartościach, na przykład identyfikatorach zamówień, słownik kategorii może zużyć więcej pamięci niż zwykła kolumna tekstowa.

Najmniejsze zużycie RAM uzyskuje się zwykle wtedy, gdy dane są filtrowane i zapisywane możliwie wcześnie, a w pamięci pozostaje wyłącznie porcja robocza oraz niewielki stan agregacji. Zanim skrypt zostanie przebudowany, dobrze jest potwierdzić profilowaniem, czy problem rzeczywiście wynika z odczytu CSV, a nie z późniejszego sortowania, konwersji do słowników albo niepotrzebnego gromadzenia wyników w liście.

JSON strumieniowo: jak uniknąć kosztu json.load()

W przeciwieństwie do CSV, format JSON jest strukturą z natury hierarchiczną. Standardowy parser biblioteki Pythona, json.load(), wymaga załadowania całego łańcucha znaków i odtworzenia pełnego drzewa obiektów w pamięci podręcznej przed zwróceniem wyniku. Dla pliku o rozmiarze 4 GB na dysku proces ten oznacza nie tylko odczytanie gigabajtów tekstu, ale również alokację milionów powiązanych słowników, list, ciągów znaków oraz liczb zmiennoprzecinkowych. W praktyce próba sparsowania tak dużego pliku klasyczną metodą niemal zawsze kończy się natychmiastowym błędem MemoryError lub przerwaniem procesu przez mechanizm OOM (Out Of Memory) systemu operacyjnego.

Rozwiązaniem tego problemu jest rezygnacja z podejścia holistycznego na rzecz odczytu strumieniowego. Zamiast budować w pamięci reprezentację całego pliku, skrypt może ekstrahować z niego wyłącznie interesujące fragmenty w momencie, gdy parser natrafia na nie w strumieniu bajtów.

Parsowanie zdarzeniowe za pomocą biblioteki ijson

Standardowym i najbardziej dojrzałym narzędziem do strumieniowego parsowania formatu JSON w Pythonie jest biblioteka ijson. Działa ona w oparciu o parser iteracyjny (zdarzeniowy), który przesuwa się po pliku sekwencyjnie i emituje zdarzenia w miarę napotykania kolejnych struktur składniowych. Dzięki temu pamięć operacyjna zawiera jedynie bufor odczytu oraz aktualnie przetwarzany obiekt potomny.

Najwygodniejszą funkcją pakietu jest ijson.items(), która pozwala zdefiniować ścieżkę do obiektów za pomocą prefiksu i iterować po nich dokładnie tak samo, jak po wierszach w pliku tekstowym. Typowym scenariuszem jest ogromna tablica obiektów JSON zapisana w jednym pliku:

import ijson

def przetworz_duzy_json(sciezka_do_pliku):
    laczna_wartosc = 0.0
    licznik = 0

    with open(sciezka_do_pliku, "rb") as plik:
        # 'item' wskazuje, że iterujemy po elementach tablicy na najwyższym poziomie
        obiekty = ijson.items(plik, "item")
        
        for rekord in obiekty:
            if rekord.get("aktywny") and "kwota" in rekord:
                laczna_wartosc += float(rekord["kwota"])
                licznik += 1
                
    return laczna_wartosc, licznik

Warto zwrócić uwagę na otwarcie pliku w trybie binarnym ("rb"). Biblioteka ijson potrafi wykorzystywać natywne, bardzo szybkie backendy napisane w C (np. yajl2_c), co pozwala drastycznie zredukować narzut czasowy parsowania strumieniowego, utrzymując jednocześnie profil zużycia RAM na stałym poziomie kilkudziesięciu megabajtów przez cały czas trwania operacji.

Format JSON Lines (JSONL / NDJSON) jako alternatywa

Jeśli istnieje wpływ na format zapisu danych źródłowych, najlepszym rozwiązaniem architektonicznym jest zastąpienie jednolitego pliku JSON formatem JSON Lines (znanym również jako NDJSON – Newline Delimited JSON). W formacie tym każdy wiersz pliku tekstowego stanowi w pełni poprawny, niezależny dokument JSON.

Podejście to łączy elastyczność strukturalną formatu JSON z sekwencyjnymi zaletami CSV. Przetwarzanie wielogigabajtowego pliku JSONL nie wymaga żadnych zewnętrznych bibliotek i może być zrealizowane za pomocą standardowych mechanizmów Pythona:

import json

def filtruj_ndjson(zrodlo, cel):
    with open(zrodlo, "r", encoding="utf-8") as f_in, 
         open(cel, "w", encoding="utf-8") as f_out:
        
        for linia in f_in:
            rekord = json.loads(linia)
            if rekord.get("poziom") == "ERROR":
                f_out.write(json.dumps(rekord) + "n")

Skrypt odczytuje dokładnie jedną linię, parsuje ją do natywnego słownika, podejmuje decyzję o filtracji lub zapisie, po czym referencja do słownika znika przy kolejnym obrocie pętli. Narzut pamięciowy pozostaje mikroskopijny i w pełni przewidywalny bez względu na to, czy plik docelowy ma 100 megabajtów, czy 2 terabajty.

Optymalizacja przetwarzania JSON w praktyce

Wybierając metodę przetwarzania dużych wolumenów danych w formatach tekstowych, warto dopasować narzędzie bezpośrednio do charakterystyki wejścia:

• Standardowy moduł csv: bezkonkurencyjny pod względem stabilności pamięciowej przy prostych strukturach tabelarycznych, gdy nie są wymagane skomplikowane operacje matematyczne.
• pandas z parametrem chunksize: optymalny wybór w analizie numerycznej i wektorowej, pod warunkiem restrykcyjnego określenia typów (dtype) i unikania ponownego łączenia bloków w pamięci RAM.
• Biblioteka ijson: niezbędna przy pracy z monolitycznymi plikami JSON o strukturze drzewiastej lub głęboko zagnieżdżonymi tablicami, których nie można zmodyfikować u źródła.
• Format JSON Lines (NDJSON): najbardziej skalowalny format wymiany złożonych danych, łączący prostotę iteracji linia po linii z bogactwem reprezentacji obiektowej.

Skuteczna redukcja zużycia pamięci podręcznej nie polega na agresywnym wywoływaniu kolektora odśmiecania przez gc.collect(), lecz na projektowaniu potoków przetwarzania danych w sposób bezstanowy lub porcjowy. Utrzymanie w pamięci operacyjnej wyłącznie minimalnego wycinka danych, który jest aktualnie poddawany transformacji, pozwala na bezawaryjne uruchamianie zadań analitycznych nawet na maszynach o bardzo skromnych parametrach sprzętowych.

Najważniejsze wnioski

• Nie należy ładować całych dużych plików CSV i JSON do pamięci, jeśli zadanie można wykonać strumieniowo.
• Rozmiar pliku na dysku nie odpowiada jego rozmiarowi w pamięci Pythona, ponieważ obiekty mają dodatkowy narzut pamięciowy.
• Operacje takie jak filtrowanie, sortowanie czy konwersja do słownika mogą tworzyć tymczasowe kopie danych i powodować skoki zużycia RAM.
• Przed optymalizacją warto zmierzyć pamięć bieżącą i szczytową za pomocą narzędzi takich jak tracemalloc, memory_profiler lub psutil.
• Dobór rozwiązania powinien uwzględniać kompromis między zużyciem pamięci, czasem wykonania i prostotą kodu.

Źródła

• [1] Python Software Foundation – csv — CSV File Reading and Writing — Python 3.15.0 documentation ↑
• [2] Python Software Foundation – json — JSON encoder and decoder — Python 3.15.0 documentation ↑
• [3] Python Software Foundation – codecs — Codec registry and base classes — Python 3.12.15 documentation ↑