.NET Conf

Optymalizacja aplikacji .NET na systemach Linux to wyzwanie obejmujące zarządzanie pamięcią, Garbage Collection, konteneryzację i kontrolę zasobów. W przeszłości aplikacje .NET na Linux były znacznie mniej wydajne niż na Windows – szczególnie podczas operacji na stringach, alokacji pamięci i zarządzania GC w środowiskach kontenerowych. Nowoczesne wersje .NET, zwłaszcza 6, 7 i 8, wprowadziły zaawansowane mechanizmy memory management, dynamiczne dostosowywanie limitów oraz lepszą integrację z Docker i Kubernetes. Kluczowe aspekty optymalizacyjne to odpowiedni wybór GC (Server vs Workstation), rozwiązanie problemów z file cache interpretowanym przez cgroups na Linux, a także korzystanie z nowych API, takich jak RefreshMemoryLimit(), do zarządzania zasobami w chmurze.

Spis treści [odkryj]

Architektura i mechanizmy garbage collection w środowisku Linux

Specyfika Garbage Collection w .NET na Linux wynika z innego podejścia do zarządzania pamięcią niż na Windows. Główną trudnością jest nieprawidłowa interpretacja limitów pamięci przez GC – w Linux file cache jest wliczany do całkowitego limitu pamięci kontenera przez cgroups, w przeciwieństwie do Windows i Job Objects.

Przy intensywnym dostępie do dysku, file cache powoduje, że memory limit kontenera jest wypełniony do 100%, nawet gdy realnej pamięci roboczej jest jeszcze pod dostatkiem. To zmusza GC do agresywnego działania i znacząco obniża wydajność aplikacji .NET.

Pojęcie High Memory Load Threshold nabiera tu decydującego znaczenia – GC przechodzi w tryb agresywny już przy 90% wykorzystania pamięci, a w kontenerach z dużym file cache ten bufor bezpieczeństwa jest często zbyt mały.

Różnice między Server a Workstation GC są bardzo istotne na Linux – Server GC generuje osobny heap i wątek GC dla każdego rdzenia, co mocno podnosi użycie pamięci w maszynach wielordzeniowych. Ustawienie Workstation GC (<ServerGarbageCollection>false</ServerGarbageCollection> w csproj) często radykalnie ogranicza zużycie RAM przy akceptowalnej wydajności.

Konfiguracja i optymalizacja kontenerów Docker dla aplikacji .NET

Lepsze zrozumienie interakcji .NET runtime z cgroups i zasobami systemowymi pozwala zoptymalizować aplikacje uruchamiane w Docker.

  • od .NET Core 3.0 – heap GC ustawiany jest na największą z wartości: 20MB lub 75% limitu cgroup,
  • minimalny segment heap GC to 16MB, zapobiega nadmiernej fragmentacji pamięci,
  • cgroups v1 oraz v2 – różnią się zarządzaniem ograniczeniami i hierarchią,
  • limity przypisuje się przez -m/--memory (twardy limit) i --memory-reservation (miękki limit),
  • parametr --memory-swap – reguluje dostęp do swap; wartości większe od limitu włączają swap, 0 ignoruje swap, -1 daje nieograniczony dostęp, wartość równa limitowi efektywnie wyłącza swap.

Właściwe ustawienie środowiskowych zmiennych, takich jak DOTNET_GCHeapHardLimit i DOTNET_GCHeapHardLimitPercent, jest kluczowe, by GC respektował limity cgroup (na AWS często ustawiane automatycznie, w innych środowiskach warto zadbać o to manualnie).

Dla monitorowania zaleca się korzystać z narzędzi diagnostycznych docker inspect lub odczytu plików cgroup, np. /sys/fs/cgroup/memory/ (v1) i memory.limit_in_bytes, memory.usage_in_bytes bądź /sys/fs/cgroup/ (v2) wraz z memory.max oraz memory.current.

Zarządzanie limitami zasobów i memory management

Zaawansowane zarządzanie zasobami aplikacji .NET na Linux wymaga precyzyjnej konfiguracji GC, thread poola, alokacji pamięci i dynamicznych limitów.

  • RefreshMemoryLimit() – pozwala GC dynamicznie poznać i wykorzystać nowy limit pamięci bez restartu,
  • na platformach 32-bitowych nowy limit heap działa, gdy był uprzednio ustawiony,
  • przy agresywnym skalowaniu zalecane jest użycie GC.Collect(2, GCCollectionMode.Aggressive) przed odświeżeniem limitów.

Kiedy chcesz precyzyjnie zarządzać różnymi typami heap (SOH, LOH, POH), możesz określić procentowe limity w odpowiednich zmiennych środowiskowych, pamiętając o konieczności jednoczesnego ustawienia dla wszystkich. Jeśli jednak używasz limitów bezwzględnych, ustawienia procentowe będą ignorowane.

High Memory Percent to domyślnie 90%, ale jego optymalne ustawienie zależy od charakterystyki aplikacji. Można konfigurować ten parametr przez DOTNET_GCHighMemPercent i System.GC.HighMemoryPercent, optymalizując reakcje GC na zużycie pamięci.

Analiza problemów wydajnościowych Linux versus Windows

Kluczowe różnice wydajności .NET między systemami Linux a Windows to duże wyzwanie, zwłaszcza w kontekście mikrobenchmarków i operacji stringowych.

  • odmienny model zarządzania pamięcią,
  • różne realizacje file cache,
  • warianty synchronizacji i bibliotek systemowych,
  • Transparent Huge Pages w Linux zwiększają opóźnienia GC – należy je wyłączyć przez echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled oraz echo never > /sys/kernel/mm/redhat_transparent_hugepage/defrag.

