Python GIL a Kubernetes CPU Limity: Pasca Threadingu

O GIL som sa naucil tvrdo, v pode s CPU limitom. “Naša Python API má štyri workery so štyrmi threadmi každý. Dali sme jej 4 CPU jadrá. Prečo je throttlovaná 80% času a využíva len 25% CPU?” Túto otázku som počul desiatky krát a odpoveď vždy ľudí prekvapí. Je to klasický prípad dvoch systémov—Python GIL a Linux CFS scheduler—ktoré interagujú spôsobom, o ktorom ani jedna dokumentácia nespomína.

Prvýkrát som narazil na tento problém pred rokmi, keď sme migrovali Django aplikáciu do Kubernetes. Aplikácia bežala krásne na 4-jadrovom VM, spracovávala stovky requestov za sekundu s gunicornom nakonfigurovaným na 4 workery a 4 thready každý. Po migrácii, s rovnakou konfiguráciou a CPU zdrojmi, sa latencia strojnásobila a videli sme konštantný CFS throttling. Trvalo nám dva dni pochopiť prečo.

Testované na: Python 3.11, Kubernetes 1.28, gunicorn so 4 workermi

Pochopenie Global Interpreter Lock

Predtým než sa ponoríme do interakcie s Kubernetes, potrebujeme pochopiť čo GIL vlastne je a prečo ho Python má.

Global Interpreter Lock je mutex, ktorý chráni prístup k Python objektom a zabraňuje viacerým threadom vykonávať Python bytecode súčasne. Existuje preto, lebo správa pamäte v CPythone nie je thread-safe. Mechanizmus počítania referencií, ktorý Python používa pre garbage collection, by bez ochrany GILom skončil v race condition.

Keď vytvoríte viaceré thready v Pythone, len jeden môže vykonávať Python kód v akomkoľvek momente. Ostatné čakajú, držia referencie na Python objekty, ale nemôžu s nimi nič robiť. GIL sa uvoľňuje približne každých 5 milisekúnd (konfigurovateľné cez sys.setswitchinterval()), čo umožňuje ďalšiemu threadu ho získať.

To vedie k protiintuitívnej realite: pridanie viacerých threadov do CPU-bound Python aplikácie ju neurobí rýchlejšou. V skutočnosti ju často spomalí kvôli réžii získavania a uvoľňovania GIL. Thready v Pythone sú prospešné len pre I/O-bound prácu, kde trávia väčšinu času čakaním na externé operácie (sieť, disk) a GIL sa počas týchto čakaní uvoľňuje.

import sys
import threading
import time

# Skontroluj default switch interval
print(f"GIL switch interval: {sys.getswitchinterval()} seconds")

# Táto CPU-bound práca sa neparalelizuje cez thready
def cpu_intensive():
    total = 0
    for i in range(10_000_000):
        total += i
    return total

# Jeden thread: ~0.5 sekúnd
start = time.time()
cpu_intensive()
print(f"Jeden thread: {time.time() - start:.2f}s")

# Štyri thready: Stále ~0.5 sekúnd (alebo horšie!)
# Striedajú sa v držaní GIL
start = time.time()
threads = [threading.Thread(target=cpu_intensive) for _ in range(4)]
for t in threads:
    t.start()
for t in threads:
    t.join()
print(f"Štyri thready: {time.time() - start:.2f}s")

Pochopenie CFS CPU Kvót

Teraz sa pozrime na druhú polovicu rovnice: ako Kubernetes vynucuje CPU limity.

Kubernetes používa bandwidth control Linuxového Completely Fair Schedulera (CFS) na vynucovanie CPU limitov. Keď nastavíte CPU limit 1000m (jedno jadro), Kubernetes to preloží na CFS parametre:

• Perióda: 100ms (ako často sa kvóta resetuje)
• Kvóta: 100ms (koľko CPU času môže kontajner využiť za periódu)

Kritické je pochopiť, že CFS počíta CPU čas naprieč všetkými threadmi v cgroupe. Ak máte 4 thready, každý bežiaci 25ms v perióde, to je 100ms spotrebovaného CPU času—celá vaša kvóta—aj keď wall-clock čas bol len 25ms.

