- gerner1
- bitpork: Augusztus 2- szombat jelen állás szerint.
- sziku69: Fűzzük össze a szavakat :)
- sziku69: Szólánc.
- Luck Dragon: Asszociációs játék. :)
- eBay-es kütyük kis pénzért
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Chosen: Canon 5D II - portrézás 2025-ben
- Geri Bátyó: B550 szűk keresztmetszet, de mi és miért?
- Fogkefe: elektromos vagy manuális?
-
LOGOUT
Mára a ProHardver!/IT.News Fórum is nagylétszámú Linuxban jártas taggal büszkélkedhet. Nehéz szinteket felállítani egy olyan rendszer ismeretében, ami annyira sokrétű, hogy teljesen szinte lehetetlen megismerni minden egyes részét. Azt azonban mindenki tudja, hogy kezdő-e vagy sem. Elsősorban nekik szólnak az alábbiak, de érdemes mindenkinek elolvasnia, mint útjelző táblát.
Új hozzászólás Aktív témák
-
-
válasz
sh4d0w
#32798
üzenetére
Nem tudom, nem jottunk ra. Ryzen 3600-as szervereken neztuk, determinisztikusan softlockupoltak a gepek par naponta, tucatnyi. Default Ubuntu 22.04 minimal installacio + K8s.
https://forum.proxmox.com/threads/kernel-bug-cpu-soft-lockup-vm-host-freezes.110059/
Ezt talaltuk, ami kozel all a problemahoz.
"Since I downgraded to 5.11 it did not crashed while it was crashing several times a day on 5.15 and 5.19." -- ezt esetleg probald meg meg. Nekunk nem jott be.
-
válasz
bambano
#32794
üzenetére
microcode van, korábbi kernelt még nem néztem, de akkor csekkolom azzal is
#32793 emvy
köszi, ezt a kernel paramétert megnézem, energiagazdálkodás ide, vagy oda, fontosabb, hogy ez a gép működjön.
egyébként érdekes módon nem használat közben fagy meg, hanem ha ott hagyom egy időre, de akkor az energiagazdálkodás kilövése segíthet. -
A cegnel lattunk pont ilyet Ryzen szervereken, mas kernelekkel is. Mindegyik (tucatnyi) gepen elofordult sajnos, eros terheles alatt. Intelnel nem volt ilyen.
Azt lehet megprobalni, h a boot parameterekhez hozzaadod azt, hogy processor.max_cstate=1
Mondjuk ez kicsit megb*ssza az energiagazdalkodast.
-
Arch Linux 6.1.1-es és 6.1.2-es kernel, fagyogat a gép.
a journalban ilyeneket olvashatok szép számmaljan 03 00:00:20 vavatch kernel: watchdog: BUG: soft lockup - CPU#8 stuck for 39112s! [kworker/8:0:3803177]
jan 03 00:00:20 vavatch kernel: Modules linked in: xt_nat xt_tcpudp veth xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_filter iptable_nat nf_nat nf_>
jan 03 00:00:20 vavatch kernel: sp5100_tco mdio_devres pcspkr wmi_bmof zcommon(POE) i2c_piix4 k10temp ccp soundcore video znvpair(POE) libphy spl(OE) gpio_amdpt gpio_generic acpi_>
jan 03 00:00:20 vavatch kernel: CPU: 8 PID: 3803177 Comm: kworker/8:0 Tainted: P D W OEL 6.1.1-arch1-1 #1 9bd09188b430be630e611f984454e4f3c489be77
jan 03 00:00:20 vavatch kernel: Hardware name: ASUS System Product Name/TUF GAMING B450-PLUS II, BIOS 3802 04/28/2022
jan 03 00:00:20 vavatch kernel: Workqueue: events drain_vmap_area_work
jan 03 00:00:20 vavatch kernel: RIP: 0010:smp_call_function_many_cond+0xee/0x310
jan 03 00:00:20 vavatch kernel: Code: d0 48 89 df e8 03 36 40 00 3b 05 0d df e9 01 73 26 48 63 d0 49 8b 34 24 48 03 34 d5 a0 7a b5 9f 8b 56 08 83 e2 01 74 0a f3 90 <8b> 4e 08 83 e1>
jan 03 00:00:20 vavatch kernel: RSP: 0018:ffffbe23a858fd90 EFLAGS: 00000202
jan 03 00:00:20 vavatch kernel: RAX: 0000000000000003 RBX: ffffa0480ec34108 RCX: 0000000000000001
jan 03 00:00:20 vavatch kernel: RDX: 0000000000000001 RSI: ffffa0480eafa740 RDI: ffffa0480ec34108
jan 03 00:00:20 vavatch kernel: RBP: 0000000000000000 R08: 0000000000000003 R09: ffffa0480ec34130
jan 03 00:00:20 vavatch kernel: R10: 0000000000000007 R11: 0000000000000000 R12: ffffa0480ec34100
jan 03 00:00:20 vavatch kernel: R13: 0000000000000001 R14: 0000000000000020 R15: 0000000000000008
jan 03 00:00:20 vavatch kernel: FS: 0000000000000000(0000) GS:ffffa0480ec00000(0000) knlGS:0000000000000000
jan 03 00:00:20 vavatch kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
jan 03 00:00:20 vavatch kernel: CR2: 00007f077162fa70 CR3: 000000014dd96000 CR4: 0000000000350ee0
jan 03 00:00:20 vavatch kernel: Call Trace:
jan 03 00:00:20 vavatch kernel: <TASK>
jan 03 00:00:20 vavatch kernel: ? __flush_tlb_all+0x30/0x30
jan 03 00:00:20 vavatch kernel: on_each_cpu_cond_mask+0x24/0x40
jan 03 00:00:20 vavatch kernel: __purge_vmap_area_lazy+0xd6/0x730
jan 03 00:00:20 vavatch kernel: ? __schedule+0x378/0x12a0
jan 03 00:00:20 vavatch kernel: drain_vmap_area_work+0x29/0x60
jan 03 00:00:20 vavatch kernel: process_one_work+0x1c7/0x380
jan 03 00:00:20 vavatch kernel: worker_thread+0x51/0x390
jan 03 00:00:20 vavatch kernel: ? rescuer_thread+0x3b0/0x3b0
jan 03 00:00:20 vavatch kernel: kthread+0xde/0x110
jan 03 00:00:20 vavatch kernel: ? kthread_complete_and_exit+0x20/0x20
jan 03 00:00:20 vavatch kernel: ret_from_fork+0x22/0x30
jan 03 00:00:20 vavatch kernel: </TASK>ki tudtok ebből hámozni valami értelmeset?
meg most van egy ilyen is
jan 03 08:46:15 vavatch kernel: ------------[ cut here ]------------
jan 03 08:46:15 vavatch kernel: list_del corruption. prev->next should be ffff9b0830b241a8, but was ffff9b0d8ea33938. (prev=ffff9b0d8ea33938)memória lehet?
-
Penty
aktív tag
Na, akkor még egy utolsó, mert nem hagyott nyugodni.
Normál betű: Minden sysctl érték alapértelmezetten. A csatolás sync nélküli.
Italic betű: Minden sysctl érték alapértelmezetten, kivéve a:vm.dirty_background_ratio = 1ésvm.dirty_ratio = 2.A csatolás sync nélküli.mv $source $destination
HDD > USBHDD Kb. 4 mp-nél visszakapom a promptot, de a merevlemez kb. 63-69 mp-ig dolgozik.
USBHDD > HDD Kb. 4 mp-nél visszakapom a promptot, de a merevlemez kb. 23-29 mp-ig dolgozik.HDD > USBHDD Kb. 63-67 mp múlva kapom vissza a promptot. A merevlemez még kb. 2 mp-ig dolgozik.
USBHDD > HDD Kb. 23-29 mp múlva kapom vissza a promptot. A merevlemez is kb. ekkor fejezi be.-----
mv $source $destination && sync
HDD > USBHDD Kb. 63-69 mp múlva kapom vissza a promptot. A merevlemez is kb. ekkor fejezi be.
USBHDD > HDD Kb. 23-29 mp múlva kapom vissza a promptot. A merevlemez is kb. ekkor fejezi be.HDD > USBHDD Kb. 63-69 mp múlva kapom vissza a promptot. A merevlemez is kb. ekkor fejezi be.
USBHDD > HDD Kb. 23-29 mp múlva kapom vissza a promptot. A merevlemez is kb. ekkor fejezi be.-----
rsync -ahv --info=progress2 --remove-source-files $source $destination
HDD > USBHDD Kb. 4 mp-nél visszakapom a promptot (de volt, hogy más időpontban), de a merevlemez kb. 63-69 mp-ig dolgozik.
USBHDD > HDD Kb. 4 mp-nél visszakapom a promptot (de volt, hogy más időpontban), de a merevlemez kb. 23-29 mp-ig dolgozik.HDD > USBHDD Az rsync végig frissíti az infókat. Mikor végzett, szépen kilépett, visszaadta a promptot. Mindez a szokásos 63-69 mp körüli idővel. Ingadozás a már korábban említett minimális.
USBHDD > HDD Az rsync végig frissíti az infókat. Mikor végzett, szépen kilépett, visszaadta a promptot. Mindez a szokásos 23-29 mp körüli idővel. Ingadozás a már korábban említett minimális.-----
rsync -ahv --info=progress2 --remove-source-files $source $destination && sync
HDD > USBHDD Az rsync kb. 4 mp-ig frissíti az infóit, majd "kifagy és végez", de nagyjából 63-69 mp-nél kapom vissza a promptot. A merevlemez is kb. ekkor fejezi be.
USBHDD > HDD Az rsync kb. 4 mp-ig frissíti az infóit, majd "kifagy és végez", de nagyjából 23-29 mp-nél kapom vissza a promptot. A merevlemez is kb. ekkor fejezi be.HDD > USBHDD Az rsync végig frissíti az infókat. Mikor végzett, szépen kilépett, visszaadta a promptot. Mindez a szokásos 63-69 mp körüli idővel. (Na jó, talán 1-2 mp-cel lassabb volt.) Ingadozás a már korábban említett minimális.
USBHDD > HDD Az rsync végig frissíti az infókat. Mikor végzett, szépen kilépett, visszaadta a promptot. Mindez a szokásos 23-29 mp körüli idővel. (Na jó, talán 1-2 mp-cel lassabb volt.) Ingadozás a már korábban említett minimális.Ha az alapértelmezett sysctl beállításokkal a csatolásnál használom a sync opciót, akkor nagyon belassul a külső merevlemezre való áthelyezés. Legutóbb 20 perc feletti értéket mértem egy sima mv paranccsal a 2GB-os fájlra.
Nem vagyok egy nagy szakértő, de nekem a módosított verzió kicsit felhasználóbarátabbnak tűnik úgy, hogy közben az áthelyezés ideje – ahogy azt a korábbi hozzászólásból is ki lehetett venni – nem változik jelentősen, illetve egyáltalán.
Bocsi a túl hosszú hozzászólásokért!
-
nah, akkor lassan kezdődik a Linux Éve™
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
Penty
aktív tag
Visszaállítottam mindent az alapértelmezettre, majd a külső meghajtót sync-el csatoltam fel:
mount -o sync /dev/mapper/Backup /media/Backup/
A külső meghajtóra a 2GB-os teszt.dd fájlt a korábban látott kb. 1 perc körüli idő helyett 13:36 perc alatt rakta át. Igaz, hogy mikor visszakaptam a promptot, akkor tényleg be volt fejezve minden, nem szöszmötölt még a háttérben.
Visszahelyezésnél a korábban látott 23 mp helyett kb. 4 mp alatt végzett... őőő... izé... visszaadta a promptot, de utána még vagy 20 mp-ig sync-elt. Szóval a szokásos utólagos molyolás itt megmaradt.Ezek után ismét sync nélkül csatoltam, és inkább a parancs végére raktam sync-et.
Szóval ha az áthelyezős parancs végére rakok egy && sync sort (rsync -ahv --info=progress2 --remove-source-files $source $destination && sync), akkor bár az rsync pár másodpercen belül vissza akarja adni a promptot, de nem tudja, amíg le nem fut a sync. Kb. 01:01 odahelyezési és 00:29-es visszahelyezési idővel jön vissza. Lemezművelet ilyenkor már nincs. Ilyen téren ez már hasonlít a korábbi kísérletezéseimhez időben, azt leszámítva, hogy pár mp után van egy "lefagyott" rsync kimenetem (kb. 00:04-es idővel, meg 450M bytes/sec sebességgel), ami majd csak akkor fog "felolvadni", mikor befejeződik a sync is. Ekkor tudom ismét használni a terminált.
Nekem ez a megoldás kevésbé tetszik, mert a korábbi kísérleteimnél szépen működött az rsync: frissítette végig a sebességet és az időt, és mikor végzett, akkor végzett, ahogy kell. Időben kb. hasonló volt, mint ez a megoldás.Úgy látszik mégiscsak kísérletezgetnem kell még a vm.dirty_ratio és vm.dirty_background_ratio értékeivel, ha - számomra - normális(nak nevezhető) működést szeretnék fájlok külső adathordozóra/adathordozóról való áthelyezésekor...
Na jó, szerintem mára ennyi lesz. BUÉK mindenkinek!
-
De engedi lecsatolni, csak blokkolo call. Szoval addig nem fog visszaterni a mount, amig nem fut le a sync. Ez normal Unix mukodes. Tobb fele keppen is el lehet kerulni:
- Alapbol sync-el mountolsz es akkor nincs page cache
- A dd-t futtatod sync-el
- Hivsz egy sync parancsot a dolog vegenA swappiness-nek nincs koze a page cache-hez.
-
Penty
aktív tag
Ha jól értelmezem, akkor amíg ott van az a dirty_page a kernelben, addig pl. nem engedi lecsatolni a külső hdd-t (mert az bizony még ott kerreg jó pár mp-ig), bár én már visszakaptam a promptot és akár le is csatolhatnám. És engem igazándiból ez zavar. Látszólag vége a dolognak, de a gép még dolgozik ezerrel, nincs meg az az érzés, hogy végzett a művelettel.
Mindenesetre az alapértelmezetthez viszonyítva ezekkel megyek most próbaképpen:
vm.swappiness = 60 (10)
vm.vfs_cache_pressure = 100 (75)
kernel.nmi_watchdog = 1 (0)
vm.dirty_ratio = 40 (2)
vm.dirty_background_ratio = 10 (1)
vm.dirty_expire_centisecs = 3000 (1000)
vm.dirty_writeback_centisecs = 500 (500)
vm.min_free_kbytes = 67587 (232454)Egyelőre okésnak tűnik.
-
válasz
f_sanyee
#32777
üzenetére
hA dirty_ratio-val az a baj, hogy az a memoria szazalekat jelenti, szal ha sok akkor lehet egyszerre nagyon sokat kell majd kiirni. HDD-n en joval konzervativabb szamokat hasznalnek. Az expire_centisecs is 3000 vagyis 30s, az baromi sok. Ha beut a szar akkor nem igazan lesz jo egy ideig a gep semmire amig malmozik es sync-el. Plusz egy kernel crash-nel potencialisan 30s logot vesztesz, ami nyilvan itt nem akkora gond
De akkor is baromi sok. -
Penty
aktív tag
válasz
f_sanyee
#32777
üzenetére
Elképzelhető. Majd még utána kell olvasnom, hogy melyik érték pontosan mit is csinál, bár a CPT.Pirk által belinkelt maxperfwiz scriptben vannak rövid magyarázatok. Egyelőre csak kísérletezgetek, majd még meglátom, hogy mik lesznek a végleges értékek.
Pl. mi történik akkor, ha a vm.dirty_ratio-t visszarakom 40-re, de a vm.dirty_background_ratio megmarad 1-2 környékén.
Mindjárt teszek is egy próbát. -
Penty
aktív tag
válasz
CPT.Pirk
#32774
üzenetére
Reggel 5 körül ébredtem, valamivel el kellett ütni az időt.
"Az áthelyezés ideje pár százalékot romlott..."
Azt hiszem a pontosabb megfogalmazás itt inkább az lenne, hogy a prompt visszaadás ideje "romlott" valamicskét, maga a művelet a prompt visszaadásával ténylegesen befejeződött. Nincs az, hogy még pár másodpercig (pár tíz másodpercig) a háttérben fut a művelet a prompt visszaadása után.
@ (#32775) ivana
Alapból nem szoktam létrehozni dd-vel ilyen fájlokat és azokat másolgatni ide-oda, ezt most csak egy amatőr próba kedvéért tettem, hogy lássam, hogyan befolyásolják a módosított értékek az írási sebességet és stabilitást. Mindenesetre köszi az infót! -
Ha ilyen nagy fajlokat mozgatsz kulso hdd-re akkor nyugodtan be lehet kapcsolni a sync-et. Vagy szimplan futtatni egy sync-et ha vegzett. Az 1MB block size nyugodtan lehet sokkal tobb, en 128MB-vel meg hasonlokkal szoktam. 1MB-vel szoktuk irni 64MB-s, 128MB-s flasht beagyazott rendszeren.
-
Penty
aktív tag
válasz
CPT.Pirk
#32772
üzenetére
Ez lett a hatása:
Elkezdtem a belső és egy külső usb-s hdd között egy pont 2G-os (dd if=/dev/zero of=test1.dd bs=1M count=2048) anyagot oda-vissza mozgatni többször egymás után 40-60 mp-es "pihenőkkel". A mozgatásra az rsync-et használtam: rsync -ahv --info=progress2 --remove-source-files $source $destination
Ezek voltak tehát az alapértelmezett értékek, amikhez hozzányúlt a script:
vm.swappiness = 60
vm.vfs_cache_pressure=100
kernel.nmi_watchdog=1
vm.dirty_ratio=40
vm.dirty_background_ratio=10
vm.dirty_expire_centisecs=3000
vm.dirty_writeback_centisecs=1500
vm.min_free_kbytes=67584Értékek (rövidítve)
60 100 1 40 10 3000 500 675841. menet
hdd > usbhdd 01:02 33.83M bytes/sec
usbhdd > hdd 00:17 122.74M bytes/sec
2. menet
hdd > usbhdd 00:59 35.50M bytes/sec
usbhdd > hdd 00:04 390.55M bytes/sec
3. menetv
hdd > usbhdd 01:03 33.30M bytes/sec
usbhdd > hdd 00:10 204.57M bytes/sec
4. menetv
hdd > usbhdd 01:00 34.93M bytes/sec
usbhdd > hdd 00:04 390.55M bytes/sec
5. menetv
hdd > usbhdd 00:27 75.37M bytes/sec
usbhdd > hdd 00:10 204.57M bytes/secHDD-ről az USBHDD-re: Sokszor megakad az áthelyezés, másodperceket vár, majd hirtelen nagy sebességgel megindul, majd megint megáll. A prompt előbb jött meg, mint ahogy a feladat befejeződött volna.
500-600MB/s-ról indul, majd egyre csökken, de nagyon ugrál. Az egyik menetben 27 mp után visszaadta a promptot, de az usbhdd ledje még 30-40 mp-ig villogott jelezvén, hogy a valóságban még tart az áthelyezés. (Tovább kísérletezve vele volt, hogy 4-5 mp alatt visszakaptam a promptot, de persze a külső lemez még dolgozott vagy egy percig!)USBHDD-ről HDD-re: Ugyanez volt megfigyelhető az usbhdd-ről hdd-re másolásnál is. Gyorsan visszakaptam a promptot, de utána még jó pár másodpercig villogott a laptop hdd aktivitást jelző ledje.
500-600 MB/s-ről indul, de a sebesség nagyon ugrált, sokszor 1-2MB/sec, aztán meg +100MB/sec. Nem volt egy nagyjából stabil sebesség.Összegzés: Nagyon ingadozó sebesség, "hamis" befejezettséget jelző prompt visszaadással.
----------
Srcipt futtatása után:
10 75 0 5 5 3000 1500 2324541. menet
hdd > usbhdd 01:01 34.37M bytes/sec
usbhdd > hdd 00:24 87.67M bytes/sec
2. menet
hdd > usbhdd 01:14 28.83M bytes/sec
usbhdd > hdd 00:24 87.67M bytes/sec
3. menet
hdd > usbhdd 00:56 38.02M bytes/sec
usbhdd > hdd 00:23 91.40M bytes/sec
4. menet
hdd > usbhdd 00:57 36.72M bytes/sec
usbhdd > hdd 00:22 95.47M bytes/sec
5. menet
hdd > usbhdd 00:57 36.72M bytes/sec
usbhdd > hdd 00:23 87.67M bytes/secHDD-ről USBHDD-re: Megakadás nem igazán volt.
300-400MB/s-ről indul, majd egyre csökken, végül 20-50 között ingadozik (néha kicsit több, néha kicsit kevesebb).
Lényegesen kevésbé ingadozik, mint az alapértelmezett beállításokkal.
Az áthelyezés ideje nem sokat változott. Az igazi nyereség, az az ingadozás csökkenése, valamint az, hogy a prompt visszakapása után pár mp-ig még villog a led, de lényegesen kevesebb ideig, mint a fenti esetben.USBHDD-ről HDD-re: Megakadás nem volt itt sem.
200-300MB/s-ről indul, majd egyre csökken, végül nagyjából 50-90 között ingadozik.
Ez is lényegesen kevésbé ingadozik, mint a fentebbi az alapértelmezett beállásokkal.
Az áthelyezés ideje elég stabilan 23 mp körül van, nincsenek nagy kiugrások. A prompt visszakapása után 1 másodperccel később a laptop hdd aktivitást jelző ledje is kialszik.Összegzés: Lényegesen kisebb ingadozás, a prompt visszakapása után pár mp-cel ténylegesen befejeződik a művelet.
----------
Általam végzett módosítások
10 75 0 3 3 3000 1500 2324541. menet
hdd > usbhdd 01:00 34.93M bytes/sec
usbhdd > hdd 00:23 87.67M bytes/sec
2. menet
hdd > usbhdd 01:00 34.93M bytes/sec
usbhdd > hdd 00:26 81.06M bytes/sec
3. menet
hdd > usbhdd 01:00 34.93M bytes/sec
usbhdd > hdd 00:24 84.24M bytes/sec
4. menet
hdd > usbhdd 01:01 34.93M bytes/sec
usbhdd > hdd 00:23 91.40M bytes/sec
5. menet
hdd > usbhdd 01:00 34.93M bytes/sec
usbhdd > hdd 00:24 84.24M bytes/secHDD-ről USBHDD-re: Megakadás nem igazán volt.
100-200MB/sec-ről indult, majd beállt 20-40MB/sec közé. Még kisebb az ingadozás.
Az áthelyezés ideje nem változott. A prompt visszakapása után 2-3 mp-ig még villog a led.USBHDD-ről HDD-re: Megakadás nem volt itt sem.
200-300MB/s-ről indul, majd egyre csökken, végül nagyjából 50-80 között ingadozik.
Az áthelyezés ideje itt is elég stabilan 23 mp körül van, nincsenek nagy kiugrások. A prompt visszakapása után azonnal kialszik a laptop hdd aktivitást jelző ledje.Összegzés: Még kisebb ingadozás, a prompt visszakapása után ténylegesen befejeződik a művelet a külső hdd-ről a belső hdd-re mozgatásnál, de fordítva is csak 2-3 mp-et kell várni a tényleges befejezésre.
----------
Újabb általam végzett módosítások
10 75 0 1 1 3000 1500 2324541. menet
hdd > usbhdd 01:05 32.79M bytes/sec
usbhdd > hdd 00:23 87.67M bytes/sec
2. menet
hdd > usbhdd 01:05 32.30M bytes/sec
usbhdd > hdd 00:24 87.67M bytes/sec
3. menet
hdd > usbhdd 01:06 32.30M bytes/sec
usbhdd > hdd 00:28 75.37M bytes/sec
4. menet
hdd > usbhdd 01:05 32.30M bytes/sec
usbhdd > hdd 00:26 78.11M bytes/sec
5. menet
hdd > usbhdd 01:05 32.79M bytes/sec
usbhdd > hdd 00:25 81.06M bytes/secHDD-ről USBHDD-re: Megakadás nem volt.
100-150MB/sec-ről indult, majd beállt 28-32MB/sec környékére.
Az áthelyezés ideje 5-6 mp-et romlott, viszont a prompt visszakapása után azonnal megáll a lemezművelet is a külső lemezen.USBHDD-ről HDD-re: Megakadás nem volt itt sem.
100-150MB/s-ről indul, majd egyre csökken, végül nagyjából 65-80 között ingadozik.
Az áthelyezés ideje elég stabilan 24 mp körül van, ami egy leheletnyivel rosszabb mint az előző kettő. A prompt visszakapása után azonnal kialszik a laptop hdd aktivitást jelző ledje.Összegzés: Még kisebb ingadozás, a prompt visszakapása után ténylegesen befejeződik a művelet minden irányban. Az áthelyezés ideje pár százalékot romlott, de cserébe elég stabil a sebesség, nem ingadozik nagyon.
Ahogy elnézem a két érték csökkentésével az ingadozások amplitúdója lesz kisebb és az egész művelet a tényleges áthelyezési sebességhez közelebbi értékről indul el. Talán még majd megnézem az egészet 2-es értékkel is. Akkor talán megmarad a minimális ingadozás, de talán nem romlik az áthelyezési idő azzal a pár százalékkal.
-
Penty
aktív tag
válasz
CPT.Pirk
#32762
üzenetére
A kiindulási pont nálam egy Void Linux egy közel 10 éves laptopon, amiben most egy 5200-as HDD van. Az alábbiak voltak az alapértelmezettek itt:
vm.dirty_background_bytes = 0
vm.dirty_background_ratio = 10
vm.dirty_bytes = 0
vm.dirty_expire_centisecs=3000
vm.dirty_ratio=40
vm.dirty_writeback_centisecs=500
vm.dirtytime_expire_seconds = 43200A script még ezekhez is hozzányúlt, amiknek ez volt az alapértelmezett értéke:
kernel.nmi_watchdog = 1
vm.min_free_kbytes=67587
vm.vfs_cache_pressure = 100
vm.swappiness = 60A script futtatása után ezek az értékek lettek:
vm.swappiness = 10
vm.vfs_cache_pressure=75
kernel.nmi_watchdog=0
vm.dirty_ratio=5
vm.dirty_background_ratio=5
vm.dirty_expire_centisecs=3000
vm.dirty_writeback_centisecs=1500
vm.min_free_kbytes=232454Az udev-es beállítást átugrottam.
-
Siriusb
veterán
válasz
CPT.Pirk
#32767
üzenetére
Ez a gyógyhatású változat, latin nevén Archea Vulgaris. Megtalálható otthonokban és irodákban, általában árnyékos helyen lelhető fel. Megfelelő körültekintéssel kell alkalmazni, jó kezekben idegnyugtató, görcsoldó, ám rosszul használva dührohamot és trágár beszédet okoz.
-
Siriusb
veterán
válasz
CPT.Pirk
#32762
üzenetére
Ez lett az új, talán egy kivétellel nem fogadtam el a felajánlott értéket:
Contents of temporary file /tmp/maxperfwiz/99-maxperfwiz.conf:vm.swappiness=10vm.vfs_cache_pressure=75kernel.nmi_watchdog=0vm.dirty_ratio=3vm.dirty_background_ratio=3vm.dirty_expire_centisecs=3000vm.dirty_writeback_centisecs=1500Contents of temporary file /tmp/maxperfwiz/66-maxperfwiz.rules:ACTION=="add|change", KERNEL=="nvme[0-9]*", ATTR{queue/scheduler}="none"ACTION=="add|change", KERNEL=="sd[a-z]|mmcblk[0-9]*", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="mq-deadline"ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="bfq" -
-
CPT.Pirk
Jómunkásember
Nálatok is ez volt az eredeti állapot?
vm.dirty_background_bytes = 0vm.dirty_background_ratio = 10vm.dirty_bytes = 0vm.dirty_expire_centisecs = 1500vm.dirty_ratio = 20vm.dirty_writeback_centisecs = 1500vm.dirtytime_expire_seconds = 43200
Főleg a dirty_ratio a probléma a ma megszokott 16..32GB ram mellett. -
válasz
Siriusb
#32760
üzenetére
Én kipróbáltam, minden opcióra rákérdez, és van egy rövid leírás, hogy az adott dolog mit csinál, és miért érdemes átállítani mire.
Szóval elég bolondbiztos
Illetve mivel tulajdonképp csak két konfigfájlt hoz létre, így ezek törlésével meg újraindítással helyreállítható az eredeti állapot. -
-
válasz
CPT.Pirk
#32752
üzenetére
Ez de jól jött volna, amikor egy alkalommal két rendőrrel egy órán keresztül néztük egymást malmozva, miközben a térfigyelő kameráink felvételeit másoltam nekik egy pendrivera... Nekem volt kellemetlen, hogy mi a francért olyan tetves lassú, de nem küldhettem el őket, hogy "majd szólok ha megvan"
-
#32754
Speeedfire
félisten
Speeedfire
#32751
Speeedfire
félisten
válasz
Speeedfire
#32751
üzenetére
Érdekesség, hogy a nas nem lát egy db hangkártyát se cli alatt. De pl VM alatt már látja a HDMI-t. Ami még furább, hogy a HDMI app (HD Station látja mind a kettőt
)
Még a mai napig tud meglepetést okozni nekem a linux.
A HD Station egy teljesen már rétegen lenne kezelve, ahol már látja ezt? A docker, és a host gép miért nem lát semmit? Illetve a VM miért csak az intel-t látja?! Számomra ez érthetetlen.
-
CPT.Pirk
Jómunkásember
https://gitlab.com/cscs/maxperfwiz/
Arch és Manajro alatt szükséges ez a szkript, ha nagyobb fájlokat szeretnél másolni emberi idő alatt pendrivera, vagy partíciók között.
Ezeket az értékeket variálja, egy részét a gépben lévő ram mennyísége alapján, ezek már a frissített értékek nálam:
vm.vfs_cache_pressure=75vm.dirty_ratio=3vm.dirty_background_ratio=3vm.dirty_expire_centisecs=3000vm.dirty_writeback_centisecs=1500vm.min_free_kbytes=118812Más disztróknál mi a helyzet?
Konkrétan akkor akadtam rá erre, mikor elkezdtem nyomozni, hogy egy 70GB-os fájl másolási sebessége pár perc után miért esett le 1MB/s alá. A szkript futtatása óta meg gyönyörűen tudok másolni ekkora fájlokat is. -
#32751
Speeedfire
félisten
Speeedfire
félisten
Sziasztok,
adott egy qnap 253d nas, amiben docker alatt ezt használom raspotify-hoz. Vagyis csak próbálnám, mert tudok csatlakozni. Viszont nincs hangkártya, pedig át van elvileg mappelve. Miért nem látja? Mit lehetne kezdeni vele?
root@raspotify-docker-1:/# aplay -L
null
Discard all samples (playback) or generate zero samples (capture)
default
plugequal
equal
root@raspotify-docker-1:/# aplay -l
aplay: device_list:274: no soundcards found... -
#32750
lionhearted
őstag
ivana
#32748
Megszaladt valóban.
Visszaolvasva, újragondolva: /var/run alatt a runtime létrehozott fájlok (többnyire mondjuk lock) szoktak lenni, így a tény, hogy nem indul és a tény, hogy nincs ott a socket annak az ok-okozata fordított is lehet... nem indul, ezért nem jön létre a fájl. De ezt nem a telepítés hozza akkor létre, hanem a szolgáltatás.
Nem összekeverendő ez a fájl típus a systemd.socket fájllal...
De nem vagyok CUPS szagértő.
@_ak_ : a compose mapping csak a hoston nézi a szabad portot, hogy belül mi fog ráülni (ha fog bármi bármikor is), az csak később, runtime derül ki.
-
#32749
_ak_
addikt
lionhearted
#32747
_ak_
addikt
válasz
lionhearted
#32747
üzenetére
Ebből a szempontból mindegy kellene, hogy legyen (szerintem), mert CUPS service a portot foglalja le vagyis alapból a 631-es porton figyel. Ez egy szabad port, ha nem lenne az a docker compose sem tudná mappelni, de ez megtörténik.
-
#32748
ivana
Ármester
lionhearted
#32747
válasz
lionhearted
#32747
üzenetére
A socket az socket, nem device.
-
#32747
lionhearted
őstag
_ak_
#32746
-
#32746
_ak_
addikt
lionhearted
#32741
_ak_
addikt
válasz
lionhearted
#32741
üzenetére
Az ulimitre unlimited válasz jön, a tartomány nem tudom, hogy szólhatna bele. Mm mindegyik esetben más tartományban fut. Valami CenOS vagy ESXi specifikus lehet (talán), de semmit nem találok a neten. A konkrét hibára sincs találat sajnos, úgy kellett kibogozni, hogy cups.sock hiánya miatt állhat le a service és ahogy látom annak már a telepítés után ott kellene lennie.
Próbáltam manuálisan létrehozni a socketet, de az sem volt jó (igaz őszintén megvallva nem tudom, hogy egyáltalán valid socket lett-e) -
Archttila
veterán
válasz
Archttila
#32744
üzenetére
Sajnos nem ez a volt a gond. Most arra gyanakszom, hogy az agent korul lesz a problema, bar elvileg a default-agent az esetek 99%-ában tokeletesen mukodik.
journalctl-ba ilyet talaltam amikor ki-be kapcsoltam a kerdeses kontrollert:
Dec 25 08:31:13 arch kernel: microsoft 0005:045E:02E0.0007: unknown main item tag 0x0Dec 25 08:31:13 arch kernel: input: 8BitDo Pro 2 as /devices/pci0000:00/0000:00:08.1/0000:02:00.4/usb3/3-2/3-2.2/3-2.2.2/3-2.2.2:1.0/bluetooth/hci0/hci0:3/0005:045E:02E0.0007/input/input28Dec 25 08:31:13 arch kernel: microsoft 0005:045E:02E0.0007: input,hidraw5: BLUETOOTH HID v9.03 Gamepad [8BitDo Pro 2] on 0a:61:10:06:13:7f -
#32742
Archttila
veterán
lionhearted
#32741
Archttila
veterán
válasz
lionhearted
#32741
üzenetére
3 eszkoz lóg egy BT sticken, amibol az egyik egy 8bitDo Pro 2 controller. Eszrevettem, hogy a tobbi eszkozzel ellentetben a kontrollernek mindig kell korulbelul egy perc mire az adott alkalmazasban (Yuzu, Heroic Games Launcher stb) hasznalhato allapotba kerul, magyaran detektalja.
Szerintetek mi lehet ennek az oka ha:[alucard@arch ~]$ bluetoothctlAgent registered[CHG] Controller 0A:61:10:06:13:7F Pairable: yes[Keychron K8]# devicesDevice B8:F8:BE:7D:A2:BF LG HBS-FN6Device DC:2C:26:26:48:E8 Keychron K8Device E4:17:D8:2E:6D:7B 8BitDo Pro 2[alucard@arch ~]$ sctl.status bluetooth.service● bluetooth.service - Bluetooth serviceLoaded: loaded (/usr/lib/systemd/system/bluetooth.service; enabled; preset: disabled)Active: active (running) since Sat 2022-12-24 07:13:24 CET; 5h 0min agoDocs: man:bluetoothd(8)Main PID: 622 (bluetoothd)Status: "Running"Tasks: 1 (limit: 16609)Memory: 3.2MCPU: 70msCGroup: /system.slice/bluetooth.service└─622 /usr/lib/bluetooth/bluetoothdDec 24 07:37:08 arch bluetoothd[622]: profiles/input/device.c:ioctl_is_connected() Can't get HIDP connection infoDec 24 07:37:13 arch bluetoothd[622]: profiles/input/device.c:control_connect_cb() connect to E4:17:D8:2E:6D:7B: Host is down (112)Dec 24 07:37:38 arch bluetoothd[622]: profiles/input/device.c:ioctl_is_connected() Can't get HIDP connection infoDec 24 07:37:43 arch bluetoothd[622]: profiles/input/device.c:control_connect_cb() connect to E4:17:D8:2E:6D:7B: Host is down (112)Dec 24 07:38:08 arch bluetoothd[622]: profiles/input/device.c:ioctl_is_connected() Can't get HIDP connection infoDec 24 07:38:13 arch bluetoothd[622]: profiles/input/device.c:control_connect_cb() connect to E4:17:D8:2E:6D:7B: Host is down (112)Dec 24 07:38:38 arch bluetoothd[622]: profiles/input/device.c:ioctl_is_connected() Can't get HIDP connection infoDec 24 07:38:43 arch bluetoothd[622]: profiles/input/device.c:control_connect_cb() connect to E4:17:D8:2E:6D:7B: Host is down (112)Dec 24 09:21:32 arch bluetoothd[622]: /org/bluez/hci0/dev_B8_F8_BE_7D_A2_BF/sep2/fd0: fd(33) readyDec 24 10:14:46 arch bluetoothd[622]: src/profile.c:ext_io_disconnected() Unable to get io data for Hands-Free Voice gateway: getpeername: Transport endpoint is not connected (107) -
#32741
lionhearted
őstag
_ak_
#32740
-
_ak_
addikt
Sziasztok!
CUPS problémám van és kifutottam mindenféle ötletből.
Van egy docker image-em (temurin-17/focal) ahol többek között is CUPS-ot is installálok. Azure Ubuntu (20.04) VM-re telepített dockerben futtatom az image-t, minden az elvárták alapján működik.
Viszont (majdnem) ugyan az az image egy ESXi-ben futtatott CentOS 9-re telepített dockerben másképp működik.
A hiba amit a CUPS logol:X [19/Dec/2022:14:20:06 +0100] cupsdDoSelect() failed - Bad address!X [19/Dec/2022:14:20:06 +0100] Listeners[0] = 6X [19/Dec/2022:14:20:06 +0100] Listeners[1] = 7X [19/Dec/2022:14:20:06 +0100] Listeners[2] = 8X [19/Dec/2022:14:20:06 +0100] CGIPipes[0] = 9E [19/Dec/2022:14:20:06 +0100] Scheduler shutting down due to program error.
Addig sikerült eljutnom, hogy a /var/run/cups-ban itt nincs cups.sock és nagy valószínűséggel ezért kapom a Bad address! hibát is.
Természetesen próbáltam már északnak állítva a laptopot fejenpörögve elindítani a CUPS-ot, ezen VM-én pontosabban dockerben egyszer szer sem sikerült futtatnom, amúgy a host OS-en is rendben megy.
Triviálisnak tűnő ötleteket is szívesen fogadok. -
hyrex
tag
válasz
bambano
#32722
üzenetére
Nem.
Ez alapján Windows alatt beállítottam: https://dosbox-x.com/wiki/Guide%3ASetting-up-printing-in-DOSBox%E2%80%90X#_windows_host_method_2De én kifejezetten Linux alatt szeretném megoldani. Nincs parport0-ám és ha jól értem az lenne Linux alatt az lpt port:
https://dosbox-x.com/wiki/Guide%3ASetting-up-printing-in-DOSBox%E2%80%90X#_linux_host_2Ezért gondoltam arra, hogy kiíratom fájlba, aztán az lp -d nyomtato_neve -o raw prnt.txt parancsal meg kinyomtatom. Csak arra nem találtam megoldást, hogy másodpercenként nézze a fájlt, hogy módosítás történt-e.
-
#32735
gregory91
senior tag
fatpingvin
#32734
gregory91
senior tag
válasz
fatpingvin
#32734
üzenetére
A glibc6 -nak vannak depedenciái ha azok valahol elakadtnak akkor a rendszernek "kampec".
Ilyenkor(még előtte) KÖTELEZŐ egy mentést csinálni a jelenlegi állapotáról. -
#32733
fatpingvin
addikt
bambano
#32729
fatpingvin
addikt
válasz
bambano
#32729
üzenetére
jogos. ez így hirtelen nem jutott eszembe pedig valóban egyszerűbb, bár emlékeim szerint egy már lokálisan meglévő csomagnál nem számít a signature*. a lényeg ugyanaz, lett egy, a rendszerbe abszolút nem illeszkedő csomagod ami egy olyan állapot amit alapvetően inkább megszüntetni illik mint előállítani.
*csináltam már ilyet, valami audiovizualizációs cuccnál aminek a deb csomagjában a drága fejlesztő benne hagyta a building dependencyket is, hogy milyen megfontolás alapján azt meg ne kérdezd, de at that point egyszerűbb volt így megoldani mint újraforgatni az egészet.
-
#32731
lionhearted
őstag
bambano
#32729
válasz
bambano
#32729
üzenetére
Amit csak repo esetén lehet érdemben ellenőrizni, tudtommal debianban csak a Repository fájl/adatbázis van aláírva, és abban van a hash a csomagra vonatkozóan.
A lokálisan felforceolt deb nem tartozik ebbe a körbe, így ebből nincs gond.RPM-ben előfordul a csomag aláírás is.
-
#32730
Fecogame
veterán
fatpingvin
#32728
válasz
fatpingvin
#32728
üzenetére
Abszolút megválasztoltad a kérdésem
Ezek alapján tényleg szüksége van az összes csomagra a nano frissítéséhez, csak nem gondoltam, hogy ennyire kiterjed a dolog -
#32729
bambano
titán
fatpingvin
#32728
bambano
titán
válasz
fatpingvin
#32728
üzenetére
helyesen: olyankor marad az a csótány megoldás, hogy letöltöd a legújabb debet, és dpkg -i --force-depends vagy force-all kapcsolóval felrakod és utána hold-ra rakod.
a deb kicsomagolását és visszacsomagolását nem javasolnám, mivel jó eséllyel eltöri az aláírást.
-
#32728
fatpingvin
addikt
Fecogame
#32727
fatpingvin
addikt
válasz
Fecogame
#32727
üzenetére
örülök ha segíthettem
viszont hadd kérdezzek vissza, ez válasz volt a kérdésedre?
ha önmagában egy csomagot akarsz frissíteni a potenciális dependency breaking árán, azt az APT legjobb tudomásom szerint (amúgy teljesen érthető okokból) nem támogatja. olyankor marad az a csótány megoldás hogy beszerzed valahonnan a csomagot, kibontod, törlöd a dependency listáját, újracsomagolod és felteszed, de ez az a fajta tákolás amit senkinek nem javaslok ugyanis kb garantáltan gallyra fog menni valami, nem véletlenül van kitalálva a függőségkezelés.
ja, és a --no-install-recommends nem írja felül, csak potenciálisan lecsökkenti a járulékosan upgradelt-telepített csomagok listáját ha van köztük olyan ami nem dependency csak recommended. az APT ugyanis by default arra van konfigurálva hogy a recommended csomagokat is dependencyként kezelje, kivéve ha ez valahol törést okozna, olyankor nyilván nem. meg lehet mondani neki explicite hogy ne így viselkedjen default de hacsak nbem valami célirányosan nagyon minimál rendszerre van szükséged akkor nem érdemes, nem véletlenül van szétszedve a recommended és a suggested: a suggested tényleg csak a javasolt, a recommended viszont simán lehet hogy konkrétan kell a csomag funkcionális működéséhez, csak technikailag üzemképes anélkül is.
-
#32727
Fecogame
veterán
fatpingvin
#32726
válasz
fatpingvin
#32726
üzenetére
-
#32726
fatpingvin
addikt
Fecogame
#32725
fatpingvin
addikt
válasz
Fecogame
#32725
üzenetére
apt show nano megválaszolja a kérdésed...
Depends: libc6 (>= 2.27), libncursesw6 (>= 6), libtinfo6 (>= 6)
magyarán a dependency resolver nem tudja CSAK a nanót frissíteni ugyanis az új verzió magával hozza a dependencyk új verziójától való függőséget is. jelen esetben ez a 3 csomag az ami érintett, ott is vannak a listában, viszont ezeknek is vannak saját függőségeik. esetleg rá lehet próbálni a --no-install-recommends kapcsolóra
az --only-upgrade switch nem azt csinálja hogy a függőségi fa figyelmen kívül hagyásával feldobja a legújabb csomagot aztán vagy működik vagy nem, hanem a fán simán csak nem megy tovább a hard dependencyknél, azokat viszont mint minden normális dependency resolver, frissíti.
-
hyrex
tag
#32719 Lenry: Azt szeretném kiváltani ha lehet.
#32720 bambano: Úgy sikerült beállítanom még Windows alatt, hogy ablakban feldobta milyen nyomtatóra szeretném ha nyomtatna. De emlékeim szerint a nyomtatás sem volt jó.Próbálnék valami linuxos megoldást keresni, főleg a kihívás miatt.
-
hyrex
tag
Sziasztok!
Segítséget szeretnék kérni. Van egy Dos-os programom. Ez a program tudna nyomtatni is lpt porton keresztül, 32BIT-es Windows alatt ez működik is. Linux Mint DosBox-X alatt el is indítottam a programot, viszont a nyomtatásnál megállt a fogaskerekem. Azzal próbálkoztam, hogy fájlba kiíratom a nyomtatni kívánt dolgokat majd az lp -d nyomtato_neve -o raw prnt.txt -el kinyomtatom. Nekem az kellene, hogyha új adat kerül bele a fájlba akkor nyomja ki a gép.
Ez hogyan oldható meg? Vagy esetleg milyen megoldás van hálózati megosztáson lévő DOS program elindítására?
A válaszotokat előre is köszi!
-
felora:)
tag
Sziasztok!
Olyan kérdésem lenne, hogy:
Van egy gépem, 2x Xeon E5-2630Lv2 (SR1AZ) 6-Core 12-Threads 2.4GHz, tehát összesen 24 szál, 32gb DDR3. (Dell PowerEdge R720-8BAY-LFF-CTO)10G SFP+ kártyán amikor magas sávszél kéne, akkor "csak" legjobb esetben is 6G körül mozog a sebesség. A CPU kihasználtságot elnézve 1 magot pörget ilyenkor 100% -on...
Az oprendszer az IPFire amivel a sebesség probléma van. Ha Debian alatt próbálom akkor tökéletesen megy ezzel a géppel, ott hozza az elvárt 10G körüli sebességet.
Annyi még, hogy egy Kontron KTQM87 lapban az IPFire az SFP+ kártyával szintén hozza a 10G körüli sebességet.... A KTQM87 lapban egy I7 4860EQ proci van 4 mag / 8 szál... Ott nem "csak" 1 magot pörget 100% -on, hanem azért szét osztja...
Hasonlóval találkozott már valaki?
Vagy merre induljak el, mit nézzek meg, hogy hol lehet a probléma? -
_Dumber_
őstag
válasz
_Dumber_
#32715
üzenetére
Válaszolva a saját kérdésemre:
2 napos szívás és internet feltúrása után egy kernel visszaűállítás segített a dolgon.
Rossz kernel: Arch: 5-15-81-1 LTS
Ami még biztos, hogy jó: 5-10-90-1 LTS (lehet hogy az 5-15 eleje is megfelelő, de nem próbáltam).
Valamint az aktuális Nem LTS 6-os is működik. -
_Dumber_
őstag
Sziasztok
Mai napon a hanggal gyűlt meg a bajom
Ha bekapcsolom a gépemet, akkor bámely alkalmazással amivel hangot tudok lejátszani működik hang (pl chrome: youtube, youtubemusic, spotify) egésszen addig, amíg ezt az alkalmazást be nem zárom.
Problémaehy példa alapjn:Gép bekapcs.
Spotify indít : zene hallható
"pause"-val megállítom, majd újraindítom, még mindig van hang.
Alkalmazást bezárom, majd bármely másikat (video vagy audio) alkalmazást elidítok, akkor már nincs hangom.Ezt elő tudom adni, chrome+video, vagy youtubemusic alkalmazással is.
Ezekután már rendszerhangom sincs. A hangbeállításokban a "teszt" sem működik, pedig a "hangeszköz beállításokban" látszólag minden rendben. Meg vannak a eszközök és a kienetek is.
A problémát a pipewire.session ujraindítása oldja meg, a következő lejátszás + alkalmazás bezárásig.Merre induljak el a hibakeresésben?
(Archlinux+ KDE + pipewire)
-
#15041568
törölt tag
- Egy ideje opcionálisan választható telepitésnél a teljes lemez titkositása [pld. LinuxLite, Xubuntu].
- A VeraCrypt gyakran elhasal, rossz vége lehet, ha bent maradnak a cuccok a konténerben.
- A TrueCryptnél ilyet még nem tapasztaltam. [sudo add-apt-repository ppa:stefansundin/truecrypt..]
- Andreas csak simán menő, jelszavaknál hasznos 2 platform között, de hasonlóra alkalmas az md5hashing.net is -
-
![;]](http://cdn.rios.hu/dl/s/v1.gif)
De akkor is baromi sok.
Új hozzászólás Aktív témák
Hirdetés
- Assassin's Creed Shadows Collector's Edition PC
- Windows, Office licencek kedvező áron, egyenesen a Microsoft-tól - Automata kézbesítés utalással is!
- Eladó steam/ubisoft/EA/stb. kulcsok Bank/Revolut/Wise (EUR, USD, crypto OK)
- Microsoft licencek KIVÉTELES ÁRON AZONNAL - UTALÁSSAL IS AUTOMATIKUS KÉZBESÍTÉS - Windows és Office
- Bontatlan - BATTLEFIELD 1 Collectors Edition - Játékszoftver nélkül
- Nincs még weboldala, vagy szeretne újabbat? 50.000-ért teljes oldalt kap
- AKCIÓ! AMD Ryzen 7 3800X 8mag 16szál processzor garanciával hibátlan működéssel
- Bomba ár! Lenovo X1 Yoga 2nd - i7-7G I 8GB I 256SSD I 14" WQHD I HDMI I W11 I CAM I Garancia!
- ÁRGARANCIA!Épített KomPhone Ryzen 7 9800X3D 64GB RAM RTX 5080 16GB GAMER PC termékbeszámítással
- Telefon felváráslás!! iPhone 15/iPhone 15 Plus/iPhone 15 Pro/iPhone 15 Pro Max
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged