Artykuł [Niedokończony] Czy procesor ośmio-rdzeniowy, w Twoim NAS, może działać wolniej niż czterordzeniowiec? - No właśnie... - To zależy

[Silas Mariusz]

Czy procesor ośmio-rdzeniowy, w Twoim NAS, może działać wolniej niż czterordzeniowiec?​

​

- No właśnie...​

A w komputerze PC?​

- To zależy,​

... i mało osób sobie zdaje z tego sprawę ale NVMe w NAS-ie też bierze w tym udział.​

​

Z cyklu „Kroniki z sektora zero”.​

Temat intrygujący, zawsze do niego lubię wracać, jest tym samym fackupem, jak stwierdzenie, że 640KB RAM to aż za dużo.
A właśnie... po ile dzisiaj za kość?

W skrócie (TL;DR)
vCPU nie jest rdzeniem. Jest obietnicą, że kiedy przyjdzie Twoja kolej, dostaniesz rdzeń. Dlatego maszyna wirtualna z ośmioma vCPU na czterowątkowym NAS-ie czeka dłużej niż ta z dwoma — hypervisor musi posadzić wszystkie jej procesory naraz. O tym, czy Windows w wirtualce żyje, decyduje wydajność jednowątkowa, a nie liczba rdzeni na pudełku: ośmiordzeniowy TVS-675 ma ją najniższą w całym zestawieniu, a szesnastordzeniowy EPYC — niższą niż czterordzeniowy i3. Pamięci nie da się nadsubskrybować tak jak procesora, a na QuTS hero ZFS bierze ją pierwszy. I jeszcze jedno: cztery wirtualki po 250 GB z pełnym backupem co dwanaście godzin to około 730 TB zapisu rocznie. Konsumencki NVMe kończy z tym po kilku miesiącach.
Clue: hipernadzorca nie tworzy zasobów. On je tylko dzieli. Zawsze dzieli.

Spis treści

• I. Drugie życie NAS-a ma imię: hipernadzorca
• II. vCPU to nie rdzeń. To miejsce w kolejce
• III. Trzy liczniki, które mówią prawdę
• IV. Pamięć jest twardsza od procesora
• V. Wąskie gardło, którego nikt nie liczy
• VI. 250 GB co dwanaście godzin
• Ciekawostka: nadsubskrypcja to nie oszustwo. To linia lotnicza
• VII. Twoje wirtualki, moje wirtualki
• VIII. Jedenaście NAS-ów na stole
• VIII.5. Wysoka dostępność: kiedy wirtualka nie może umrzeć
• IX.5. Scenariusze: co się stanie, gdy dam 4 rdzenie na...?
• IX. A co ja bym dzisiaj zrobił?
• Addendum: Fizyka radiatora na dysk NVMe
• Addendum: Dyski enterprise do wirtualek
• Addendum: Jak PassMark mierzy różne rzeczy dla różnych procesorów
• X. Kodeks starego wyjadacza
• Epilog. A co z tymi TOPS-ami?
• Słownik pojęć — po polsku, tak jak mówi Microsoft
• Słowniczek maga
• Najczęstsze pytania (FAQ)
• Źródła sobie znajdziecie... to nie jest SEO party

​

A co, dam mu dwadzieścia cztery. Na procku z dwunastoma to przynajmniej wyciśnie 101% I nikt mi nie będzie mówił jak mam żyć,​

... zwłaszcza Microsoft.​

[COLUMNS=2]Pradawne księgi mówią jeszcze o drugiej krainie.
Niby z tego samego universum, ale nie ma w niej ani jednego wirującego świata.
Nie ma talerzy, nie ma głowic, nie ma miast z krzemu ani skarbców pełnych odpowiedzi.
Nie ma tam w ogóle miejsca — nie ma tam nic...

Podobno żyje tam, Pan Tik Tak.
Podobno jedno serce bije tam za wiele naszych ciał.
Uderzy raz — i żyje... Tik.
Uderzy drugi raz — i żyje Tak.
Obaj są przekonani, że serce bije tylko dla jednego z nich, wyłącznie jednego.

Rzemiosło w tamtych stronach, to precyzyjna, nauka cięcia,
w której gildia nauczyła się dzielić jedną sekundę na plastry tak cienkie,
że ich nawet oko ich nie widzi, a program nawet nie
zauważa, że przez moment go nie było.

Nad plastrami czuwa Ten, Który Rozdaje. Kronikarze nazywają go po prostu... Harmonogramem.
Jest sprawiedliwy i jest ślepy — nikogo nie pomija i nikomu nie odmawia.
Ma tylko jedno ograniczenie, którego nie potrafi obejść nawet on sam:
nie umie rozdać więcej czasu, niż sam jego zegar ma.

Reszty dopuszczają się już ludzie.

Bo w tamtej krainie istnieje grzech, którego świat wirujących talerzy w ogóle nie zna.
Nazywa się... Obietnica.
Obiecać komuś czas, którego się samemu nie ma, to najłatwiejsza rzecz pod słońcem.
Nikt Ci tego nie zabroni. Żaden system nie wsadzi do więzienia. Ale pozwoli Ci, szastać nim jak pieniędzmi z komunii.

I dopiero potem, znacznie później, kiedy wszyscy obdarowani zjawią się po swoje w tej samej sekundzie — do drzwi zapuka Ten Toe.

Nikt nie wie, skąd przychodzi. Widać tylko to, co po sobie zostawia:
- brakujące uderzenia jego serca.
Cykle, które ktoś sam dostał, ale oddał komuś,
bo sam ich nie mógł udźwignąć.
A potem nie umiał ich odnaleźć.

Gildia nazywa go: Skradzionym Czasem.

Na to nie na kodów, nie działa IDDQD, nie działa przechodzenie przez ściany IDCLIP.
Za to działa, odpoczynek.

— z zapisków nieznanego kronikarza, odzyskanych z sektora zero
[/COLUMNS]

Księga I. Drugie życie NAS-a ma imię: hipernadzorca​

[COLUMNS=2]Tyle pradawnej księgi. Teraz wersja współczesna, i to bardzo współczesna. W felietonie o dyskach napisałem, że każdy NAS przechodzi dwa życia: w pierwszym przechowuje filmy i kopie zdjęć z telefonu, a w drugim uruchamia Dockera, snapshoty, VPN-a i maszyny wirtualne. Dzisiaj zajmujemy się dokładnie tym drugim życiem. Tym momentem, w którym magazyn plików dostaje awans na serwer aplikacji, a jego właściciel — zupełnie nowy zestaw problemów, o których nikt go nie uprzedził.

I muszę zacząć od pewnego wyznania. Osiem lat temu, w grudniu 2017 roku, napisałem na tym forum tekst o granicy wydajności między procesorem fizycznym a maszynami wirtualnymi22​. Podałem tam proporcje przydziału, opisałem skradziony czas, wspomniałem o regule dotyczącej pamięci. Od tamtej pory zmieniło się właściwie wszystko: procesory w NAS-ach mają dziś dwadzieścia cztery rdzenie zamiast czterech, pamięci potrafi wejść sto dziewięćdziesiąt dwa gigabajty zamiast ośmiu, a Virtualization Station doczekała się czwartej generacji — od października 2025 również z wysoką dostępnością maszyn wirtualnych natywnie oraz jako active-passive na systemie QuTS hero15​. Nie zmieniło się jedno.

Prawa.

I to jest jedyny powód, dla którego wracam do tamtego tekstu - nie dlatego, że pamiętam słowa i obietnice Microsoftu i Intela o wielowątkowości. Nie nie. Wracam rozliczyć wszystkich po czasie. Bullshit passmarka i ruszyć drażliwy temat.... Więcej RAMu znaczy lepiej. Dysk na NVMe znaczy lepiej. Oczywiście, Więcej vCPU znaczy lepiej. Itd itd... Nie, nie zamierzam, absolutnie powiedzieć, że dysk NVMe to zło. Ale... Gorący dysk NVMe, VM wąskie gardło itd td. to już inna spara kaloszy.... [[[[TODO: dokonczyc raport....]]]] (Tia.... Jakby się wychowali na 386, to każdy takt zegara czuliby jak gęsią skórkę.)

Od starego wyjadacza
„Przecież ten NAS ma osiem rdzeni” — najczęstsze zdanie w każdej dyskusji o wirtualizacji na forum. Za każdym razem odpowiadam pytaniem: a ile z nich potrafi wykonać jedną instrukcję szybko? Bo Twoja VM-ka z Windowsem nie potrzebuje ośmiu rdzeni. Ona potrzebuje jednego szybkiego, i to natychmiast.

