Profilowanie pamięci w Go pomaga radzić sobie z nagłymi skokami ruchu. Praktyczny przewodnik po pprof, jak znaleźć gorące punkty alokacji w JSON, skanowaniu DB i middleware.
„Skok pamięci” w produkcji rzadko oznacza jedną prostą liczbę. Możesz zobaczyć RSS (pamięć procesu) szybko rosnące, podczas gdy sterta Go ledwie się porusza, albo sterta rośnie i spada w ostrych falach, gdy GC działa. Jednocześnie opóźnienia często się pogarszają, bo runtime więcej czasu poświęca na sprzątanie.
Typowe wzorce w metrykach:
Skoki ruchu powiększają alokacje na zapytanie, bo „małe” marnotrawstwo skalowane liniowo z obciążeniem robi różnicę. Jeśli jedno żądanie alokuje dodatkowe 50 KB (tymczasowe bufory JSON, obiekty na skan wiersza, dane kontekstu middleware), to przy 2000 żądań na sekundę dokarmiasz alokator około 100 MB na sekundę. Go potrafi wiele znieść, ale GC wciąż musi prześledzić i zwolnić te krótkotrwałe obiekty. Gdy alokacja przewyższa sprzątanie, cel sterty rośnie, RSS podąża za nim i możesz trafić w limity pamięci.
Objawy są znajome: OOM od orkiestratora, nagłe skoki latencji, więcej czasu spędzanego w GC i serwis, który wygląda na „zajęty”, nawet gdy CPU nie jest wykorzystane. Możesz też dostać thrash GC: serwis działa dalej, ale ciągle alokuje i kolekcjonuje, więc przepustowość spada właśnie wtedy, gdy najbardziej jej potrzeba.
pprof pomaga szybko odpowiedzieć na jedno pytanie: które ścieżki kodu alokują najwięcej i czy te alokacje są konieczne? Profil sterty pokazuje, co jest zatrzymane teraz. Widoki skupione na alokacjach (np. alloc_space) pokazują, co jest tworzone i odrzucane.
Czego pprof nie zrobi: nie wyjaśni każdego bajta RSS. RSS zawiera więcej niż sterta Go (stacki, metadane runtime, mapowania OS, alokacje cgo, fragmentację). pprof najlepiej wskazuje gorące miejsca alokacji w kodzie Go, a nie daje dokładnej sumy pamięci kontenera.
pprof najłatwiej użyć jako endpointów HTTP, ale te endpointy mogą ujawniać dużo o twojej usłudze. Traktuj je jak funkcję administracyjną, nie publiczne API.
W Go najprostsze ustawienie to uruchomić pprof na osobnym serwerze administracyjnym. To trzyma trasy profilowania z dala od głównego routera i middleware.
package main
import (
"log"
"net/http"
_ "net/http/pprof"
)
func main() {
go func() {
// Admin only: bind to localhost
log.Println(http.ListenAndServe("127.0.0.1:6060", nil))
}()
// Your main server starts here...
// http.ListenAndServe(":8080", appHandler)
select {}
}
Jeśli nie możesz otworzyć drugiego portu, możesz zamontować trasy pprof w głównym serwerze, ale łatwiej je przez przypadek ujawnić. Osobny port admina to bezpieczny domyślny wybór.
Zacznij od kontroli trudnych do pomylenia. Bindując do localhost, endpointy nie są osiągalne z internetu, chyba że ktoś dodatkowo wystawi ten port.
Szybka lista kontrolna:
Utrzymaj zmianę małą: dodaj pprof, wypchnij ją i potwierdź, że jest osiągalna tylko stamtąd, skąd oczekujesz. Jeśli masz staging, przetestuj tam najpierw, symulując obciążenie i przechwytując profil sterty i allocs.
Dla produkcji wdrażaj stopniowo (jedna instancja lub mały wycinek ruchu). Jeśli pprof jest źle skonfigurowany, zasięg szkód pozostanie mały, dopóki naprawiasz.
Podczas skoku pojedynczy snapshot rzadko wystarcza. Zrób małą linię czasu: kilka minut przed skokiem (baseline), w trakcie skoku (impact) i kilka minut po (recovery). Łatwiej wtedy oddzielić rzeczywiste zmiany alokacji od normalnego rozruchu.
Jeśli potrafisz odtworzyć skok przy kontrolowanym obciążeniu, dopasuj go jak najbardziej do produkcji: miks żądań, rozmiary payloadów i współbieżność. Skok z małych żądań zachowuje się inaczej niż skok z dużymi odpowiedziami JSON.
Weź zarówno profil sterty, jak i profil skupiony na alokacjach. Odpowiadają na różne pytania:
Praktyczny wzorzec przechwytywania: złap jeden profil sterty, potem profil alokacji, potem powtórz 30–60 sekund później. Dwa punkty w trakcie skoku pomagają zobaczyć, czy podejrzana ścieżka jest stabilna, czy przyspiesza.
# examples: adjust host/port and timing to your setup
curl -o heap_during.pprof "http://127.0.0.1:6060/debug/pprof/heap"
curl -o allocs_30s.pprof "http://127.0.0.1:6060/debug/pprof/allocs?seconds=30"
Wraz z plikami pprof zapisz kilka statystyk runtime, żeby wyjaśnić, co robił GC w tym samym czasie. Rozmiar sterty, liczba GC i czas pauz zazwyczaj wystarczą. Nawet krótka linijka logu przy każdym zrzucie pomaga powiązać „alokacje wzrosły” z „GC zaczął działać non-stop”.
Prowadź notatki incydentu: wersja builda (commit/tag), wersja Go, ważne flagi, zmiany konfiguracji i jaki ruch się działy (endpointy, tenanty, rozmiary payloadów). Te szczegóły często mają znaczenie, gdy porównujesz profile i odkrywasz, że miks żądań się zmienił.
Profil sterty odpowiada na różne pytania w zależności od widoku.
Inuse space pokazuje, co jest nadal w pamięci w momencie zrzutu. Użyj go do wykrywania wycieków, długożyjących cache'ów lub przypadków, gdy żądania zostawiają obiekty.
Alloc space (całkowite alokacje) pokazuje, co było alokowane w czasie, nawet jeśli zostało szybko zwolnione. Użyj go, gdy skoki powodują dużo pracy GC, skoki latencji lub OOM-y z churnu.
Próbkowanie ma znaczenie. Go nie zapisuje każdej alokacji. Próbkuje alokacje (sterowane przez runtime.MemProfileRate), więc małe, częste alokacje mogą być niedostatecznie reprezentowane, a liczby są estymacjami. Największe winowajczynie i tak zwykle się wyróżniają, szczególnie w warunkach skokowych. Szukaj trendów i głównych kontrybutorów, nie idealnego rozliczenia.
Najbardziej użyteczne widoki pprof:
Diffy są praktyczne. Porównaj profil baseline (normalny ruch) z profilem ze skoku, by uwypuklić, co się zmieniło, zamiast gonić za szumem tła.
Zwaliduj ustalenia małą zmianą przed dużym refaktorem:
sync.Pool) w gorącej ścieżceJeśli liczby ruszają we właściwą stronę, znalazłeś rzeczywistą przyczynę, nie tylko przerażający raport.
Podczas skoków praca związana z JSON może stać się dużym rachunkiem pamięciowym, bo odbywa się przy każdym żądaniu. Gorące miejsca JSON często objawiają się wieloma małymi alokacjami, które mocniej obciążają GC.
Jeśli widok sterty lub alokacji wskazuje encoding/json, przyjrzyj się temu, co do niego podajesz. Wzorce, które zwykle zwiększają alokacje:
map[string]any (lub []any) dla odpowiedzi zamiast typowanych strukturjson.MarshalIndent w produkcjifmt.Sprintf, konkatenacja) przed marshalingiem[]byte na string (lub odwrotnie) tylko po to, by dopasować APIjson.Marshal zawsze alokuje nowy []byte dla całego wyjścia. json.NewEncoder(w).Encode(v) zwykle unika tego jednego dużego bufora, bo zapisuje do io.Writer, ale nadal może alokować wewnętrznie, szczególnie jeśli v pełne jest any, map lub struktur z wieloma wskaźnikami.
Zacznij od typowanych struktur dla kształtu odpowiedzi. Zmniejszają one pracę refleksji i unikają boxingowania pól do interface{}.
Potem usuń zbędne tymczasowe obiekty na zapytanie: reużyj bytes.Buffer przez sync.Pool (ostrożnie), nie wstawiaj indentacji w produkcji i nie re-marshaluj tylko dla logów.
Małe eksperymenty potwierdzające, że to JSON jest winny:
map[string]any strukturą dla jednego gorącego endpointu i porównaj profileMarshal na Encoder, zapisujący bezpośrednio do responseMarshalIndent lub formatowanie debugowe i re-profiluj pod tym samym obciążeniemGdy pamięć skacze podczas obciążenia, odczyty z bazy często są niespodzianką. Łatwo skupić się na czasie wykonania SQL, ale krok skanowania może alokować dużo na wiersz, szczególnie gdy skanujesz do elastycznych typów.
Typowi winowajcy:
interface{} (lub map[string]any) i pozwalanie driverowi decydować o typach[]byte na string dla każdego polasql.NullString, sql.NullInt64) w dużych zestawach wynikówJeden wzorzec, który potajemnie pali pamięć, to skanowanie danych wiersza do zmiennych tymczasowych, a potem kopiowanie do właściwej struktury (albo budowanie mapy na wiersz). Jeśli możesz skanować bezpośrednio do struktury z konkretnymi polami, unikasz dodatkowych alokacji i kontroli typów.
Rozmiar partii i paginacja zmieniają „kształt” pamięci. Pobieranie 10 000 wierszy do slice alokuje pamięć na wzrost slice i każdy wiersz, wszystko naraz. Jeśli handler potrzebuje tylko strony, wymuś stronicowanie w zapytaniu i utrzymuj rozmiar strony stabilny. Jeśli musisz przetworzyć dużo wierszy, streamuj je i agreguj małe podsumowania zamiast przechowywać każdy wiersz.
Duże pola tekstowe wymagają uwagi. Wiele driverów zwraca tekst jako []byte. Konwersja tego do string kopiuje dane, więc robienie tego dla każdego wiersza może eksplodować alokacje. Jeśli wartość jest potrzebna tylko czasami, opóźnij konwersję lub skanuj mniej kolumn dla danego endpointu.
Aby potwierdzić, czy driver czy twój kod robi większość alokacji, sprawdź, co dominuje w profilach:
database/sql lub drivera, zmniejsz liczbę wierszy i kolumn najpierw, potem rozważ opcje specyficzne dla driveraPrzykład: endpoint „list orders” skanuje SELECT * do []map[string]any. Podczas skoku każde żądanie buduje tysiące małych map i stringów. Zmiana zapytania na wybieranie tylko potrzebnych kolumn i skanowanie do []Order{ID int64, Status string, TotalCents int64} często natychmiast obniża alokacje. Ta sama zasada działa, jeśli profilujesz wygenerowany backend z AppMaster: gorący punkt zwykle leży w tym, jak kształtujesz i skanujesz dane wynikowe, a nie w samej bazie.
Middleware wydaje się tanie, bo to „tylko wrapper”, ale działa przy każdym żądaniu. Podczas skoku małe alokacje na żądanie sumują się i pokazują jako rosnące tempo alokacji.
Middleware logujące to częste źródło: formatowanie stringów, budowanie map pól lub kopiowanie nagłówków dla ładniejszego outputu. Helpery generujące request ID mogą alokować przy każdym żądaniu, konwertując ID na string i przyczepiając go do kontekstu. Nawet context.WithValue może alokować, jeśli na każde żądanie zapisujesz nowe obiekty (lub nowe stringi).
Kompresja i obsługa ciała to kolejny częsty winowajca. Jeśli middleware czyta całe body, by „zerknąć” lub zweryfikować, możesz mieć duży bufor na żądanie. Middleware gzip może alokować dużo, jeśli tworzy nowych readerów i writerów każdorazowo zamiast reużywać bufory.
Warstwy auth i sesji są podobne. Jeśli każde żądanie parsuje tokeny, dekoduje base64 ciasteczka lub ładuje blob sesji do świeżych struktur, dostajesz stały churn, nawet gdy praca handlera jest lekka.
Tracing i metryki mogą alokować więcej, niż się spodziewasz, gdy etykiety są budowane dynamicznie. Konkatenowanie nazw tras, user-agentów lub identyfikatorów tenantów w nowe stringi na żądanie to klasyczny ukryty koszt.
Wzorce, które często pokazują się jako „śmierć przez tysiąc cięć”:
fmt.Sprintf i nowe map[string]any na żądanieAby odizolować koszt middleware, porównaj dwa profile: jeden z pełnym łańcuchem włączonym i jeden z middleware tymczasowo wyłączonym lub zastąpionym no-opem. Prosty test to endpoint health, który powinien być niemal bez alokacji. Jeśli /health alokuje dużo podczas skoku, handler nie jest problemem.
Jeśli budujesz backendy Go generowane przez AppMaster, ta sama zasada ma zastosowanie: trzymaj funkcje przekrojowe (logowanie, auth, tracing) mierzalne i traktuj alokacje na żądanie jako budżet, który możesz audytować.
Mając widoki heap i allocs z pprof, priorytetyzuj zmiany, które zmniejszają alokacje na zapytanie. Cel nie polega na genialnych sztuczkach, a na sprawieniu, by gorąca ścieżka tworzyła mniej krótkotrwałych obiektów pod obciążeniem.
Jeśli rozmiary są przewidywalne, prealokuj. Jeśli endpoint zwykle zwraca około 200 elementów, stwórz slice z pojemnością 200, żeby nie rósł i nie kopiował się kilka razy.
Unikaj budowania stringów w gorących ścieżkach. fmt.Sprintf jest wygodny, ale często alokuje. Dla logów preferuj pola strukturalne i reużywaj małego bufora tam, gdzie ma to sens.
Jeśli generujesz duże odpowiedzi JSON, rozważ ich strumieniowanie zamiast budowania jednego ogromnego []byte lub string w pamięci. Typowy wzorzec skoku: przychodzi żądanie, czytasz duże body, budujesz dużą odpowiedź, pamięć skacze, aż GC nadgoni.
Szybkie zmiany, które zwykle widać wyraźnie w profilach przed/po:
sync.Pool dla powtarzalnych, jednorodnych obiektów (bufory, encodery) i zawsze je resetuj/przywracajsync.Pool pomaga, gdy wielokrotnie alokujesz ten sam typ, jak bytes.Buffer na żądanie. Może też zaszkodzić, jeśli poolujesz obiekty o nieprzewidywalnych rozmiarach lub zapominasz je zresetować — wtedy duże tablice pozostają żywe.
Mierz przed i po użyciu tego samego obciążenia:
Jeśli tworzysz backendy Go wygenerowane przez AppMaster, te poprawki nadal mają zastosowanie do kodu wokół handlerów, integracji i middleware. Tam zwykle chowają się alokacje wywołane skokami.
Najszybszy sposób na zmarnowanie dnia to optymalizowanie niewłaściwej rzeczy. Jeśli serwis jest wolny, zacznij od CPU. Jeśli jest zabijany przez OOM, zacznij od sterty. Jeśli przetrwa, ale GC działa bez przerwy, patrz na tempo alokacji i zachowanie GC.
Inną pułapką jest patrzenie tylko na „top” i myślenie, że to koniec. „Top” ukrywa kontekst. Zawsze sprawdzaj stosy wywołań (lub flame graph), żeby zobaczyć, kto wywołał alokator. Poprawka często leży o jedną lub dwie ramki wyżej niż gorąca funkcja.
Obserwuj też mylenie inuse z churnem. Żądanie może alokować 5 MB krótkotrwałych obiektów, wywołać dodatkowy GC i skończyć z tylko 200 KB inuse. Patrząc wyłącznie na inuse, przegapisz churn. Patrząc tylko na całkowite alokacje, możesz optymalizować coś, co nigdy nie pozostaje resident i nie stanowi ryzyka OOM.
Szybkie sanity checki przed zmianą kodu:
encoding/json często jest objawem)Nierealistyczne testy obciążeniowe powodują fałszywe alarmy. Jeśli twój test wysyła małe ciała JSON, a produkcja wysyła 200 KB payloady, będziesz optymalizować złą ścieżkę. Jeśli twój test zwraca jeden wiersz bazy, nigdy nie zobaczysz zachowania skanowania przy 500 wierszach.
Nie gonić szumu. Jeśli funkcja pojawia się tylko w profilu ze skoku (nie w baseline), to mocny trop. Jeśli pojawia się w obu na tym samym poziomie, może to być normalna praca tła.
W poniedziałek rano wychodzi promocja i twój API Go zaczyna dostawać 8x normalnego ruchu. Pierwszy objaw to nie crash. RSS rośnie, GC robi się bardziej aktywny, a p95 latencji skacze. Najgorętszy endpoint to GET /api/orders, bo aplikacja mobilna odświeża go przy każdym otwarciu ekranu.
Robisz dwa snapshoty: jeden z cichego momentu (baseline) i jeden w trakcie skoku. Zrób ten sam typ profilu sterty w obu przypadkach, by porównanie było uczciwe.
Przebieg działań, który działa w praktyce:
W tym przypadku profil ze skoku pokazał, że większość nowych alokacji pochodziła z kodu JSON. Handler budował map[string]any dla wierszy, a potem wywoływał json.Marshal na slice map. Każde żądanie tworzyło dużo krótkotrwałych stringów i wartości interface{}. Najmniejsza bezpieczna poprawka to przestać budować mapy. Skanuj wiersze bazy bezpośrednio do typowanej struktury i koduj tę slice. Nic więcej się nie zmieniło: te same pola, ten sam kształt odpowiedzi, te same statusy. Po wdrożeniu zmiany na jednej instancji alokacje na ścieżce JSON spadły, czas GC zmalał, a latencja się ustabilizowała.
Dopiero potem wdrażasz stopniowo, obserwując pamięć, GC i wskaźniki błędów. Jeśli korzystasz z platformy no-code jak AppMaster, to przypomnienie, by trzymać modele odpowiedzi typowane i spójne — to pomaga unikać ukrytych kosztów alokacji.
Gdy ustabilizujesz skok, spraw, by następny był nudny. Traktuj profilowanie jak powtarzalne ćwiczenie.
Napisz krótki runbook dla zespołu, który można uruchomić, gdy są zmęczeni. Powinien mówić, co zbierać, kiedy to robić i jak porównać do znanego dobrego baseline. Bądź praktyczny: dokładne komendy, gdzie trafiają profile i co oznacza „normalnie” dla twoich top allocatorów.
Dodaj lekkie monitorowanie presji alokacji zanim uderzy OOM: rozmiar sterty, cykle GC na sekundę i bajty alokowane na żądanie. Wykrywanie „alokacje na żądanie w górę o 30% tydzień do tygodnia” często jest użyteczniejsze niż czekanie na twardy alarm pamięci.
Przenieś kontrole wcześniej: krótki test obciążeniowy w CI na reprezentatywnym endpointzie. Małe zmiany w odpowiedzi mogą podwoić alokacje, jeśli wywołają dodatkowe kopie, i lepiej to znaleźć zanim zrobi to produkcja.
Jeśli prowadzisz wygenerowany backend Go, eksportuj źródło i profiluj je tak samo. Wygenerowany kod to nadal kod Go, a pprof wskaże realne funkcje i linie.
Jeśli wymagania często się zmieniają, AppMaster (appmaster.io) może być praktycznym sposobem na przebudowę i regenerację czystych backendów Go w miarę rozwoju aplikacji, a potem profilowanie wyeksportowanego kodu pod realistycznym obciążeniem przed wdrożeniem.
Why does a sudden traffic spike cause memory to jump even if my code didn’t change?Skok zwykle zwiększa tempo alokacji bardziej, niż się spodziewasz. Nawet drobne tymczasowe obiekty na zapytanie mnożą się liniowo z RPS, co zmusza GC do częstszego działania i może podnieść RSS, nawet jeśli żywa sterta nie jest duża.
Why does RSS grow while the Go heap looks stable?Metryki sterty pokazują pamięć zarządzaną przez Go, ale RSS zawiera więcej: stosy goroutine, metadane runtime, mapowania OS, fragmentację i wszelkie alokacje poza stertą (w tym niektóre użycia cgo). Podczas skoków to normalne, że RSS i sterta poruszają się inaczej — użyj pprof, by wskazać gorące miejsca alokacji, zamiast próbować „dopasować” RSS dokładnie.
Should I look at heap or alloc profiles first during a spike?Zacznij od profilu sterty, gdy podejrzewasz retencję (coś zostaje w pamięci), a od profilu skupionego na alokacjach (np. allocs/alloc_space), gdy podejrzewasz churn (dużo krótkotrwałych obiektów). Podczas skoków ruchu churn często jest głównym problemem, bo napędza CPU GC i ogonowe opóźnienia.
What’s the safest way to expose pprof in production?Najprostsze i najbezpieczniejsze ustawienie to uruchomić pprof na osobnym serwerze admina związanym z 127.0.0.1 i udostępniać go tylko przez dostęp wewnętrzny. Traktuj pprof jak interfejs administracyjny — ujawnia wewnętrzne szczegóły serwisu.
How many profiles should I capture, and when?Zrób krótki timeline: jeden profil kilka minut przed skokiem (baseline), jeden w trakcie skoku (impact) i jeden po (recovery). To ułatwia rozróżnienie rzeczywistych zmian alokacji od normalnej aktywności rozruchowej.
What’s the difference between inuse and alloc_space in pprof?Użyj inuse, by znaleźć to, co faktycznie jest zatrzymane w chwili zrzutu, i alloc_space (lub alloc_objects), by znaleźć to, co jest intensywnie tworzone. Częsty błąd to patrzenie tylko na inuse i przeoczenie churnu, który powoduje thrash GC.
What are the quickest ways to cut JSON-related allocations?Gdy encoding/json dominuje w alokacjach, zwykle to kształt danych jest winny, nie biblioteka sama w sobie. Zastąpienie map[string]any typowanymi strukturami, unikanie json.MarshalIndent i nie budowanie JSON-a przez tymczasowe stringi często natychmiast zmniejsza alokacje.
Why can database query scanning blow up memory during spikes?Skanowanie wierszy do elastycznych typów jak interface{} czy map[string]any, konwertowanie []byte na string dla wielu pól i pobieranie zbyt wielu wierszy/kolumn może alokować dużo na zapytanie. Wybieraj tylko potrzebne kolumny, stronicuj wyniki i skanuj bezpośrednio do konkretnych pól struktury — to częste, skuteczne poprawki.
What middleware patterns commonly cause “death by a thousand cuts” allocations?Middleware działa przy każdym żądaniu, więc małe alokacje pod obciążeniem rosną szybko. Tworzenie nowych stringów do logów, generowanie wysokorozróżnialnych etykiet do śledzenia, generowanie ID żądania, tworzenie gzip readerów/writerów na żądanie i zapisywanie nowych obiektów w context mogą się sumować do stałego churnu alokacji.
Can I use this pprof workflow on Go backends generated by AppMaster?Tak — ta metoda profilowania działa dla dowolnego kodu Go, wygenerowanego lub pisanego ręcznie. Jeśli wyeksportujesz wygenerowany backend (AppMaster), możesz uruchomić pprof, znaleźć ścieżki alokacji i dostosować modele, handlery i logikę przekrojową, by zmniejszyć alokacje przed kolejnym skokiem.
21 sty 2026
8 min
20 sty 20268 min
20 sty 20268 minEksperymentuj z AppMaster z darmowym planem.
Kiedy będziesz gotowy, możesz wybrać odpowiednią subskrypcję.
