Zaloguj się
Wniosek o naprawę gwarancyjną

W przypadku problemu zapewnimy diagnostykę i naprawy na miejscu instalacji serwera. Za darmo.

Język

Jak wybrać procesor serwerowy: Poradnik eksperta 2026

How to Choose a Server CPU: Expert Guide 2026

Wprowadzenie

Procesor serwerowy nie jest po prostu „najmocniejszym komponentem” — to element, który wyznacza sufit skalowania, definiuje balans całej platformy (pamięć, PCIe, storage, sieć) i bezpośrednio wpływa na całkowity koszt posiadania w horyzoncie 3–5 lat. Błąd w doborze CPU rzadko ujawnia się „od razu”: częściej zamienia się w przewlekłe objawy — regularne skoki opóźnień w bazie danych, niedobór linii PCIe dla NVMe/GPU, brak możliwości rozbudowy pamięci albo nagły wzrost kosztów licencji lub energii.

Procesory serwerowe różnią się od desktopowych nie tylko liczbą rdzeni. Ważniejszy jest ekosystem serwerowy zbudowany wokół nich: obsługa pamięci ECC, funkcje niezawodności i diagnostyki (RAS), długie wsparcie cyklu życia platformy, przewidywalne zachowanie 24/7 pod obciążeniem, zweryfikowana kompatybilność z płytami głównymi, RAID/HBA, kartami sieciowymi, hiperwizorami i systemami klasy enterprise. Dochodzą do tego rozszerzone możliwości I/O: więcej kanałów pamięci i linii PCIe, które w realnym serwerze często są ważniejsze niż „+200 MHz w turbo”.

Ten artykuł to praktyczny przewodnik dla administratorów systemów, inżynierów DevOps i menedżerów IT, którzy dobierają CPU do konkretnych obciążeń: aplikacji webowych, baz danych (OLTP/OLAP/In‑Memory), wirtualizacji, Kubernetes, software‑defined storage oraz AI/ML. Rozłożymy na czynniki kluczowe parametry, podamy wzory i przykłady obliczeń (w tym energię i TCO), pokażemy typowe konfiguracje i zakończymy checklistą, która pozwala podjąć decyzję bez dodatkowego „googlowania”.

Główni producenci: Intel Xeon i AMD EPYC

Intel Xeon (ekosystem serwerowy i przewidywalność platformy)

Intel historycznie jest mocny w kompatybilności enterprise, dojrzałości platform i szerokiej dostępności u vendorów. Najbardziej „uniwersalna” linia to Xeon Scalable: obejmuje zarówno względnie przystępne modele do typowych zadań, jak i procesory wysokiej wydajności do baz danych, analityki i wirtualizacji. W ekosystemie Xeon nie chodzi wyłącznie o rdzenie — liczą się także możliwości platformy: liczba kanałów pamięci, wsparcie PCIe Gen5, funkcje bezpieczeństwa i telemetrii oraz optymalizacje pod popularne obciążenia enterprise. Oficjalna linia Xeon Scalable i jej pozycjonowanie są dostępne na stronie Intel.

Funkcje, które często „wychodzą” w realnych workloadach:

  • Hyper‑Threading (wątki) — pomaga w obciążeniach równoległych, ale nie zastępuje fizycznych rdzeni (zwłaszcza przy rygorystycznych SLO dla opóźnień).
  • Instrukcje wektorowe (w tym AVX‑512 w niektórych zadaniach) — zauważalne w HPC/obliczeniach naukowych, części analityki i multimediach. (Ważne: efekt zależy od oprogramowania oraz tego, jak zostało skompilowane/skonfigurowane.)

AMD EPYC (dużo I/O i pamięci „w standardzie”, wysoka gęstość)

Najnowsze generacje AMD EPYC to zakład na wysoką gęstość obliczeń i szczególnie na I/O: dużo linii PCIe, wiele kanałów pamięci, wysoka przepustowość — a to bywa krytyczne dla wirtualizacji, kontenerów, analityki i systemów storage. Może to mieć znaczenie zależnie od licencjonowania: część produktów licencjonuje się per socket, więc jedno gniazdo AMD z dużą liczbą rdzeni może być bardziej opłacalne niż platforma Intel 2‑socket.

Rodziny, które najczęściej bierze się pod uwagę przy zakupach w 2026:

  • EPYC 9004 (Genoa) — 4. generacja EPYC dla nowoczesnych data center.
  • EPYC 9005 (Turin) — 5. generacja EPYC (Zen 5 / Zen 5c) jako kolejny krok w wydajności i efektywności.

AMD podkreśla także „szeroki zakres” liczby rdzeni i profili mocy oraz pozycjonuje EPYC pod cloud/enterprise na swojej stronie produktowej. (AMD)

