Szerverek összehasonlítása

Szerverek

Sziasztok!

A most használt egyik bérelt szervert lecserélném egy DDR5 RAM-os modernebbre.
A gondom az, hogy az ój gépben a proci csak 2.1 GHz-es, míg a régiben 3.0 GHz-es van---

A gépen 16 VM fut.

  • 2 db Windows Server 2016
  • 1 db Windows Server 2019
  • 3 db Windows Server 2022
  • 6 db e-mail szerver (Debian) (+5 Nextcloud)
  • 4 db Samba fájlszerver (Debian)

Azonos paraméterek:

  • Gen4 NVMe SSD, valószínűlrh ugyan az a márka (Samsung 3.84TB Datacenter),
  • Ugyan annyi RAM (bár az új proci 8 csatornán tudja a RAM-okat kezelni, ezért lehet, hogy teszek még bele),

Pro (az új gép mellett)

  • DDR5 4400 MT/s RAM (DDR4 2933 MT/s helyett)
  • 24 mag (48 thread) 18 (36)  helyett

Con (az új gép ellen:)

  • 2.1 GHz CPU, (3.0)GHz helyett

Átlag 30 felhasználó RDP-n keresztül dolgozik a Windows-okon.
A leginkább erőforrásihényes alkalmazás egy számlázó program az egyik Win 2022-n, valamint egy-egy vállalatirányítási rendszer, amely 2 Wibdiws-on is fut (2016 és 2022), valamint 1-1 Windows szolgálja ki nekik a Firebird adatbázist.

A kérdés, hogy a Workstation CPU-val szemben gyorsabb lesz-e az alacsonyabb működési frekvencia ellenére a Server Gold CPU DDR5 RAM-okkal?

Alapvetően a CPU MHz adata alapot adhatna az egy szálon futó alkalmazások várható sebességére (15-en 32 bites DOS-os programokkal könyvelnek, bérszámfejtenek).
De a CPUBench szerint az Intel Xeon Gold 5412U egy szálon is gyorsabb, mint a Intel Xeon W-2295 @ 3.00GHz.
Milyen ezt elhinni?

Szerk.: Megválaszolom a saját kérdésem: 15-35%-al LASSABB az új szerver, úgyhogy egyelőre marad a régi.

A tesztelt programok és környezet (Proxmox 8.1.4, + ZFS + 128 GB ECC RAM mindegyik gépben).
1. gép:

  • CPU: Intel® Xeon® W-2145 CPU @ 3.70GHz
  • NVME SSD: SAMSUNG MZQLW960HMJP-00003, 960 GB, Gen3
  • RAM: 128 GB DDR4 ECC

2. gép:

  • CPU: Intel® Xeon® W-2295 CPU @ 3.00GHz
  • NVMe SSD: SAMSUNG MZQL23T8HCLS-00A07, 3,84 GB, Gen4
  • RAM: 128 GB DDR4 ECC

3. gép

  • CPU:  Intel® Xeon® Gold 5412U @ 2.10 GHz
  • NVMe SSD: Intel (sajnos nem írtam fel a pontos típust, de az adatlapja szerint írási sebességben lassabb volt, mint a 2. gép Samsungja) , 3,84 GB, Gen4
  • RAM: 128 GB DDR5 ECC

AbevJava betöltési idő 40k+ nyomtatvánnyal:

  1. 51 mp
  2. 21 mp
  3. 26 mp

Két ERP-t is próbáltam. Nem írok nevet.

ERP 1 indulási idő:

  1. N/A
  2. 45 mp
  3. 66 mp

ERP 2 indulási idő:

  1. N/A
  2. 12 mp
  3. 16 mp

VM restore backupból (zst, 102 005 473 280 byte, 19,5% sparse):

  1. N/A (este lehet, hogy letesztelem)
  2. 115 mp
  3. 135 mp
  • 2224 megtekintés

( ppenta | 2024. 01. 25., cs – 09:19 )

PassMark szerint:

Intel Xeon W-2295 @ 3.00GHz Single Thread Rating: 2651

Intel Xeon Gold 5412U @ 2.10GHz Single Thread Rating: 3087

 

Nyilván ez csak egy statikus eredmény... 

Hármas........alá............kettes.........................egyest írtam be.

( zrubi v | 2024. 01. 25., cs – 09:35 )

Szerkesztve: 2024. 01. 25., cs – 09:37

A kérdés, hogy a Workstation CPU-val szemben gyorsabb lesz-e az alacsonyabb működési frekvencia ellenére a Server Gold CPU DDR5 RAM-okkal?

Ja, meg hogy milyen színű a kapitány lányának bugyija? :D

 

erre egyszerűen nem lehet válaszolni, mert erősen függ sokmindentől is, pl:

- mennyire többszálasított az alkalmazás ( a gyakorlatban az ilyen random vackok kb semennyire)

- a RAM sebesség volt-e a szűk keresztmetszet (várhatóan nem)

- az SSD-ből melyik alaplam mennyit tud kihozni?

- stb.

 

így tippre én aszondanám, hogy a nagyobb CPU MHz többet számít, mert az alkalamzások a gyakorlatban nincsenek túloptimalizálva. (így többnyire egy szálon erőből dolgoznak)

De neked most itt a lehetőség, hogy összemérd :) - csak ne gondolt túl az eredményeket, mert kizárólag a te workload-odra lesz csak igaz ;)

zrubi.hu

így tippre én aszondanám, hogy a nagyobb CPU MHz többet számít, mert az alkalamzások a gyakorlatban nincsenek túloptimalizálva. (így többnyire egy szálon erőből dolgoznak)

Kiegészítettem az OP-t a CPUBench linkkel, ami az egész thread apropóját adta,
Tippre én sem cseréltem volna le a 3.0 GHz-es procit 2.1-re, de a tesztek szerinnt az újabb CPU kb. 16%-al gyorsabb egy szálon is.

( zeller | 2024. 01. 25., cs – 09:41 )

Nulladik körben több logikai és fizikai mag, darabonként jobb performanciával. De... Alaposan nézd át, hogy hogyan célszerű/javasolt teljesítményre optimalizáltan feltölteni a memóriafoglalatokat, illetve azt is gondold át, hogy a jelenlegi workload esetén melyik vm mennyi vcpu-t kap, és azt mennyire használja ki - ha valami jelenleg "szűken" fér bele abba, ami van, azt az új környezetben alapból többel indítanám.

