Új hozzászólás Aktív témák
-
stratova
veterán
-
Smiley
addikt
Koszi! Igazabol vmware-el es hpyerv-vel meg nem volt dolgom, amire mi hasznaljuk boven eleg a libvirt/kvm paros, meg amugy is tul vannak meretezve a fizikai vasak. Akkor csak azt nem ertem miert eri meg a redhat-nak foglalkozni/kifejleszteni ezeket a feature-ket amik a qemu-ban vannak...
-
joysefke
veterán
Erre a Vmware kitalálta a CPU illetve memória "reservation" fogalmát: Ha egy virtuális gépnek be van állítva reservation (pl 1000MHz CPU reservation és 4GB memória reservation) akkor a VM a futása során bármikor hozzájuthat legalább ennyi erőforráshoz, függetlenül attól, hogy a hoston hány másik VM fut és azok éppen mit csinálnak. Értelemszerűen egy reservation-nel konfigurált VM-et csak akkor lehet egyáltalán elindítani, ha az őt futtató Host vagy cluster rendelkezik elég erőforrással a reservation kielégítésére.
Ha disk I/O intenzív a VM, akkor vagy külön storage partícióra kell rakni, vagy (megfelelő vSphere licensz esetén) lehet share-ekkel priorizálni a VM i/o kéréseit a többi VM-el szemben.
Egy VM hez konfigurált vCPU-hoz fixen fizikai CPU magot hozzárendelni, míg a többi VM-elől azokat eltiltani (pl.: Affinity beéllítás segítségével) így kiiktatva a virtualizációs réteg ütemezőjét műszakilag nonszensz, nehezen tudom elképzelni, hogy valaki ilyet önként akarjon beállítani, amikor az erőforráskezelésre sokkal jobb módszerek vannak.
J.
-
#82
imibogyo
veterán
Döglött Róka
#81
imibogyo
veterán
válasz
Döglött Róka
#81
üzenetére
-
#80
imibogyo
veterán
Döglött Róka
#78
imibogyo
veterán
válasz
Döglött Róka
#78
üzenetére
Nincs olyan eset, amikor úgymond "úgymaradna" RDP-n. Most sincs és a jövőben sem lesz. Ez egy belső homokozó, most sem megy 24/7-ben és nem is látszódik kifelé. Ha valaki olyan munkát akar csinálni, amihez "állandó" hozzáférés kell, arra most is ott vannak a "kifelé látható" homokozók a nagy tartalék szervereken. Ez a gép csak arra kell, hogy az "extrém ötleteket" ki tudjuk próbálni, de úgy, hogy ne terheljünk olyan gépeket, amiket nagyságrenddel többen használnak, valamint mivel érzékeny adatokkal is dolgozunk, ezért ha valamit elrontunk, akkor is "házon belül marad". De elfogadom, hogy hülyeség. Itthon működik, de ez azért más felhasználás.
-
#79
Fiery
veterán
shabbarulez
#74
Fiery
veterán
válasz
shabbarulez
#74
üzenetére
Ez sok mindent megmagyaraz, koszi az infot. Ezek szerint az LCC/MCC/HCC tema csak az E, EN es EP szegmensre vonatkozik.
-
imibogyo
veterán
Az lemaradt, hogy ha ez meg is oldható, akkor se úgy képzeld el, hogy erre naponta, vagy hetente lenne szükség. A jelenlegi vid. renderek rendszeressége jó ha megüti a havi egyet, akkor viszont 30-40 GB-os anyagokkal is kell dolgozni ezért kellene egy nagyon bika gép hozzá.
-
#76
imibogyo
veterán
Döglött Róka
#75
imibogyo
veterán
válasz
Döglött Róka
#75
üzenetére
Különálló OS-ekkel. Most is így használom az otthoni gépemet, innen jött az ötlet. 3 MR-em van, közülük az első 2-t kapcsolgatom gépindítás előtt (1-1 előre beállított OS). 1-en fut a fő rendszerem, 1-en fut egy alternatív/teszt/buherálós rendszerem, 1-be pedig egy 3TB-os merevlemez van adatokkal, filmekkel, programokkal stb.-vel (de ez igazából nem lényeges). Úgy gondoltam itt is kialakítható hasonló megoldás (persze a több merevlemezes kiépítést figyelembe véve), attól, hogy nagyobb teljesítményű gép, az alapjai gondolom ugyanazok, csak mondjuk 2-2 háttértárral. Persze még soha nem próbáltam ténylegesen ilyet megoldani egy ekkora rendszeren. Eddig még csak elméleti síkon játszottam ezzel. Persze ha nagyon-nagy hülyeség, akkor sztornó. Csak úgy agyalogtam, mert mint mondtam egy gépből kellene kihoznunk a legtöbbet.
-
#73
imibogyo
veterán
Döglött Róka
#72
imibogyo
veterán
válasz
Döglött Róka
#72
üzenetére
És hol írtam azt, hogy nem lenne VM? Én is 4 VM-ben gondolkozom. De mondjuk ha mindenki hazamegy, én meg amúgy is benn maradok, akkor menne bele egy saját felépített rendszer, amin mehetnének az "izmosabb" feladatok. Ezt amúgy is csak a fő munkaidőn kívül tudom megoldani (mármint a 8:00-17:00-es munkaidőn kívül.
Az a baj, hogy nem vehetünk csak egy gépet, de abból lényegében "akármekkorát". Tehát van pénz, de csak egy eszközre tudjuk elszámolni. Ezért ilyen orvosi ló most ez a gép.
-
#71
imibogyo
veterán
Döglött Róka
#54
imibogyo
veterán
válasz
Döglött Róka
#54
üzenetére
Altalanos celok alatt mit ertesz?
Már írtam. Ez csak egy belső fejlesztői gép lenne, de emellett még számtalan (nagyon időszakos) feladata is lenne (vid. conf. anyagok renderelése stb.). Mivel szinte minden gépünk mobil munkaállomás, ezért kellene egy bika vas. Elsődleges feladata természetesen a homokozó lenne, de be szeretnénk fogni más feladatokra is. Nem kell redundánsnak lennie. Vannak komoly szervereink amik ilyen feladatokat ellátnak, ennek csak ezt a 30-50 embert kell kiszolgálnia és izmosabb feladatokat ad-hoc módon ellátnia. Szóval ez ilyen "játszós" gép lesz majd, ha úgy tetszik. Nem kritikus szolgálatra lesz, nem kell 99,9%-os készenlétet produkálnia... -
#69
Fiery
veterán
Balala2007
#64
Fiery
veterán
válasz
Balala2007
#64
üzenetére
Akkor az az egy SKU kivetel a szabaly alol
(bar van me'g masik gyanus SKU is, ami HCC-bol van megvagva) Amugy meg az Intel sosem allitotta, hogy a HCC-bol nem keszitenek -4 magnal jobban megvagott verziot. -
#67
Smiley
addikt
Döglött Róka
#66
Smiley
addikt
válasz
Döglött Róka
#66
üzenetére
Elolvastad azt amit irtam? Ha felszabadul teljesen egy host-om akkor megnezem mi ertelme van ennek az egesznek, de inkabb ne is menjunk bele.
-
#65
Smiley
addikt
Döglött Róka
#63
Smiley
addikt
válasz
Döglött Róka
#63
üzenetére
Csupan kivancsisagbol...
-
#63
Döglött Róka
veterán
Smiley
#61
-
-
-
#58
Smiley
addikt
Döglött Róka
#57
Smiley
addikt
válasz
Döglött Róka
#57
üzenetére
rendben
-
Smiley
addikt
Ezzel egyet is ertek, de lehetnek olyan bizonyos esetek amikor egy ilyen jol johet, teszem fel, kisebb hosting max 2 cpu a hoston, par darab virt gep, amik kozul mondjuk 2 baromi fontos dolgot csinal, esetleg egyenkent sajat IO-val is rendelkeznek, itt azert elgondolkoznek azon, hogy ez a 2 veletlenul se maradjon cpu ido nelkul, azert mert a 3-ik gepen valamelyik barom nem tud programozni es vegtelen ciklusba kuldi a sajat vcpu-it.
-
-
#54
Döglött Róka
veterán
imibogyo
#29
Döglött Róka
veterán
Ha 40-50 ember hasznalja erdemes 4 virtualis geppel nekiesni. Gepenkent 12 user nem fogja lassitani a rendszert, 4 vcpu 8-16 giga ram, ha fejlesztok vagytok (pont nemreg epitettem sap fejlesztoknek vm-et). A hattertar mellekes, egy jo SAS disk boven eleg, inkabb azon legyen a hangsuly, hogy az egyideju felhasznalokat tobb gepre osszatok el.
En 16 maggal, es min 64 giga rammal kezdenek.
Altalanos celok alatt mit ertesz? DHCP, AD, SQL? Mert akkor lehet mar ket gep kellene (amugyis a redundancia miatt).
-
#53
Dark Archon
addikt
Na, végre elfogadható sebességgel fog futni a Karateka
-
anulu
félisten
ha van valami, amit rábíznék a virtualizációs rétegre és nem b@xtatnám az a CPU assign. főleg nem nagy környezetnél. egy ponton a sys admin saját magának csinál plusz melót, hogy melyik virt gép melyiket használhatja, annak az adminisztrációja, illetve az overhead-ek kiküszöbölése (túl sokat tol egyre, stb). szerintem ez a "van, de minek" kategóriájú feature.
-
Peter13
senior tag
-
-
Meridian
senior tag
" Ez (is) adja a virtualizált infrastruktúra jobb kihasználtságát."
Ami továbbá azt statisztikai tényt használja ki, hogy minden virtuális gép nem fut 100%-os terheltséggel minden egyes időpillanatban... virtuális gépek kiosztásánál, pl egy ilyesmivel foglalkozó szolgáltatónál, azt adják meg a "kliensnek", hogy az adott virtuális gép milyen valós procival megépített valós géppel ekvivalens teljesítményű lesz.
-
#45
Meridian
senior tag
macilaci78
#8
Meridian
senior tag
válasz
macilaci78
#8
üzenetére
Nahát, siet az órád, jelentősen... még nincs augusztus.
-
#44
Smiley
addikt
feketebirka
#40
Smiley
addikt
válasz
feketebirka
#40
üzenetére
Tudom, de egy szaros gcc-hez is kell vagy 4-5gb ramfs, es a virt gepeket nem nagyon kapcsolhatom le amig frissitek. Amugy van par darab ilyen i7-em gigabiten azokon distcc-vel szepen el van osztva a terheles a forditas idejere, igy majdnem debian feeling.
Latnad az irodai routerem az egy igazi vadallat, 3.6GHz P4 HT... szerencsetlen nem tud olyan gyorsan linkelni ahogy az i7 adja ala a cuccot forditaskor
-
gaba.hu
csendes tag
Valóban meglepő a 4 magos lapka mint önálló termék, általánosság helyett had írjak egy konkrét példát. Az Oracle adatbázis kezelője után fizetendő licence díj magszám alapú. Ráadásul egy komplex adatbázis (adattárház) inkább cache és memória sávszélesség korlátos (meg persze háttértár, de most azt tekintsük egyformának). Ha a hardver árához hozzátesszük a szoftver költséget is, akkor egy 8x4 magos rendszer olcsóbb és gyorsabb lehet, mint egy 2x18 magos (összességében 32 kontra 36 mag), mivel a cache és a memória kb. 4x gyorsabb és a licence is kevesebb. Természetesen nem minden esetben igazak a fentiek, de nagyjából ez az értelme a 4 magos processzornak.
-
#42
imibogyo
veterán
feketebirka
#39
imibogyo
veterán
válasz
feketebirka
#39
üzenetére
Köszi neked is. Mint mondtam vannak jól skálázódó programjaink és vannak "általános" nem túl jól skálázódó programjaink is. Ezért is mondtam, hogy általános felhasználásra melyik lehet talán a jobb. De egyre jobban hajlok afelé, hogy inkább a kevesebb mag magasabb GHz lesz a döntés, pont a feljebb is írtak miatt. A disk alrendszer jelenleg is SSD. Amúgy nem kritikus gépről van szó, de erősnek kell majd lennie. LXC-vel még nem foglalkoztam, köszönöm utána olvasgatok.
(#41) Smiley: az új gépben azok amúgy is kiesnének, mert vékonyszerverről szeretnénk átmenni Quadro-s környezetbe (a vid. vágás és 3d render miatt elsődlegesen). Nem tudom, hogy ehhez majd milyen lapot tudunk venni. Az után még 2 másodpercet sem olvastam. Mondjuk procik után sem, ez a cikk most csak úgy szembe jött velem. Valamikor 1 év múlva lesz esedékes a vásárlás.
-
#39
feketebirka
csendes tag
imibogyo
#29
feketebirka
csendes tag
Az, hogy milyen proci éri meg neked jobban, nagyon függ attól, pontosan milyen szoftvereket használsz. Nyilván ha olyanok vannak túlnyomó többsébben, amik a memória sávszélességet eszik, akkor édes mindegy, hogy milyen procit veszel. A sok apró, független feladat pl. nem jó többmagosnak, mert elaprózzák a cache-edet. Tapasztalatból úgy gondolom, a többmagos prociknak akkor van előnyük a magasabb órajelen futókhoz képest, ha vannak több szálon (azaz azonos virtuális címtartományon) hatékonyan futó alkalmazások, mert akkor a több mag előnye megvan, és a közös cache-é is. Bizonyos videokodekek ilyenek. Azt ki kell tapasztalni, hogy hány szálon futtatva tudják még a rendszert hatékonyan kihasználni. Érdemes megnézni, hogy vannak-e még szűk keresztmetszetek a rendszerben, mert pl egy nem megfelelő disk alrendszer is odavághatja a teljesítményt (tök cuki nézni, amikor a procik wait-ben csücsülnek 50-60%-ban). Esetlegesen lehet lényegesen több RAM-ban gondolkodni, így bizonyos ideiglenes fájlokat lehet tmpfs-re írni (ha itt bizonyul szűknek a keresztmetszet). Azért én VM-ek helyett meggondolnám az LXC használatát is.
-
#38
Meteorhead
aktív tag
westlake
#1
Meteorhead
aktív tag
Mit jelent a "8 utas" kiépítés? A 32-ről már nem is beszélve. Már egy quad socket deszkából sem látszik más, csak a foglalatok és a memória foglalatok hadrendje. Hogyan lehet 8-32 utas szervert építeni? Vagy a blade-t hívnák így? Vagy ez egy sima NUMA gép lenne? Az Intel a csoda interfészével egybekötött gépeket már egynek tekinti?
Biztos én vagyok a butus. Nem tudom elképzelni.
-
imibogyo
veterán
Köszi a további infókat. Nekünk most is SSD-k vannak hadrendben (kapnak is rendesen szegények), de a következő gépben is biztosan azok lesznek majd. Minden fontos dologról van 2 óránként auto backup, ráadásul tükrözve is vannak, tehát nem halunk bele, ha valamelyik eltávozik (volt már rá többször példa), viszont a sebességük kárpótol mindenért. A cégnek meg belefér anyagilag.
-
Smiley
addikt
Nem a processzorokkal van a baj a legtobb esetben hanem azzal hogy mindig keves a ram es lassu az franya IO...
Osszehasonlitaskepp van 2 ilyen gepem.
"A" gep: i7 950 (24GB ram + 2db mezei WD 7200 raid1)
"B" gep: i7-4770 (32GB ram + 2db WD black enterprise@7200 raid1)
Ugyanaz az a gentoo es kernel fut mind a 2 gepen, a kernel forditas alatt, ha megkuldom max-on mind a 2 gepet, kb elhanyagolhato a 4770 elonye... max 15-20 mp lehet, pedig lenyegesen lassabb IO van a regi i7 alatt. Szoval ha kapna rendes storage-ot maga ala a regi i7 akkor az a vilagbol kimenne meg a mai napig... -
joysefke
veterán
nem, feljebb leírtam, hogyan működik.
A virtuális gép virtuális processzormagjai és a fizikai processzormagok (ezek lehetnek HT magok is) között dinamikus a hozzárendelés, és a virtualizációs réteg ütemezőjének a feladata. ha avirtuális gép nem akar CPU hoz jutni (mert nincsen dolga) akkor nem kap fizikai processzormagot. Ha dolga van, akkor az ütemező megpróbál osztani neki.
Könnyen elképzelhető (szinte általános) hogy egy szerver, amelynek mondjuk 32 fizikai processzormagja van elfuttat egyszerre 50 virtuális gépet úgy hogy mindegyikbe kettő virtuális processzormagot konfiguráltál.
J.
-
#29
imibogyo
veterán
Döglött Róka
#13
imibogyo
veterán
válasz
Döglött Róka
#13
üzenetére
Fejlesztési célokra homokozónak 30-50 embernél több nem nagyon lenne rajta egy időben. Emellett "általános" feladatokat is el kellene majd látnia, ezért volt a kérdés. Debian futna rajta egyébként. Mivel érzékeny adatok és programok a "területünk" mindenképpen egy belső "offline" gépre van szükségünk, ami csak belülről érhető el, de abból egy viszonylag erősre lesz szükségünk.
Jómagam nem vagyok hardveres, ez gondolom kiderült én csak "használom" a gépeket. Ismerem azt a 3-4 programot amit használnom kell, de úgy nagy általánosságban nem tudom hol áll ma a technika. Nem ez a dolgom. Ettől függetlenül érdekelt, hogy mi lehet a racionálisabb döntés. Igazából mind a két processzor fényévekre van a jelenlegi gépünktől, szóval nagyon mellé nem nyúlnánk egyikkel sem.
Jelenleg egy ilyesmit használunk homokozónak (2x QC Xeon E5405 2.0Ghz, 12M Cache, 1333MHz FSB, 32GB DDR2 667, SSD ), de kezd nagyon kevés lenni több (4) virtuális gépet futtatva még homokozóként is. És mivel most van lehetőségünk egy nagyobb fejlesztési összeget új gépre költeni, elgondolkozhatunk akár ilyen újabb processzorokban is, jóval több memóriával.
(#15) Tigerclaw: igen ez evidens. És szerintem rosszul is tettem fel a kérdést. Engem az érdekelne, hogy egy viszonylag jól skálázádó rendszeren, ahol azért általános feladatok is adódnak (szerver, render, vid. konf. anyagok konvertálása és utómunkája, stb.), oda melyik lehet a jobb választás a két fenti proci közül. Tehát általános(abb) felhasználásra a több mag, vagy a magonkénti magasabb GHz tekinthető "jobbnak".
(#18) Smiley: ennyire soha nem lesz szükségünk. Nem ez a sarkalatos része a dolognak számunkra. Jelenleg (és már nagyon hosszú idő óta) 3-4 VM-nél nem használunk többet a mostani "központi" gépen sem. Csak mivel be vannak határolva a fejlesztési költségeink, ezért kérdeztem, hogy hosszútávon melyik lehet a jobb döntés. Tudom, hogy ez így túl általános és nehezen megfogható kérdés, de többet sajnos nem írhatok arról, hogy mire használnánk....
-
Fiery
veterán
3 fele die letezik a Haswell-E/EN/EP/EX procikbol. A legkisebb fizikailag 8 magos kialakitasu, es 4-8 magot engedelyez az Intel. Ezt hivja LCC-nek (Low Core Count), 2.6 milliard tranyo, 354 mm2 die. Ez a verzio kerul pl. a Haswell-E (Core i7-5000 csalad -- HEDT szegmens) tokjaba is.
A masodik verzio az MCC (Medium Core Count), 10-12 magos termekekhez, fizikailag 12 maggal. 3.84 milliard tranyo, 492 mm2 die.
Az igazan brutalis pedig a HCC (High Core Count), 14-18 magos termekekhez, a hirben emlitett parameterekkel.
Tehat a 4 magos Haswell-EX-hez a 8 magos die-t hasznalja az Intel, csak letiltja a magok felét. A 4 magos, magas orajelre skalazott procinak pedig nyilvan megvan a maga ertelme, megvan a maga piaca, kulonben az Intel nem veszodne egy ilyen SKU kialakitasaval.
-
joysefke
veterán
nem választasz le semmit.
A virtualizációs réteg ütemezi a fizikai processzormagokat (ezek lehetnek hyperthreading magok is) a futni kívánó virtuális gépek (VM-ek) között. Ha egy VM-hez 4 darab virtuális processzormagot konfuguráltál be (4x vCPU), akkor a virtualizációs réteg ütemezője megpróbál keríteni 4db fizikai processzormagot és azt egy időszelet erejéig odaadja a virtuális gépnek. Ha az ütemező nem tud keríteni éppen 4 darab pizikai magot, akkor nem ütemezi a virtuális gépet (és az éhezik).
Az általános konfiguráció az, hogy a fizikai processzormagok száma jóval kevesebb mint a futtatott virtuális gépekhez bekonfigolt virtuális processzormagok összessége. Ez (is) adja a virtualizált infrastruktúra jobb kihasználtságát.
J.
-
tatabike
őstag
-
Smiley
addikt
Tobbfelekeppen lehet megoldani. Van lehetoseged olyanra is, legalabbis libvirt alatt, hogy pl a proci #1 #2 magja "direktben" (persze a host mindig elsobbseget elvez) csak az "A" virt gepnek all csak rendelkezesre, aztan ezt lehet tovabb bonyolitani, mondjuk #3 #4 -es magok pedig "A" es "B" virt gepek is hasznalhatjak. Tehat akkor "A" gepnek van 2 db olyan magja ami csak neki dolgozik, es meg 2 amin viszont mar osztoznia kell "B" geppel.
-
Peter13
senior tag
Ez a 4 magos kivitel most komoly? Értem én hogy +50% órajel, meg 8 utas, meg qtyafüle, de akkor is, ez azt jelenti hogy az eredetileg 18 magosnak indult lapkából 4 (!) működő magot sikerült összehozni, de azok legalább jó sokat fogyasztanak (140W TDP?!)
Elment ezeknek az eszük, vagy én értettem valamit nagyon félre?
-
sg22
senior tag
de ez nem ugy mukodik h beallitasz pl 2 magot a virtualis gepnek es akkor azt igy levalasztja a procibol. annyit hasznalhat max. pl nalunk is a virt servernek van 64 magja, bevan allitva h X core menjen ehhez, X meg ahhoz MAXIMUM. szoval load hatasara osztja szet az erroforrast.
Olyan programoknal amik ezek a gepek hasznalnak nagyon jol megvan oldva a skalazhatosag, de ez nyilvan szoftverfuggo hogy melyik a jobb (orajel vs mag)
-
imibogyo
veterán
Vigyázat amatőr kérdés következik. Hogyan állnak ezek a processzorok a kihasználtsággal és a skálázhatósággal? Tehát jelenthet annyit, a +2 mag az alkalmazásoknál, mint a majdnem 1 GHz-el magasabb órajel? Persze biztos van eset (renderfarm stb.), amikor igen..... De úgy általában, mondjuk általános szerver feladatokra gondolok.... Konkrétan ennél a két procinál fogalmazódott ez meg bennem:
- E7-8880 v3 (18 mag) 2,5 GHz 4 / 8 utas 45 MB 150 W
- E7-8860 v3 (16 mag) 3,4 GHz 4 / 8 utas 40 MB 140 WNekem valami olyasmi van/volt a fejemben, hogy még mindig előnyösebb a magonkénti magasabb teljesítményt választani, mint a több magot. Persze különösen egy ilyen helyzetben, mert mondjuk 2 vs. 4 magnál 50% a különbség a magokat tekintve, de itt mondjuk a 16 vs. 18 magnál már csak ~12%, miközben az órajelek között ~35%. Lehet nettó hülyeség a kérdés is.
-
#8
macilaci78
nagyúr
macilaci78
nagyúr
Dinnyét! Dinnyét! ...
:
Új hozzászólás Aktív témák
- Nagyon erős ajánlat lett az Apple Watch SE 3
- A magas vérnyomást is felismerheti az Apple Watch Series 11
- BestBuy topik
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Kézbe fogható paradoxon lett az iPhone Air
- Merész dizájn és új teleobjektív az iPhone 17 Pro mobilokban
- Bluetooth hangszórók
- Kerékpárosok, bringások ide!
- Gusztusos, 11 literes térfogatú Jonsbo ház jött a kompaktabb vasakat kedvelőknek
- Azonnali fáradt gőzös kérdések órája
- További aktív témák...
- LG 55C2 - 55" OLED evo - 4K 120Hz 1ms - NVIDIA G-Sync - FreeSync Premium - HDMI 2.1 - A9 Gen5 CPU
- Samsung Galaxy A21s 32GB, Kártyafüggetlen, 1 Év Garanciával
- Xiaomi Redmi 12C 64GB, Kártyafüggetlen, 1 Év Garanciával
- GYÖNYÖRŰ iPhone 14 Pro 256GB Deep Purple -1 ÉV GARANCIA - Kártyafüggetlen, MS3352
- ÁRGARANCIA!Épített KomPhone Ryzen 7 5700X 16/32/64GB RAM RX 9060 XT 8GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft.
Város: Budapest