Tabela: porównanie producentów (uproszczone, pod praktyczny wybór)

Kryterium Intel Xeon (Scalable) AMD EPYC (9004/9005)
Wydajność „na rdzeń” Często mocna w zadaniach, gdzie liczy się single‑thread/latencja (zależnie od modelu) Duża rozpiętość w liniach; często wygrywa „na serwer” dzięki zasobom platformy
Pamięć (kanały/przepustowość) Zwykle do 8 kanałów DDR5 na socket w typowych platformach Scalable 12 kanałów DDR5 i wysoka przepustowość — kluczowa przewaga EPYC 9004/9005
PCIe i I/O Często 80 linii PCIe Gen5 na socket 128 linii PCIe Gen5 w 1P — silny argument pod NVMe/GPU/sieć
Ekosystem (serwery/firmware/kompatybilność) Bardzo szeroki, wiele zweryfikowanych konfiguracji Szeroki i szybko rosnący, szczególnie w chmurze i high‑density

Kluczowe parametry CPU (i jak „objawiają się” w serwerze)

Key CPU characteristics (and how they “show up” in a server)

3.1 Liczba rdzeni i częstotliwość: gdzie jest prawda, a gdzie marketing

Rdzenie fizyczne vs wątki (SMT/Hyper‑Threading). Wątki (SMT) poprawiają wydajność, gdy workload dobrze się równolegli i ma przestoje w potoku (czekanie na pamięć/gałęzie). Ale wątki nie są równe dodatkowym rdzeniom: dla baz danych z wymaganiami na niską latencję albo dla zadań CPU‑bound (kompilacja, część obliczeń) fizyczne rdzenie zwykle są ważniejsze.

Kiedy potrzebujesz dużo rdzeni:

  • wirtualizacja (wiele VM/kontenerów);
  • klastry Kubernetes o wysokiej gęstości podów;
  • serwery WWW i aplikacje z wieloma równoległymi żądaniami;
  • analityka/ETL, batch joby, wiele usług storage.

Kiedy liczy się częstotliwość (i niska latencja):

  • bazy OLTP (krótkie transakcje, dużo locków/konkurencji, latencja krytyczna);
  • legacy aplikacje o ograniczonej równoległości;
  • niektóre komponenty middleware, gdzie ważny jest czas odpowiedzi single‑thread.

Base vs Turbo — co to naprawdę znaczy.

  • Częstotliwość bazowa — taktowanie, które CPU ma utrzymać w ramach budżetu mocy/termiki przy długotrwałym obciążeniu (w uproszczeniu).
  • Turbo/Boost — „szczytowa” częstotliwość, gdy dostępny jest budżet termiczny/mocy; często z ograniczoną liczbą aktywnych rdzeni, które mogą boostować wyżej.

Wniosek praktyczny: jeśli kupujesz „32 rdzenie, bo turbo ma 3,9 GHz”, upewnij się, że workload realnie działa na ograniczonej liczbie rdzeni lub potrafi utrzymać wymagany boost przy Twoim profilu zasilania/chłodzenia. W przeciwnym razie dostaniesz „wiele rdzeni o umiarkowanej częstotliwości” — co czasem jest OK (wirtualizacja), a czasem nie (OLTP).

3.2 Cache: dlaczego L3 bywa ważniejsze niż „+200 MHz”

Dla serwerów cache to bufor pomiędzy rdzeniami a pamięcią RAM. Gdy working set (indeksy, „gorące” strony DB, metadane) częściej trafia w L3, maleje liczba dostępów do RAM, spada latencja i rośnie przewidywalność.

W praktyce:

  • Bazy OLTP zyskują na większym L3, bo spada liczba cache missów na „gorących” indeksach i strukturach wewnętrznych.
  • OLAP/analityka także korzysta, zwłaszcza przy skanach/agregacjach i wielokrotnym użyciu danych.
  • Wirtualizacja ma stabilniejszą latencję, gdy „gorące” strony hiperwizora i gości częściej pozostają bliżej rdzeni.

Łatwo zobaczyć typowe rozpiętości L3 na realnych modelach: przykładowo AMD EPYC 9554 ma 256 MB L3. Wysokie modele Intel Xeon Platinum 8580 również oferują dużą pojemność cache i wysoką gęstość rdzeni.

3.3 Obsługa pamięci: DDR4 vs DDR5, kanały, pojemność, typy DIMM

DDR4 vs DDR5. W zakupach 2026 DDR5 jest już de‑facto standardem dla nowych platform: wyższa przepustowość i lepsze skalowanie w konfiguracjach multi‑CPU/wysokordzeniowych. DDR4 nadal może być ekonomicznie uzasadnione — podobnie jak wybór nieco starszej generacji serwera, gdzie platforma jest tańsza, a oczekiwany workload nie wysyca przepustowości pamięci (zwłaszcza biorąc pod uwagę ceny RAM na początku 2026).

Liczba kanałów pamięci i przepustowość są krytyczne dla:

  • baz danych (szczególnie In‑Memory i analityki);
  • wirtualizacji przy wysokiej gęstości VM;
  • wielu zadań przetwarzania danych i storage (np. Ceph na węzłach „pod korek”).

Różnice na poziomie platformy są znaczące:

  • Intel Xeon Scalable zwykle zapewnia do 8 kanałów pamięci.
  • AMD EPYC 9004/9005 zapewnia 12 kanałów DDR5 jako bazową przewagę platformy.

Maksymalna pojemność RAM zależy nie tylko od CPU, ale też od serwera (liczba slotów DIMM i wsparcie RDIMM/LRDIMM). Producenci podają limity wprost: na przykład HPE ProLiant DL360 Gen11 wskazuje do 8 TB DDR5 oraz I/O PCIe Gen5.

RDIMM vs LRDIMM.

  • RDIMM zwykle jest tańszy i wystarczający dla większości workloadów.
  • LRDIMM stosuje się, gdy potrzebujesz maksymalnej pojemności na socket (droższy, czasem z niuansami dot. częstotliwości/latencji).

Tabela: pamięć i I/O w popularnych liniach (praktyczna ściąga)

Linia Pamięć Kanały PCIe Komentarz
Intel Xeon Scalable (przykład: Gold 6430) DDR5 8 80 linii Gen5 Mocny ekosystem, zbalansowany „uniwersał”
AMD EPYC 9004/9005 DDR5 12 128 linii Gen5 Wysokie I/O i gęstość pamięci „w standardzie”
Serwer entry (przykład: Dell PowerEdge T360) DDR5 ECC UDIMM zależy od platformy zależy Do 128 GB ECC UDIMM — typowo dla SMB/oddziałów

3.4 Linie PCIe: NVMe, GPU i 100G — gdzie CPU decyduje o wszystkim

PCIe lanes: NVMe, GPUs, and 100G — where the CPU decides everything

PCIe 4.0 vs 5.0. PCIe Gen5 podwaja przepustowość na linię względem Gen4. To ma znaczenie, gdy:

  • masz dużo dysków NVMe (zwłaszcza U.2/U.3/EDSFF i RAID po sieci);
  • masz wiele GPU;
  • używasz szybkich NIC (25/100/200G) oraz SmartNIC/DPU.

Ile linii naprawdę potrzebujesz? Prosta metoda to policzyć urządzenia wg „szerokości”:

  • dysk NVMe prawie zawsze to x4;
  • NIC 100G często ma x16 (zależnie od modelu);
  • GPU zwykle ma x16.

Przykładowy podział (koncepcja, nie jedyny schemat):

  • 8× NVMe (8 × x4 = 32 linie)
  • 2× NIC 100G (2 × x16 = 32 linie)
  • 4× GPU (4 × x16 = 64 linie)
    Razem: 32 + 32 + 64 = 128 linii — typowy „idealny” przypadek dla CPU oferującego 128 linii PCIe (np. platforma EPYC).

Na konkretnych modelach Intel możesz sprawdzić liczbę linii na socket: przykładowo Xeon Gold 6430 podaje 80 linii PCIe.
Wniosek praktyczny: jeśli planujesz „dużo wszystkiego”, PCIe nie jest „drugorzędne” — często to główne ograniczenie.

3.5 Moc (TDP) i pieniądze: przykład obliczenia

TDP nie jest „dokładnym poborem z gniazdka”, ale to solidny punkt odniesienia dla projektu termicznego i zrozumienia klasy CPU. W praktyce serwer może pobierać więcej/mniej zależnie od trybów turbo, profilu mocy w BIOS, wykorzystania, liczby DIMM, dysków itd.

Żeby nie zgadywać, użyj przybliżenia opartego o średnią moc pod Twoim workloadem. Załóżmy:

  • serwer średnio pobiera 250 W (0,25 kW) dla CPU+platformy pod realnym obciążeniem;
  • cena energii to $0,12/kWh (przykład);
  • działa 24/7 przez 5 lat.

Policz:

  • godziny rocznie: 24 × 365 = 8760
  • zużycie roczne: 0,25 × 8760 = 2190 kWh
  • koszt roczny: 2190 × 0,12 = $262,80
  • koszt 5‑letni: 262,80 × 5 = $1314,00

Teraz wyobraź sobie, że wybrałeś CPU/profil mocy, który dodaje +100 W średniego poboru (0,10 kW) dla małego zysku wydajności, którego nie potrzebujesz. Wtedy „nadwyżka” przez 5 lat to:

  • 0,10 × 8760 × 0,12 × 5 = 876 × 0,12 × 5 = 105,12 × 5 = $525,60
    I to bez uwzględnienia chłodzenia i rack/UPS. Wniosek: „tańszy CPU” nie zawsze jest tańszy w praktyce.

3.6 Multi‑socket (1P vs 2P) i NUMA: kiedy drugi procesor jest naprawdę potrzebny

Multi-socket (1P vs 2P) and NUMA: when a second CPU is really needed

1P (jedno gniazdo) jest prostsze: mniej efektów NUMA, łatwiejszy tuning i zwykle bardziej przewidywalna latencja. Warto dodać, że AMD ma też strojenie NUMA: na jednym sockecie możesz skonfigurować od 1 do 4 węzłów NUMA — i w zależności od workloadu warto to dobrać.
2P (dwa gniazda) daje więcej rdzeni, pamięci, PCIe i zwykle wyższy sufit skalowania.

2P ma jednak koszt: NUMA. Pamięć jest „bliżej” swojego socketa, a gdy aplikacja stale sięga po pamięć zdalną, rośnie latencja i spada wydajność. Jest to krytyczne dla:

  • baz OLTP,
  • niektórych usług wrażliwych na latencję,
  • gęstej wirtualizacji bez poprawnego NUMA pinningu.

Reguła praktyczna:

  • Wybierz 2P, jeśli naprawdę potrzebujesz pamięci/PCIe/rdzeni ponad to, co daje 1P, albo jeśli serwer konsoliduje wiele różnych workloadów.
  • Zostań przy 1P, jeśli kluczowym KPI jest latencja i prostota operacyjna, a jeden socket daje wystarczające zasoby z zapasem.

3.7 Instrukcje specjalne i akceleratory: kiedy to ma znaczenie

  • AES‑NI / szyfrowanie sprzętowe: przyspiesza TLS, VPN, szyfrowanie dysków. W nowoczesnych CPU serwerowych to zwykle bazowy „must‑have”.
  • AVX‑512: potrafi zauważalnie przyspieszyć HPC/obliczenia naukowe, część analityki i wyspecjalizowane oprogramowanie (jeśli faktycznie używa tych instrukcji).
  • Akceleracja AI/ML (np. VNNI/DL accelerators): istotne, gdy robisz inference na CPU lub przyspieszasz pewne operacje macierzowe bez GPU. Kluczowe jest sprawdzenie benchmarków dla Twojego frameworka i wersji.

Typy workloadów i wymagania: przełożenie zadania na parametry CPU

4.1 Serwery WWW i aplikacje

Profil: dużo równoległych żądań; liczy się stabilna przepustowość, potrzebujesz odpowiedniej liczby rdzeni, ale częstotliwość wpływa też na latencję p95/p99.

Typowa rekomendacja: 16–32 rdzenie, umiarkowana częstotliwość, odpowiednia pamięć oraz szybkie I/O.
Logika wyboru: Intel Xeon Silver/Gold lub AMD EPYC ze średniej półki. Jako punkt odniesienia w EPYC często rozważa się modele klasy EPYC 9254 (seria 9004) jako zbalansowane pod rdzenie/częstotliwość dla aplikacji ogólnych.

4.2 Bazy danych

OLTP (transakcyjne)

Profil: wiele krótkich operacji, locki, journaling; latencja jest krytyczna.

Potrzebujesz:

  • wysokiej częstotliwości turbo na „pracujących” rdzeniach;
  • szybkiej pamięci i odpowiedniej przepustowości;
  • przewidywalnej latencji (często lepiej z 1P albo dobrze zestrojonym 2P/NUMA).

Przykładowa klasa CPU dla OLTP: Intel Xeon Gold z naciskiem na częstotliwość (np. Gold 6538N bywa klasyfikowany jako opcja high‑frequency/DB w obrębie linii — warto zweryfikować pozycjonowanie pod swój przypadek).

OLAP (analityczne)

Profil: skany, agregacje, równoległe zapytania, batch joby.

Potrzebujesz:

  • dużo rdzeni (32–64+);
  • dużego cache;
  • wysokiej przepustowości pamięci;
  • wystarczającego PCIe dla szybkich NVMe i sieci.

In‑Memory DB (Redis / podejście typu SAP HANA)

Profil: wszystko w pamięci; kluczowe są przepustowość i pojemność.

Potrzebujesz:

  • maksymalnej liczby kanałów pamięci;
  • wysokiej prędkości RAM i poprawnego obsadzenia DIMM;
  • dużej łącznej pojemności RAM.

Tabela: szybkie wskazówki konfiguracyjne dla baz