( zrubi v | 2024. 01. 25., cs – 09:45 )

mondjuk ha virtualizász - és a Hypervisor tudja a dolgát - akkor a több CPU miatt több cikulus juthat egy-egy VM-nek, ami teljesítményjavulásként mutatkozhat - ha okosan van kiosztva a vCPU a VM-eknek. - szóval itt is nagyon sok a HA, meg az ATTÓL FÚGG ;)

zrubi.hu

( PDA_FAN | 2024. 01. 25., cs – 09:58 )

Szerkesztve: 2024. 01. 25., cs – 10:01

Ez egy tisztán produktív szerver16 VM-mel? Vagy ezen tesztrendszer is van? Mert ha utóbbi, akkor szerintem érdemes két szerverre szétdobni a VM-eket, aszerint hogy produktív-e, vagy teszt. De ha tisztán produktív, akkor is meggondolnám, hogy ne egy szerveren fusson minden.

( arpi_esp v | 2024. 01. 25., cs – 09:59 )

Szerkesztve: 2024. 01. 25., cs – 10:09

gold:  Max Turbo Frequency   3.90 GHz

azert ha kell tud az gyors is lenni.

amugy igen keves olyan muvelet van manapsag ahol tenyleg a cpu a szuk keresztmetszet, a legtobb esetben a memoriara varakozik. az 1.5x memoria sebesseg szerintem tobbet dob a gyakorlatban, mint amit a cpu orajelen bux.

a cput csak addig tudod kihasznalni, amig az adat amin epp dolgozik befer a cache-be. ami nem tul sok ugye...

az ilyen szamlazo meg adatbazis szerver tipusu workloadoknal meg az ssd fog a leginkabb szamitani, ott is foleg az iras, mert minden tranzakciot ki kell synceljen a DB. itt talan erdemes lenne berakni a 4tb ssd melle valami kicsi de tenyleg gyors ssd-t is, amit adatbazisokhoz fejlesztettek (kiss belso blokkmeret, nagy IOPS)

itt talan erdemes lenne berakni a 4tb ssd melle valami kicsi de tenyleg gyors ssd-t is, amit adatbazisokhoz fejlesztettek (kiss belso blokkmeret, nagy IOPS)

A nyitóban azt írta, hogy Gen4 NVMe SSD van a szerverben, aminek elvileg tudnia kellene az optane tempóját, max. a DWPD értéke alacsonyabb.

az optanenak az volt a nagy ujitasa hogy byte (vagy legalabbis pici szektor) meretben lehetett random irni, szemben a nagy ssd-kkel amik altalaban sok megas (64-256MB a maiaknal) tud csak egyszerre. tehat ha 10 byteot modositasz valahol akkor beolvassa azt a 64MB blokkot, eraseli a flashban, modositja a 10 byteot es visszairja az egeszet. hiaba gyors a burst r/w, ha egy DB workloadnal sok pici syncelt/flusholt iras van.

sajat tapasztalat, hogy adatbazis alatt meg egy SAS hdd is gyorsabb tud lenni mint egy SSD, ha sok kis iras van

"sajat tapasztalat, hogy adatbazis alatt meg egy SAS hdd is gyorsabb tud lenni mint egy SSD, ha sok kis iras van"

Ezt sokan nemhiszik el, pedig így van. Tudomásom szerint  optane-t már nem gyártják. De ebben a műfajban(adatbázis ,vm azonnali irás, stb, vagyis  szinron 4-16 K random irás)  tud 300 MB/sec -et.
Ezt csak az optane tudja, a többi  enterprise 60-80 ig jut. NVME egy platform, nem sebesség. Egy sima samsung pro jó ha tud ilyen irásnál 5-6 MB/sec -et.
Samsung DC -kel nincs tapasztalatom. 

https://blog.claryel.hu

Igen, nem plp-s szinkronnál (adatbázis, vm irása )  kénytelen a cellákba írni a nem PLP-s, (ráadásul sokat, iráserősítés )
a plp-s meg mindig RAM-ba ír.
Aszinkron írásnál már nincs lényegi különbség asztali és DC ssd között, pl aszinkron random írásnál, mind a kettő ram-ba ír, -amíg el nem fogy az is)  Egy  asztali nem plp -s Nvme ssd is kénytelen nand-nba írni közvetlenül, 3-5 MB/sec.
Erős io-p esetén nem árt a DC ssd . Ha 20-30 könyvelő ütöget be a számlákat, illetve asztali géphez nem kell.

Optaine meg olyan minőségű volt, hogy perzisztens RAM-ot gyártottak belőle  cache nélkül.
Valamiért nem jött be , nem gyártják már.

https://blog.claryel.hu

( necrolite | 2024. 01. 25., cs – 14:38 )

TS tapasztalatok alapján közelíteném meg elsőként. A magszám/socketek száma sokat számít hogy elkerüld a mágikus context switch is too high hibaüzenetet. Továbbá hogy mennyire használják a GUI-s appok a 3d gyorsítást igénylő elemeket. Ugye a memória sávszélesség nőtt (a bővítésnél figyelj rá hogy annyi modullal bővítsd hogy az ne csökkenjen) illetve hogy egy VM elfér-e egy sockethez tartozó memóriában. Ha nem akkor ugye jön a vicces állapot hogy a 2 socket egymás között beszélget hogy egy VM-et kiszolgáljon ergo a másik cpu és a buszok "feleslegesen" a NUMA miatt lesznek használatban. Ezen felül amikor a CPU magok teljesítményét írják egy szálon az úgy értik hogy turbo módban 3.9ghz de mivel a termikus keret nem változik a többi mag megy alukálni ergo ára van az egy magos extra teljesítménynek. 

( n.balazs v | 2024. 01. 25., cs – 19:23 )

Én leegyszerűsíteném a kérdést: Mit vársz a cserétől? Mi az a plusz, amiért megérheti lecserélni pl: ár, üzleti előny? Mekkora a memória overcommit jelenleg?

Nyilván a cserének / átállásnak is van egy költsége. Jó esetben ez 0 Ft számodra.
Ha áramfogyasztás alapján fizetsz és az új gép kevesebb áramot fogyaszt, akkor nyerhetsz.
A Ghz önmagában semmit sem jelent úgy 15-20 éve. Utasításkészlet, támogatott feature-k számítanak igazán. Plusz szerver CPU-knál az interconnect kapcsolatok száma, sávszélessége.
A virtualizáció memória (sávszélesség) igényes. Overcommit esetén mindenképp fontos a sávszélesség. Viszont ha nincs kihajtva a gép, akkor észre se fogod venni a növekedést.

Szerintem.

Mi az a plusz, amiért megérheti lecserélni

  • Kb. 15%-kal olcsóbb az új szerver,
  • kapok +128 GB RAM-ot. Eddig is be tudtam osztani, de van hová tenni a pluszt. :)
  • rákérdeztem - még nem válaszoltak-, hogy az új szerverben lévő Gen4 NVMe Datacenter SSD ugyan az a típus-e, mint a régiben lévő? Ha igen, akkor nem kell telepítenem, csak átrakatom a régieket, ha nem, és az új gyorsabb, akkor azért lesz jobb nekem. Win-win :D
  • több CPU mag: lásd: RAM-oknál

Nyilván a cserének / átállásnak is van egy költsége. Jó esetben ez 0 Ft számodra.

Még nem tudom, hogy a /29 subnet áthelyezésének van-e díja. A munka, ami az átállással jár, az a hobbim, amiért még fizetnek is. :D

( debtamas88 | 2024. 01. 25., cs – 21:49 )

Szerkesztve: 2024. 01. 25., cs – 21:53 
Intel Xeon W-2295
	https://www.intel.com/content/www/us/en/products/sku/198011/intel-xeon-w2295-processor-24-75m-cache-3-00-ghz/specifications.html
	Launch Date: Q4'19 
	Vertical Segment: Workstation
	Total Cores: 18
	Total Threads: 36 
	Max Turbo Frequency: 4.60 GHz
	Intel® Turbo Boost Max Technology 3.0 Frequency ‡: 4.80 GHz
	Processor Base Frequency: 3.00 GHz
	Cache: 24.75 MB 
	Memory Types: DDR4 2933 

Intel Xeon Gold 5412U 
	https://www.intel.com/content/www/us/en/products/sku/232374/intel-xeon-gold-5412u-processor-45m-cache-2-10-ghz/specifications.html
	Launch Date: Q1'23
	Servicing Status: Baseline Servicing 
	Total Cores: 24
	Total Threads: 48
	Max Turbo Frequency: 3.90 GHz
	Processor Base Frequency: 2.10 GHz
	Cache: 45 MB 
	Memory Types: Up to DDR5 4400 MT/s 1DPC and 2DPC
	High Priority Cores: 8		(p-cores)
	High Priority Core Frequency: 2.30 GHz
	Low Priority Cores: 16		(e-cores)
	Intel On Demand Available Upgrades: 
		- Analytics Suite 1
		- SGX512

 

Fentiek alapján kijelenthető, hogy az újab CPU nem jobb, hanem rosszabb -> (p-cores)  és (e-cores) architektúra

Ezt nem is értem, hogy a szerver CPU oldalon ezt miért csinálják, asztali/laptop-nál érhető, de a szerver esetében homogén magokra van szükség és állandó teljesítményre - inkább AMD procira váltanék.

Azért az Intel nem hülyék gyülekezete. https://www.intel.com/content/www/us/en/support/articles/000094490/proc…

High-priority cores and low-priority cores are related to the Intel® Speed Select Technology. Depending on individual choices and needs, it is possible to set some cores as:

  • Intel® Speed Select Technology - Turbo Frequency: high-priority cores to give them a turbo frequency that exceeds the nominal turbo frequency limits when all cores are active.
  • Intel® Speed Select Technology - Performance Profile: to make them receive the surplus frequency first.
  • Intel® Speed Select Technology – Base Frequency: applying to them a higher base frequency.

A megfelelő ütemező ki tudja használni a két mag típus közötti különbséget.

( WG | 2024. 02. 08., cs – 12:03 )

Szerkesztve: 2024. 02. 08., cs – 12:06

3 napig teszteltem a kiszemelt szervert, de nem váltotta be a hozzá fűzött reményeimet.
Az én esetemben a háttértár sebessége nyomja a legtöbbet a latba(n?) (szvsz). Meg kell várnom, amíg a Gen5 NVMe SSD-k elterjednek és elérhetőek lesznek a hostingnál. Vagy össze kell raknom saját szervert, ha gyorsítani akarok.

A nyitó posztba beírtam néhány teszteredményt.

Köszi mindenkinek, aki foglalkozott a kérdésemmel!

A 3 CPU közül papíron a 2.1 GHz-es a leggyorsabb, ránézésre a 3.7 GHz-es kellebe, hogy legyen, a mérések szerint mégis a 3.0 GHz-es gép veri mindkettőt. A RAM-ok közti sebességkülönbség sem tudta az újabb szerver proci javára billenteni a mérleget.

A gépekben lévő NVMe SSD-k adatlapja szerint a 3.0 GHz-sben lévő Samsung írási sebességben jóval, olvasásiban kissé gyorsabb, mint az újabb gépben lévő Intel.
Készültem egy beszámolóval az SSD-k összehasonlításáról, de más elfoglaltságom miatt sajnos elmaradt és a pontos típusát sem írtam fel az Intel-nek, így nem tudok pontos adatokkal szolgálni.
Az is igaz, hogy az SSD-k között nem volt akkora sebességkülömbség (papírom, mert ezt külön sajnos nem teszteltem), mint amekkora különvséget a teszteredmény mutat. Valószínűleg a kiszemelt újabb proci is lassabb... :(

( ggallo | 2024. 02. 08., cs – 21:38 )

Előre sorry, ha túl offenzív vagyok.

Jól értem, hogy azon megy itt a polemizálás, hogy melyik CPU-val (szerverrel) gyorsabb a felvázolt rendszer, és a kiszemelt kiépítésű teszt rendszerekben van 1 szem CPU, mindössze 128 GB memória és egy szem SSD? Mindezen ZFS? És több Windows szerver, meg 30 RDP kliens? Ez ugye vicc?

Alapjában véve, elolvasva mindent, nem tudom mit szeretne az OP. Velvázolt egy elég komoly hardver igényű VM csomagot és tesztelt hozzájuk három erősebb workstation kategóriájú gépet, egyikben jobb CPU-val.

Az, hogy a CPU mennyi GHz-es, nem áll egyenes arányban sem az egyszálú, sem a többszálú teljesítménnyel. Az, hogy a DDR4-nek meg a DDR5-nek mennyi az elméleti sávszélessége, nem áll egyenes összefüggésben az alkalmazásban/virtualizáció alatt elérhető terljesítménnyel. Az, hogy egy SSD-re mennyi read/write IOPS van megadva, nagyjából semmilyen összefüggésben nincs azzal, a valóságban milyen teljesítményt mutat.

Ne vicceljünk már, hogy amit itt le van írva, annak a rendes futtatásához PCIe 5.0-s SSD-kre meg még jobb CPU-kra kell várni... Veszek egy használt R630-at megfelelő CPU-kkal, megfelelő mennyiségű memóriával és diszk alrendszerrel, és tökélesenen fog futni rajta minden, egyszerre... Ehhez azért nem kell csillagromboló, csak mindenből elégséges. A koszolidáció meg a "mindenből 1 kicsi" nem barátok.

A teszt gépen fent volt az összes rendszer, egyszerre használták a user-ek, és úgy jöttek ki ezek az eredmények? Vagy fent volt egy szem VM, és úgy? Hyper threading engedélyezve volt? Milyen mitigációk voltak bekapcsolva vagy letiltva host és VM szinten? Mennyi memóriája volt a Windows VM-nek? Mennyi volt az ARC mérete teszt után, volt kézi limit, vagy csak a default?

ZFS ashift milyen partiban volt az SSD valós szektormérettel? Ekkora SSD-k már általában 8k, Proxmox ashift default 12 (4k). ZFS recordsize milyen viszonyban volt a rátett OS FS-ével? Proxmox default 8k, ami mindenhez kevés, NTFS pl. 64k-t igényel... Milyen virtuális tároló volt a VM-ben (VirtIO SCSI single, vagy mi)? Ballooning egedélyezve volt-e (default igen, Windows nem szereti...)?

Egy darab SSD volt a teszt gépekben? Ilyen feladat alá 6 vagy 8 SSD-ből kellene RAID10 indulásnak is, mindjárt lenne elég IOPS (megfelelő ZFS ashit mellett...) akkor is, ha nem PCIe 5.0x4 SSD-k vannak a gépben. A PM963-as SSD ugye csak a kakukktojás, hogy észrevesszük-e a maga 30k write IOPS-ével (ideális esetben ennyi)?Hiába magas az SSD IOPS értéke, azt nem arra adják meg, hogy 16 VM 100 szála akar rá dolgozni egy időben...

Most már érdekelne, milyen beállítások és optimalizációk előzték meg a tesztelést...

Abból a hibás elképzelésből indultál ki, hogy bármi gond lenne a jelenlegi éles rendszerrel. Pedig minden megfelelően működik, minden felhasználó boldog. Így én is az vagyok. :)
Azért keletkezett a post, mert lehetőségem lett újabb gépekre váltani úgy, hogy miközben a hardver papíron majd' másfélszeres gyorsulást ígért, a költség nem nőtt volna.

A tesztelési körülmények mindhárom gépen azonosak voltak - a hardverelemek különbségétől eltekintve, - így nincs jelentősége a kérdéseid nagy részének. Hogy megnyugtassalak, sem a teszt környezetben, sem az éles rendszerekben nem 1 szál SSD van. :)

Nem indultam ki semmilyen elképzelésből.

Abból indultam ki, amit leírtál. Azt írtad, 16 VM van, ebből 6 Windows szerver. Ennek futtatására teszteltél 1 CPU-s, 128 GB memóriás, 1 SSD-s gépeket. Legalábbis leírva ennyi volt. A mostani gép specifikációját nem adtad meg, így az olvasó (én) nem tudhatom, hogy az _nem_ 1 CPU-s, 128 GB memóriás, 1 SSD-s

De így az egésznek mi értelme volt? A kérdés feltevésnek, aztán magának a tesztelésnek mi értelme volt, ha a teszt rendszerek nem is hasonlítanak az éles rendszerre? Mi értelme volt úgy teszt eredményeket írnod, hogy nincs meg a mostani rendszer eredménye (viszonyítási alap)? Ráadásul azt írod, hogy a megadott specifikáció (amihez a teszteredményt írtad) nem is az, amin valójában teszteltél (pl. ha több SSD volt, nem egy)?

Bemegyek egy Toyota szalonba tesztvezetek egy hibrid Auris-t és az alapján eldöntöm, vegyek-e Mercedes E osztály AMG kivitelt, olyan lesz-e a kényelme, gyorsulása, fogyasztása, amit várok. Ja nem, először megkérdezem a közvéleményt, és megírom, hogy az Auris milyen számokat produkált. Aztán leírom, hogy nem is olyan motoros volt az Auris, mint írtam. Meg leírom később, hogy most is E osztály AMG-m van, csak egyel régebbi, és tök jó, meg vagyok vele elégedve, nem is kellene cserélni.

Beidéznéd azt a részt, ahol azt állítottam, hogy 1 db SSD van bármelyik gépben? Javítani szeretném.

Sem a gépek pontos specifikációjáról, sem a pontos szoftverkörnyezetről, sem a Proxmox pontos beállításairól nem írtam részletekbe menő konkrétumokat. A kérdésem az Intel® Xeon® Gold 5412U CPU általam fellelt paramétereinek megkérdőjelezéséről szólt. A teszteredmények (számomra) igazolták a kétségeimet. Egy akadémiai publikációban biztosan nem állnák meg a helyüket, de itt erről most nincs is szó. Vedd úgy, hogy blogoltam magamnak egyet, de Ti is részt vehettetek az agymenésben. Én már elengedtem ezt a témát, szerintem tégy így Te is. :)

Az autós hasonlatot külön köszönöm! Nem olvastam végig (tl;dr), de biztosan tanulságos volt. :)

TL;DR Nem kell elolvasnod, úgy sem érdekel. A többieknek szól a válaszom.

...
2. gép:

  • CPU: Intel® Xeon® W-2295 CPU @ 3.00GHz
  • NVMe SSD: SAMSUNG MZQL23T8HCLS-00A07, 3,84 GB, Gen4
  • RAM: 128 GB DDR4 ECC

...

Ha én írok ilyesmit, akkor azt írom pl. (nem 1 db SSD esetén), hogy "NVMe SSD:  4x SAMSUNG MZQL23T8HCLS-00A07, 3,84 GB, Gen4, RAID10". És, mint általában a legtöbben, én is magamból indulok ki, és azt feltételezem, más is megjelöli, mennyi eszközről beszélünk, milyen felállásban, abban az esetben, ha fontos a kérdés esetén ez az adat.

Így van, nem írtál semmit a pontos környezetről. De konkrét számadatokat írtál eredményként. Namost a pontos környezet ismerete nélkül hogyan kellett volna nekünk ezen számokat értelmezni? Ráadásul még a mostani rendszer számait sem írtad le.

Namost, ha megadod, hogy milyen Xeon Gold prociról beszélünk, de nem írod le, hogy az ebben lévő eltérő magokat figyelembe vetted-e, és úgy állítottad-t be a rendszert, hogy a nagy teljesítmény igényű VM-ek mindenképp csak a P magokon fussanak, vagy ezzel egyáltalán nem foglalkoztál, és lehet, hogy az E magokon futott a teszed, az igenis számít, nem mellékes.

Ezen felül a tároló teljesítményt kevesellted, és mégújabb technológiás eszközre várást helyeztél kilátásba a neked nem tetsző mérési eredmények miatt, miközben nem adtad meg, milyen konfigurációval futott a ZFS, ami eléggé erősen befolyásolja az eredményeket...

 

De nem ez a fő baj számomra. Ez Neked okozna gondot, ha tanulni akarnál mások tapasztalataiból. De gondolom nem akarsz - a válaszaid alapján. Valószínű megerősítést vártál csak, de nem kaptad meg nagyjából senkitől.
Hanem az a gondom, hogy én ugyan offenzív voltam az ebben a topicban olvasható pongyolaság és definiálatlanság miatt, viszont Te nem vitába szálltál, hanem csak arrogánsan válaszoltál valami nem relevánsat arra, amit felvetettem...

Sajnálom, hogy nem tudod elengedni. Utoljára futok még egy kört Veled.

Sehol nem írtam, hogy 1 db SSD van, ahogy pl. azt sem, hogy a 128 GB RAM hány modulból áll össze.
A fájlrendszer paramétereit sem írtam oda és a RAID típusát sem.

...ha fontos a kérdés esetén ez az adat

Nem fontos.

Esetemben megegyezett:

  • a virtualizációs környezet
  • a háttértárak száma
  • a háttértárak kapacitása
  • a fájlrendszer és a RAID típusa és minden beállítási paramétere
  • a csatolófelület típusa (PCIe, a verzió eltér)
  • ~100 GB tesztfájl (szekvenciális írás/olvasás/tömörítés teszt)
  • a VM-ek (random olvasás, adatbázis betöltése)
  • a programok a VM-ekben
  • a tesztben részt vevő VM-ek
  • ugyan annyi P mag
  • RAM mennyisége
  • stb... (nem folytatom, pongyolaság ide, vagy oda, de szerintem a többiek már értik így is). (közben telefonom volt, úgyjogy ez a gondolatmenet itt véget ért... :D.)

tl;dr
A tesztelni kívábt hardver összetevőkön kívül minden megegyezett.

nem adtad meg, milyen konfigurációval futott a ZFS

Ugyan olyan konfigurációval.
Tudnál (kérdezem tisztelettel) egy olyan példát mutatni, ahol X és Y gyártó háttértárainak összehasonlításában a fentiekhez hasonló összehasonlítási környezetben, ugyan azokat a teszteket futtatva (szekvenciális írás/olvasás, random R/W, stb) X gyártó eszköze gyorsabb (nem a hibahatáron belüli néhány %-al és nem az esetleges cache méretbeli különbségeket kihasználva), ugyan ezen eszközök más fájlrendszerrel, vagy más RAID konfigurációban pedig Y gyártóé ledolgozza a hátrányát? Mindkét tesztkörnyezeten ugyan azokat a változtatásokat eszközölve, persze.  Specifikálhatnám részletesebben, hogy mit várok de gyanítom, hogy még szabad kezet kapva sem tudsz példát mutatni arra, amiért velem kötözködsz.

tl;dr
Mutass 2 db (esetünkben 3.84TB-os NVMe Datacenter) SSD-t, amelyek közül egyik gyorsabb mondjuk 35%-al minden írási/olvasási feladat elvégzése során ugyan abban a tesztkötnyezetben, majd változtasd meg azokat a paramétereket, amire rákérdeztél bármilyen kombinációban és mutasd meg az eredményt. (Ez így sem sokkal rövidebb :D)

válaszoltál valami nem relevánsat arra, amit felvetettem..

Nem releváns a felvetésed. Az arroganciáért pedig elnézésedet kérem, ez valami emberi reflex lehet nálam az offenzív társalgások kezelésére. :)

peace

Igen rendes Tőled, hogy szánsz még rám időt. Igaz, Te kérdeztél és kértél itt segítséget, így mi szántunk Rád időt elsősorben, de értékelem, hogy tovább foglalkozol a témával.

Érdekes, hogy azt írod, én nem tudom elengedni. Én írtam valamit, Te válaszoltál rá egy kitérő, nem releváns hosszászólással, amire én ezt megegyeztem, hogy ez nem válasz a felvetéseimre. Erre most leírod ugyan azt bővebben, hogy a Te tesztelési metódusod a megfelelő, és pl. a háttértár teljesítményéről beszélve nem releváns az eszközök száma, szervezése (szerinted).

Nem érzem, hogy bizonyítanom kellene számokkal, tesztekkel az állításaimat, mert ha felütöd az OpenZFS dokumentációját, ott pontosan le van írva, hogy melyik paraméter milyen befolyással bír a teljesítményre. Elnézést, de nem rakok össze azért egy tesztkörnyezetet, hogy lemérjem Neked (helyetted) az ashift és recordsize rossz megválasztása és jó megválasztása közötti különbséget, meg a különböző számű diszkek különböző kötetbe szervezése közötti különbségeket - ráadásul ezt már sokan megtették, a neten biztosan találsz mérési eredményeket. Ezen felül nem is állítottam, hogy rosszul van bármi, hanem kérdeztem, hogyan van, hátha lehet konfigurációval javítani.

De, hogy mondjak egy egyszerű példát: ugyan azon 4 db meghajtó RAID5 kötetként random íráskor egyetlen meghajtó írási IOPS-ét hozza (ideális esetben), RAID10 kötetben 2 meghajtónyi random írási IOPS-t hoz, nem redundáns stripe esetén pedig 4 meghajtónyi random írási IOPS-t hoz... Tehát durván befolyásolja a kötet szervezése azonos számú és típusú eszközök mellett is az elérhető teljesítményt, ami mindenféle konkrét mérés nélkül is belátható.

Például, hogy érthető legyen: a PM9A3 igér 180e IOPS-t írásra, a PM963 pedig 30e-et. Ha csinálok egy stripe tömböt 6 db PM963-ból, akkor a tömb tudni fogja a 180e írási IOPS-t, de közben (ráadásként) a hatszorosára növekszik a szekvenciális műveleti sebesség... Persze mondhatod, hogy akkor Te a PM9A3-ból csinálsz egy ilyen 6 maghajtós tömböt, de a kérdés az volt, hogy más meghajtókkal más szervezésben tudják-e hozni a javulást. Tudják.

Ráadásul maga a ZFS nem gyors, nem azért született. Egy csomót kell rajta matekozni, hogy kicsit gyorsuljon. Ha ugyan arra az SSD-re ext4-et teszel, akkor valószínű sokkal gyorsabb lesz, még akkor is, ha MD RAID és LVM van alatta. A ZFS-t a robosztssága és a hibatűrése, öngyógyító képessége miatt szokás választani, aztán matekozni vele, hogy azért ne legyen sokkal lassabb másoknál.

Az, hogy egyezik a konfiguráció, szerintem még nem ok az örömre, mert lehet az eredeti konfiguráció sem optimális az eredeti hardveren, és az is lehet ettől függetlenül, hogy az új hardveren más konfiguráció az optimális, mint az eredeti hardveren volt. Szóval tesztelni csak úgy lenne érdemes, ha minden hardveren az azon optimális konfiguráció futna.

Viszont, ha Te teszteltél valahogy, és a Te kiváncsiságod kielégíti az úgy kapott eredmény, és döntöttél is ez alapján, akkor egyáltalán miről vitázunk itt? Viszzatérek az eredeti kérdésemhez: mit szerettél volna megtudni a többiektől? Persze nem kell válaszolni, ez csak költői kérdés ezek után.

Nézz bele fio-val , akár meg is oszthatod, ha másra nem a gépek öszehasonlítására jó, fio van windowsra:
Akkor az én mérésem:

Asztali windows samsung asztali sata ssd-vel, tipus nem érdekes kb. mindegyik hasonló: (power shell):  iops 284 ,      1.1 MB/sec
 

C:\Users\vasla> fio --name=ssdtest --filename=testfile1 --size=100M --bs=4k --iodepth=1 --rw=randwrite --randrepeat=1 --sync=1 --fsync=1|select-string write

ssdtest: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=windowsaio, iodepth=1
  write: IOPS=284, BW=1137KiB/s (1164kB/s)(100MiB/90096msec)
  WRITE: bw=1137KiB/s (1164kB/s), 1137KiB/s-1137KiB/s (1164kB/s-1164kB/s), io=100MiB (105MB), run=90096-90096msec

Proxmox hostban raidZ (mirror)  2xIntel S3700: IOPS 3896,    15 MB/sec 
Ez egy régi elég régi tipusú sata dc ssd.
 

 fio --name=ssdtest --filename=testfile1 --size=100M --bs=4k --iodepth=1 --rw=randwrite --randrepeat=1 --sync=1 --fsync=1|grep write
ssdtest: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=1
  write: IOPS=3896, BW=15.2MiB/s (15.0MB/s)(100MiB/6570msec); 0 zone resets

Proxmox egy vm-jében ugyanezen a lemezen: (ext4en  a vm) iops: 2419  ,  9MB/sec

 fio --name=ssdtest --filename=testfile1 --size=100M --bs=4k --iodepth=1 --rw=randwrite --randrepeat=1 --sync=1 --fsync=1|grep write
ssdtest: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=1

  write: IOPS=2419, BW=9677KiB/s (9909kB/s)(100MiB/10582msec)

 

 

https://blog.claryel.hu

Húú azért a 284 iops, random write 4k qd1-re, már-már HDD szint. A 15k rpm-es HDD-k kb megugrották ezt a szintet.

Ez nagyrészt a windows fs overhead-je lesz. Block device szinten a desktop samsung SSD-k (még az ősi 830-ak is), ennél legalább egy nagyságrenddel többet tudtak.

Régóta vágyok én, az androidok mezonkincsére már!

Próbálj ki egy bármilyen, akár nvme-s asztali ssd-t a fioval és hasonlitsd össze (wan fio windows.hoz is)
 

sajat tapasztalat, hogy adatbazis alatt meg egy SAS hdd is gyorsabb tud lenni mint egy SSD, ha sok kis iras van

Pár hozzászólással feljebb irta arpi-esp. Nem szokták elhinni. Utána jön a" szar a fio". "Nem jó a mérés". Az enyém az jobb.
Szóval kinek hisz az ember? A marketingnek vagy a saját szemének? Logikus hogy a marketingnek... 
Mérd le a tidet. Ugyanez lesz linux alatt is.

https://blog.claryel.hu

Elég sokat méregettem fio-val :) Bár én többnyire block device szinten mértem. Ezért is nyeltem nagyot, mikor láttam, hogy windows alatt, ntfs fölött, mekkorát zuhan az eredmény. A QD1 egyébként csúnya corner-case az SSD-knek (random read-ben még rosszabb is, mint random write-ban), a gyakorlatban azért a legtöbb alkalmazás terhelésprofilja ennyire nem aljas.

Ha sikerülne a jövőben rávennem magam, hogy ne prokrasztináljak :), akkor megírnám a saját tesztjeimről posztokat.

Régóta vágyok én, az androidok mezonkincsére már!

Értem mire gondolsz, de a gyártók csinálnak ritkamód low-end vackokat is, amire nem írják rá a mágikus marketingszavakat. QLC-s flash, DRAM-nélküli "HMB"-s kontroller stb. Általában onnan ismerni fel, hogy mi nincs ráírva. Lehet, hogy egy rövid tesztben _látszólag_ olyan, mint a pro-super-ultra változat, de tartósabb terhelésnél vagy mondjuk 3/4-ig adatokkal töltve óriásit zakózik a teljesítménye a normál desktop változathoz képest is. Szóval van lefele bőven, csak a gyártók már ügyesek lettek abban, hogy ideális mérési körülmények között, rövid ideig jónak látszódjanak a szar típusaik is.

Régóta vágyok én, az androidok mezonkincsére már!

Nem kell rövid ideig se jónak látszani, Pár éve wd nas lemez botrány, szó nélkül smr lemez lett a NAS crm-ből. Miközben alkalmatlabnabb lemezt senki em találhatott volna NAS hoz , ahol a raid nem egy szokatlan dolog.
WD azt nmondta hogy de az. Illetve hogy minden csip csup dologról nem tájokoztatnak. 

https://blog.claryel.hu

Samsung PM9A3:

ssdtest: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=1
  write: IOPS=6747, BW=26.4MiB/s (27.6MB/s)(100MiB/3794msec); 0 zone resets
  WRITE: bw=26.4MiB/s (27.6MB/s), 26.4MiB/s-26.4MiB/s (27.6MB/s-27.6MB/s), io=100MiB (105MB), run=3794-3794msec

zászló, zászló, szív

Hitachi 15k SAS diszk zfs raid1:

ssdtest: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=1
  write: IOPS=193, BW=774KiB/s (793kB/s)(100MiB/132249msec); 0 zone resets
  WRITE: bw=774KiB/s (793kB/s), 774KiB/s-774KiB/s (793kB/s-793kB/s), io=100MiB (105MB), run=132249-132249msec

Intel DC 3500 SAS SSD zfs raid1:

ssdtest: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=1
  write: IOPS=2370, BW=9481KiB/s (9709kB/s)(100MiB/10800msec); 0 zone resets
  WRITE: bw=9481KiB/s (9709kB/s), 9481KiB/s-9481KiB/s (9709kB/s-9709kB/s), io=100MiB (105MB), run=10800-10800msec

Szóval, na: van fejlődés enterprise SSD téren is és a desktop SSD nem ér többet mint a 15k SAS diszk.

zászló, zászló, szív

KINGSTON SKC3000D4096G, KC3000 PCIe 4.0 NVMe M.2 SSD, 3.73 TB, ext4 + LUKS, asztali gépben

ssdtest: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=1
  write: IOPS=218, BW=874KiB/s (895kB/s)(100MiB/117210msec); 0 zone resets
  WRITE: bw=874KiB/s (895kB/s), 874KiB/s-874KiB/s (895kB/s-895kB/s), io=100MiB (105MB), run=117210-117210msec

Itt válik el az asztali a DC-től, hiába nvme, 0.9 MB/sec. Adatbázis kezelés pedig szinkron írás, ha nem is 4, inkább 16k. 
Nem szokták elhinni, mint már írtam.  De persze nem ezt irják, hanem ezt:

A Kingston KC3000 PCIe 4.0 NVMe M.2 SSD új szintű teljesítményt nyújt a legújabb Gen 4x4 NVMe vezérlő és 3D TLC NAND segítségével.

Nem szerverkörnyezetben használják akkor tökéletes, asztaliba kiváló. VM-ekhez nem. 
 

https://blog.claryel.hu

SAMSUNG MZQL23T8HCLS-00A07, 3,84 GB, Gen4, ZFS RaidZ

ssdtest: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=1
  write: IOPS=19.8k, BW=77.3MiB/s (81.1MB/s)(100MiB/1293msec); 0 zone resets
  WRITE: bw=77.3MiB/s (81.1MB/s), 77.3MiB/s-77.3MiB/s (81.1MB/s-81.1MB/s), io=100MiB (105MB), run=1293-1293msec

SAMSUNG MZQLW960HMJP-00003, 960 GB, Gen3, ZFS RaidZ

ssdtest: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=1
  write: IOPS=18.9k, BW=73.9MiB/s (77.4MB/s)(100MiB/1354msec); 0 zone resets
  WRITE: bw=73.9MiB/s (77.4MB/s), 73.9MiB/s-73.9MiB/s (77.4MB/s-77.4MB/s), io=100MiB (105MB), run=1354-1354msec

Ha már lúd akkor...

Ez van jelenleg a desktopomban:

Non-Volatile memory controller: SK Hynix PE8110 Series NVMe Solid State Drive (rev 21)

fio -filename=/dev/nvme0n1 -direct=1 -rw=randwrite -bs=4096 -iodepth=1 -size=$TESTSIZE -name=randwrite

randwrite: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=1
fio-3.31
Starting 1 process
Jobs: 1 (f=1): [w(1)][100.0%][w=322MiB/s][w=82.4k IOPS][eta 00m:00s]
randwrite: (groupid=0, jobs=1): err= 0: pid=5313: Mon Aug 29 17:10:42 2022
  write: IOPS=82.7k, BW=323MiB/s (339MB/s)(4096MiB/12679msec); 0 zone resets

Régóta vágyok én, az androidok mezonkincsére már!

Félig tele van, de történetesen ext4fs fölött meg tudom mérni:

ssdtest: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=1
write: IOPS=15.8k, BW=61.6MiB/s (64.6MB/s)(1000MiB/16243msec); 0 zone resets

Annyit változtattam, hogy --size=1000M. 100MB-ra elég összevissza (50-70MB/s) eredményeket mutatott. Az utóbbi időkben arra szoktam rá, hogy a kézzel heurisztikázott --size helyett --size=128G --runtime=30s el futtatok mindent, akkor a fio automagically belövi a méretet, hogy pont 30 másodpercig fusson (mondjuk ez block device-on könnyű, filerendszeren előreallokált file esetén nem próbáltam ki, mit csinál).

Amúgy - nem meglepő módon - ez egy szerverbe való SSD, eleve 22110-es méretű, és gyanítom, hogy van rajta power loss protection, bár egyértelmű paramétert erre nem tudtam kiszedni belőle. Csak hardveraprón olcsón árulták, mert gondolom aki megvette az mellényúlt vele, hogy nem illik az alaplapi foglalatba.

Régóta vágyok én, az androidok mezonkincsére már!

Samsungból most éppen ilyen eredmény volt kéznél:

Samsung 830 (retail) 256GB, Orico 25PWIC-C3 USB3 adapteren keresztül, Tp-Link C2600 routerre kötve, mindez OpenWRT alatt:

