Serwer domowy do Minecrafta i CS2: więcej CPU niż RAM
Piątkowy wieczór, 8 graczy w CS2 na domowym serwerze — maszyna z 4 rdzeniami 3,8 GHz, 16 GB RAM, uplink 100 Mbps, 128-tick. Najpierw skacze RTT, potem dropy pakietów, w końcu gracze zaczynają przeklinać na czacie.
objawy i szybka diagnoza
Zalogowałem się do serwera, spojrzałem na top i ifstat. CPU nie była w 100% obciążona wokół wszystkich rdzeni, ale pojedynczy wątek przy procesie gry szedł do 100% — klasyczny sygnał że bottleneck leży w single-core. Równocześnie widziałem skoki jitteru i okresowe wzrosty packet loss, mimo że uplink reklamowany jako 100 Mbps prawdopodobnie miał problemy z bufferingiem lub kolejkami w routerze.
dlaczego 16 GB RAM to często nadmiar
Fakty mówią: 2 GB wystarczy dla 1–2 graczy, 5 GB dla 3–6 8 GB dla większych sesji; 16 GB często jest nadmiarem jeśli komputer niczego innego nie robi. RAM pomaga przy cache i wielu usługach jednocześnie, ale nie rozwiąże problemu wysokiego RTT ani przetwarzania jednowątkowego. Jeśli wahasz się przy wyborze pamięci, sprawdź też moje tekst o ECC RAM i kiedy ma sens w środowisku domowym.
gdzie naprawdę robi się wąskie gardło
Najczęściej płynność gier sieciowych zabija jedna z dwóch rzeczy: wydajność pojedynczego wątku CPU lub jakość łącza (uplink/jitter/packet loss). Tickrate 128 oznacza większe wymagania na CPU i I/O niż standardowe serwery 64-tick. Jeśli serwer jest hostowany na maszynie z wolnym single-core, nawet 16 GB RAM nie uratuje gry. Jeśli natomiast CPU ma zapas mocy to niestabilne łącze — kolejki w modemie, duże jittery od współdzielonego łącza lub słaba jakość routera — robi robotę. Diagnoza wymaga równoczesnego pomiaru RTT, jitteru i obciążenia jednowątkowego.
Krótka dygresja z moich początków: mój pierwszy serwer LAN stał na Core 2 Duo z 2 GB RAM. Był archaiczny, ale wytrzymał kilkanaście godzin grania i nauczył mnie dwóch rzeczy: proste monitorowanie (top, iftop, i tcpdump) oraz że dobre ustawienia sieciowe i prosty QoS potrafią więcej niż dodatkowe GB RAM.
co poprawić najpierw
Sprawdź single-core CPU load i latency z punktu widzenia klienta. Jeśli pojedynczy wątek bije 100% — priorytet CPU o wyższej częstotliwości. Jeśli RTT i packet loss rosną mimo luźnego CPU, skup się na łączu: symetryczność niski jitter router z obsługą QoS i kabel Ethernet zamiast Wi‑Fi. SSD dla świata gry zmniejszy I/O latency podczas zapisów świata; HDD będzie tu widocznym bólem przy większych sesjach i backgroundowych zadaniach.
konkretne rekomendacje sprzętowe i sieciowe
Dla sesji do ~8 graczy celuj w CPU 2–4 rdzenie z wysoką wydajnością single-core (minimum ~2 GHz preferowane 35+ GHz), RAM 8–16 GB (8 GB zwykle wystarcza 16 GB tylko jeśli serwer pełni dodatkowe role), SSD i symetryczne łącze 50–100+ Mbps z niskim jitterem. System: Linux headless lub Windows 10+. Skaluj CPU i łącze liniowo wraz ze wzrostem liczby graczy; nie przepłacaj za nadmiar RAMu.