Typ bazy CPU Pamięć I/O
OLTP mniej, ale szybsze rdzenie; wysoka częstotliwość turbo wysoka częstotliwość/przepustowość, wystarczająca pojemność NVMe/journal, niska latencja
OLAP dużo rdzeni, duży cache dużo pamięci i przepustowości NVMe/przepustowość, sieć
In‑Memory balans częstotliwości i rdzeni maksymalna liczba kanałów i pojemność często drugorzędne, ale stabilność jest ważna

4.3 Wirtualizacja

Profil: wiele różnych VM, konkurencja o CPU/cache/pamięć; ważna jest „płaska” latencja.

Praktyczne szacowanie: częsta zasada kciuka to 4–6 vCPU na jeden rdzeń fizyczny (silnie zależne od profilu VM). Warto też pamiętać, że dla krytycznych VM może to być anty‑wzorzec (więcej vCPU niż rdzeni/wątków) — to tzw. CPU oversubscription, który pod dużym obciążeniem nie zawsze daje najlepsze rezultaty.

Szacunek: jeśli celujesz w 30–50 VM o średniej gęstości, rozsądnym startem jest 32–64 rdzenie fizyczne plus zapas.

Przykłady klasy 2P:

  • 2× Intel Xeon Gold 6430 (typowo 32 rdzenie na socket w 2P daje łącznie 64 rdzenie).
  • 2× AMD EPYC 9334 (odniesienie: 32 rdzenie na socket w 2P).

Klucz: konfiguracja świadoma NUMA — pinning, właściwe rozmieszczenie VM i kontrola zdalnych dostępów do pamięci.

4.4 Konteneryzacja (Kubernetes)

Containerization (Kubernetes)

Profil: wysoka gęstość podów, narzut platformy, requests/limits, możliwe piki.

Rekomendacja: więcej rdzeni przy średniej częstotliwości + odpowiednia pamięć i przepustowość pamięci. Jeśli masz dużo sidecarów i service mesh, CPU „topi się” szybciej, niż wynika to z metryk aplikacji.

4.5 Systemy storage

  • Ceph / software‑defined storage: często wystarcza 16–32 rdzenie na węzeł, ale wiele zależy od roli (OSD/Monitor), sieci i dysków. CPU ma znaczenie dla kodowania (erasure coding), kompresji, szyfrowania i stosu sieciowego.
  • NVMe‑over‑Fabrics: wąskie gardła na PCIe, sieci i obsłudze kolejek — CPU i liczba linii PCIe są krytyczne.
  • File serwery: CPU zwykle nie jest bottleneckiem, chyba że jest dużo szyfrowania/kompresji/deduplikacji.

4.6 ML/AI i compute

Jeśli masz serwer GPU, głównym zadaniem CPU jest „nie przeszkadzać” GPU:

  • często 16–32 rdzenie CPU wystarcza dla węzła multi‑GPU (o ile nie ma ciężkiego preprocessing’u na CPU);
  • krytyczne jest zapewnienie PCIe x16 dla każdego GPU i nie „zjedzenie” linii przez dyski/sieć.

Platformy z dużą liczbą linii PCIe (np. 128) są szczególnie wygodne do takich konfiguracji.

Dodatkowe czynniki, które zmieniają wybór

Additional factors that change the choice

5.1 Niezawodność: ECC i RAS to nie „opcje”, tylko higiena bazowa

Pamięć ECC to standard serwerowy: zmniejsza ryzyko rzadkich, ale destrukcyjnych błędów pamięci. Funkcje RAS (diagnostyka, logowanie błędów sprzętowych) są ważne operacyjnie: chcesz wykrywać degradację DIMM/CPU zanim dojdzie do awarii.

5.2 Kompatybilność: HCL, firmware i wsparcie producenta

Sprawdź kompatybilność HCL (hiperwizor/OS/kontrolery/NIC) oraz wspierane CPU dla konkretnego modelu serwera. Ten sam „Xeon Gold” może być fizycznie niekompatybilny z inną generacją serwera.

5.3 Licencjonowanie software’u: per‑core może uczynić „tani CPU” drogim

Niektóre produkty enterprise licencjonuje się według liczby rdzeni. To zmienia ekonomię: czasem lepiej wybrać CPU z mniejszą liczbą, ale szybszych rdzeni niż „więcej tańszych rdzeni” i potem płacić za licencje.

5.4 TCO (Total Cost of Ownership): wzór, który warto policzyć

Uproszczone:
TCO = Cena serwera + (Średnia moc × taryfa × 24 × 365 × 5)
To przybliżenie, ale już na tym poziomie widać, że energia i chłodzenie potrafią „zjeść” różnicę między dwiema klasami CPU.

5.5 Bezpieczeństwo: podatności klasy Spectre/Meltdown i wpływ na wydajność

Mitygacje podatności CPU/OS‑kernel mogą obniżać wydajność. Zależnie od scenariusza i platformy efekt bywa mały, ale czasem zauważalny; Red Hat wskazywał, że wpływ silnie zależy od workloadu i konkretnych mechanizmów ochrony.
W praktyce: aktualizuj firmware/mikrokod i kernel, a wpływ mierz na własnym profilu obciążenia przed zakupem „w ciemno”.

Przykłady zastosowań 2026: serwery Dell/HPE i odpowiednie klasy CPU (bez wiązania do cen)

Uwaga: ceny zależą od regionu, wsparcia, konfiguracji storage/sieci/pamięci i warunków dostaw — dlatego poniżej jest wyłącznie logika konfiguracji.

6.1 Dell PowerEdge dla małej firmy / oddziału

Serwer: Dell PowerEdge T360 (tower, single‑socket) — typowa opcja dla biura/oddziału.
CPU: Intel Xeon E‑2488 (8 rdzeni/16 wątków; odniesienia częstotliwości — specyfikacje Intel).
Zastosowania: usługi plikowe, kontroler domeny, aplikacje SMB, lekka wirtualizacja.
Pamięć: do 128 GB DDR5 ECC UDIMM.

6.2 HPE ProLiant dla hostingu WWW / kontenerów

Serwer: HPE ProLiant DL360 Gen11 (1U, 2P).
HPE wprost podaje wsparcie Intel Xeon Scalable 4./5. gen, do 64 rdzeni, do 8 TB pamięci oraz PCIe Gen5.
Opcje CPU: Intel Xeon Silver 4416+ (bardziej budżetowy start) albo Xeon Gold 6430 (wyższa gęstość).
Zastosowania: hosting WWW, Kubernetes, usługi mid‑tier, „umiarkowane” bazy danych.

6.3 Dell PowerEdge dla baz OLTP (workload wrażliwy na latencję)

Serwer: Dell PowerEdge R760 (2U, platforma pod nowoczesne Xeon Scalable; odniesienia pamięci/PCIe — specyfikacje Dell).
CPU: Intel Xeon Gold 6538N (często uznawany za opcję z naciskiem na częstotliwość pod DB; zweryfikuj kompatybilność z wybraną platformą).
Zastosowania: systemy OLTP o wysokim obciążeniu, aplikacje klasy ERP/CRM, usługi transakcyjne.
Komentarz: dla OLTP niemal zawsze ważniejsze jest poprawne zbudowanie pamięci/dysków/journalingu i stabilne p95/p99 niż „dołożenie kolejnych 16 rdzeni”.

6.4 HPE ProLiant dla wirtualizacji (2P, wysoka gęstość)

HPE ProLiant for virtualization (2P, high density)

Serwer: HPE ProLiant DL380 Gen11 (2U, 2P). HPE wskazuje wsparcie Xeon Scalable 4./5. gen i do 8 TB DDR5, oraz pozycjonuje model pod wirtualizację.
Opcje CPU:

  • 2× Intel Xeon Gold 6430 (łącznie 64 rdzenie)
  • albo platforma AMD z 2× EPYC 9334 (odniesienie: 32 rdzenie na socket)

Zastosowania: 50–100 VM (zależnie od profilu), klaster hiperwizora.

6.5 Dell/HPE dla OLAP/analityki (Data Warehouse, ETL)

Podejście: dużo rdzeni + wysoka przepustowość pamięci + szybkie I/O.
Odniesienia klas CPU:

  • Intel Xeon Platinum 8580 (high‑end, dużo rdzeni i cache)
  • AMD EPYC 9554 (64 rdzenie/128 wątków, 256 MB L3)
    Jako „podwozie” do takich zadań często wybiera się platformy klasy Dell PowerEdge R760 lub odpowiadające im serie HPE 2U — zależnie od wymagań dot. dysków/GPU/sieci.

6.6 HPE ProLiant dla ML/AI (serwer GPU)

Serwer: HPE ProLiant DL385 Gen11 (platforma pod AMD). Materiały vendorowe podkreślają wsparcie EPYC i nacisk na skalowanie pod nowoczesne workloady.
CPU: EPYC 9554 lub inny EPYC 9004/9005 dobrany pod wymagany balans częstotliwości/rdzeni.
Krytyczne: topologia PCIe dla GPU (x16 na GPU), sieć oraz zasilanie/chłodzenie.

Tabela: przypadki Dell vs HPE (wg celu)