root@router:~# for IODEPTH in 1 2 4 8 16 32 64 128; do echo $IODEPTH; TESTSIZE="1G"; fio -filename=/dev/sda -direct=1 -ioengine=libaio -rw=randwrite -bs=4k -iodepth=$IODEPTH -size=$TESTSIZE -name=randwrite; done

randwrite: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=1
  write: IOPS=4421, BW=17.3MiB/s (18.1MB/s)(1024MiB/59282msec); 0 zone resets
randwrite: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=2
  write: IOPS=8322, BW=32.5MiB/s (34.1MB/s)(1024MiB/31500msec); 0 zone resets
randwrite: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=4
  write: IOPS=9651, BW=37.7MiB/s (39.5MB/s)(1024MiB/27161msec); 0 zone resets
randwrite: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=8
  write: IOPS=8383, BW=32.7MiB/s (34.3MB/s)(1024MiB/31269msec); 0 zone resets
randwrite: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=16
  write: IOPS=11.8k, BW=46.1MiB/s (48.4MB/s)(1024MiB/22200msec); 0 zone resets
randwrite: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=32
  write: IOPS=11.9k, BW=46.6MiB/s (48.9MB/s)(1024MiB/21974msec); 0 zone resets
randwrite: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=64
  write: IOPS=8362, BW=32.7MiB/s (34.3MB/s)(1024MiB/31347msec); 0 zone resets
randwrite: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=128
  write: IOPS=8247, BW=32.2MiB/s (33.8MB/s)(1024MiB/31786msec); 0 zone resets

Régóta vágyok én, az androidok mezonkincsére már!

Ez sem lenne rossz, de szerintem ez nem szinkron írás, "csak" direkt. (operációs rendszer pufferelést kikapcsolja, de a lemezét nem) Aszinkron írás, a lemez RAM-ját méred, ez nem azonnali írás, ha elszáll a gép a lemez cach-ben lévő adatoknak annyi. A szinkron írás pedig azonnali lemezre írás. Tedd mögé az fsync, sync paramétert , direkt akár maradhat, nem számít, ha a másik kettő ott van. Akkor lesz szerintem azonnali írás, ha tévedek majd kijavítasz. A teszt fájl mérete sem számít. 

https://blog.claryel.hu

Tudom. Nekem ez az eredmény van korábbról kéznél. fio-val kb 60000 féleképpen paraméterezve lehetne mérni, csak most nincs üresen olyan SSD-m amin gyorsan tudnék méregetni. Általában két sort szoktam végigmérni, egy iodepth-et, meg egy blocksize-ot, de a nyers block device-on, nem filerendszer felett. Elsősorban nem a randwrite iodepth=1 sync szokott érdekelni, ezért is van ebből relative kevés mentett eredményem. Randread iodepth=1 egy nehezebb műfaj, azt nem lehet elcsalni semmilyen cache/puffereléssel.

Régóta vágyok én, az androidok mezonkincsére már!

A poén kedvéért én is végeztem mérést. Semmi finomhangolást nem csináltam.
A gép: Dell Precision 7520, i7-7820hq, 64 GB RAM, Windows 10, NTFS fájlrendszer
Fio verzió: 3.25

Kingston SFYRD2000G (NVME desktop ssd)
fio-3.25-x86-windows.exe --name=ssdtest --filename=testfile1 --size=100M --bs=4k --iodepth=1 --rw=randwrite --randrepeat=1 --sync=1 --fsync=1
    ssdtest: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=windowsaio, iodepth=1
    write: IOPS=1803, BW=7214KiB/s (7387kB/s)(100MiB/14195msec); 0 zone resets

Kingston SEDC600M3840G (SATA low budget DC ssd)
c:fio-3.25-x86-windows.exe --name=ssdtest --filename=testfile1 --size=100M --bs=4k --iodepth=1 --rw=randwrite --randrepeat=1 --sync=1 --fsync=1
    ssdtest: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=windowsaio, iodepth=1
    write: IOPS=5328, BW=20.8MiB/s (21.8MB/s)(100MiB/4804msec); 0 zone resets

Kingston sajnos hírhedt abból a szempontból, hogy típuson belül néha figyelmeztetés nélkül változtat az alkatrészeken. És nem mindig a jobb minőség irányába... Legutóbb a KC2500-nál kapták rajta őket ("Kingston’s top-performing KC2500 is the latest example of just that: The company rebadged its KC2000 as the faster KC2500 even though it had the same hardware" - link), de nem ez volt az első eset náluk.

Régóta vágyok én, az androidok mezonkincsére már!

2xSamsung SSD 850 EVO 2TB, lsi 2208 raid1, luks

  write: IOPS=3983, BW=15.6MiB/s (16.3MB/s)(100MiB/6427msec); 0 zone resets
 

de valszeg itt a raid kartya bezavar, mert 2xTOSHIBA HDWR11A hdd

  write: IOPS=3505, BW=13.7MiB/s (14.4MB/s)(100MiB/7302msec); 0 zone resets
 

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Amúgy miért van itt "elbaszva" bármi is? Nem CPU-kat hasonlított össze, hanem 3, adott konfigurációjú, komplett gépet. Azokkal az alkalmazásokkal tesztelve, amivel élesben is használva van. Ha nincs lehetősége arra, hogy szabadon cserélgesse az alkatrészeket, akkor maximum érdekesség-jelleggel lehet nyomozgatni, hogy pontosan mi is a szűk keresztmetszet. Ha dönteni érdemben csak a 3 kész konfig között tud, erre ez a teszt pont megfelelő.

Régóta vágyok én, az androidok mezonkincsére már!

Ez az OP:

"A gondom az, hogy az ój gépben a proci csak 2.1 GHz-es, míg a régiben 3.0 GHz-es van---"

Végül is össze lehet hasonlítani akár a narancsot a villamossal is: a narancs így sárga a villamos meg úgy hosszú, értem én.
Mérnökként egy kicsit bassza a csőrömet csak, nem érdekes.

zászló, zászló, szív

Én azt mondom, hogy sajnos ez gyakorlatban így megy. Először az embernek van egy elképzelése arról, hogy mi fog számítani. Aztán méreget, és akkor derül ki, hogy az elképzelése teljesen rossz volt. Ahogy elnézem, itt ezt a folyamatot látjuk.

Régóta vágyok én, az androidok mezonkincsére már!

( WG | 2024. 02. 08., cs – 22:48 )

Szerkesztve: 2024. 02. 08., cs – 22:50

nemide