Głębokie pauzy GC mogą wynikać z zablokowań kernel space podczas operacji I/O. Warto skrócić interwał page flushing (z 30 do 5s) oraz zoptymalizować CPU governor i scheduler systemu.

Optymalizacje dla systemów wielordzeniowych i architektur ARM

Nowoczesne platformy ARM, jak Ampere, pozwalają wykorzystywać nawet do 80 rdzeni, co daje ogromny potencjał do optymalizacji.

  • od .NET 7 radykalnie poprawiono skalowalność przez partycjonowanie thread poola i memory poola dla socketów;
  • na 80-rdzeniowych maszynach Ampere: wzrost wydajności RPS dla platformy plaintext o 514% i JSON o 311%;
  • partycjonowanie redukuje konkurencyjność o zasoby i podnosi ogólną skalowalność procesów.

Zaawansowana konfiguracja affinity dla wątków Garbage Collector poprzez System.GC.HeapAffinitizeRanges pozwala przypisać je do konkretnych rdzeni – poprawiając lokalność i wydajność.

Optymalizacje ARM obejmują tuning JIT oraz wykorzystanie SIMD. Benchmarki dowodzą, że aplikacje .NET Native AOT na Ampere Linux potrafią przewyższać managed mode, szczególnie w lekkich, intensywnie powtarzalnych operacjach.

Native AOT jako alternatywa optymalizacyjna

Native Ahead-of-Time (AOT) to nowatorskie podejście w .NET na Linux – pozwala ominąć overhead JIT, znacząco skrócić czas startu i zredukować zapotrzebowanie na RAM. Aplikacje Native AOT mogą wykorzystywać nawet 1,5-2x mniej pamięci niż managed (np. 56 MB AOT vs 126 MB managed w Stage1).

Najważniejsze obserwacje:

  • przy dużej liczbie powtórzeń różnice w wydajności marginalizują się,
  • największe zyski z AOT uzyskuje się w krótkich, intensywnych zadaniach,
  • bardzo szybki start czyni AOT idealnym dla serverless i auto-scaling.

Ograniczenia: większy rozmiar obrazów Docker, dłuższy czas kompilacji i ograniczone wsparcie dynamicznych funkcji jak reflection.

Nowoczesne funkcje i możliwości .NET 6–8

Aktualne wersje .NET radykalnie zmieniają możliwości optymalizacji kontenerów oraz zarządzania pamięcią na Linux.

  • .NET 8 dynamicznie reaguje na zmieniające się limity pamięci – szczególnie przydatne w środowiskach chmurowych i podczas auto-skalowania;
  • RefreshMemoryLimit() – GC poznaje nowy limit pamięci bez przerywania działania aplikacji;
  • na platformach 32-bitowych nowy hard limit jest możliwy tylko przy wcześniej ustawionym limicie;
  • w .NET 7 dla Windows wdrożono managed IO pool, co pozwoliło osiągnąć 27% wzrostu RPS przy operacjach JSON i zmniejszyć zużycie CPU nawet o 10% przez uniknięcie zbędnych wyjątków.

Praktyczne wskazówki konfiguracyjne i strategie wdrożeniowe

Aby systematycznie wdrożyć optymalizację .NET na Linux, warto kierować się praktycznymi zasadami:

  • wybór Server lub Workstation GC – dostosowany do liczby rdzeni i specyfiki aplikacji;
  • konfiguracja kontenerów Docker – ustawienie -m i --memory-reservation oraz DOTNET_GCHeapHardLimit dla kontroli pamięci;
  • ograniczenie lub wyłączenie swap (przez --memory-swap) – poprawia przewidywalność opóźnień na hostach z dużą ilością RAM;
  • ciągły monitoring – zarówno statystyk GC (GC.GetGCMemoryInfo()), jak i całościowego zużycia pamięci (working set, RSS, statystyki cgroup, narzędzia: Prometheus, Grafana);
  • regularne testowanie i profilowanie wydajności – narzędzia takie jak NBomber, Apache Bench, dotnet-counters, dotnet-trace czy APM.

Zaawansowane techniki optymalizacji i rozwiązywanie problemów

Eksperci rekomendują poniższe zaawansowane techniki:

  • tuning parametrów kernela Linux – m.in. swappiness (optymalnie 10–20) i wyłączenie Transparent Huge Pages;
  • zaawansowaną konfigurację GC – np. DOTNET_GCSegmentSize (rozmiar segmentu), DOTNET_GCLargeObjectHeapCompactionMode (kompaktowanie LOH);
  • troubleshooting – logowanie GC (DOTNET_GCStress), memory dump, profilowanie CPU przy pauzach GC i długoterminowe monitorowanie sieci/baz danych.

Wnioski i przyszłe kierunki rozwoju

Optymalizacja aplikacji .NET na Linux wymaga całościowego podejścia: odpowiedniej konfiguracji GC, przemyślanych limitów zasobów oraz ciągłego monitoringu i udoskonalania ustawień. Dzięki nowym możliwościom .NET oraz dynamicznemu rozwojowi narzędzi i społeczności, różnice wydajności między Linux a Windows są coraz mniejsze, a przyszłość .NET na Linux to automatyczne, adaptacyjne optymalizacje zarządzane przez AI, pełna integracja z ekosystemem chmurowym i coraz dojrzalsze narzędzia diagnostyczne.

Ekosystem narzędzi do optymalizacji .NET na Linux szybko się rozwija, oferując coraz lepsze profile, monitoring i praktyki wdrożeniowe. Dzięki społeczności open source, profesjonalistom coraz łatwiej skutecznie optymalizować i monitorować nowoczesne aplikacje .NET w środowiskach produkcyjnych.