Zanim jednak pójdziemy dalej, ustalmy jedną rzecz techniczną, bo od niej zależy wszystko, co przeczytasz niżej. Virtualization Station to nadbudowa nad KVM-em — hypervisorem wbudowanym w jądro Linuksa. Po polsku, za Microsoftem: hipernadzorcą. Wymaga procesora Intel x86, zwanego dalej AMD64 (dzięki uprzejmości swojej własnej głupoty i wysokiego EGO w owych wielowątkowych czasach przedstawiając światu Intel64,którego pokonał wieśniak bez pieniędzy i perspektyw, AMD64... A software'owy partner od wielowątkowości poległl pierwszy raz przez rynek porno i musiał się pożegnać ze swoim HDDVD, to za chwile ile idea programowania wielowątkowego MVVP przekresliła dwóch wspaniałych graczy, i musieli się pogodzić z AMD. Ale nie mogło niczego zabraknąć, musieli się wyróżnić, rozszerzeniami wirtualizacji, kolejno Intel VT i AMD-V. QNAP do QKVM wymaga, minimum cztery gigabajty pamięci, rzecz naturalna, sam QNAP. NAS-y na ARM-ie odpadają całkowicie i nie ma tu żadnej furtki: ARM i x86 różnią się listą instrukcji, a wirtualka z Windowsem na x86 nie ma na czym się uruchomić. Może i jest na czym, przecież qemu pociągnię, ale po co? To jest inna platforma, inne instrukcje... Dla ARM-a producent wskazuje Container Station i to jest uczciwa odpowiedź, nie odsyłanie z kwitkiem — kontener to inne narzędzie do innej pracy, o czym jeszcze będzie mowa w księdze VII.

Zdanie, które proszę zapamiętać na cały tekst: hipernadzorca nie tworzy zasobów. Nie ma w nim żadnego mechanizmu, który z czterech rdzeni robi osiem. Wszystko, co robi, to bardzo szybkie i bardzo sprawiedliwe dzielenie tego, co fizycznie istnieje. Kiedy więc w Virtualization Station przesuwasz suwak liczby procesorów, nie kupujesz mocy. Podpisujesz zobowiązanie.[/COLUMNS]

↑ Spis treści​

Księga II. vCPU to nie rdzeń. To miejsce w kolejce​

Zróbmy eksperyment myślowy, bo to najkrótsza droga do zrozumienia całej reszty. Wyobraź sobie małą restaurację z czterema miejscami. Nie czterema stolikami — czterema krzesłami. Przychodzi rezerwacja: stolik dla dwóch osób. Kelner sadza gości natychmiast, zostają jeszcze dwa wolne krzesła. Za chwilę wchodzi kolejna rezerwacja: stolik dla ośmiu. I tu zaczyna się problem, którego nie widać w żadnej karcie katalogowej.

Kelner nie może posadzić czterech osób teraz, a pozostałych czterech za dziesięć minut. Cała ósemka musi usiąść razem, w tej samej chwili, bo inaczej to nie jest jedna rezerwacja. Więc ósemka stoi przy wejściu i czeka na moment, w którym zwolni się osiem krzeseł jednocześnie. Para przy stoliku w tym czasie już je deser.

To nie jest przenośnia poetycka. To dokładny opis mechanizmu, który w świecie wirtualizacji nazywa się współplanowaniem, a jego skutkiem jest zdanie, w które nikt nie chce uwierzyć: szeroka maszyna wirtualna czeka dłużej niż wąska. Przydzielając wirtualce więcej procesorów, niż potrafi wykorzystać, nie dodajesz jej mocy. Dodajesz jej warunek, który trudniej spełnić.

Procesor logiczny, procesor wirtualny i cała reszta rodziny​

Skoro mamy rozmawiać poważnie, musimy mówić jednym językiem — i tu proponuję oprzeć się na Microsofcie, bo to on od dwóch dekad ustala w tej dziedzinie polską terminologię. W dokumentacji Hyper-V po polsku wszystkie te pojęcia mają swoje ustalone nazwy i będę się ich trzymał w całym tekście (pełną tabelę znajdziesz w słowniku pojęć).

Rdzeń to fizyczna jednostka wykonawcza w krzemie. Wątek to strumień instrukcji. SMT, czyli jednoczesne wielowątkowanie — u Intela pod handlową nazwą Hyper-Threading — pozwala jednemu rdzeniowi obsłużyć dwa wątki. To, co system operacyjny hosta widzi i liczy, nazywa się procesorem logicznym. To, co przydzielasz maszynie wirtualnej, nazywa się procesorem wirtualnym. I to są dwie zupełnie różne rzeczy, choć suwak w interfejsie sugeruje coś przeciwnego.

Tu ląduje najwięcej pomyłek: SMT nie podwaja wydajności. Microsoft pisze o tym wyjątkowo szczerze, bez cienia marketingu — SMT „zwykle daje niewielką poprawę wydajności obciążeń”, a gdy wątki konkurują ze sobą o współdzielone zasoby rdzenia, „czasami nie ma zauważalnej poprawy wydajności” i „może nawet wystąpić niewielki spadek wydajności”1​. Czyli: sześciordzeniowy procesor z dwunastoma wątkami nie jest dwunastordzeniowy. Jest sześciordzeniowy i ma dwanaście kolejek.

Druga rzecz z tej samej dokumentacji, o której prawie nikt nie wie, a która świetnie tłumaczy, dlaczego host nigdy nie oddaje Ci całej maszyny: między procesorami wirtualnymi partycji głównej — czyli samego systemu NAS-a — „a podstawowymi procesorami logicznymi istnieje mapowanie jeden do jednego”, i te procesory wirtualne „nie migrują”. System operacyjny Twojego NAS-a nie jest gościem, którego można odstawić na później. On siedzi na swoich krzesłach na stałe.

Mit z sieci
„Dam wirtualce wszystkie rdzenie, jakie mam. W najgorszym razie nie wykorzysta.”
Fakt: w najgorszym razie będzie czekać. Przydzielenie ośmiu procesorów wirtualnych obciążeniu, które używa dwóch, oznacza, że hypervisor musi znaleźć osiem wolnych okien naraz — zamiast dwóch. Za nadmiarowy przydział płaci się opóźnieniem, nie bezczynnością. To jedna z niewielu sytuacji w informatyce, w której „na zapas” jest gorsze niż „dokładnie tyle, ile trzeba”.

Ósemka, którą Microsoft po cichu pochował​

Jest w tej historii pewien ciekawy zwrot. W czasach Windows Server 2008 R2 Microsoft podawał twardą, oficjalną liczbę: obsługiwane do ośmiu procesorów wirtualnych na jeden procesor logiczny, a dla wdrożeń VDI z Windows 7 jako gościem podniesiono ten limit do dwunastu do jednego. Przy Windows Server 2012 formalny wymóg proporcji zniknął z dokumentacji5​.

Tylko że „zniesiono limit” i „zniesiono konsekwencje” to dwa różne zdania. Bo równolegle nigdy nie odwołano zalecenia, żeby dla najlepszej wydajności utrzymywać proporcję jeden do jednego. Producent po prostu przestał ustawiać barierkę i zaczął zakładać, że dorosły administrator sam policzy. Uczciwie? Owszem. Skutecznie? Zajrzyj na dowolne forum.

VMware trzyma się w tej sprawie liczb i to od nich pożyczyłem tabelkę, którą podałem w 2017 roku — bo do dziś nie znalazłem lepszej6​:

Proporcja vCPU : procesor fizyczny	Co się dzieje
1:1 – 3:1	bez problemu; typowe środowisko produkcyjne
3:1 – 5:1	zaczyna się degradacja wydajności
6:1 i więcej	problemy występują często

Jedna praktyczna wskazówka wprost z zaleceń Microsoftu, która nic nie kosztuje: przy włączonym SMT przydzielaj procesory wirtualne w wielokrotnościach dwóch2​. Dwa, cztery, sześć. Nie trzy, nie pięć. Wątki chodzą parami, więc niech przydział chodzi parami razem z nimi.

Wróćmy na chwilę do TS-877 z 2017 roku​

W tamtym tekście użyłem przykładu, który do dziś uważam za najbardziej pouczający w całej tej dziedzinie. NAS z dwunastoma procesorami logicznymi. Dwie maszyny wirtualne, każda z dwunastoma procesorami wirtualnymi. Razem dwadzieścia cztery. System pozwala, interfejs nie protestuje, obie wirtualki wstają i działają.

Do momentu, w którym obie zaczynają naprawdę pracować.

Wtedy nadzorca staje przed zadaniem, którego nie da się rozwiązać: ma posadzić dwunastu gości pierwszej rezerwacji i dwunastu drugiej, dysponując dwunastoma krzesłami, z których część i tak jest na stałe zajęta przez sam system NAS-a. I nie zwolni wtedy jedna wirtualka. Zwolnią obie, a razem z nimi wszystko inne na urządzeniu — panel, udziały SMB, kontenery, harmonogramy.

Osiem lat później suwaki są dłuższe, bo rdzeni jest więcej. Arytmetyka jest identyczna.

↑ Spis treści​

Księga III. Trzy liczniki, które mówią prawdę​

„Jeśli licznik procesora logicznego hipernadzorcy (_Total) — łączny czas pracy — wynosi ponad 90%, host jest przeciążony.”
— dokumentacja Microsoftu, dosłownie3​

Cała księga II była o teorii. Ta jest o dowodach. Bo „wirtualka wolno chodzi” to nie diagnoza — to objaw, i to objaw wspólny dla co najmniej pięciu różnych chorób. Na szczęście istnieją trzy liczniki, które potrafią rozstrzygnąć, która to z nich. Nauczę Cię czytać wszystkie trzy, bo od tego momentu przestajesz zgadywać.

▸ 1. Czas gotowości — czy ja w ogóle dostałem procesor?

Czas gotowości to najczystsza miara przesprzedania procesora, jaka istnieje: ile czasu wirtualka była gotowa policzyć, ale nie miała na czym. To nasza ósemka stojąca przy wejściu do restauracji, z menu w ręku.

VMware mierzy to w milisekundach w okienku dwudziestu sekund, czyli dwudziestu tysięcy milisekund, i podaje progi, które w praktyce sprawdzają się wszędzie7​: do 50 ms zdrowo, 50–300 ms warto się przyjrzeć, powyżej 300 ms robi się poważnie, a około 500 ms to sufit tolerancji. Przeliczone na procenty daje to regułę, którą łatwiej zapamiętać: poniżej pięciu procent na każdy procesor wirtualny8​. Powyżej — sprzedałeś więcej krzeseł, niż masz.

▸ 2. Czas skradziony — nasz licznik, bo Virtualization Station to KVM

Rzecz, o której na forach mówi się zdumiewająco rzadko. Czas gotowości to metryka świata VMware. Twój NAS nie jest światem VMware — Virtualization Station stoi na KVM-ie, a tam ta sama prawda nazywa się inaczej i mieszka w innym miejscu.

Pamiętasz restaurację z poprzedniej księgi? To właśnie tutaj kelner wystawia rachunek.

Nazywa się czasem skradzionym i w Linuksie widnieje w kolumnie %st. Znajdziesz go w top, w vmstat, w mpstat. I bardzo proszę, zapamiętaj jedno rozróżnienie, bo z niego bierze się połowa błędnych diagnoz: to nie jest bezczynność. To realnie utracone okna wykonania — czas, który Twój procesor wirtualny miał obiecany i którego nie zobaczył9​.

Progi w praktyce: utrzymane powyżej pięciu procent przy odczuwalnych opóźnieniach to już sygnał rywalizacji o zasoby (ang. contention), a powyżej dziesięciu procent przez dwadzieścia minut oznacza, że działasz w środowisku zdegradowanym i trzeba coś zmienić. Obciążenia wrażliwe na opóźnienia — bazy danych, telefonia, cokolwiek, na co człowiek patrzy i czeka — poskarżą się przy wartościach znacznie niższych.

▪ top — wnętrze gościa, nie hosta

%Cpu(s): 11,4 us, 3,1 sy, 0,0 ni, 51,2 id, 2,1 wa, 0,0 hi, 0,3 si, 31,9 st

Ten jeden wiersz mówi więcej niż godzina spekulacji. Procesor gościa jest w połowie „bezczynny”, obciążenie użytkownika śmiesznie niskie — a jedna trzecia jego czasu po prostu nie istnieje. Nikt tej wirtualki nie zamęczył. Ktoś jej po prostu obiecał więcej, niż zegar posiada.

▲ Pułapka nadzoru, na którą wpada każdy: Monitor zasobów w QTS pokazuje obciążenie hosta. Skradzionego czasu tam nie ma i nigdy nie będzie — z definicji jest to czas, który host wykorzystał, tylko nie na tego gościa. Żeby go zobaczyć, musisz wejść do środka maszyny wirtualnej. Host powie Ci, że jest zajęty. Tylko gość powie Ci, że został okradziony.

▸ 3. Oczekiwanie na we/wy — licznik, który wszyscy czytają na opak

I trzeci, najbardziej zdradliwy, bo generuje najwięcej nieporozumień na forum. Oczekiwanie na we/wy, w Linuksie kolumna wa.

Powiem to możliwie wprost: wysokie oczekiwanie na we/wy nie oznacza obciążonego procesora. Oznacza dokładnie odwrotność — procesor stoi i się nudzi, bo czeka na dysk. To jak kierowca w korku: silnik pracuje, licznik przebiegu nie rośnie. Kiedy widzisz obciążenie systemu grubo powyżej liczby rdzeni przy niskim zużyciu procesora, prawie zawsze patrzysz na jedną z dwóch rzeczy: skradziony czas albo zablokowane we/wy10​.

I zaraz uczciwe zastrzeżenie, żeby nikt nie wyszedł stąd z przekonaniem, że ma już srebrną kulę: ten licznik mówi „magazyn ogranicza postęp”. Nie mówi, kto go ogranicza. Nie wskaże, czy winna jest pula, kontroler, firmware dysku, system plików gościa, czy jedna jedyna wirtualka waląca zapisami synchronicznymi w dysk, na którym leży wszystko pozostałe. Do tego trzeba już zejść poziom niżej — i o tym jest cała księga V.

Czy wiesz, że…
Microsoft podaje w swojej dokumentacji dwie liczby, które warto trzymać w pamięci jak progi na termometrze. Pierwsza: łączny czas pracy procesorów logicznych hipernadzorcy powyżej 90% oznacza, że host jest przeciążony — trzeba dodać moc albo przenieść wirtualki gdzie indziej. Druga, moim zdaniem cenniejsza, dotyczy dysków: jeżeli opóźnienia magazynu są stale większe niż 50 ms, to nie jest „no cóż, NAS ma dużo pracy”. To jest wąskie gardło i trzeba je usunąć3​. Pięćdziesiąt milisekund. Zapamiętaj tę liczbę, wróci w księdze V.

↑ Spis treści​

Księga IV. Pamięć jest twardsza od procesora​

[COLUMNS=2]Procesor jest wyrozumiały. Da się go przesprzedać i przez długi czas nikt nie zauważy — wszystko po prostu chodzi trochę wolniej, a potem trochę wolniej, i tak dalej. Pamięć nie ma tej łaskawości. Pamięć albo jest, albo jej nie ma, a moment przejścia z pierwszego stanu w drugi bywa gwałtowny i kończy się nie spadkiem wydajności, ale ubitym procesem.

I tu dochodzimy do rzeczy, która na QNAP-ie zaskakuje najwięcej osób, bo nie znajdziesz jej w żadnym ogólnym poradniku o wirtualizacji — a na QuTS hero decyduje o wszystkim.

ZFS jest pierwszy w kolejce po pamięć​

QuTS hero stoi na ZFS-ie, a ZFS utrzymuje w RAM-ie swoją pamięć podręczną odczytu, czyli ARC. To nie jest kaprys ani nadmiar — bez ARC-u pula chodzi wyraźnie gorzej, bo każde żądanie ląduje na dyskach. Problem polega na tym, że ta pamięć nie jest wolna, mimo że w niektórych statystykach wygląda, jakby była.

Najlepszy dowód pochodzi od samego producenta i to jest chyba mój ulubiony fragment całej dokumentacji QNAP-a, bo jest brutalnie szczery. Weźmy NAS z QuTS hero i 128 GB pamięci — sprzęt, o którym większość ludzi powiedziałaby „no, tu już na pewno starczy na wszystko”. Liczymy razem z QNAP-em13​:

Policzmy to

• Start: 128 GB pamięci fizycznej.
• System operacyjny NAS-a zabiera około 18 GB. Zostaje 110 GB.
• Na ARC domyślnie idzie 75% tego, co zostało.
• Dla maszyn wirtualnych zostaje: około 25 GB.

To wystarcza na trzy wirtualki z Windows Server po 8 GB — albo na sześć Ubuntu po 4 GB. Na maszynie ze stu dwudziestoma ośmioma gigabajtami pamięci.
Clue: pamięć, którą widzisz w specyfikacji, i pamięć, którą możesz sprzedać wirtualkom, to dwie różne liczby. Zanim policzysz drugą, odejmij system i odejmij ZFS.

Można ARC przyciąć — służy do tego ustawienie ARC RAM Usage w globalnych opcjach magazynu — i czasem trzeba. Ale QNAP dopisuje przy tym uczciwe ostrzeżenie, które warto przeczytać dwa razy: zrobisz to kosztem wydajności we/wy swojej puli. Czyli oddajesz szybkość dysków, żeby dostać pamięć dla wirtualek. To handel wymienny, nie zysk. Wolno Ci go zrobić — pod warunkiem, że wiesz, co wymieniasz na co.

Co robi QuTS hero, kiedy pamięć naprawdę się kończyTo nie jest teoretyczne. Producent opisuje trzy następstwa i żadne z nich nie jest ładne. Po pierwsze: spada skuteczność ARC-u, więc rośnie liczba bezpośrednich odwołań do dysków i wydajność „zauważalnie leci”. Po drugie: procesy zaczynają wisieć w nieprzerwanym oczekiwaniu na we/wy — słynny stan D — szczególnie przy intensywnym zapisie, podczas czyszczenia puli albo odbudowy macierzy. Po trzecie, i najgorsze: jądro systemu zaczyna przymusowo ubijać procesy, także te niezwiązane z ZFS-em14​. Czyli: zabrakło pamięci dla wirtualki, a przewróciła się usługa, która z wirtualizacją nie miała nic wspólnego. Właśnie dlatego pamięć planuje się przed, a nie po.

Cztery suwaki pamięci w Virtualization Station i kiedy każdy z nich szkodzi​

Virtualization Station 4 daje przy pamięci więcej możliwości, niż większość ludzi zauważa — i każda z nich ma swoją cenę12​.

Pamięć maksymalna to górny limit, powyżej którego gość nie wyjdzie. Pamięć zarezerwowana to gwarantowane minimum — jedyny mechanizm, który realnie chroni wirtualkę przed sąsiadami, i dlatego właśnie tam wpisuje się potrzeby produkcyjnej bazy danych. Przydział dynamiczny pozwala systemowi dawać wirtualce tyle, ile w danej chwili potrzebuje. Udziały rozstrzygają, kto wygra, gdy zabraknie dla wszystkich. Jest jeszcze współdzielenie pamięci, które usuwa zduplikowane strony między gośćmi — bardzo skuteczne, jeżeli masz pięć niemal identycznych Debianów, i praktycznie bezużyteczne, jeżeli każdy gość robi coś innego.

Pułapka siedzi w pamięci dynamicznej i jest naprawdę nieoczywista. Microsoft pisze wprost: pamięci dynamicznej nie można używać jednocześnie z wirtualną architekturą NUMA — maszyna z włączoną pamięcią dynamiczną ma tylko jeden wirtualny węzeł NUMA i żadna topologia nie jest jej pokazywana2​. Kogo to dotyczy? Ten sam Microsoft podaje przykład aplikacji obsługującej NUMA i jest to — proszę usiąść — SQL Server. Czyli dokładnie to, co siedzi pod Subiektem, o którym będzie księga VII. Wniosek praktyczny jest krótki i wart zapamiętania: wirtualce z bazą danych dajesz pamięć na stałe, nie dynamicznie.

Reguła „stu pięćdziesięciu procent”, którą dziś napisałbym inaczej​

W tekście z 2017 roku podałem praktykę, którą wtedy stosowało pół branży: rozdzielaj między wirtualki około 150% dostępnej pamięci fizycznej, licząc na to, że nie wszystkie zażądają swojego maksimum w tej samej chwili. Dopisałem też, co się dzieje po przekroczeniu — wejście w plik wymiany i degradacja rzędu 300–500%22​.

Druga część tego zdania obroniła się w całości i nie zmieniłbym w niej ani przecinka — Microsoft do dziś zaleca wymiarować pamięć maszyny wirtualnej tak, jak wymiarowałoby się ją dla aplikacji serwerowej na fizycznym komputerze, „aby rozsądnie obsłużyć oczekiwane obciążenie w normalnych i szczytowych godzinach”, bo niewystarczająca pamięć „może znacznie wydłużyć czas odpowiedzi”4​. Pierwszej dziś nie napisałbym w takiej formie i chcę powiedzieć dlaczego, bo to dobra ilustracja tego, jak sprzęt zmienia zalecenia. Osiem lat temu prawie wszyscy siedzieli na QTS-ie z klasycznym systemem plików, gdzie nadmiar pamięci naprawdę bywał nadmiarem. Na QuTS hero ta sama nadsubskrypcja wchodzi w konflikt z ARC-em, a ZFS nie jest uprzejmym sąsiadem — on tę pamięć zajmie. Więc dziś mówię inaczej: na QuTS hero nie sprzedawaj pamięci na zapas. Najpierw ustal budżet, dopiero potem twórz wirtualki — dokładnie tak, jak w ramce z arytmetyką wyżej.

Zmiana zdania po ośmiu latach nie jest w tym fachu wadą. Wadą jest nie zmienić go, kiedy zmienił się sprzęt.[/COLUMNS]

↑ Spis treści​

Księga V. Wąskie gardło, którego nikt nie liczy​

[COLUMNS=2]Zapytaj na dowolnym forum, dlaczego wirtualka wolno chodzi, i dostaniesz dwadzieścia odpowiedzi o procesorze i pamięci. Tymczasem w moim doświadczeniu — a diagnozuję to zawodowo — większość skarg na wydajność maszyn wirtualnych na NAS-ie kończy się na dyskach. Nie na procesorze. I to zwykle nie dlatego, że dysk jest wolny, ale dlatego, że nikt nie policzył, ile operacji na sekundę może wykonać.

Osiemdziesiąt operacji na sekundę, czyli cała prawda o talerzach​

Dysk talerzowy 7200 obrotów wykonuje przy zapisie losowym mniej więcej 80–120 operacji na sekundę. Nie osiemset. Osiemdziesiąt do stu dwudziestu. Ta liczba nie zmieniła się od dwudziestu lat i nie zmieni się, bo wynika z fizyki: głowica musi dolecieć nad ścieżkę, a talerz musi się dokręcić.

Teraz policzmy, co się dzieje w typowym domowym scenariuszu, o którym nikt nie myśli jako o czymś ciężkim. Cztery wirtualki, każda „prawie nic nie robi”. Home Assistant zapisuje zmianę stanu czujnika. Debian dopisuje wiersz do logu. Windows sprawdza aktualizacje. Czwarta VM-ka jest testowa i ktoś zapomniał ją wyłączyć. Każda z nich generuje po kilkanaście drobnych zapisów w losowych miejscach. Z punktu widzenia macierzy nie ma czterech spokojnych gości — jest jeden strumień losowych operacji, i to strumień, w którym głowica nigdy nie dostaje dwóch sąsiednich zadań z rzędu.

Pamiętasz próg pięćdziesięciu milisekund z księgi III? Właśnie tak się go przekracza. Nie wielkim transferem. Czterema wirtualkami, które „nic nie robią”.

VirtIO, albo procesor spalony na emulacji​

Druga rzecz jest darmowa i dlatego tak boli, gdy ktoś jej nie zrobił. Tworząc dysk wirtualny w Virtualization Station, wybierasz kontroler: IDE, SATA albo VirtIO12​. Pierwsze dwa to urządzenia emulowane — hypervisor udaje przed gościem układ scalony, który fizycznie nie istnieje, i płaci za ten teatr cyklami procesora przy każdej operacji. VirtIO to sterownik, który wie, że jest w maszynie wirtualnej, i zamiast oglądać przedstawienie, rozmawia z hypervisorem bezpośrednio.

Microsoft opisuje ten sam mechanizm od strony Hyper-V i formułuje to zdanie, które warto przenieść na nasz grunt jeden do jednego: usługi integracji zawierają sterowniki, które „znacznie zmniejszają obciążenie procesora przy operacjach we/wy w porównaniu z urządzeniami emulowanymi”, a ich instalacja to „pierwszy krok dostrajania wydajności”2​. Pierwszy. Nie dziesiąty, po dosypaniu pamięci i dokupieniu SSD.

U nas znaczy to konkretnie: dysk i karta sieciowa na VirtIO, a przy Windowsie doinstalowanie sterowników VirtIO w gościu — bez nich instalator po prostu nie zobaczy dysku i połowa ludzi wraca wtedy do SATA, płacąc za to wydajnością do końca życia wirtualki. Warto też zajrzeć do sekcji działanie w tle w tej samej dokumentacji: usuń emulowaną kartę sieciową, wyrzuć nieużywane napędy CD i porty COM, wyłącz wygaszacz ekranu i indeksowanie w gościu. Brzmi jak drobiazgi. Na czterordzeniowym NAS-ie z czterema wirtualkami drobiazgi są całym budżetem.

Wzmocnienie zapisu, czyli dlaczego warstwy się mnożą​

Tę rzecz trzeba zrozumieć przed księgą VI, bo bez niej tamtejsza arytmetyka wygląda na przesadzoną. Prześledźmy drogę jednego zapisu z wnętrza wirtualki na talerz albo do kości pamięci:

1. System plików gościa zapisuje blok — i przy okazji swoje metadane, i swój dziennik.
2. Plik obrazu dysku wirtualnego zapisuje ten blok — a jeżeli jest formatem kopiowania przy zapisie, to zapisuje go w nowym miejscu i aktualizuje własne mapowanie.
3. Pula zapisuje to wszystko — ZFS też jest systemem kopiowania przy zapisie i też prowadzi swoje metadane.
4. RAID dopisuje sumę kontrolną albo parzystość.
5. Kontroler SSD, jeśli to SSD, przenosi bloki w ramach porządków i wyrównywania zużycia.

Jeden zapis gościa wchodzi. Na dole wychodzi kilka razy więcej. To zjawisko nazywa się współczynnikiem wzmocnienia zapisu i ma jedną paskudną właściwość, którą trzeba powiedzieć głośno: w zagnieżdżonych warstwach kopiowania przy zapisie te narzuty mnożą się, a nie dodają17​. Do tego dochodzi drugi mechanizm z tej samej rodziny: częste migawki i drobne zapisy losowe zużywają pamięć NAND szybciej niż duże, spokojne transfery sekwencyjne.

Od starego wyjadacza
Miejsce maszyn wirtualnych jest na SSD. Nie dlatego, że „SSD jest szybszy” — to zbyt płaska prawda. Dlatego, że wirtualka generuje zapis losowy, a przy zapisie losowym różnica między talerzem a półprzewodnikiem nie jest dwukrotna, tylko dwustukrotna. A jeżeli ten SSD ma trzymać wirtualki produkcyjne, to interesują mnie w nim dokładnie dwie rzeczy, dokładnie te same, o których pisałem w księdze VII felietonu o dyskach: PLP i DWPD co najmniej 1. Reszta to wykresy z recenzji.

Dlaczego PLP wraca akurat tutaj? Bo maszyna wirtualna to nie jeden plik, który da się odtworzyć z kopii. To działający system plików z otwartym dziennikiem i bazą w środku. SSD bez ochrony przed zanikiem zasilania, tracąc prąd w trakcie zapisu, potrafi zgubić nie tylko ostatnie dane, ale i fragment własnej tablicy mapowania — a wtedy nie tracisz jednej wirtualki, tracisz wszystko, co leżało na tym nośniku. Przy dyskach z filmami to przygoda. Przy dyskach z wirtualkami to poniedziałek, którego nikt nie chce przeżyć.

▲ Jest jeszcze jeden szczegół, który wychodzi dopiero w praktyce i potrafi zepsuć cały plan ochrony: w Virtualization Station migawki nie są dostępne dla maszyn korzystających z przekazywania urządzeń fizycznych ani z dysków wirtualnych na SATA12​. Czyli decyzja, którą podejmujesz przy tworzeniu wirtualki — „ee, dam SATA, będzie prościej” — potrafi po pół roku odebrać Ci narzędzie, na którym oparłeś całą strategię kopii. Warto o tym wiedzieć przed, nie po.

[/COLUMNS]

↑ Spis treści​

Księga VI. 250 GB co dwanaście godzin​

[COLUMNS=2]eraz rozdział, od którego zaczęła się cała ta rozmowa, bo pytanie pada na forum w niemal identycznym brzmieniu co najmniej raz w miesiącu. Ktoś ma cztery maszyny wirtualne po dwieście pięćdziesiąt gigabajtów. Każda robi swój backup co dwanaście godzin, bo — cytuję z pamięci wiele wątków — „lepiej dwa razy dziennie niż raz”. Wszystko leży na jednym NVMe, bo tak jest najszybciej. I wszystko działa świetnie.

Przez kilka miesięcy.

Zrobiłem to, czego większość ludzi nie robi przed ustawieniem harmonogramu: policzyłem.

Policzmy to — 250 GB × 4 × dwa razy na dobę

• Jedna wirtualka, pełny backup: 250 GB.
• Co dwanaście godzin, czyli dwa razy na dobę: 500 GB na wirtualkę na dobę.
• Cztery wirtualki: 2 TB zapisu na dobę.
• W skali roku: około 730 TB danych wysłanych do dysku.

Teraz przyłóżmy do tego zwykły, dobry konsumencki NVMe 1 TB z wytrzymałością 600 TBW18​:

• W idealnym świecie, przy wzmocnieniu zapisu równym jedności: zasób na całe życie dysku wyczerpany po niecałych dziesięciu miesiącach.
• Przy wzmocnieniu 1,5 — realistycznym dla obrazu na puli: około siedmiu miesięcy.
• Przy wzmocnieniu 3, czyli format kopiowania przy zapisie na ZFS-ie plus migawki: nieco ponad trzy miesiące.

I ta sama prawda ujęta drugą miarą, tą, którą posługuje się branża: 2 TB na dobę na dysku o pojemności 1 TB to 2 DWPD. Konsumencki nośnik z 600 TBW rozłożonym na pięć lat gwarancji jest zaprojektowany na około 0,33 DWPD.
Clue: eksploatujesz go sześciokrotnie ponad to, na co go zaprojektowano — i nie dowiesz się o tym z żadnego wykresu prędkości.

Widzisz już paradoks? Ten harmonogram wziął się z ostrożności. Człowiek chciał mieć pewność, że nie straci danych, więc ustawił kopię dwa razy częściej, niż potrzebował. I dokładnie tą ostrożnością wyznaczył swojemu nośnikowi datę śmierci — bo pełny backup nie jest zabezpieczeniem danych. Jest zapisem. A zapis się zużywa.

Termika, czyli druga połowa tej samej katastrofy​

Gdyby to było wszystko, dałoby się z tym żyć: wymieniasz dysk raz w roku i traktujesz to jako materiał eksploatacyjny. Tylko że jest druga połowa, która działa szybciej niż zużycie komórek i uderza już pierwszego dnia.

Okno backupu to długi, nieprzerwany zapis sekwencyjny — czyli dokładnie to jedno obciążenie, którego konsumencki NVMe nie znosi najbardziej. Taki dysk osiąga swoje reklamowane prędkości dzięki buforowi pseudo-SLC, który obejmuje ułamek pojemności i pracuje w trybie szybkiego zapisu. Przy dwustu pięćdziesięciu gigabajtach ciągłego strumienia ten bufor kończy się w pierwszych minutach, a potem dysk zapisuje z prędkością własnej pamięci — czasem kilkakrotnie niższą.

I wtedy dochodzi temperatura. Na QNAP-ie działa twardy próg: przy 70 °C na kontrolerze SSD system rozkręca wentylatory na sto procent. Realny throttling termiczny wielu nośników zaczyna się w okolicach 78 °C, a radiator dokładany przez producenta zdejmuje mniej więcej dziesięć stopni. W spokoju chcesz widzieć 30–50 °C, pod obciążeniem 50–65 °C19​. Backup czterech dwustupięćdziesięciogigabajtowych wirtualek z rzędu nie jest obciążeniem. To jest wypiek.

Efekt kuli śnieżnej — mechanizm, który zamyka pułapkęTu następuje rzecz, której nie widać w żadnej pojedynczej metryce, bo jest procesem, nie stanem. Pierwszy backup po instalacji trwa, powiedzmy, trzy godziny. Miesiąc później dysk jest bardziej zapełniony, bufor szybkiego zapisu mniejszy, temperatura pod obciążeniem wyższa, throttling wchodzi wcześniej — i to samo zadanie trwa cztery godziny. Potem pięć. Aż w pewien dzień okno startujące o północy jeszcze się nie skończy, gdy startuje okno z południa. Od tej chwili NAS zapisuje bez przerwy, kolejki się nakładają, oczekiwanie na we/wy z księgi III idzie w górę, wirtualki zaczynają się dławić — a użytkownik szuka winy w procesorze, bo tam patrzy pierwszy suwak. Wina nie siedzi w procesorze. Siedzi w harmonogramie.

To samo zadanie, zrobione dobrze​

Na szczęście jest też dobra wiadomość: to samo zabezpieczenie da się osiągnąć za pięćdziesiątą część tego kosztu. Wystarczy przestać wysyłać co dwanaście godzin te same dwieście pięćdziesiąt gigabajtów, które się nie zmieniły.

Virtualization Station daje do tego dwa oddzielne narzędzia i warto rozumieć różnicę: migawki, czyli zamrożony stan maszyny — do trzydziestu dwóch na wirtualkę — oraz backup, czyli pełną kopię z własną retencją i harmonogramem12​. W typowej wirtualce zmienia się na dobę rzędu jednego–dwóch procent bloków. Dla naszych czterech maszyn oznacza to około czterdziestu gigabajtów dziennie zamiast dwóch terabajtów — niespełna 15 TB rocznie zamiast 730. Ten sam dysk, ten sam poziom ochrony, pięćdziesięciokrotnie mniejsze zużycie.

Sześć rzeczy, które robię przy takim zestawie. Wszystkie darmowe poza ostatnią:

1. Migawka plus przyrost jako podstawa. Pełna kopia okresowo, nie dwa razy na dobę.
2. Rozsuń harmonogramy. Nie 00:00 dla czterech zadań. 00:00, 00:40, 01:20, 02:00.
3. Cel kopii na innym nośniku niż dyski wirtualek — najlepiej na talerzach, bo backup to zapis sekwencyjny i talerz robi to dobrze i tanio.
4. Radiator na M.2 i sprawdzenie temperatury pod obciążeniem, nie w spoczynku.
5. Patrz na zapis podtrzymywany, nie szczytowy. Liczba z pudełka opisuje pierwsze trzydzieści sekund.
6. Do wirtualek produkcyjnych: SSD z PLP i DWPD ≥ 1. To jedyna pozycja, która kosztuje, i jedyna, której nie da się nadrobić konfiguracją.

Przerwa na kawę
Odłóż na moment ten tekst i odpowiedz sobie na jedno pytanie, nie zaglądając do panelu: o której godzinie startują wszystkie Twoje harmonogramy? Backup wirtualek. Kopia udziałów. Czyszczenie puli. Migawki. Aktualizacje. Zadania w gościach. Jeżeli w odpowiedzi pojawiła się jedna godzina — a pojawi się, prawie u każdego — to właśnie znalazłeś swoje wąskie gardło. Nie kupując niczego.

[/COLUMNS]

↑ Spis treści​

Ciekawostka​

Nadsubskrypcja to nie oszustwo. To linia lotnicza​

[COLUMNS=2]Muszę w tym miejscu stanąć w obronie producentów, bo z poprzednich rozdziałów mógłby wyjść fałszywy wniosek: że nadsubskrypcja — sprzedawanie większej liczby procesorów wirtualnych, niż mamy logicznych — to jakaś sztuczka. Nie jest. To jeden z najlepszych pomysłów w historii informatyki użytkowej, a jego działanie najlepiej rozumieć na przykładzie zupełnie z innej branży.

Linie lotnicze sprzedają więcej biletów, niż mają miejsc w samolocie. Nie dlatego, że ktoś tam jest nieuczciwy, ale dlatego, że statystyka jest po ich stronie: część pasażerów nie przyjdzie, część przesiądzie się na inny lot, część odwoła podróż. Sprzedaż stu dziesięciu biletów na sto miejsc jest racjonalna i wszyscy na niej wygrywają — pasażerowie płacą mniej, samoloty latają pełne, nikt nie wozi powietrza.

Nadsubskrypcja procesorów działa dokładnie na tej samej zasadzie i jest równie sensowna. Twój Home Assistant przez dwadzieścia trzy godziny na dobę nic nie robi. Debian z reverse proxy budzi się na milisekundy. Windows z programem księgowym pracuje między dziewiątą a siedemnastą i to nie w każdej minucie. Gdyby każdemu z nich trzeba było przypisać rdzeń na wyłączność, wirtualizacja nigdy by się nie przyjęła — i słusznie, bo byłaby marnotrawstwem.

Model jest więc poprawny. Ma tylko jedno założenie.

Że nie wszyscy przyjdą naraz.

I tu, drodzy państwo, tkwi cała różnica między serwerownią a NAS-em w domu albo w małej firmie. W dużym środowisku obciążenie jest zdywersyfikowane: setki maszyn, setki właścicieli, setki niezależnych rytmów. Prawdopodobieństwo, że wszyscy zażądają swojego w tej samej sekundzie, jest bliskie zeru. A na Twoim NAS-ie?

Na Twoim NAS-ie wszyscy przychodzą o 00:00.

Bo tam ustawiłeś backup wirtualek. I kopię udziałów. I aktualizacje. I czyszczenie puli w niedzielę. I migawki. A w środku gości siedzą zaplanowane zadania Windows, których nikt nigdy nie ruszał, i one też startują o północy albo o trzeciej. Nie masz stu niezależnych pasażerów. Masz ośmiu, i wszyscy kupili bilet na ten sam lot, bo wszyscy klikali w to samo domyślne pole w tym samym kreatorze.

Mit z sieci
„Skoro producent pozwala przydzielić dwadzieścia cztery procesory wirtualne na dwunastu wątkach, to znaczy, że tak można.”
Fakt: można — dokładnie w tym samym sensie, w jakim można sprzedać sto dziesięć biletów na sto miejsc. Różnica polega na tym, że linia lotnicza wie, że przesprzedała, i ma na to procedurę. Interfejs wirtualizacji nie ostrzeże Cię ani słowem. Microsoft zdjął formalny limit proporcji ponad dekadę temu5​ i to była decyzja poprawna — tylko przeniosła odpowiedzialność za policzenie z producenta na Ciebie. Nikt Ci tego nie powiedział, bo nie było komu.

Dlatego rozsunięcie harmonogramów o czterdzieści minut potrafi zrobić dla wydajności więcej niż dosypanie pamięci. To nie jest sztuczka dla oszczędnych. To przywrócenie założenia, na którym stoi cały model.[/COLUMNS]

↑ Spis treści​

Księga VII. Twoje wirtualki, moje wirtualki​

[COLUMNS=2]Dosyć teorii. Zejdźmy do tego, co ludzie naprawdę uruchamiają na NAS-ach — bo w tym zestawie jest kilka pozycji, które zachowują się zupełnie inaczej, niż wynikałoby z ich rozmiaru.

▸ Home Assistant — najcichszy zabójca nośników

Zaczynam od niego, bo to dziś najpopularniejsza wirtualka w polskich domach i jednocześnie najlepiej maskująca swoją naturę. Wymagania są śmieszne: dwa procesory wirtualne, 2 GB pamięci — w praktyce daj cztery — i około 32 GB dysku20​. Zużycie procesora bliskie zeru. Wygląda jak najspokojniejszy lokator w budynku.

Tylko że Home Assistant prowadzi rejestrator zdarzeń, który zapisuje do bazy każdą zmianę stanu każdej encji. Trzydzieści czujników temperatury raportujących co pół minuty, kilka wtyczek pomiarowych liczących zużycie prądu w sposób ciągły, trochę czujników ruchu — i masz nieustanny strumień drobnych zapisów w losowych miejscach, dwadzieścia cztery godziny na dobę, przez lata. Dokładnie ten profil obciążenia, o którym mówiła księga V: pojedynczo błahy, w sumie morderczy.

Trzy rzeczy, które załatwiają problem i nie kosztują nic: wyklucz z rejestratora encje, których historii nigdy nie czytasz, ustaw sensowny okres przechowywania, a przy większej instalacji przenieś bazę na MariaDB. Wirtualka po tym zabiegu przestaje pisać bez sensu — i nagle temperatura NVMe spada o kilka stopni bez żadnego radiatora.

▸ Debian — dobra decyzja, o której się zapomina

Debian albo Ubuntu jako host dla kontenerów, reverse proxy, Pi-hole'a, Zabbiksa, Wireguarda. Dwa procesory wirtualne, 2 GB, i to naprawdę wystarcza. Warto tylko wiedzieć, że taka VM-ka rośnie — dziś jest w niej jeden kontener, po roku siedem. Zaglądaj do niej co kwartał zamiast zakładać, że jest taka, jaką ją zbudowałeś.

I jedna uwaga, którą trzeba postawić uczciwie, bo inaczej cały ten tekst byłby sprzedażą wirtualizacji: jeżeli to, co uruchamiasz, jest kontenerem — uruchom to jako kontener. Container Station nie płaci za emulację sprzętu, nie potrzebuje własnego jądra, nie rezerwuje pamięci pod system gościa i nie ma nic wspólnego z problemem współplanowania z księgi II. Pełna maszyna wirtualna jest właściwą odpowiedzią wtedy, gdy potrzebujesz innego systemu operacyjnego, innego jądra albo prawdziwej izolacji. Nie wtedy, gdy potrzebujesz Pi-hole'a.

▸ Windows z Subiektem, czyli korpo stack w małej firmie

Teraz część biznesowa, czyli najczęstszy realny powód, dla którego polska firma w ogóle sięga po wirtualizację na NAS-ie: Subiekt i cała rodzina InsERT-a. Wymagania producenta są skromne — procesor klasy Core2Duo, 4 GB pamięci, około 500 MB na klienta i gigabajt na serwer, Windows 10 od wersji 1809, 11 lub Windows Server, a pod spodem Microsoft SQL Server, w pakiecie w wersji Express21​. Sam producent zaznacza przy tym, że przy większej liczbie jednoczesnych użytkowników wypada pomyśleć o dedykowanym serwerze bazy i pełnej wersji SQL Servera.

Realistycznie na NAS-ie: dwa do czterech procesorów wirtualnych, 8–12 GB pamięci i sto gigabajtów z górką. I trzy pułapki, o których nikt nie uprzedza:

1. Pamięć na stałe, nie dynamicznie. Pamiętasz księgę IV? SQL Server jest aplikacją obsługującą NUMA, a pamięć dynamiczna wyłącza wirtualną architekturę NUMA2​. Wpisz pamięć zarezerwowaną i zapomnij o suwaku.
2. Znaj limity edycji Express, zanim obwinisz sprzęt. Bufor pamięci ograniczony do około 1410 MB, wykorzystanie procesora do jednego gniazda albo czterech rdzeni, a rozmiar bazy do 10 GB — z tym że w SQL Server 2025 podniesiono go do 50 GB23​. To znaczy, że dosypanie wirtualce dwudziestu gigabajtów pamięci nic nie da: baza i tak nie weźmie więcej, niż jej wolno. Zanim dokupisz kość, sprawdź, w co właściwie uderzasz: w licencję czy w krzem.
3. Jednowątkowo, nie wielowątkowo. Zamknięcie miesiąca, wydruk raportu, otwarcie dużej kartoteki — to obciążenia, które biegną w jednym wątku. Nie przyspieszysz ich liczbą procesorów wirtualnych. Przyspieszy je tylko szybszy pojedynczy rdzeń, a o tym jest cała następna księga.

▸ Windows Server z pulpitem zdalnym dla trzech osób

Najcięższa pozycja na tej liście i regularnie najbardziej niedoszacowana. Trzy osoby pracujące zdalnie na jednej wirtualce to nie „trzy razy nic” — to trzy pełne zestawy procesów, trzy sesje graficzne, trzy przeglądarki z dwudziestoma kartami każda. Cztery procesory wirtualne, 16 GB to podłoga, nie sufit (żargonem AI, który mnie irytuje). Jeżeli po tym rozdziale miałbyś zapamiętać jedną rzecz o RDS-ie na NAS-ie: policz to jak trzy komputery, bo tym właśnie jest.

▸ Wirtualka testowa, którą ktoś zostawił włączoną

Wiem, że się teraz uśmiechasz. Ja też — i dlatego ta pozycja jest w tabeli poważnie, a nie dla żartu. Bezczynny gość Windows zużywa mniej niż procent procesora, ale ma zarezerwowaną pamięć, ma swoje zaplanowane zadania, ma Defendera i ma aktualizacje, które startują wtedy, kiedy im pasuje. Microsoft ma na to nawet własny rozdział pod tytułem „działanie w tle” i podaje w nim listę rzeczy do wyłączenia u gościa2​. Ja mam prostszą metodę: wyłącz ją. Naprawdę.

Zbierzmy to w jedną tabelę. Nie jest to lista zakupów, tylko punkt startu — mierzenie, jak zawsze, zaczyna się po uruchomieniu:
[/COLUMNS]

Obciążenie	vCPU	Pamięć	Dysk	Na czym się to naprawdę wywala
Home Assistant OS	2	2–4 GB	32 GB	nie na procesorze — na tysiącach drobnych zapisów rejestratora
Debian / host kontenerów	2	2 GB	16–32 GB	rośnie w czasie; po roku to już nie ta sama wirtualka
Windows 11 do jednego programu	2	8 GB	64 GB	aktualizacje i skaner potrafią zająć całą wirtualkę na godzinę
Windows + Subiekt + SQL Express (1–3 stanowiska)	2–4	8–12 GB	100 GB+	pamięć dynamiczna vs NUMA; limity edycji Express; wydajność jednowątkowa
Windows Server + pulpit zdalny, 3 osoby	4	16 GB	120 GB	to nie jedna maszyna — to trzy komputery w jednym
Router / zapora (np. OPNsense)	2	2 GB	16 GB	przepustowość zależy od karty — tu ma sens SR-IOV albo przekazanie PCIe
VM-ka testowa z zeszłego roku	—	—	—	trzyma pamięć i budzi się o trzeciej nad ranem. Wyłącz ją

↑ Spis treści​

Księga VIII. Jedenaście NAS-ów na stole​

[COLUMNS=2]No i doszliśmy do rozdziału, na który część z Was przewinęła od razu ze spisu treści — i bardzo dobrze, bo to najbardziej praktyczna tabela w całym tekście. Położyłem na stole jedenaście modeli, od najmniejszego dwuzatokowego pudełka po serwer z EPYC-iem, wyciągnąłem z każdego procesor i sprawdziłem, ile naprawdę potrafi.

Zanim jednak spojrzysz na liczby, muszę wyjaśnić, dlaczego są tu dwie kolumny z wynikiem, a nie jedna. Bo od tego rozróżnienia zależy, czy z tej tabeli wyjdziesz z wiedzą, czy z kolejnym mitem.

Wynik wielowątkowy mówi, ile pracy urządzenie wykona łącznie, gdy zaprzęgniesz wszystkie rdzenie. To dobra miara dla kompresji, dla czyszczenia puli, dla transkodowania, dla dziesięciu Linuksów pracujących równolegle. Wynik jednowątkowy mówi, jak szybko urządzenie wykona jedną rzecz. I to on decyduje o tym, czy człowiek siedzący przed pulpitem wirtualki ma poczucie, że komputer działa — bo otwarcie okna, wydruk raportu, zamknięcie miesiąca w Subiekcie i reakcja interfejsu na kliknięcie to obciążenia jednowątkowe.

Wszystkie wyniki pochodzą z bazy PassMark16​ i są odczytem z sierpnia 2026; maksymalne pojemności pamięci — ze specyfikacji producenta24​. Wartości oznaczone znakiem ≈ pochodzą z bliźniaczych wariantów tych procesorów różniących się wyłącznie układem graficznym — na wynik obliczeniowy nie ma to wpływu, ale wolę to zaznaczyć, niż udawać precyzję, której nie mam.[/COLUMNS]

Model	Procesor	Rdzenie / wątki	Wielowątkowo	Jeden wątek	Maks. pamięć
TS-253D	Intel Celeron J4125	4 / 4	2 932	1 152	8 GB
TS-464	Intel Celeron N5105 / N5095	4 / 4	3 987	1 491	16 GB
TS-473	AMD R-Series RX-421ND	4 / 4	3 024	dolna połowa rankingu	64 GB
TS-673A	AMD Ryzen Embedded V1500B	4 / 8	4 513	1 136	64 GB
TVS-675	ZhaoXin KaiXian KX-U6580	8 / 8	3 227	745	64 GB
TS-855X	Intel Atom C5125	8 / 8	8 631	1 486	128 GB
TVS-h674 (i3)	Intel Core i3-12100	4 / 8	≈13 953	≈3 433	64 GB
TVS-h674 / h674T (i5)	Intel Core i5-12400	6 / 12	≈19 555	≈3 486	64 GB
TVS-h1288X	Intel Xeon W-1250	6 / 12	13 668	2 818	128 GB
TVS-h877AX	AMD Ryzen 5 PRO 7645	6 / 12	27 564	3 954	192 GB
TVS-AIh1688ATX	Intel Core Ultra 9 285 (8P + 16E)	24 / 24	57 537	4 896	192 GB
QAI-h1290FX	AMD EPYC 7302P	16 / 32	32 087	1 897	do 1 TB

Proszę spojrzeć na dwa wiersze, które wytłuściłem, bo te dwa wiersze unieważniają wszystko, co przeciętny człowiek zakłada, patrząc na liczbę rdzeni w karcie katalogowej.

Mit z sieci — paradoks pierwszy
„TVS-675 ma osiem rdzeni, a TS-253D tylko cztery — więc do wirtualek jest dwa razy lepszy.”
Fakt: wielowątkowo owszem, jest wyżej. Ale jego wynik jednowątkowy to 745 — najniższy w całej tej tabeli, mniej więcej trzydzieści procent poniżej Celerona J4105 sprzed ośmiu lat, a w rankingu jednowątkowym PassMarka wypada w okolicach czterotysięcznej pozycji na blisko sześć tysięcy skatalogowanych procesorów16​. Praktyczne następstwo jest niemiłe i bardzo konkretne: wirtualka z Windowsem będzie się na tym NAS-ie wlokła niezależnie od tego, ile procesorów wirtualnych jej przydzielisz, bo suwak nie zwiększa szybkości jednego rdzenia. Osiem rdzeni to znakomita rzecz — do ośmiu zadań równoległych. Jeden człowiek klikający w jeden program nie jest ośmioma zadaniami równoległymi.

Mit z sieci — paradoks drugi, i to jest ten, który mnie samego kiedyś zaskoczył
„Wezmę QAI-h1290FX z EPYC-iem, szesnaście rdzeni i trzydzieści dwa wątki — na tym Subiekt poleci jak rakieta.”
Fakt: EPYC 7302P ma wynik jednowątkowy 1 897. Czterordzeniowy i3-12100 z „małego” TVS-h674 ma około 3 433 — czyli niemal dwa razy więcej. Wniosek, który brzmi absurdalnie, a jest po prostu prawdziwy: zamknięcie miesiąca w Subiekcie zrobi się szybciej na tańszym, mniejszym NAS-ie niż na flagowym serwerze AI. EPYC nie jest gorszy — jest inny: zbudowany do trzydziestu dwóch strumieni pracy naraz, nie do jednego szybkiego. Kupując go pod jedną wirtualkę z programem księgowym, płacisz za trzydzieści jeden wątków, których nie użyjesz, i tracisz połowę tego jednego, który Cię interesuje. Słuszność tej tezy udowodnił najdroższy sprzęt w ofercie producenta.

Przypis z laboratorium — zanim porównasz lewą kolumnę Celerona z EPYC-iem
Zajrzałem niedawno do środka samego PassMarka. Linuksowa binarka PerformanceTest nie ma usuniętych symboli, więc dało się z niej wyjąć funkcję liczącą ocenę razem z wagami — i okazało się, że wynik „wielowątkowy” to w istocie średnia harmoniczna dziewięciu podtestów, a jeden z tych podtestów jest… jednowątkowy. Średnia harmoniczna ma zaś tę właściwość, że najsłabszy składnik ciągnie ją w dół najmocniej. Skutek jest przewrotny: im więcej rdzeni ma procesor, tym mocniej o jego wyniku „wielowątkowym” decyduje właśnie ten jeden podtest — na 96-rdzeniowym Threadripperze to już połowa oceny, na 128-rdzeniowym EPYC-u blisko dwie trzecie. Dlatego serwerowy EPYC 9754 ma w bazie ocenę o 30% niższą od Threadrippera, choć rdzeni ma o 32 więcej, a w czystym teście liczb całkowitych idą łeb w łeb. Z samej formuły wynika też twardy sufit: żaden procesor nie przeskoczy około 73 × swojego wyniku jednowątkowego, choćby miał milion rdzeni25​.
Clue: lewa kolumna uczciwie porównuje procesory w obrębie tej samej klasy i generacji — i tylko tak jej tu używamy. Między klasami, Celeron kontra EPYC, waży już zupełnie co innego, więc traktuj ją jak orientację, nie jak ranking. A co dokładnie wyszło z tej binarki — to materiał na osobny felieton.

Rdzenie, które nie są sobie równe​

Jest jeszcze trzecia rzecz, świeża, i będzie się o niej mówiło przez najbliższe lata. Core Ultra 9 285 w TVS-AIh1688ATX ma dwadzieścia cztery rdzenie, ale nie dwadzieścia cztery takie same rdzenie: osiem wydajnościowych i szesnaście energooszczędnych. Maszyna wirtualna nie ma jak zapytać, który dostała. Może trafić na rdzeń wydajnościowy i lecieć, może wylądować na energooszczędnym i być trzy razy wolniejsza — przy identycznym ustawieniu w konfiguracji.

O tym, że to nie moja spekulacja, świadczy dokumentacja Microsoftu, która wśród powodów istnienia trzeciego trybu planowania podaje wprost potrzebę „prawidłowej obsługi przyszłych systemów z heterogenicznymi architekturami rdzeni”1​. Przyszłość, o której pisali, właśnie stanęła w ofercie NAS-ów. Stary problem z księgi II dostał nowe wydanie: kiedyś chodziło o to, czy dostaniesz rdzeń. Teraz chodzi też o to, jaki.

Od starego wyjadacza
Trzy nawyki, które wyniosłem z tej tabeli i stosuję odruchowo. Po pierwsze: podziel wynik wielowątkowy przez liczbę wątków — dostaniesz przybliżoną wartość jednego „miejsca w kolejce” i od razu zobaczysz, czy sprzedajesz krzesła, czy taborety. Po drugie: host też je procesor. ZFS liczy sumy kontrolne, czyszczenie puli chodzi godzinami, migawki mają swój koszt, a jeżeli ktoś w domu włączy film z transkodowaniem, to Twoja wirtualka właśnie dostała nowego, bardzo głodnego sąsiada. Po trzecie: jednowątkowo do ludzi, wielowątkowo do maszyn. Jeżeli przed wirtualką siedzi człowiek — patrz na prawą kolumnę. Jeżeli wirtualka przetwarza w tle — patrz na lewą.

[/COLUMNS]

↑ Spis treści​

Księga IX. A co ja bym dzisiaj zrobił?​

Ta księga jest zbudowana dokładnie tak, jak jej odpowiednik w felietonie o dyskach, i z tego samego powodu: nie znajdziesz tu ani jednej rekomendacji. Znajdziesz opis tego, co sam robię — pod moje obciążenie, mój próg ryzyka i mój budżet. Twój serwer wykonuje inną pracę niż mój, więc traktuj to jak podglądanie cudzych notatek, nie jak instrukcję.

▸ Procesor

Dwa wątki zawsze zostają hostowi. Zawsze, na każdym urządzeniu, niezależnie od tego, ile ich jest. To nie ostrożność, to konieczność — system NAS-a ma swoje procesory wirtualne przypisane na stałe i nie da się ich odłożyć na później.

Na czterech wątkach sprzedaję najwyżej połowę — czyli w praktyce jedną wirtualkę z dwoma procesorami wirtualnymi albo dwie po jednym. Powyżej dwunastu wątków dochodzę spokojnie do proporcji dwa–trzy do jednego, czyli do górnego rejonu tabelki VMware z księgi II — ale ani kroku dalej, i tylko wtedy, gdy widzę w licznikach, że jest miejsce.

Startuję od dwóch procesorów wirtualnych i rosnę tylko na dowodach. To jest ta zasada, którą stosuję najbardziej religijnie i którą najtrudniej sprzedać ludziom, bo jest sprzeczna z odruchem. Nowa wirtualka dostaje dwa. Jeżeli po tygodniu jej własne obciążenie siedzi pod sufitem przy niskim skradzionym czasie — dokładam. Jeżeli skradziony czas jest wysoki, to znaczy, że problem jest po stronie hosta, a dołożenie procesorów pogorszy sprawę, nie poprawi. Nigdy „na zapas”, bo w tej dziedzinie zapas kosztuje opóźnienie.

I mechanicznie, bez zastanowienia: przydział w wielokrotnościach dwóch, zgodnie z zaleceniem Microsoftu2​.

▸ Pamięć

Na QuTS hero najpierw budżet, potem wirtualki. Liczę tak, jak w ramce z księgi IV: odejmuję system, odejmuję ARC, i to, co zostaje, jest moim całym światem. Jeżeli zostaje za mało — przycinam ARC świadomie, wiedząc, że płacę za to wydajnością puli, albo dosypuję kość. Trzeciej drogi nie ma i udawanie, że jest, kończy się ubitym procesem.

Wirtualki z bazą danych — a Subiekt to baza danych — dostają pamięć zarezerwowaną, nie dynamiczną. Wirtualki bezobsługowe, których nikt nie pilnuje, mogą chodzić dynamicznie. Współdzielenie pamięci włączam tylko wtedy, gdy mam kilka niemal identycznych gości; przy zoo różnych systemów to narzut bez zysku.

▸ Dyski i kopie

Dyski wirtualek na SSD z PLP, w lustrze. Cel kopii — gdzie indziej, najchętniej na talerzach, bo backup to zapis sekwencyjny i talerz robi to dobrze i za grosze. Kontroler VirtIO wszędzie, gdzie to możliwe, a przy Windowsie sterowniki wgrywane od razu, przy instalacji, żeby nie było pokusy sięgnięcia po SATA „na chwilę”.

Backup przyrostowo, a harmonogramy rozsunięte. Po księdze VI nie muszę tego uzasadniać.

▸ I jedna rzecz, którą robię raz na kwartał

Wchodzę do środka każdej wirtualki i patrzę na trzy liczby z księgi III. Nie w panel NAS-a. Do gościa. To zajmuje pięć minut na wszystkie i jest jedyną znaną mi metodą, żeby dowiedzieć się o przesprzedaniu, zanim zadzwoni ktoś z firmy. Przy okazji sprawdzam temperaturę M.2 pod obciążeniem, nie w spoczynku — bo w spoczynku wszystko jest zawsze w porządku.

Od starego wyjadacza
Największą poprawę wydajności, jaką w życiu uzyskałem na NAS-ie z wirtualkami, dała zmiana godziny w harmonogramie. Nie procesor, nie pamięć, nie dysk. Cztery zadania startujące o północy rozsunięte na cztery różne godziny. Koszt: zero złotych. I pamiętam, jak trudno było w to uwierzyć człowiekowi, który był już z kartą kredytową w ręku i szukał modelu z EPYC-iem.

Zbierzmy to w drogowskaz. Nie ranking — mapę: co na jakim sprzęcie realnie da się uruchomić:

Klasa sprzętu	Co realnie uruchomisz	Gdzie trzymać wirtualki
2 zatoki, 4 wątki, 8 GB (TS-253D)	jedna lekka wirtualka Linux — albo, uczciwiej, kontenery zamiast wirtualizacji	czym jest, tym jest; NVMe tylko jeśli jest gniazdo
4–6 zatok, 4 wątki, 16–64 GB (TS-464, TS-473, TS-673A)	Home Assistant + Debian; Windows okazjonalnie, nie produkcyjnie	para SSD w lustrze, backup na talerze
8 rdzeni o niskiej wydajności jednowątkowej (TVS-675, TS-855X)	kilka wirtualek Linux równolegle; Windows dla ludzi — niechętnie	para SSD w lustrze
Core i3/i5 lub Xeon, 64–128 GB (TVS-h674, TVS-h1288X)	2–4 wirtualki Windows i kilka Linux; produkcja małej firmy, Subiekt, RDS dla kilku osób	SSD enterprise z PLP w lustrze, kopia na osobnym nośniku
Ryzen 7000 / Core Ultra, 192 GB (TVS-h877AX, TVS-AIh1688ATX)	poważna konsolidacja: bazy, pulpity zdalne, wiele systemów obok siebie	U.2 NVMe enterprise; pula wirtualek osobno od puli kopii
EPYC (QAI-h1290FX)	wiele obciążeń równoległych, kontenery, AI — nie pod jedno szybkie zadanie jednowątkowe	U.2 NVMe enterprise

Masz TS-464 i chcesz Home Assistanta oraz Debiana? To wiersz drugi: po dwa procesory wirtualne na każdę, para SSD, backup przyrostowy o różnych godzinach. I to wystarczy — bez dokupywania czegokolwiek.

↑ Spis treści​

Księga VIII.5. Wysoka dostępność: kiedy wirtualka nie może umrzeć​

Przez długo myśleliśmy, że wirtualizacja na QNAP-ie to rozwiązanie dla hobbyistów. Życzliwe, ale nie dla biznesu. Wtedy w 2025 roku na QuTS hero 5.3.0+ pojawiła się Wysoka Dostępność — natywna replika VM-ki między dwoma fizycznymi NAS-ami.

Zanim jednak wyolbrzymimy znaczenie tego featu, trzeba być szczerze: to nie jest to, na co wygląda. Wirtualka do tego czasu siedziała na jednym dysku, pod jednym kontrolerem. Wysoka Dostępność nie zmienia magicznie tego w multi-master cluster, w którym obie maszyny jednocześnie pracują. To active-passive — zawsze pracuje jedna, druga czeka w pogotowiu.

▸ Jak to działa — po polsku

Dwaj NAS-y są połączeni dedykowanym łączem A-Link, zwykle 10 Gbps. Każda zmiana stanu maszyny wirtualnej — każdy zapis na jej dysk, każda zmiana pamięci — trafia jednocześnie na NAS lokalny i zdalny. To synchroniczny transfer, czyli każdy zapis czeka na potwierdzenie z drugiej strony.

Wynika z tego coś, co producent nie pisze dużymi literami: wydajność pada do poziomu wolniejszego łącza. Nawet jeśli A-Link ma 10 Gbps, a wirtualka generuje 100 MB/s zapisu, to każdy bajt idzie tam i z powrotem, a każdy transport czeka na ACK z drugiej strony. To nie jest bezkarnie.

W skrócie
Wysoka Dostępność dla wirtualek to nie redundancja procesora — to redundancja dysku. Jeśli NAS z wirtualką upadnie, druga kopię wznawia w sekundę. Ale obie VM-ki nigdy nie pracują równocześnie — poza tym przepada gwarancja spójności danych.

▸ Gdzie to ma sens?

SQL Server produkcyjny. Home Assistant z trzema latami historii, którą nie chcesz tracić. Kontener Dockera, który synchronizuje stan do bazy między startem i zamknięciem. Wszystko, co działa w single-threaded loop i nie ma w sobie wbudowanej replikacji.

Gdzie to nie ma sensu? Serwer gier. Wielowątkowe transkodowanie video. Cokolwiek, co używa dużo I/O i ciężko by to znosiło opóźnienie synchronizacji. Tutaj wirtualka byłaby wolna z powodu samego łącza, a nie braku procesorów.

▸ Koszt: pamięć i sieć

Każda VM w HA zajmuje tę samą pamięć na obu maszynach. Jeśli masz Windows Server 8 GB na lokalnym, to Windows Server 8 GB musi być zarezerwowany i na zdalnym — nawet jeśli nie pracuje. Pamięć nie jest współdzielona — to jest kopia pełna.

Sieć A-Link nie może być tym samym łączem, co administracja czy wirtualki — bo wtedy każdy zapis wirtualki czekałby w kolejce za backupem lub skanowaniem. Dedykowane 10 Gbps między NAS-ami. To koszt, ale ucziwy.

Failover i co się dzieje, gdy lokalny upadnie​

Kiedy NAS lokalny (ten, na którym pracuje maszyna) straci zasilanie, routing automatycznie przenosi VM na zdalne urządzenie. W normalnych warunkach to trwa kilka sekund — system musi sprawdzić, czy łącze A-Link jeszcze żyje, czy to na pewno awaria, czy tylko przyrżnięte kable.

Ale tu jest punkt zapytania: kiedy się obudzi VM na zdalnym NAS-ie, jej dysk zawiera stan ostatniej synchronizacji. Jeśli ostatnia transakcja bazy danych nie zdążyła być potwierdzana, ginie. Jeśli aplikacja robi batch job — ginie. Nie jest to zero-downtime failover. To raczej „szybki failover z możliwością straty ostatnich sekund".

Dlatego — i to jest ważne — Wysoka Dostępność dla VM-ki nie zastępuje aplikacyjnej replikacji. SQL Server z zawsze włączonym (Always On) robi swoją własną synchronizację baz przez własne łącze. Wtedy High Availability QNAP-a jest warstwą pod spodem: jeśli SQL Server przpadnie z powodu upadku maszyny — VM się podnosi. Jeśli SQL będzie miał duplikat synchronizowany na zdalnym serwerze — dane są bezpieczne.

↑ Spis treści​

Księga IX.5. Scenariusze: co się stanie, gdy dam 4 rdzenie na...?​

Zamiast abstrakcji, zobaczmy co się rzeczywiście dzieje w typowych zastosowaniach. Wezmę od każdego cztery procesory wirtualne — tak chyba myśli większość ludzi o „godnym" przydziale — i sprawdzę co się stanie.

▸ Routing i usługi sieciowe (PPPoE, forwarding)

Cztery rdzenie dla routera to nie mało. WireGuard, OpenVPN, qBittorrent czy Pi-hole — każda z tych usług to pojedynczy thread, czasem kilka. Ale oto problem, który wszyscy pomijają: sieć to streaming. Pakiety przychodzą w strumieniu — czasem bursty, ale uśrednioną przepustowością.

Jeśli dajesz PPPoE upstream 1 Gbps, a download 500 Mbps — i chcesz to wszystko przetworzyć (NAT, firewall rules, VPN encryption) — teoretycznie jeden procesor wystarczy. Ale burst może zajść w pięćset nanosekund, a wtedy nagle cztery rdzenie pracują. Otwierasz 20 nowych TCP connections o 00:00 — pojawia się burst, VM się dławiła, wszystko czeka.

Rozwiązanie? Hardware offloading. Na x86_64 z QNAP, pytanie brzmi: czy dany NAS obsługuje offloading do NIC-u (network interface card)? To zależy od kontrolera sieciowego. Intel NICs obsługują TSO (TCP Segmentation Offload), rzadko coś więcej. RouterOS nie ma dobrej obsługi offloadingu na x86_64 — lepiej byłaby dedykowana linux bota z bnx2x lub mlx4 driver'em. Ale to już nie „mały NAS" — to serwer sieciowy.

Wniosek dla routingu
Cztery rdzenie wystarczą na „przyzwoity" router domowy. Ale jeśli chcesz Gigabita pełnoprawnie — bez fragmentacji pakietów, bez burstów opóźniających się na koleję VPN-a — potrzebujesz w ogóle innego sprzętu. RouterOS na Virtualization Station to przygoda edukacyjna, nie biznes.

▸ Transkodowanie wideo (H.264, H.265, NVENC)

Cztery rdzenie CPU dla kodowania wideo. Powiedzmy, że masz serwer Plex lub Jellyfin, który koduje on-the-fly dla klienta na niskiej przepustowości.

Realistyczne liczby: jeden stream H.264 na 1080p 8 Mbps zajmuje około dwóch wątków CPU (zależy od profilu). Cztery rdzenie — to teoretycznie dwa równoczesne streamy. W praktyce? Jeden stream będzie psuty, bo harmonogramowanie wirtualki będzie rozdargniętę między oczekiwaniem na dysk, wczytywaniem GOP (Group of Pictures), i samym kodowaniem.

Ale jest haczyk lepszy: NVENC. GPU Nvidia robią H.264/H.265 bez procesora. Problemy:
1. Virtualization Station nie obsługuje GPU passthrough na kvmie — GPU pozostaje hostem
2. Nawet jeśli obsługiwałoby — ile VM-ki mogłyby dzielić jeden GPU? Zazwyczaj jedna.
3. Na x86_64 NAS-ach QNAP nie ma GPU Nvidia, są tylko zintegrowane iGPU (Intel UHD, AMD Radeon). Te mogą kodować, ale są ograniczone do jednego streama jednocześnie.

Wynik: daj pięć–sześć rdzeni, jeśli naprawdę chcesz transkodowanie live na VM-ce. I pamiętaj, że dyskiem może być wąskim gardłem wcześniej niż procesorem — zwłaszcza jeśli masz dwa rdzenie dla VM-ki jako read source (filesystem) i cztery dla VM-ki jako encoder. Wszystko jest wpięte do tej samej puli ZFS.

▸ Bazy danych — MySQL, PostgreSQL, MariaDB

Baza danych na VM-ce to popularny scenariusz w małych firmach. Subiekt nexo z SQL Server Express, WordPress z MariaDB, Gitea z PostgreSQL.

Cztery rdzenie? Za mało i za dużo zarazem.

Za mało: bazy danych robią rzeczy równolegle. Każdy request klienta to osobny thread, tymczasem w tle działa compaction (w SQLite), vacuum (w PostgreSQL), index rebuild (wszędzie). To dobrze, że są cztery wątki do dystrybucji. Ale jeśli każdy z nich siedzi przez 30% czasu w oczekiwaniu na we/wy (I/O wait) — to tylko jeden realnie pracuje, a trzej czekają.

Za dużo: jeśli masz tabelę 10 GB, to baza danych będzie chciała ją cachować w pamięci. Pamięć dynamiczna wyłączy NUMA — to oznacza, że każdy dostęp do pamiętki będzie przez fabric, a nie local, i będzie wolniejszy o 30%. Lepiej dać zarezerwowaną pamięć (4-8 GB dla VM-ki), którą baza widzi w topologii NUMA.

Strategia dla baz danych
Daj cztery rdzenie — ale zarezerwowaną pamięć. Nie dynamiczną. Patrz na slow-query log, nie na CPU monitor. Jeśli query biegnie 2 sekundy, to nie będzie wolniejszy na dwóch rdzeniach — będzie dokładnie tyle samo czasu, bo siedzi nad dyskiem. Jeśli query biegnie 50 ms, to dodatkowy rdzeń może pomóc.

I najważniejsze: backup bazy to nie pełna kopia całej VM-ki. To mysqldump albo pg_dump — dane na innym nośniku, zdekompresowane, bez WAL (write-ahead log). To 50-100x mniejsze zapisy niż backup VM. Używaj tego.

▸ Serwery gier — czemu to słaba idea

Serwer gry — Counter-Strike, Minecraft, Valheim, cokolwiek. Cztery rdzenie dla VM-ki.

Teoretycznie wystarczy. Praktycznie? Latencja. Gracz klika myszkę, pakiet IP trafia do serwera, serwer przetwarza, wysyła odpowiedź. Na fizycznym sprzęcie: <10 ms. Na VM-ce z hypervisorem w drodze?

Steal time. Każdy millisekund jest cenny. I tu pojawia się problem, którego artykuł nie poruszył:

„Jaki procent ruchu IP można przenieść do wirtualki?"

W typowej konfiguracji QNAP Virtualization Station, NAS zarządza siecią. Każdy pakiet który wchodzi do VM-ki musi przejść przez — jeśli VM-ka ma VirtIO NIC — vrho_net w hipernadzorcy. To kawałek CPU hosta. Każda operacja synchronizacji, każdy interrupt sieciowy — to CPU hosta.

Praktycznie: jeśli serwer gry generuje 100 000 pakietów na sekundę (realistycznie dla 30 graczy), każdy interrupt to ~ 10-100 mikrosekund CPU hosta (zależy od architektury). To może być 1-10% CPU hosta samego w sobie. A VM z grą siedzi w kolejce, czekając na to.

Wynik: gry nie są dobrym celem dla wirtualizacji. Jeśli musisz — wybierz sprzęt z dużą przepustowością sieciową (10 Gbps, dedykowany interrupt affinity, może przydać się SR-IOV) i przygotuj się na to, że VM będzie miała steal time w granicach 5-15% pod pełnym obciążeniem.

↑ Spis treści​

Addendum: Fizyka radiatora na dysk NVMe​

Dla ludzi stawiających radiatory na SSD-y z rozpędu: radiator zawsze odprowadza ciepło z dysku, ale z zastrzeżeniem.

Radiator pasywny to kawałek metalu — zwykle aluminium — o dużej powierzchni. Ciepło z dysku przechodzi do radiatora (kondukcja), a potem rozprasza się do otaczającego powietrza (konwekcja).

Ale w obudowie QNAP-a, która jest zamknięta, powietrze jest limitowane. A obudowy wiele NAS-ów nieznośnie słabo wentyluje M.2. Radiator może odprowadzić ciepło na dokładnie 2 cm w każdą stronę — całą resztę pochłania obudowa.

Nowo-fakt: jeśli radiator jest biały/czarny (nieprzewodzący prąd), to może nawet przytrzymać ciepło bardziej niż bez niego, jeśli obudowa nie ma aktywnego przepływu powietrza tuż przy nim. To paradoks, bo radiator „działa", ale kiedy wewnątrz obudowy jest 40 °C w stanie spokojnym, dodanie radiatora może przesunąć problem z dysku na radiator, a stąd nigdzie.

Wskazówka: zamiast radiatora
Czysty przepływ powietrza. Jeśli wentylatory NAS-a są skierowane na M.2 — wystarczy. Jeśli nie — radiator to ulepszenie, ale nie rozwiązanie. Najlepsze dyski enterprise do QNAP-a (Samsung PM9A3, Kioxia PM7-R, SK Hynix PE8110) mają wbudowany radiator i temperaturę pracują w 35-50 °C w normalnym workloadu bez dodatkowego chłodzenia.

↑ Spis treści​

Addendum: Dyski enterprise do wirtualek​

„Konsumencki dysk to 600 TBW, podaję pełną kopię co 12 godzin, umiera po 3 miesiącach."

Jest lepszy wybór. Dyski enterprise do wirtualek mają inne parametry:

Model	Typ	DWPD	Pojemność	Temp. pracująca	Zysk vs konsument
Samsung PM9A3	NVMe U.2	8 DWPD	960 GB – 1.92 TB	0–55 °C	Pełna kopia VM 250 GB co 4h, zamiast co 12h
Kioxia PM7-R	NVMe U.2	10 DWPD	960 GB – 1.92 TB	0–60 °C	Backup 500 GB co 2h bez degradacji
SK Hynix PE8110	NVMe M.2	5 DWPD	512 GB – 1.6 TB	0–70 °C	Stabilny zapis sekwencyjny bez throttlingu
Konsumencki (ref)	NVMe M.2	~0.3–0.5 DWPD	1–2 TB	0–60 °C (throttling od 70)	Baseline

[COLUMNS=2]Wszystkie dyski enterprise mają PLP — Power Loss Protection. Kondensatory pozwalają kontrolerowi dokończyć zapis nawet jeśli zasilanie pada. To jest konieczne dla VM-ki — baza danych nie może tracić fragmentu tablicy mapowania.

Rekomendacja dla produkcji
Jeśli masz małą firmę z Subiektem czy Gitea: Samsung PM9A3 960 GB w lustrze na puli wirtualek. Każdy dysk — 960 GB, razem 1.92 TB pojemności, RAID 1 pod maską. Kopia zapasowa co cztery godziny, nie co dwanaście. Koszt? Dwa dyski × 300–400 zł ≈ 600–800 zł zamiast 100 zł za konsumencki. Zysk? 12 lat gwarancji zamiast 5, DWPD 8 zamiast 0.3, i po trzy miesiące nie czytasz artykułu „dysk mi zmurł".

[/COLUMNS]

↑ Spis treści​

Addendum: Jak PassMark mierzy różne rzeczy dla różnych procesorów​

Przy porównywaniu EPYC-a z Celerom-iem w tabelce (linia Księgi VIII) trzeba znać, co mierzy się naprawdę. Zajrzałem do binarki PassMark'a — linuksowa wersja nie ma usuniętych symboli, więc można odtworzyć funkcję liczącą wynik razem z wagami.

Okazało się, że CPU Mark to nie średnia arytmetyczna dziewięciu podtestów. To średnia harmoniczna — czyli suma odwrotności. To ma konsekwencje.

📐 Formuła mierzyła coś innego
Średnia harmoniczna 1/(suma_(i=1..9) 1/(X_i · W_i)) ma czarowną właściwość: najsłabszy składnik ciągnie ją w dół najmocniej. W PassMark-u jeden z dziewięciu podtestów to test jednowątkowy — który z definicji nie rośnie od dodawania rdzeni. To znaczy, że im więcej rdzeni ma procesor, tym mocniej wynik „wielowątkowy" decyduje się na podstawie tego jednego podtestu.

Realne liczby:

• EPYC 9754 (128 rdzeni): wynik jednowątkowy waży 62,8% całej oceny
• Threadripper PRO 7995WX (96 rdzeni): wynik jednowątkowy waży 52,3%
• Ryzen 9 9950X (16 rdzeni): 19,2%
• Celeron N5105 (4 rdzenie): 3,7%

Zmiana siedemnastokrotna. Porównywanie oceny Celerona z oceną EPYC-a to porównanie zupełnie różnych rzeczy — pierwszy wiersz to test mnożenia macierzy, drugi to wydajność jednowątkowa.

▸ Praktyka: jaki jest sufit?

Z formuły wynika również, że żaden procesor nie przeskoczy około 72,9 × swojego wyniku jednowątkowego, choćby miał milion rdzeni. To nie asymptota — to twardy sufit matematyczny. Współczesne 128-rdzeniowe procesory są już na połowie drogi do niego.

Przykład: Threadripper PRO 7995WX ma wynik jednowątkowy 3 831 i ocenę 141 091. Sufit dla tego wyniku to 279 262 — czyli już jest na 50,5% sufitu. Zwiększenie do 256 rdzeni podniosłoby ocenę na ~160 000, czyli byłoby to przyrost 12,5%, a rdzeni byłoby 2,67× więcej. Każdy dodatkowy rdzeń po pewnym punkcie daje coraz mniej.

Wniosek: ta tabela w Księdze VIII, porównując lewą kolumnę (PassMark) między wierszami, jest uczciwa tylko w obrębie tej samej klasy sprzętu — nie między klasami. Celeron kontra EPYC, pojedyncza wirtualka kontra serwerownia — tam już tabela mierzy apples to oranges i powinna być traktowana jako orientacja, nie ranking.

Kiedy tą tabelą można się kierować
Porównuj procesory w tej samej generacji i tej samej klasie — tam rozdział „głosów" między podtestami jest podobny, więc liczby rzeczywiście mierzą to samo. Między klasami — use your brain.

↑ Spis treści​

Księga X. Kodeks starego wyjadacza​

Dziesięć zasad, które zostają po lekturze

1. vCPU to nie rdzeń. To obietnica, że kiedy przyjdzie Twoja kolej, dostaniesz rdzeń.
2. Szeroka wirtualka czeka dłużej niż wąska. Zawsze.
3. Hipernadzorca nie tworzy zasobów. Dzieli te, które fizycznie istnieją.
4. Jednowątkowo do ludzi, wielowątkowo do maszyn. Liczba rdzeni na pudełku nie mówi ani jednego, ani drugiego.
5. Skradziony czas mieszka w gościu, nie w monitorze hosta. Kto patrzy tylko na panel, nie zobaczy go nigdy.
6. Wysokie oczekiwanie na we/wy to nie obciążony procesor. To stojący procesor.
7. Pamięci nie nadsubskrybujesz bezkarnie — a na ZFS-ie stoisz w kolejce za ARC-iem.
8. Pełny backup co dwanaście godzin to nie ostrożność. To zużycie z harmonogramem.
9. Najpierw dowód, potem vCPU. Nigdy odwrotnie i nigdy „na zapas”.
10. Na fizykę rdzeni nie ma IDCLIP-a.

Największym błędem nie jest zresztą przydzielenie za dużo procesorów wirtualnych. Największym błędem jest przydzielenie właściwej liczby z niewłaściwego powodu — bo wtedy nawet trafna decyzja niczego nas nie uczy i przy następnej wirtualce zaczynamy od zera.

A na koniec wróćmy do początku. W krainie wirujących światów pytanie brzmiało: „jaki dysk kupić?”. W krainie pożyczonego czasu brzmi: „ile mu dać?”. I w obu przypadkach prawdziwa odpowiedź jest ta sama, tylko nikt jej nie chce usłyszeć: a co ta maszyna ma właściwie robić? Ja swoje wirtualki poukładałem tak, jak opisałem w księdze IX, i nadal nie umiem rozstrzygnąć jednego: czy w małej firmie lepiej postawić jedną mocną wirtualkę i wpuścić do niej trzy osoby przez pulpit zdalny, czy trzy oddzielne i mieć spokój z izolacją. A Wy jak to macie? Ile wirtualek trzyma Wasz NAS, ile im dajecie, i czy kiedykolwiek sprawdziliście u siebie skradziony czas? Ktoś rozsunął harmonogramy i zobaczył różnicę — czy nadal wszystko startuje o północy? Piszcie w komentarzach. Bo to jest forum — tu artykuł się nie kończy. Tu się dopiero zaczyna.

PS. Elvis ma się dobrze. Dostał dwa procesory wirtualne i pamięć zarezerwowaną. Twierdzi, że nigdy nie czuł się lepiej.​

↑ Spis treści​

Epilog. A co z tymi TOPS-ami?​

Na koniec zostawiłem sobie rzecz, którą mówię niechętnie.
Ale powiem.

Bo przez cały ten tekst tłumaczyłem, że liczba rdzeni nie jest wydajnością.
A z tego wynika drugie zdanie, które nikomu się nie spodoba.

W felietonie o dyskach napisałem, że przez dwie dekady kupowaliśmy naklejki.
Że kolor obudowy miał zastąpić kartę katalogową.
Że prawdę mówiło dopiero firmware.

W świecie procesorów ta naklejka nazywa się: liczba rdzeni.

I działa dokładnie tak samo.
Bo „ośmiordzeniowy NAS” brzmi lepiej niż „czterordzeniowy”.
Nawet wtedy, gdy ten ośmiordzeniowy ma jednowątkowo siedemset czterdzieści pięć,
a czterordzeniowy — trzy i pół tysiąca.

Virtualization Station widnieje na listach funkcji modeli,
w których jedna wirtualka z Windowsem nie ma najmniejszych szans.
I formalnie wszystko się zgadza.
Procesor ma VT-x. Aplikacja się instaluje. Wirtualka wstaje.
Tylko nie działa.

Mam z tym problem — ale nie dlatego, że ktoś kłamie.
Nikt nie kłamie.
Po prostu nikt nie dopisuje drugiego zdania.

A potem przyszły TOPS-y.

Trzydzieści sześć TOPS. Na pudełku. Dużą czcionką.
„AI i wirtualizacja” w jednej linijce specyfikacji,
jakby to były dwa zawody, które można wykonywać tym samym mięśniem.

Nie można.

Jednostka NPU nie policzy Subiekta.
Nie zamknie miesiąca.
Nie wystawi faktury.
Nie obsłuży trzech pulpitów zdalnych.
Nie przyspieszy Twojej bazy danych ani o jedną milisekundę.
Ona rozpoznaje twarze na nagraniach z kamer.
I robi to znakomicie.
To wszystko.
I nie jest to zarzut — to specyfikacja.

Ja widzę to tak:
naklejka przeniosła się z koloru obudowy na liczbę rdzeni,
a z liczby rdzeni na TOPS-y.
Za trzy lata będzie coś jeszcze.
Zawsze jest coś jeszcze.

Proponuję więc prosty eksperyment, taki jak przy tamtym artykule.
Weźcie kartę katalogową swojego NAS-a.
Wypiszcie z niej procesor.
Wpiszcie jego nazwę w bazę benchmarków.
I spójrzcie na kolumnę jednowątkową.
Nie na tę pierwszą, dużą i ładną.
Na tę drugą.

A potem zadajcie sobie jedno pytanie:
ile TOPS-ów potrzebuje Subiekt?

Odpowiedź brzmi: zero.
Potrzebuje jednego szybkiego rdzenia i dysku, który nie kłamie.

Sprzęt można kupić dwa razy.
Godzin, w których firma nie fakturuje, bo „wirtualka wolno chodzi” — już nie.

A licho nie śpi.
Bądźcie czujni, robaczki!

↑ Spis treści​

Słownik pojęć — po polsku, tak jak mówi Microsoft​

Wirtualizacja jest dziedziną, w której polskie nazwy powstały raz i na dobre — a ustalił je Microsoft w dokumentacji Hyper-V. Trzymam się ich w całym tekście, bo jeżeli mamy się na forum rozumieć, musimy mówić jednym językiem. W lewej kolumnie termin polski, w środkowej angielski, którym i tak posługuje się każdy interfejs, w prawej — co to znaczy naprawdę.

Po polsku (Microsoft)	Po angielsku	Co to znaczy naprawdę
rdzeń	core	fizyczna jednostka wykonawcza w krzemie. Jedyna rzecz, której nie da się namnożyć
wątek	thread	strumień instrukcji
jednoczesne wielowątkowanie (SMT)	simultaneous multi-threading	jeden rdzeń obsługuje dwa wątki. Zysk „niewielki”, czasem żaden, czasem ujemny — słowa producenta
procesor logiczny	logical processor	to, co system hosta liczy jako procesor: rdzeń albo jego wątek SMT
procesor wirtualny	virtual processor (vCPU)	to, co przydzielasz gościowi. Nie rdzeń — miejsce w kolejce po rdzeń
hipernadzorca	hypervisor	warstwa dzieląca sprzęt między gości. Nie tworzy zasobów — dzieli je
partycja główna	root partition	system operacyjny hosta. Ma swoje procesory przypisane na stałe i nie oddaje ich
partycja podrzędna	child partition	maszyna wirtualna gościa
klasyczny harmonogram / harmonogram rdzeni / harmonogram główny	classic / core / root scheduler	trzy tryby rozstrzygania, kto i kiedy dostaje rdzeń
nadsubskrybowanie	oversubscription, overcommit	sprzedanie więcej, niż jest. Sensowne — dopóki nie wszyscy przyjdą naraz
pamięć dynamiczna	dynamic memory	pamięć wg bieżącej potrzeby. Wyłącza wirtualną architekturę NUMA
pamięć zarezerwowana	reserved memory	gwarantowane minimum. Jedyna realna ochrona przed sąsiadami
udziały	shares	kto wygrywa, gdy zabraknie dla wszystkich
wirtualna architektura NUMA	virtual NUMA (vNUMA)	pokazanie gościowi topologii pamięci. Korzysta z tego m.in. SQL Server
usługi integracji maszyn wirtualnych	integration services	sterowniki, dzięki którym gość nie płaci za emulację sprzętu. U nas ich odpowiednikiem jest VirtIO
koligacja procesorów	CPU affinity	przypisanie zadania do wskazanych procesorów
czas gotowości	CPU ready time (%RDY)	gotów pracować, nie dostał procesora. Cel: poniżej 5% na procesor wirtualny
czas skradziony	steal time (%st)	rdzeń poszedł do kogoś innego. Widoczny wyłącznie z wnętrza gościa
oczekiwanie na we/wy	I/O wait	procesor bezczynny, bo czeka na dysk. To nie jest obciążenie procesora
plik stronicowania	paging file, swap	pamięć udawana dyskiem. Wejście w nią to spadek rzędu setek procent
migawka / punkt kontrolny	snapshot / checkpoint	zamrożony stan maszyny. Nie jest kopią zapasową
działanie w tle	background activity	co gość robi, kiedy „nic nie robi”. Ma u Microsoftu własny rozdział i listę rzeczy do wyłączenia
wąskie gardło	bottleneck	najwęższe miejsce łańcucha. Zwykle nie tam, gdzie patrzysz pierwszy
wzmocnienie zapisu	write amplification	ile bajtów naprawdę trafia na nośnik na każdy bajt wysłany przez gościa. W warstwach mnoży się, nie dodaje

↑ Spis treści​

Słowniczek maga​

A skoro każda gildia ma dwa języki — jeden do dokumentacji, drugi do rozmowy przy kawie — oto ten drugi:

Z gildyjnego słownika

• Harmonogram — Ten, Który Rozdaje. Sprawiedliwy i ślepy: nikogo nie pomija i nikomu nie odmawia. Nie umie tylko rozdać więcej czasu, niż zegar posiada. Po naszemu: planista procesora w hipernadzorcy.
• Obietnica — grzech krainy pożyczonego czasu: obiecać komuś czas, którego nie ma. Nikt Ci tego nie zabroni, suwak po prostu przesunie się dalej. Po naszemu: nadsubskrypcja.
• Skradziony Czas — Ten Trzeci. Nie wiadomo, skąd przychodzi; widać tylko brakujące uderzenia serca. Po naszemu: %st, i mieszka wyłącznie w gościu (księga III).
• Stolik dla ośmiu — rezerwacja, której nie da się posadzić na raty. Dlatego szeroka wirtualka czeka dłużej niż wąska (księga II).
• Plaster sekundy — najcieńsza porcja czasu, jaką da się komuś przydzielić, tak cienka, że program nie zauważa, że przez chwilę go nie było.
• Korek — silnik pracuje, przebieg nie rośnie. Po naszemu: wysokie oczekiwanie na we/wy.
• Wypiek — okno backupu na konsumenckim NVMe: siedemdziesiąt stopni, wentylatory na sto procent i dysk, który zwalnia, im dłużej pracuje (księga VI).
• Kula śnieżna — okno kopii, które rośnie miesiąc po miesiącu, aż spotka następne. Wtedy NAS zapisuje już bez przerwy.
• Linia lotnicza — model nadsubskrypcji: sto dziesięć biletów na sto miejsc. Działa znakomicie, dopóki wszyscy nie zjawią się o północy.
• IDDQD — u nas nadal nazywa się backup. Jedyne prawdziwe zaklęcie, jakim dysponują ziemscy magowie.
• IDCLIP — zaklęcie, którego nie ma. Cztery rdzenie nie wykonają pracy dwunastu, choćbyś klikał najmocniej na świecie.

↑ Spis treści​

Najczęstsze pytania (FAQ)​

Ile procesorów wirtualnych przydzielić jednej maszynie wirtualnej?

Zacznij od dwóch i zwiększaj tylko wtedy, gdy masz dowód, że to pomoże: wysokie obciążenie wewnątrz gościa przy niskim czasie skradzionym. Jeżeli czas skradziony jest wysoki, problem jest po stronie hosta i dołożenie procesorów wirtualnych pogorszy sytuację, a nie poprawi. Przy włączonym SMT Microsoft zaleca przydzielać w wielokrotnościach dwóch. I zostaw hostowi co najmniej dwa wątki — system NAS-a ma swoje procesory przypisane na stałe.

Czy więcej procesorów wirtualnych oznacza szybszą wirtualkę?

Nie, a często wręcz odwrotnie. Hypervisor musi posadzić wszystkie procesory wirtualne danej maszyny w tym samym momencie — im więcej ich jest, tym trudniej znaleźć taki moment. To dlatego maszyna z ośmioma procesorami wirtualnymi na czterowątkowym NAS-ie potrafi być odczuwalnie wolniejsza niż ta sama maszyna z dwoma. Przydzielaj tyle, ile obciążenie realnie wykorzysta, nie tyle, ile pozwala suwak.

Czy uruchomię maszyny wirtualne na NAS-ie z procesorem ARM?

Nie. Virtualization Station wymaga procesora x86 ze sprzętowymi rozszerzeniami wirtualizacji (Intel VT albo AMD-V) i nie ma tu żadnego obejścia — ARM i x86 mają inną listę instrukcji. Dla urządzeń na ARM-ie właściwym narzędziem jest Container Station, która obsługuje zarówno x86, jak i ARM. Jeżeli to, co chcesz uruchomić, istnieje jako kontener — kontener będzie lepszym wyborem także na x86.

Mam 8 GB pamięci. Wystarczy na wirtualki?

Na jedną lekką wirtualkę Linux — tak, ostrożnie. Na Windowsa — nie w sposób, który dałby Ci satysfakcję. Pamiętaj, że od tych ośmiu gigabajtów najpierw odejmuje się system NAS-a, a na QuTS hero dodatkowo pamięć podręczną ZFS. Na urządzeniach z pamięcią 8 GB rozsądniejszym rozwiązaniem są kontenery, które nie rezerwują pamięci pod osobny system operacyjny gościa.

Dlaczego Windows chodzi wolno na moim ośmiordzeniowym NAS-ie?

Bo o odczuwalnej szybkości pulpitu decyduje wydajność jednowątkowa, a nie liczba rdzeni. Przykład z tego artykułu: ośmiordzeniowy procesor w TVS-675 ma wynik jednowątkowy 745 — najniższy w całym zestawieniu jedenastu modeli i wyraźnie poniżej czterordzeniowych Celeronów z tej samej tabeli. Otwieranie okien, wydruk raportu czy zamknięcie miesiąca w programie księgowym biegną w jednym wątku, więc dodanie procesorów wirtualnych ich nie przyspieszy.

Czym jest czas skradziony i gdzie go zobaczyć?

To czas, w którym procesor wirtualny chciał pracować, ale hypervisor oddał rdzeń komuś innemu. W Linuksie widnieje jako kolumna %st w top, vmstat i mpstat. Kluczowa rzecz: zobaczysz go wyłącznie z wnętrza maszyny wirtualnej. Monitor zasobów w QTS pokazuje obciążenie hosta i czasu skradzionego tam nie ma z definicji. Utrzymane powyżej pięciu procent przy odczuwalnych opóźnieniach to już kontencja; powyżej dziesięciu przez dłuższy czas — środowisko zdegradowane.

Mam wysokie oczekiwanie na we/wy. To wina procesora?

Nie — to jego przeciwieństwo. Oczekiwanie na we/wy oznacza, że procesor jest bezczynny, bo czeka na dysk. Dokupienie mocy obliczeniowej nic tu nie zmieni. Szukaj przyczyny w magazynie: wirtualki na dyskach talerzowych (zapis losowy!), emulowany kontroler zamiast VirtIO, wszystkie harmonogramy startujące o tej samej godzinie albo backup, którego okno rozrosło się na tyle, że nakłada się na następne.

Ile pamięci naprawdę zostaje dla wirtualek na QuTS hero?

Znacznie mniej, niż wskazuje specyfikacja. Własny przykład QNAP-a dla maszyny ze 128 GB: około 18 GB zabiera system, następnie 75% pozostałej pamięci idzie domyślnie na pamięć podręczną ZFS, a dla maszyn wirtualnych zostaje około 25 GB — czyli trzy wirtualki Windows Server po 8 GB albo sześć Ubuntu po 4 GB. Udział pamięci podręcznej można obniżyć w globalnych ustawieniach magazynu, ale odbywa się to kosztem wydajności puli.

Home Assistant — maszyna wirtualna czy kontener?

Oba warianty działają; wybór zależy od tego, czy potrzebujesz dodatków systemowych, które wymagają pełnej instalacji Home Assistant OS. Ważniejsze jest jednak coś innego: niezależnie od formy Home Assistant generuje nieustanny strumień drobnych zapisów, bo jego rejestrator zapisuje każdą zmianę stanu każdej encji. To on, a nie procesor, jest tu realnym obciążeniem. Wyklucz z rejestratora encje, których historii nie czytasz, ustaw sensowny okres przechowywania, a przy większej instalacji przenieś bazę na MariaDB.

Da się uruchomić Subiekta z SQL Serverem w wirtualce na NAS-ie?

Tak, i w małych firmach jest to często rozwiązanie w pełni wystarczające. Trzy rzeczy trzeba zrobić dobrze. Po pierwsze: pamięć zarezerwowana, nie dynamiczna — pamięć dynamiczna wyłącza wirtualną architekturę NUMA, z której SQL Server korzysta. Po drugie: znaj limity edycji Express (bufor rzędu 1410 MB, jedno gniazdo lub cztery rdzenie, rozmiar bazy 10 GB, a w SQL Server 2025 już 50 GB) — inaczej będziesz dosypywał pamięć, która i tak nie zostanie użyta. Po trzecie: patrz na wydajność jednowątkową NAS-a, bo zamknięcie miesiąca i wydruki biegną w jednym wątku.

Czy backup wirtualek co 12 godzin zniszczy mi dysk NVMe?

Jeżeli jest to backup pełny, to bardzo prawdopodobnie tak. Cztery maszyny po 250 GB kopiowane dwa razy na dobę to 2 TB zapisu dziennie i około 730 TB rocznie. Konsumencki nośnik 1 TB z wytrzymałością 600 TBW wyczerpuje swój zasób po kilku–dziesięciu miesiącach, a przy realnym wzmocnieniu zapisu nawet po trzech. Rozwiązanie: kopia przyrostowa oparta o migawki, rozsunięte harmonogramy, cel kopii na innym nośniku i — do zastosowań produkcyjnych — dysk z ochroną przed zanikiem zasilania i wskaźnikiem DWPD co najmniej 1.

Czy migawka maszyny wirtualnej to kopia zapasowa?

Nie. Migawka to zamrożony stan maszyny przechowywany obok niej — świetne narzędzie do cofnięcia nieudanej aktualizacji, bezużyteczne przy awarii nośnika, na którym leży, przy zaszyfrowaniu przez ransomware i przy usunięciu maszyny. Virtualization Station daje osobno migawki (do 32 na maszynę) i osobno backup z retencją, i te dwa mechanizmy się nie zastępują. Uwaga praktyczna: migawki nie są dostępne dla maszyn korzystających z przekazywania urządzeń fizycznych ani z dysków wirtualnych na kontrolerze SATA — warto o tym wiedzieć przed utworzeniem maszyny.

↑ Spis treści​

Źródła​

1. Microsoft Learn (pl-pl) — „Zarządzanie typami harmonogramu Hyper-V funkcji Hypervisor”: SMT, mapowanie jeden do jednego partycji głównej, klasyczny harmonogram / harmonogram rdzeni / harmonogram główny, rdzenie heterogeniczne — learn.microsoft.com
2. Microsoft Learn (pl-pl) — „Wydajność procesora Hyper-V”: procesory wirtualne w wielokrotnościach dwóch, usługi integracji, działanie w tle, wirtualna architektura NUMA vs pamięć dynamiczna, SQL Server jako aplikacja obsługująca NUMA — learn.microsoft.com
3. Microsoft Learn (pl-pl) — „Wykrywanie wąskich gardeł w środowisku zwirtualizowanym”: liczniki wydajności, próg 90% dla procesorów logicznych hipernadzorcy, próg 50 ms dla opóźnień magazynu — learn.microsoft.com
4. Microsoft Learn (pl-pl) — „Hyper-V wydajność pamięci”: prawidłowy rozmiar pamięci partycji podrzędnych i głównej, pamięć dynamiczna, plik stronicowania — learn.microsoft.com
5. Microsoft TechNet Wiki — „Hyper-V Concepts: vCPU (Virtual Processor) Q&A”: historyczne 8:1, 12:1 dla VDI, zniesienie formalnego wymogu proporcji, zalecenie 1:1 — learn.microsoft.com
6. VMware vCloud Architecture Toolkit — „Determining an Appropriate vCPU-to-pCPU Ratio”: progi 1:1–3:1, 3:1–5:1, 6:1 — vmware.com
7. House of Brick — „CPU Ready Time Explained: Thresholds, Causes & How to Fix It”: okno 20 000 ms, progi 50 / 300 / 500 ms, współplanowanie szerokich maszyn — houseofbrick.com
8. „Demystifying CPU Ready (%RDY) as a Performance Metric” — reguła poniżej 5% na procesor wirtualny — actualtechmedia.com
9. Materiały o diagnostyce KVM — czas skradziony jako realnie utracone okna wykonania, progi 5% i 10%, efekt „głośnego sąsiada” — cr0x.net
10. Site24x7 — „Understanding and troubleshooting High IOWait in Linux”: czym oczekiwanie na we/wy jest, a czym nie jest — site24x7.com
11. QNAP — „Does my NAS support Virtualization Station?”: KVM, wyłącznie x86, Intel VT / AMD-V, minimum 4 GB, QTS 4.3.4+ / QuTS hero h4.5.0+, brak obsługi ARM — qnap.com
12. QNAP — „How to use Virtualization Station 4?”: procesory wirtualne i model CPU, pamięć maksymalna / zarezerwowana / dynamiczna / udziały, współdzielenie pamięci, kontrolery IDE/SATA/VirtIO, migawki do 32 na maszynę, przekazywanie PCIe i USB, SR-IOV, ograniczenia migawek — qnap.com
13. QNAP — „How many virtual machines can I deploy in Virtualization Station on QuTS hero?”: arytmetyka 128 GB → ~18 GB systemu → 75% na ARC → ~25 GB dla maszyn wirtualnych — qnap.com
14. QNAP — „How QuTS hero NAS reacts to memory exhaustion and what to do about it”: spadek skuteczności ARC, procesy w nieprzerwanym oczekiwaniu na we/wy, przymusowe ubijanie procesów także nie-ZFS-owych — qnap.com
15. QNAP — Virtualization Station 4.1 i wysoka dostępność maszyn wirtualnych (beta, wyłącznie QuTS hero 5.3.0+) — qnap.com
16. PassMark Software, cpubenchmark.net — wyniki CPU Mark i Single Thread Rating dla wszystkich procesorów z księgi VIII; odczyt: sierpień 2026 — cpubenchmark.net
17. simplyblock — „Write Amplification”: definicja współczynnika, mnożenie narzutów w zagnieżdżonych warstwach kopiowania przy zapisie, wpływ częstych migawek — simplyblock.io
18. Lexar — „Understanding TBW and SSD Endurance”: TBW, przeliczenie na realną wytrzymałość przy wzmocnieniu zapisu — lexar.com
19. „NVMe SSD Temperature Guide for NAS”: próg 70 °C i wentylatory na 100%, throttling w okolicach 78 °C, zysk z radiatora, zakresy docelowe — storagediskprices.com
20. Home Assistant — dokumentacja instalacji: minimum 2 procesory wirtualne i 2 GB pamięci, obraz maszyny wirtualnej — home-assistant.io
21. InsERT — wymagania systemowe Subiekt nexo (procesor, 4 GB pamięci, obsługiwane systemy, Microsoft SQL Server, zalecenie dedykowanego serwera bazy przy wielu stanowiskach) — insert.com.pl
22. Silas Mariusz, „Procesory fizyczne vs maszyny wirtualne — granica wydajności”, Forum QNAP Polska, 18.12.2017 — pierwotne progi przydziału, czas skradziony, reguła pamięci i degradacja pliku wymiany — forum.qnap.net.pl
23. Microsoft Learn — edycje i obsługiwane funkcje SQL Server: limity edycji Express (bufor pamięci, procesor, rozmiar bazy) — learn.microsoft.com
24. QNAP — specyfikacje sprzętowe modeli z księgi VIII (procesory, maksymalna pamięć, gniazda M.2 i U.2) — qnap.com
25. Analiza własna — formuła i wagi CPU Mark odzyskane z binarki PerformanceTest 11.0 build 1004 dla Linuksa (x86-64/ARM64, tablica symboli nieusunięta), zweryfikowane na dziesięciu opublikowanych wynikach z cpubenchmark.net; średni błąd odtworzenia oceny 1,75% — sierpień 2026
26. — poufne —————————————————————————
27. w oparciu o własną wiedzę i wypracowane schematy diagnostyczne
28. podziękowania dla inżynierów, z którymi rozbierałem to na części — tych obecnych i tych, którzy odeszli
29. — tajemnica poliszynela ——————

↑ Spis treści​

BONUS​

Czas skradziony, oczekiwanie na we/wy i temperatury nośników w jednym kokpicie, na żywo, bez wchodzenia do konsoli — sprawdzicie uruchamiając Live Demo:
StorageDiagLV Workbench w/ Silas Doctor Utilities
(Naprawdę więcej Wam nie trzeba)

ZAGADKA
Obiekt: skarga „wirtualka wolno chodzi, chyba za słaby procesor”.

top - 00:41:07 up 68 days,  4:12,  1 user,  load average: 11,84, 9,62, 7,05
Tasks: 142 total,   2 running, 140 sleeping,   0 stopped,   0 zombie
%Cpu(s):  9,1 us,  4,4 sy,  0,0 ni, 32,7 id, 21,6 wa,  0,0 hi,  0,3 si, 31,9 st
MiB Mem :   2003,4 total,    118,7 free,   1204,9 used,     679,8 buff/cache
MiB Swap:   1024,0 total,     41,2 free,    982,8 used  ⛔

Host:        DEMO_QTS_VS4 (TS-464 · Celeron N5105 · 4 rdzenie / 4 wątki)
Gość:        Debian 12 · 4 vCPU · 2 GB pamięci
Wirtualki:   4 uruchomione · łącznie 14 vCPU przydzielonych  ⛔
Dyski VM:    1 × NVMe 1 TB (konsumencki) · 71 °C · wentylatory 100%  ⚠
Backup:      4 zadania · wszystkie 00:00 · PEŁNE · co 12 h  ⛔
Wynik 1T:    1 491 (PassMark)
────────────────────────────────────────────────────────────────────────
%st  31,9   jedna trzecia obiecanego czasu nie istnieje
wa   21,6   procesor stoi i czeka na dysk
us    9,1   obciążenie użytkownika: dziewięć procent
load 11,84  na czterech procesorach wirtualnych
swap 982 MB z 1024 MB zajęte

Dziewięć procent obciążenia użytkownika.
Jedna trzecia czasu skradziona.
Czternaście procesorów wirtualnych na czterech wątkach.
Cztery pełne backupy o tej samej minucie.
I nikt tego nie zabronił.

Czy tej wirtualce brakuje procesora?
Nie.
Brakuje jej dwóch vCPU mniej i czterdziestu minut przesunięcia w harmonogramie.

Na fizykę rdzeni nie ma IDCLIP-a.

 

[QNAP AI Assistant]

Krótko: tak — ośmiordzeniowy procesor w NAS-ie (albo większa liczba vCPU w VM) może w praktyce działać „wolniej” niż czterordzeniowy, jeżeli kluczowe dla użytkownika obciążenie zależy od wydajności jednowątkowej, pamięci lub I/O, albo gdy hipernadzorca (KVM/Virtualization Station) jest przesprzedany. To samo dotyczy PC — liczba rdzeni nie zastąpi szybkiego pojedynczego wątku, a przy wirtualizacji dochodzą dodatkowe ograniczenia (vCPU to miejsce w kolejce, nie fizyczny rdzeń). NVMe też tu uczestniczy — zarówno jako potencjalne wąskie gardło I/O, jak i element ograniczający żywotność przy nadmiernych zapasach zapisu.

Wyjaśnienie (najważniejsze mechanizmy, bez ściemy)
1) Jednowątkowość vs wielowątkowość

• Dla interakcji użytkownika (pulpit zdalny, Subiekt, otwieranie okien, raporty) decyduje wydajność jednego szybkiego rdzenia (single-thread). Procesory o wielu rdzeniach o niskim IPC/clock mogą mieć słabe wyniki jednowątkowe i dać gorsze odczucie niż CPU z mniejszą liczbą, ale szybszym rdzeniem.
• Wynik wielowątkowy (sumaryczny) nie zastąpi niskiego wyniku jednowątkowego.

2) vCPU ≠ rdzeń; współplanowanie i „skradziony czas”

• vCPU to obietnica: hypervisor musi znaleźć jednocześnie tyle „okien” CPU, ile przydzieliłeś vCPU. Szeroka VM (wiele vCPU) częściej czeka na współplanowanie — „szeroka wirtualka czeka dłużej niż wąska”.
• W Linuksie/KVM szukaj procentu „steal time” (%st) wewnątrz gościa (top, vmstat, mpstat) — to realnie utracony czas CPU. Wartości >5% przy odczuwalnych opóźnieniach to znak rywalizacji o zasoby; ponad 10% przez dłuższy czas to środowisko zdegradowane.
• Monitor zasobów hosta (QTS panel) nie pokazuje %st — trzeba zajrzeć do gościa.