Tu to začína byť zložité s Pythonom. GIL znamená, že len jeden thread vykonáva Python kód naraz, ale CFS o GIL nevie. CFS vidí thready požadujúce CPU čas, byť naplánované a konzumovať cykly. Keď thread čaká na GIL, je v runnable stave, a keď sa naplánuje len aby zistil, že GIL je zamknutý, to plánovanie stále počíta do vašej kvóty.

Realita Python threadingu:

GIL (Global Interpreter Lock):
- Iba JEDEN thread vykonáva Python bytecode naraz
- Thready sa striedajú v držaní GILu
- Context switch každých 5ms (default)

Kubernetes CFS (Completely Fair Scheduler):
- CPU limit = kvóta za periódu (100ms default)
- 1000m = 100ms kvóta za 100ms periódu
- VŠETKY thready zdieľajú túto kvótu

Konflikt:
┌─────────────────────────────────────────────────────────────┐
│ 4 Python thready, 1000m limit                               │
│                                                             │
│ Thread 1: [====GIL====].........[====GIL====]...           │
│ Thread 2: ............[====GIL====].........[====]          │
│ Thread 3: Čaká na GIL                                       │
│ Thread 4: Čaká na GIL                                       │
│                                                             │
│ Ale CFS vidí: 4 thready × čas = prekročená kvóta           │
│ Výsledok: THROTTLED aj keď beží len 1 naraz!               │
└─────────────────────────────────────────────────────────────┘

Výsledok je scenár najhoršieho z oboch svetov: máte obmedzenia konkurencie GIL (len jeden thread beží Python kód naraz) kombinované s resource accountingom viacerých threadov (CFS počíta všetky).

Diagnostika Problému

Keď ste throttlovaní CFS, symptómy môžu byť mätúce. Váš monitoring ukazuje nízke využitie CPU—možno 25-30% na 4-jadrovom limite—ale vaša aplikácia je pomalá a neodpovedá. To preto, lebo throttling nastáva na úrovni kontajnera, a keď ste throttlovaní, ste throttlovaní, bez ohľadu na to koľko CPU ste reálne používali.

Tu je ako skontrolovať CFS throttling:

# Skontroluj throttling
cat /sys/fs/cgroup/cpu.stat

nr_periods 10000
nr_throttled 8000      # 80% throttled!
throttled_usec 450000000

# Napriek nízkemu CPU využitiu v top/htop
# GIL znamená že thready čakajú, ale CFS počíta ich CPU čas

Hodnota nr_throttled ukazuje koľko periód bol kontajner throttlovaný. V tomto príklade 80% všetkých plánovacích periód narazilo na CPU kvótu a bolo throttlovaných. throttled_usec ukazuje celkový čas, ktorý kontajner strávil throttlovaný—450 sekúnd v tomto prípade.

Zvnútra kontajnera môžete tiež skontrolovať tieto hodnoty:

# V cgroups v2 (moderné kernely)
cat /sys/fs/cgroup/cpu.stat | grep throttled

# V cgroups v1 (staršie systémy)
cat /sys/fs/cgroup/cpu/cpu.stat
cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us    # Vaša kvóta
cat /sys/fs/cgroup/cpu/cpu.cfs_period_us   # Perióda

Reálna Cena GIL + CFS

Dovoľte mi ilustrovať reálnymi číslami z produkčného incidentu. Tím bežal Flask aplikáciu s gunicornom nakonfigurovaným takto:

# Ich pôvodná gunicorn konfigurácia
workers = 1
threads = 8
worker_class = "gthread"

Ich Kubernetes zdroje:

resources:
  requests:
    cpu: "1"
  limits:
    cpu: "1"

Očakávali, že sa bude spracovávať 8 konkurentných requestov. Namiesto toho videli:

• 75% CFS throttling rate
• 200ms p99 latencia (mala byť 50ms)
• CPU využitie ukazujúce len 30% v metrikách

Matematika toho čo sa dialo:

1. Perióda: 100ms
2. Kvóta: 100ms (1 CPU jadro)
3. 8 threadov súťažiacich o GIL: Každý thread sa naplánuje, ale len jeden reálne beží Python
4. Overhead: Plánovanie threadov, získavanie GIL, context switche—všetko počíta ako CPU čas
5. Výsledok: 100ms kvóta vyčerpaná za ~30ms wall-clock času

Thready nerobili užitočnú prácu. Pálili CPU čas čakaním na GIL, boli naplánované len aby zistili že je zamknutý, krátko spinovali a znova spali.

Riešenia

1. Použi Procesy Namiesto Threadov

Najefektívnejšie riešenie je použiť viaceré worker procesy namiesto threadov. Každý Python proces má svoj vlastný GIL, takže môžu skutočne bežať paralelne. Kernel ich plánuje nezávisle a CFS accounting funguje podľa očakávania.

# gunicorn.conf.py

# Zle: Thready súťažia o GIL
# workers = 1
# threads = 4

# Dobre: Samostatné procesy, každý má vlastný GIL
workers = 4
threads = 1

# Alebo pre async workloady
worker_class = "uvicorn.workers.UvicornWorker"
workers = 4

S touto konfiguráciou:

• 4 samostatné procesy, každý so svojím vlastným Python interpretrom a GIL
• Každý proces môže plne využiť svoj podiel CPU
• CFS accounting zodpovedá skutočnému CPU využitiu

Kompromis je pamäť: každý proces načíta plný Python runtime a váš aplikačný kód. Pre typickú webovú aplikáciu to môže byť 100-300MB na worker. Plánujte memory limity zodpovedajúco.

2. Zosúlaď Workery s CPU Limitom

Nenastavujte viac workerov než máte CPU kvótu. Ak je váš limit 2 CPU, použite 2 workery. Viac vytvára kontenciou bez benefitu—rovnaká situácia ako thready s GIL, len na úrovni procesov.

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      containers:
        - name: app
          resources:
            requests:
              cpu: "2"
            limits:
              cpu: "2"
          env:
            # Workery = CPU limit
            - name: WEB_CONCURRENCY
              value: "2"
            # ALEBO použi downward API
            - name: CPU_LIMIT
              valueFrom:
                resourceFieldRef:
                  resource: limits.cpu

# gunicorn.conf.py
import os

cpu_limit = int(os.environ.get('CPU_LIMIT', 1))
workers = cpu_limit  # Zosúlaď workery s CPU limitom
threads = 1

Použitie Kubernetes Downward API na injektovanie CPU limitu ako environment premennej zabezpečí, že vaša aplikácia vždy škáluje správne so svojou alokáciou zdrojov. Keď zvýšite limit, aplikácia automaticky spustí viac workerov.

3. Async Namiesto Threadov

Pre I/O-bound workloady—čo popisuje väčšinu webových aplikácií, ktoré volajú databázy, API a iné služby—async/await je často najlepšia voľba. Jeden async worker zvládne tisíce konkurentných requestov pretože uvoľňuje GIL počas I/O čakaní a nikdy nepotrebuje viaceré thready na dosiahnutie konkurencie.

# Pre I/O-bound prácu použi async (žiadna GIL kontencia)
from fastapi import FastAPI
import asyncio
import httpx

app = FastAPI()

@app.get("/")
async def handler():
    async with httpx.AsyncClient() as client:
        # Concurrent I/O bez GIL problémov
        results = await asyncio.gather(
            client.get("http://service-a/"),
            client.get("http://service-b/"),
            client.get("http://service-c/"),
        )
    return {"results": [r.json() for r in results]}

# Spusti s:
# uvicorn main:app --workers 2  # Workery = CPU limit

Async model žiari, keď vaša aplikácia trávi väčšinu času čakaním na I/O. Jeden event loop dokáže žonglovať s tisíckami in-flight requestov, využívajúc minimálne CPU. Kombinované s viacerými worker procesmi (každý bežiaci svoj vlastný event loop), dostanete konkurenciu aj skutočný paralelizmus.

Avšak async nie je mágia. Ak máte CPU-intenzívne code paths—spracovanie obrázkov, komplexné výpočty, transformácia dát—tie zablokujú event loop a zhoršia výkon. Pre zmiešané workloady možno budete potrebovať offloadovať CPU-intenzívnu prácu do thread poolu alebo separátnych workerov.

# Miešanie async s CPU-bound prácou
import asyncio
from concurrent.futures import ProcessPoolExecutor

executor = ProcessPoolExecutor(max_workers=2)

async def process_image(image_data: bytes) -> bytes:
    # Spusti CPU-intenzívnu prácu v separátnom procese
    loop = asyncio.get_event_loop()
    result = await loop.run_in_executor(
        executor,
        cpu_intensive_image_processing,
        image_data
    )
    return result

Python 3.12+ a Budúcnosť GIL

Stojí za zmienku, že Python sa vyvíja. PEP 703 zaviedol voliteľný “free-threaded” build CPythonu 3.13+, ktorý môže bežať bez GIL. Je to experimentálne a opt-in, ale ukazuje to na budúcnosť, kde Python thready možno naozaj paralelizujú CPU-bound prácu.

K decembru 2024 nie je GIL-free mód odporúčaný pre produkciu. Mnohé C rozšírenia predpokladajú, že GIL existuje a nie sú thread-safe bez neho. Ale ak čítate toto v roku 2026 alebo neskôr, skontrolujte aktuálny stav PEP 703—možno už zmenil landscape Python threadingu.

Zatiaľ zostáva rada: použite procesy pre paralelizmus, async pre I/O konkurenciu, a zosúlaďte počet workerov s CPU limitom.

Monitoring GIL + CFS Problémov

Nastavte alerting na CFS throttling predtým, než sa stane problémom:

# Alert na Python GIL kontenciu
- alert: PythonHighThrottling
  expr: |
    rate(container_cpu_cfs_throttled_periods_total[5m]) /
    rate(container_cpu_cfs_periods_total[5m]) > 0.5
  for: 10m
  labels:
    severity: warning
  annotations:
    summary: "Container {{ $labels.container }} throttled >50%"

Throttling rate nad 10-15% si zaslúži investigáciu. Nad 50% definitívne necháte výkon na stole. Nulový throttling je ideálny, ale nie vždy dosiahnuteľný—nejaké burst použitie je normálne.

Tiež monitorujte vzťah medzi CPU využitím a throttlingom:

# Nízke CPU ale vysoký throttling = GIL/threading problém
- alert: PossibleGILContention
  expr: |
    rate(container_cpu_cfs_throttled_periods_total[5m]) /
    rate(container_cpu_cfs_periods_total[5m]) > 0.3
    AND
    rate(container_cpu_usage_seconds_total[5m]) < 0.5
  for: 10m
  labels:
    severity: warning
  annotations:
    summary: "Container {{ $labels.container }} throttled ale nízke CPU - skontroluj GIL"

Ak ste throttlovaní ale vaše CPU využitie je nízke, to je klasický znak GIL + CFS interakcie. Čas preveriť vašu worker/thread konfiguráciu.

Checklist Najlepších Praktík

## Python + Kubernetes CPU

### Konfigurácia
- [ ] Použi workery, nie thready pre paralelizmus
- [ ] Zosúlaď počet workerov s CPU limitom
- [ ] Zváž async pre I/O-bound workloady
- [ ] Nastav memory limity aby pojali viaceré workery

### Monitoring
- [ ] Sleduj CFS throttling rate
- [ ] Alert na throttling > 25%
- [ ] Koreluj throttling s CPU využitím
- [ ] Profiluj s py-spy alebo cProfile na nájdenie CPU-intenzívnych code paths

### Testovanie
- [ ] Load testuj s produkčnou konkurenciou
- [ ] Over že nie je throttling pod normálnou záťažou
- [ ] Zabezpeč graceful degradáciu pod preťažením

Záver

Interakcia medzi Python GIL a Kubernetes CFS schedulerom vytvára pascu, do ktorej je ľahké spadnúť a je mätúca na diagnostiku. Viaceré thready v Pythone vám nedávajú paralelizmus, ale dávajú vám zvýšený CFS accounting overhead. Výsledkom je throttling napriek nízkemu skutočnému CPU využitiu.

Riešenie je priamočiare keď pochopíte problém:

1. GIL znamená jeden thread naraz ale CFS počíta všetky thready
2. Použi procesy namiesto threadov pre paralelizmus
3. Zosúlaď workery s CPU limitom presne—nie viac, nie menej
4. Zváž async pre I/O-bound workloady kde thready nie sú potrebné

Skontrolujte vaše throttling štatistiky pomocou cat /sys/fs/cgroup/cpu.stat. Ak vidíte vysoké nr_throttled čísla s nízkym CPU využitím, našli ste GIL + CFS pascu. Opravte konfiguráciu workerov a sledujte ako sa zlepší throttling aj latencia.

Súvisiace články

• K8s CPU Throttling Pitva - CPU throttling hlboký ponor
• Go GOMAXPROCS v Kontajneroch - Container CPU tuning pre Go aplikácie
• JVM Native Memory v Kubernetes - Java memory úvahy v kontajneroch