Ostatnie komentarze
-
Karol
w artykule: Jak przyspieszyć dysk HDD? -
Krzysiek
w artykule: Jak przyspieszyć dysk HDD? -
Jurek
w artykule: Nawet Google woli refabrykowane serwery! -
Ola
w artykule: 5 Must Have aplikacji dla właścicieli zwierząt...
Szukaj w blogu
Kategorie bloga

CPU w Serwerach: Xeon Vs Epyc, Tdp, Turbo, Avx W Praktyce
Wybór procesora do serwera często wygląda tak: „weźmy więcej rdzeni, będzie szybciej”. A potem okazuje się, że baza danych chodzi gorzej, aplikacja ma dziwne piki czasu odpowiedzi, a rachunki za licencje rosną szybciej niż wydajność. W serwerach CPU to nie tylko liczba rdzeni i GHz. Liczy się też generacja platformy, kontroler pamięci, liczba kanałów, zachowanie turbo, limit mocy (TDP / power limits), instrukcje wektorowe (AVX) i to, jak dany workload skaluje się na wielu rdzeniach.
Poniżej rozkładamy to na czynniki pierwsze – bez marketingu, z perspektywy praktycznych wdrożeń. Na końcu dorzucamy typowe konfiguracje i podpowiadamy, kiedy refabrykowane platformy mają największy sens kosztowy.
1) Xeon i EPYC – co je realnie różni w serwerach?
Xeon (Intel)
W świecie enterprise Xeony są mocno „osadzone” w wielu środowiskach: wirtualizacja, systemy vendorowe, starsze platformy, sprzętowo‑zależne rozwiązania. W praktyce spotkasz dużo instalacji, gdzie całe otoczenie (sterowniki, firmware, kontrolery, polityki vendorów) jest przez lata budowane wokół Xeonów.
EPYC (AMD)
EPYC jest często wybierany tam, gdzie liczy się gęstość rdzeni, przepustowość pamięci i dużo linii PCIe (np. storage, węzły obliczeniowe, wirtualizacja na wysokiej konsolidacji). W wielu projektach EPYC wygrywa relacją „ile zasobów dostaję na socket”, ale trzeba go dobrać pod konkretny workload.
Wniosek: nie ma „lepszej” marki. Jest lepsze dopasowanie do użycia: CPU + pamięć + I/O + licencje.
2) „Generacja” CPU to nie kosmetyka
W serwerach różnice między generacjami to często:
-
inny kontroler pamięci (taktowania, obsługa większych modułów, stabilność przy pełnej obsadzie),
-
inna liczba kanałów pamięci i/lub ich realna przepustowość,
-
inne wsparcie PCIe (gen, liczba linii),
-
poprawki bezpieczeństwa i mikrokody,
-
zmiany w turbo i limitach mocy.
Dlatego przy modernizacji serwera nie patrzymy wyłącznie na „rdzenie”. Patrzymy, czy platforma nie stanie się wąskim gardłem na RAM albo I/O.
3) TDP i limity mocy – dlaczego „ten sam CPU” potrafi działać inaczej
TDP to skrót, który bywa mylący. W praktyce serwer ma:
-
ograniczenia zasilania (zasilacze, VRM na płycie),
-
ograniczenia termiczne (radiatory, airflow w racku),
-
ustawienia BIOS/firmware (limity mocy, tryby performance/energy).
Dwa identyczne procesory w dwóch różnych obudowach mogą utrzymywać różne taktowania pod obciążeniem, bo jedna platforma pozwoli utrzymać wyższy limit mocy, a druga szybciej „zjedzie” z taktowaniem, żeby utrzymać temperatury.
Praktyka
-
jeśli serwer jest w gęstym racku, z pełną obsadą dysków i kart, to CPU o wysokim TDP może nie utrzymywać długotrwale wysokiego turbo,
-
jeśli chcesz wysokie taktowanie „non stop”, często lepiej sprawdza się CPU o umiarkowanym TDP, ale z wysoką bazą i stabilnym boostem.
4) Turbo: boost jest super, dopóki nie liczysz na niego jak na bazę
Turbo (boost) w serwerach działa inaczej niż w desktopie. Zależy od:
-
liczby aktywnych rdzeni,
-
limitów mocy,
-
temperatur,
-
ustawień BIOS.
W praktyce:
-
pojedynczy wątek może dostać wysoki boost (ważne dla aplikacji słabo równoległych),
-
przy obciążeniu wszystkich rdzeni taktowanie spada do poziomu, który platforma utrzyma termicznie i energetycznie.
Dlatego dla baz danych, aplikacji transakcyjnych i systemów ERP często wygrywa CPU z dobrą wydajnością na rdzeń, a nie „maksymalna liczba rdzeni”.
5) AVX: kiedy daje kopa, a kiedy obcina taktowanie
Instrukcje AVX (i bardziej „ciężkie” odmiany) potrafią:
-
przyspieszyć konkretne obliczenia (np. symulacje, część zadań analitycznych),
-
ale jednocześnie zwiększają pobór mocy i temperaturę.
W wielu platformach serwerowych przy intensywnym AVX procesor może automatycznie obniżać taktowanie, żeby utrzymać limity. Efekt uboczny: jeśli na tym samym CPU działają jednocześnie inne usługi, mogą zauważyć spadki wydajności.
Praktyka
-
jeśli masz workloady AVX‑heavy, planuj to świadomie: osobne węzły/klastry albo przynajmniej izolacja,
-
jeżeli serwer robi „wszystko”, unikaj sytuacji, w której jeden proces AVX wycina taktowania całej maszyny w godzinach szczytu.
6) Pamięć i kanały: tu najczęściej ginie „papierowa” wydajność
W serwerach pamięć RAM nie jest dodatkiem. Jest fundamentem:
-
wirtualizacji (ilość VM i stabilność),
-
baz danych (cache, buffer pool),
-
storage (cache, metadata),
-
analityki.
CPU może mieć dużo rdzeni, ale jeśli:
-
RAM jest wolny,
-
kanały są źle obsadzone,
-
moduły są mieszane bez planu,
…to kończy się tym, że rdzenie czekają na pamięć.
Zasada: dobierając CPU, patrz na to, jaką przepustowość RAM i jaką topologię kanałów zapewni dana platforma oraz czy w budżecie jest miejsce na sensowną obsadę ECC RDIMM/LRDIMM.
7) I/O i PCIe: CPU pod storage i karty to nie CPU pod aplikację
Jeśli serwer ma:
-
dużo NVMe,
-
szybkie NIC (25/40/100GbE),
-
HBA/RAID,
-
akceleratory,
to CPU musi „unieść” nie tylko obliczenia, ale też przepływ danych przez I/O. W takich projektach często większe znaczenie mają:
-
liczba i generacja linii PCIe,
-
stabilność pod obciążeniem,
-
równowaga CPU ↔ RAM ↔ storage.
8) Licencje i koszt per rdzeń – element, który potrafi odwrócić decyzję
W wielu systemach komercyjnych (np. część baz danych, niektóre platformy middleware) koszt rośnie z liczbą rdzeni lub socketów. Wtedy „więcej rdzeni” może oznaczać:
-
wyższą fakturę za licencję,
-
a realna wydajność aplikacji i tak ograniczy się do kilku wątków.
W takich projektach często lepiej sprawdza się CPU z:
-
mniejszą liczbą rdzeni,
-
ale wysoką wydajnością na rdzeń i stabilnym taktowaniem.
9) Typowe dopasowania CPU do zastosowań (praktyczne skróty)
Wirtualizacja (dużo VM)
-
liczy się pojemność RAM i przepustowość,
-
sensownie dobrane rdzenie i I/O,
-
dobra obsada kanałów, spójna konfiguracja modułów.
Bazy danych / ERP
-
ważna wydajność na rdzeń i stabilne taktowanie,
-
RAM i dyski pod IOPS,
-
ostrożnie z „rdzeniami na siłę”, bo licencje.
Storage / backup / archiwum
-
CPU często nie jest wąskim gardłem,
-
ważniejsze są HBA/RAID, interfejsy, dyski i cache,
-
liczy się też stabilność i kompatybilność firmware.
Obliczenia / analityka
-
bywa sens w większej liczbie rdzeni,
-
AVX może mieć znaczenie,
-
warto izolować węzły pod ciężkie zadania.
10) Gdzie w tym wszystkim miejsce na refabrykowane serwery i CPU?
Refabrykowany serwer ma sens wtedy, gdy:
-
potrzebujesz stabilnej platformy enterprise,
-
chcesz rozsądnie wydać budżet,
-
zależy Ci na dostępności podzespołów (często „od ręki”),
-
i masz plan na RAM, dyski, kontrolery.
W BestMicro składamy konfiguracje pod potrzeby klienta: CPU, RAM ECC, storage, kontrolery, zasilanie. Mamy w sprzedaży podzespoły serwerowe, więc da się zbudować sensowną maszynę pod konkretny workload, zamiast brać przypadkową konfigurację.
CPU w Serwerach: Podsumowanie
CPU w serwerze wybiera się pod zastosowanie, a nie pod tabelkę. Rdzenie i GHz to początek, ale o wyniku decydują: limity mocy, turbo pod obciążeniem, AVX, pamięć, I/O i licencje. Jeśli planujesz zakup albo modernizację, podeślij nam model serwera i wymagania (VM/DB/storage) – dobierzemy platformę tak, żeby to się spinało wydajnościowo i kosztowo.