3) Pamięć jest „twardsza” niż CPU — szczególnie na QuTS hero (ZFS)

• QuTS hero (ZFS) przeznacza znaczną część RAM na ARC; przykład z dokumentacji QNAP: z 128 GB fizycznej zostaje ~110 GB po systemie, z czego ~75% idzie na ARC → zostaje ~25 GB dla VM. Dlatego dostępna RAM do sprzedaży vCPU jest mniejsza niż „na papierze”.
• ZFS faworyzuje pamięć: jeśli jej zabraknie, spadnie wydajność puli, rośnie I/O wait i jądro może ubijać procesy. Przed operacjami na pamięci (VM, DB) planuj budżet RAM.
• Na QuTS hero możesz ograniczyć ARC (ustawienie ARC RAM Usage) — to zmiana kosztem wydajności magazynu, ale czasem konieczna.

4) I/O, NVMe i „wzmocnienie zapisu”

• Maszyna wirtualna generuje wiele warstw zapisu (gość -> obraz dysku -> ZFS/RAID -> kontroler SSD), co powoduje write amplification — narzuty mnożą się.
• Konsumenckie NVMe mają ograniczoną trwałość TBW/DWPD i bufor pseudo‑SLC; intensywne, częste pełne backupy (np. 4×250 GB co 12h) zużyją je w miesiącach, nie latach. Termiczne throttlingi (NVMe) dodatkowo wydłużą okna backupów i zwiększą I/O wait.
• Dla VM-ów produkcyjnych używaj nośników enterprise z PLP (power-loss protection) i DWPD ≥1; rozważ mirror (RAID1) dla krytycznych NVMe/U.2.

5) Emulacja vs parawirtualizacja
- Emulowane kontrolery IDE/SATA są kosztowne CPU; VirtIO (parawirtualizacja) znacząco obniża narzut CPU dla operacji I/O. Przy Windowsie instaluj sterowniki VirtIO od razu — inaczej instalator może nie widzieć dysku i ludzie wybierają SATA, płacąc wydajnością.

6) Harmonogramy i backupy — najczęstsze wąskie gardło

• Wiele zadań zaplanowanych o tej samej godzinie (backup VM, kopia udziałów, migawki, aktualizacje, czyszczenia puli) nakłada się i tworzy „wypiek” na NVMe: długie, gorące, ciągłe zapisy → throttling → rosnące okna → dławienie VM.
• Rozsunięcie harmonogramów, używanie migawki + przyrostowego backupu zamiast częstych pełnych kopii, miejsce kopii na innym nośniku (talerze do sekwencyjnych zapisów) redukuje zużycie i I/O wait dramatycznie.

Konkretnie dla QNAP (QTS 5.2.x i QuTS hero 6.x+)

• Virtualization Station wymaga x86 z VT/AMD‑V; ARM nie obsłuży VM Windows — tam są kontenery (Container Station).
• QuTS hero: planuj RAM przed tworzeniem VM (odejmij system i ARC). Na ZFS: jeśli potrzebujesz więcej RAM dla VM, albo dosyp pamięci, albo świadomie przytnij ARC (koszt: wydajność magazynu).
• Przydział CPU: startuj od 2 vCPU na nową VM i zwiększaj tylko przy dowodach (wysokie użycie CPU w gościu przy niskim %st). Przy włączonym SMT przydzielaj wielokrotności dwóch.
• Pamięć: dla baz danych ustaw pamięć zarezerwowaną (reserved), nie dynamiczną — SQL Server korzysta z vNUMA i pamięć dynamiczna wyłącza vNUMA.
• Dyski VM: używaj VirtIO; dla Windows — zainstaluj sterowniki VirtIO.
• Migawki: Virtualization Station daje migawki (do 32/VM) i backup — nie myl ich. Migawki nie są dostępne dla VM z PCI passthrough ani dysków na kontrolerze SATA — planuj z góry.
• HA VM (QuTS hero HA / Virtualization Station HA): to active‑passive synchronizacja zapisu. Ma sens dla krytycznych VM (bazy), ale obniża wydajność (synchroniczny zapis po A‑Link). HA nie zastępuje aplikacyjnej replikacji (np. Always On SQL).

Praktyczne rekomendacje (lista rzeczy do wdrożenia natychmiast)
1) Przydziały CPU

• Dla większości VM start: 2 vCPU. Zwiększ tylko przy dowodzie (gość pokazuje wysokie użycie CPU przy niskim %st).
• Przy włączonym SMT przydzielaj w wielokrotnościach 2.
• Zostaw systemowi NAS co najmniej 2 wątki.

2) Pamięć

• Na QuTS hero: policz RAM = fiz. − system − ARC (domyślnie 75% pozostałego). Jeśli potrzeba, dosyp pamięć lub ogranicz ARC świadomie.
• Dla SQL/Subiekt: daj pamięć zarezerwowaną (reserved), nie dynamiczną.

3) Dysk i backup

• VM produkcyjne trzymaj na SSD enterprise z PLP i DWPD ≥1; konfiguruj mirror/U.2 jeśli możliwe.
• Zamiast pełnych backupów co 12h: migawki + backup przyrostowy/okresowy pełny. Rozsuwaj harmonogramy (np. co 40 min między zadaniami).
• Cel kopii na innym nośniku niż dyski VM (talery są dobre dla sekwencyjnych backupów).

4) Sieć i I/O

• Używaj VirtIO NIC/dysku, usuń emulowane urządzenia w VM.
• Monitoruj I/O wait i temperatury M.2 pod obciążeniem (nie tylko spoczynek). Radiator pomaga tylko przy dobrym przepływie powietrza — najlepsze: kontrolowane chłodzenie wokół M.2.

5) Diagnostyka — co i gdzie mierzyć

• Wejdź do gościa i sprawdź: %st (steal), CPU ready (jeśli hypervisor ma metrykę), I/O wait (wa). To trzy liczniki, które pokażą prawdę.
• Na hoście monitoruj obciążenie CPU logicznych, temperatury dysków, zużycie NVMe (TBW), i kolejki I/O.
• Przy QuTS hero: obserwuj ARC hit ratio; jeśli spada, rośnie liczba bezpośrednich odwołań do dysku.

6) Konfiguracja VM przy Windowsie

• Sterowniki VirtIO zainstalowane przy instalacji (dysk i NIC).
• Wyłącz zbędne urządzenia (emulowane CD, COM) i niepotrzebne usługi (indeksowanie, Defender pełne skany w godzinach pracy).
• Dla SQL Server: pamięć zarezerwowana; sprawdź limit Express (bufor ~1410 MB itp.) zanim dokupisz RAM.

Scenariusze podpowiedzi (skrót)

• Home Assistant na VM: 2–4 vCPU, 2–4 GB, ale uwaga na rejestrator — ogranicz encje i przenieś historię do zewnętrznej bazy (MariaDB).
• Subiekt/SQL Express: 2–4 vCPU, 8–12 GB zarezerwowane; zwróć uwagę na jednowątkową wydajność hosta.
• RDS dla 2–3 użytk.: 4 vCPU, 16 GB+; lepiej szybki jednowątkowy CPU niż masa rdzeni.
• Duża konsolidacja / kontenery / AI: serwer z dużą liczbą rdzeni (EPYC/ryzen), ale nie spodziewaj się, że pojedyncze zadanie jednowątkowe poleci szybciej niż na i3/i5 z wyższym single‑thread.

Ostrzeżenia (ważne!)

• ZAWSZE wykonaj kopię zapasową przed zmianami na RAID/puli/formatowaniu lub przed operacjami na pamięci i konfiguracjach ZFS.
• Nie sprzedawaj pamięci „na zapas” na QuTS hero bez przeanalizowania ARC — to prowadzi do gwałtownego ubijania procesów.
• Nadmierne pełne backupy na konsumenckich NVMe skrócą ich żywotność drastycznie.

Krótka lista kontrolna do natychmiastowego użycia na Twoim QNAP:
1) Dla każdej VM wejdź do środka i sprawdź %st, wa i użycie CPU.
2) Jeżeli %st >5% i VM wolna → zmniejsz vCPU lub rozważ przeniesienie obciążenia; nie dokładaj CPU „na zapas”.
3) Sprawdź harmonogramy backupów/migawek i rozsunięcie ich o co najmniej 20–40 minut; zmień pełne backupy na przyrostowe/migawkowe.
4) Ustaw VirtIO dla dysków i NIC; dla Windows wgraj sterowniki VirtIO przy instalacji.
5) Dla QuTS hero: policz RAM dostępny dla VM (odejmij system i ARC); jeśli za mało → dosyp RAM lub przytnij ARC świadomie.
6) Dla produkcyjnych VM na dyskach: użyj SSD enterprise z PLP i DWPD ≥1; trzymaj kopię na innych nośnikach.

Podsumowanie (jedno zdanie)
Osiem rdzeni na papierze nie równa się lepszemu „poczuciu” responsywności użytkownika — liczy się jednowątkowa wydajność, pamięć dostępna dla VM oraz jakość i organizacja I/O; przy wirtualizacji planuj CPU i RAM rozważnie, używaj VirtIO, enterprise SSD i rozsuwaj harmonogramy backupów, aby uniknąć efektu „wielu krzeseł, których nie ma”.

Jeżeli chcesz, w nowym poście na forum możesz wkleić: model NAS, QTS/QuTS hero i ilość RAM, typ dysków (NVMe/SSD/talerze), obecne przydziały vCPU i harmonogramy backupów — społeczność poda konkretne ustawienia i korekty konfiguracji.

Źródła na forum:

• Procesory fizyczne vs. maszyny wirtualne – granica wydajności!
• Jak korzystać z Virtualization Station?
• QNAP Storage Performance – Najlepsze praktyki dotyczące wydajności pamięci masowej
• Wymagania systemowe Virtualization Station

Ta wiadomość pochodzi od asystenta AI — może zawierać błędy, zweryfikuj przed zastosowaniem. Oceń ją, głosując pod postem: ▲ pomocna lub ▼ nieprzydatna.

Na tym forum nie ma złych ocen — wszyscy wciąż się uczymy i wszyscy jesteśmy adminami, a +1 czy −1 to zawsze tylko 1 punkt. Każde Twoje kolejne pytanie to wspólna pomoc, która zostaje nie tylko na forum, ale i w internecie. Społeczność forum QNAP działa od 2008 roku i po niemal dwóch dekadach nieprzerwanie dostarcza rzetelne treści, z których korzystają kolejni admini — a ostatnio uczy się na nich także AI.