Cel Dell (przykład) HPE (przykład) Klasa CPU
Mała firma/oddział PowerEdge T360 ProLiant ML (podobny segment) Xeon E‑2400 (przykład: E‑2488)
WWW/kontenery PowerEdge klasy R760 ProLiant DL360 Gen11 Xeon Silver/Gold
OLTP DB PowerEdge R760 ProLiant DL360/DL380 Gen11 wysokoczęstotliwościowy Xeon Gold (przykład: 6538N)
Wirtualizacja 2P PowerEdge klasy R760 ProLiant DL380 Gen11 2× Xeon Gold 6430 / 2× EPYC 9334
OLAP/analityka PowerEdge 2U ProLiant 2U Xeon Platinum 8580 / EPYC 9554
ML/AI (GPU) PowerEdge accelerator ProLiant DL385 Gen11 EPYC 9004/9005 + GPU

Kiedy wybrać Dell (częste powody):

  • wygodne narzędzia zdalnego zarządzania iDRAC i administracja serwerami w całej infrastrukturze.

Kiedy wybrać HPE (częste powody):

  • mocna linia ProLiant i zdalne zarządzanie iLO w scenariuszach enterprise.

Warto też brać pod uwagę oficjalne strony linii serwerów Dell i HPE — od producentów.

Metodyka wyboru krok po kroku (co naprawdę działa)

Step-by-step selection methodology (what really works)

Krok 1. Określ typ workloadu i sprofiluj obecny system.
Nie zaczynaj od „który Xeon jest lepszy”. Zacznij od metryk: wykorzystanie CPU (z podziałem user/system/iowait), latencje p95/p99, throughput dysków, sieć, cache misses (jeśli dostępne), użycie pamięci i swap, oraz głębokość kolejek dyskowych.

Krok 2. Przełóż metryki na wymagania.

  • Rdzenie: weź obecny „utrzymany peak” i pomnóż przez 1,5–2 (wzrost + zapas).
  • Częstotliwość: jeśli OLTP/latencja krytyczna — częstotliwość; jeśli równoległe WWW/kontenery — rdzenie i pamięć są ważniejsze.
  • Pamięć: pojemność + kanały. Jeśli RAM już jest „na styk”, upgrade CPU nie pomoże.
  • PCIe: policz urządzenia (NVMe/GPU/NIC) i upewnij się, że linie skończą się dopiero po budżecie, a nie wcześniej.

Krok 3. Zbuduj krótką listę 3–5 modeli CPU.
Wybierz nie „najwyższy top”, tylko kilka kandydatów: opcję ze średniej półki, „optymalną” i jedną „z dodatkowym zapasem”.

Krok 4. Sprawdź benchmarki — ale poprawnie.
Korzystaj z:

  • SPEC CPU2017 jako branżowego punktu odniesienia dla obciążeń CPU.
  • PassMark — jako masowej bazy porównawczej (z zastrzeżeniami metodologicznymi).
    Najważniejsze jednak: jeśli możesz, uruchom swoją aplikację (albo najbliższy profil syntetyczny).

Krok 5. Porównuj TCO, nie tylko cenę CPU.
To obejmuje energię, chłodzenie, licencje, przestoje oraz koszt przyszłej rozbudowy RAM/PCIe.

Krok 6. Sprawdź kompatybilność i dostępność.
Generacja serwera, BIOS/UEFI, wsparcie DIMM, lista kompatybilnych NIC/HBA, wsparcie hiperwizora.

Krok 7. Podejmij decyzję z 30–50% zapasem wzrostu.
Serwer „na styk” od pierwszego dnia prawie zawsze jest droższy w długim terminie.

Typowe błędy (i dlaczego kosztują)

  • Przepłacanie za topowy model w workloadach, gdzie bottleneckiem i tak będzie pamięć/storage/sieć albo CPU będzie mocno niewykorzystany.
  • Niedoszacowanie pamięci: często wąskim gardłem nie jest CPU, tylko przepustowość/pojemność RAM.
  • Ignorowanie poboru mocy: oszczędność na CPU może zamienić się w przepłatę w ciągu 5 lat (patrz obliczenia wyżej).
  • Zakup starej generacji „bo taniej” i utrata PCIe Gen5/DDR5, płacona czasem/ryzykiem.
  • Ignorowanie licencjonowania per‑core/per‑socket, zwłaszcza w enterprise DB/wirtualizacji.
  • Brak zapasu: serwer, który „jeszcze daje radę”, przestaje dawać radę po pierwszym kroku wzrostu.
  • Zaniedbanie NUMA: potem pojawiają się p99 i „dziwne” spadki „nagle”.

Tabela porównawcza i checklista

Tabela: „top” klasy CPU wg budżetu (referencje kategorii, nie cennik)

Klasa budżetowa Typowe scenariusze Referencja CPU
Entry biuro/oddział, usługi plikowe, lekka wirtualizacja Xeon E‑2400 (przykład: E‑2488)
Mid‑range WWW/kontenery, usługi ogólne Xeon Silver/Gold lub EPYC 9004 mid‑range (przykład: EPYC 9254)
High‑range wirtualizacja high‑density, OLAP/ETL Xeon Gold 6430 / klasa EPYC 9334
Ultra / HPC ciężka analityka, konsolidacja high‑end Xeon Platinum 8580 / EPYC 9554 i wyżej

