Új hozzászólás Aktív témák

• #9 tasiadam veterán Pikari #7

  Új Válasz 2024-06-28 18:24:14 #9

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  tasiadam

  veterán

  válasz Pikari #7 üzenetére

  Hat a ddr3 platformok egyike sem (mindegy, hogy colopvero, vagy v1-v2 vagy v3 xeonok) annyora fektiv es eros, mint egy ujabb AMD. Igy ertheto. Raadasul 1 magon olyan eros az AMD, mint egy v2 2 magon

• #8 Pikari veterán tasiadam #6

  Új Válasz 2024-06-28 16:11:54 #8

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Pikari

  veterán

  válasz tasiadam #6 üzenetére

  Az SQL-ben (mariadb) az volt a jó, hogy az legalább nem akart 20 szálon futni nem létező skálázást tettetve. Így legalább nem annyira hajtja le a villanyórát se.

• #7 Pikari veterán tasiadam #6

  Új Válasz 2024-06-28 16:09:28 #7

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Pikari

  veterán

  válasz tasiadam #6 üzenetére

  Ha Sierra alatt az új intel szerver vonalra gondolsz, akkor nem. Ezek sokkal régebbi cuccok voltak, volt közöttük kifejezetten szerver alaplap is, de hedt is. 24 körüli thread, vagy 24 körüli fizikai magszámmal, de régebbi ddr3-mas cuccok is voltak.

  Mindenhol ugyanaz volt az eredmény, függetlenül a kerneltől, oprendszertől, memóriavezérlő csatonáinak számától, fizikai processzorok számától. Úgyhogy be lett nekik rendelve a magasabb órajelű kevesebb magos konzumer ryzen. Ahol megjött, meg is oldódott a probléma a skálázódással.

• #6 tasiadam veterán Pikari #3

  Új Válasz 2024-06-28 15:54:15 #6

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  tasiadam

  veterán

  válasz Pikari #3 üzenetére

  Sierrát próbáltatok? Ha jól tudom, inkább oda fekszenek ezek, az SQL meg a haverok azok általában megálltak idő elött, mert kb fölösleges több. Most hirtelen nemtom hány magos lesz a legkisebb sierra, de kb ugyan úgy hót elég lesz SQL alá, mint az eddigi xeonok

• #5 Pikari veterán thgergo #4

  Új Válasz 2024-06-28 15:50:02 #5

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Pikari

  veterán

  válasz thgergo #4 üzenetére

  Affinitással én is szoktam régebben játszadozni (feladat magokhoz rendelése), de egy ideje már elhanyagolható.

  A példában szereplő problémákra az lett a megoldás, hogy ahol lehetséges volt, a workload kapott egy-egy random 6-8 magos ryzent, a 20-24 magos csodaxeonok meg mentek a kuka mellé, hogy ott rohadjanak el.

• #4 thgergo tag Pikari #3

  Új Válasz 2024-06-28 14:44:24 #4

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  thgergo

  tag

  válasz Pikari #3 üzenetére

  Párhuzamosan növelik is az IO-t is, 100 gigabites pcie 3.0 hálózati kártyák óta már pce 5.0 400 gigabit is betehető 1 gb 1x16 slotba.

  Skálázódás sok kis random szolgáltatásra van tervezve, ahol 1 user ritkán igényel 1-2 virtuális magnál többet, nem 1 db skálázni kívánt workload-ra. Persze az is kiderülhet, hogy papíron jó a 288 mag, de összevesznek azon, hogy ki éri el éppen a memóriát. Lesz csodálkozás, miután kiépültek az E-core dinnyemagos felhők, de az userek menekülnek belőle.

  Ilyen ütemező bugra nekem az a szokás, hogy kapcsold ki - kapjon minden thread egy dedikált magot (pl numactl parancs és társai), így nem dobálja az OS össze vissza a szálakat. Desktop 8 mag fölött másként is kell kezelni a thread kezelést.

• #3 Pikari veterán tasiadam #2

  Új Válasz 2024-06-28 12:28:21 #3

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Pikari

  veterán

  válasz tasiadam #2 üzenetére

  Magonként 2 wattot. Ja. Plusz 250et idleben attól, hogy be merted kapcsolni 8-10 thread után már haldoklik az ütemező, a memória, órajelek búvárbékába váltanak, az összeszarás határán van az interrupt kezelés és az IO, és 16 thread körül teljesen megáll az a fajta skálázódás, ami miatt azt lehetne mondani, hogy megéri ilyenről szolgáltatásokat üzemeltetni.

  Honnan tudom? Az elmúlt hónapban 4 gépen mértük ki, volt közte webszerver, konvertálás, ai, mixed típusú munka. És nem szintetikus benchmarkok voltak, ahol egy for ciklus regiszereket had össze, hanem in production workloadok (apache, sql, szövegfelismerés, stb). Szóval a konkrét feladat volt mérve, miközben élesben futott a cucc, hogy miért nem skálázódik.

  Végülis egy dolog volt, ami skálázódott, az az áramfogyasztás, az tényleg lineárisan növekedett a cpu utilization növekedésével párhuzamosan.

• #2 tasiadam veterán Pikari #1

  Új Válasz 2024-06-28 11:07:07 #2

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  tasiadam

  veterán

  válasz Pikari #1 üzenetére

  Magonkent 2 wattot esznek ezek. A 144est mar teszteltek es eleg jo. A 288 magosbol meg kihizhatsz rengeteg servicet 1 nodebol, ha containerhez hasznalos, vagy ha VM, akkor is max 288 vm, ami nem keves.

• #1 Pikari veterán

  Új Válasz 2024-06-28 10:54:59 #1

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Pikari

  veterán

  128 mag, 288 mag... adatközpontok, virtuális gépek. Hát sok sikert, nem mintha érdemben lehetne skálázni a legtöbb rendszert akár csak negyed ennyi magra is. Nem lehet mindent izomból megoldani, de ha ennyi magot 200w alatt tudnának hozni, akkor más lenne a helyzet, a szélsőséges helyzetekben kisegítene ennyi mag.

Új hozzászólás Aktív témák