3DMark ładnie wygląda, ale serwer i tak się dławi
Zapis pierwszego przebiegu Vanilla Benchmark na jednym z produkcyjnych serwerów jors.pl pokazał medianę czasu przełączania kontekstu 4,2 µs i sporadyczne skoki latencji alokacji pamięci do 38 µs — to był moment, kiedy przestałem traktować pojedyncze wykresy jak dowód.
Co zobaczyłem na żywo
Maszyna była standardowa: Xeon-ish, 64 GB ECC, typowy host w racku. Vanilla Benchmark w podstawowej konfiguracji uruchomiłem trzy razy pod rząd. Context‑switch: mediana ~4,2 µs, 95‑percentyl ~12,6 µs. Malloc/calloc/free — mediana ~3,8 µs, sporadyczne outliery do ~38 µs przy równoległych alokacjach. To nie były dramatyczne liczby; problem był w rozkładzie — kilka operacji na sekundę z dużą latencją potrafiło przesunąć kolejkę zadań i zwiększyć p99 całego serwisu.
W praktyce oznaczało to, że przy realnym obciążeniu I/O i krótkich zadaniach CPU, czas reakcji aplikacji rósł nie liniowo. Mierząc tylko throughput procesora (GFLOPS) nie zauważyłbym tego nigdy.
Dlaczego desktopowe benchmarki mylą
3DMark jest najpopularniejszym programem do testowania wydajności PC (pc benchmark), PCMark 10 też ma dużo użytkowników, a CPU‑Z/GPU‑Z to podstawy dla diagnostyki PC. Te narzędzia ładnie opisują wydajność grafiki, pamięci cache czy jednowątkowy IPC w typowym desktopowym scenariuszu. Na serwerze interesują nas jednak inne metryki: czas przełączania kontekstu, latencje alokacji pamięci, zachowanie przy lockach i I/O schedulingu.
Przekręcasz 3DMarka, dostajesz wynik, wrzucasz screena na forum i czujesz się dobrze. Tylko że ten wynik nic nie mówi o p99 requestu HTTP, o latencjach dysku przy konkurecji wielu procesów czy o tym, jak system zachowuje się gdy malloc ma outliery. Popularność narzędzia nie równa się przydatności w środowisku serwerowym — to nie jest truizm, to obserwacja z laboratoriów.
Mikro‑wspomnienie z jors.pl
Pierwsze uruchomienie Vanilla Benchmark z GitHuba na produkcyjnym hostie przekonało mnie, żeby traktować wyniki jako powtarzalne dane, a nie pojedynczy obrazek. Podczas testów poboru mocy przez macierze RAID i latencji pamięci zauważyłem, że drobne zmiany konfiguracji sysctl i polityki alokacji przesuwały rozkład p99 bardziej niż wymiana CPU. Pokazuje to, że testy pamięci to nie tylko sprawdzenie ilości GB — tu przydaje się też doświadczenie z testowanie pamięci RAM w serwerach.
Powtarzalność: ten sam skrypt, te same parametry, trzy przebiegi — dopiero wtedy zacząłem ufać trendom, a nie wykresom jednorazowym. Wartość mediany i rozkład percentyli dostarczyły informacji, których nie dostałbym z syntetycznego benchmarku desktopowego.
Mówienie o wydajności serwera tylko przez pryzmat narzędzi PC jest błędem.