Przydatne zasoby

  • Specyfikacje CPU: Intel ARK i oficjalne strony Intel Xeon Scalable.
  • AMD EPYC: oficjalna linia EPYC i strony generacji 9004/9005.
  • Benchmarki: SPEC (CPU2017) i PassMark (jako szeroka baza porównawcza).
  • Praktyczne recenzje/społeczność: ServeTheHome, niszowe fora i subreddity (homelab/sysadmin) — przydatne przy realnych pułapkach i konfiguracjach.

11. FAQ

FAQ

P: Jaka jest główna różnica między procesorami serwerowymi?
O: Przewidywalna praca 24/7, pamięć ECC, funkcje RAS, więcej kanałów pamięci i linii PCIe oraz dłuższy cykl życia platformy.

P: Czy można użyć desktopowego CPU w serwerze?
O: Technicznie czasem się da — ale zwykle tracisz ECC/RAS i dostajesz niższą niezawodność oraz kompatybilność, co jest słabym zakładem dla produkcji. Do tego CPU serwerowe zwykle wspierają znacznie większą pojemność RAM. Procesor desktopowy może być szybszy i tańszy niż serwerowy i bywa używany tam, gdzie ECC i niezawodność nie są wymagane, a kluczowe są maksymalna wydajność i niska latencja — np. w systemach tradingowych.

P: Ile rdzeni potrzeba do serwera bazodanowego?
O: OLTP często komfortowo działa w przedziale 8–32 „szybkich” rdzeni; OLAP częściej potrzebuje 32–64+ i mocnej pamięci. Dokładna odpowiedź przychodzi po profiliowaniu.

P: Co jest ważniejsze: rdzenie czy częstotliwość?
O: Zadania równoległe i wysoka gęstość = rdzenie/pamięć/PCIe. Transakcje wrażliwe na latencję = częstotliwość i przewidywalna latencja.

P: Intel czy AMD?
O: AMD często daje więcej pamięci/I/O „na socket” (12 kanałów DDR5 i 128 linii PCIe to mocny argument).
Intel jest mocny w ekosystemie i szerokim zakresie zweryfikowanych platform vendorów.

P: Czy warto kupować model top‑tier?
O: Zwykle nie. Mid‑range najczęściej daje najlepszy stosunek cena/wydajność/TCO, chyba że masz ekstremalne wymagania.

P: Jak CPU wpływa na licencjonowanie?
O: Jeśli produkt licencjonuje się per rdzeń, więcej rdzeni może oznaczać więcej licencji. Czasem mniej, ale mocniejszych rdzeni jest bardziej opłacalne.

P: Jeden mocny procesor czy dwa słabsze?
O: Jeden jest prostszy i często lepszy dla latencji (mniej NUMA). Dwa dają więcej pamięci/PCIe/rdzeni, ale wymagają poprawnego tuningu.

12. Podsumowanie

Wybór procesora serwerowego w 2026 to balans wydajności, zasobów platformy (pamięć i PCIe), ceny i przyszłego wzrostu. Najczęstszy błąd to wybór CPU „po nazwie” lub „po liczbie rdzeni” bez sprawdzenia, czy workload rzeczywiście jest CPU‑bound. W praktyce serwer to system: pamięć, dyski, sieć i topologia PCIe mogą ograniczać rezultaty bardziej niż „kolejne +16 rdzeni”.

Właściwa droga: zacznij od profiliowania obecnego systemu, przełóż metryki na wymagania (rdzenie, częstotliwość, pamięć, PCIe), zbuduj krótką listę, zweryfikuj benchmarki i kompatybilność, a potem porównaj opcje po TCO, uwzględniając energię i potencjalne licencje. I koniecznie planuj 30–50% zapasu na wzrost: serwer „na styk” zamienia się w ciągłe gaszenie pożarów.

Jeśli zastosujesz rekomendacje z tego artykułu i uczciwie policzysz pamięć/PCIe/TCO, wybór CPU zwykle staje się oczywisty — i co ważne, da się go obronić przed biznesem liczbami, a nie „odczuciami”. A jeśli coś jest niejasne lub masz dodatkowe pytania, skontaktuj się z naszymi menedżerami — doradzimy i pomożemy dobrać optymalny model.

Komentarze
(0)
Brak komentarzy
Napisz komentarz
Zgadzam się na przetwarzanie moich danych osobowych

NASTĘPNY ARTYKUŁ

Bądź pierwszym, który dowie się o nowych postach i otrzyma 50 €