-
Fototrend
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
-
Lenry
félisten
válasz
#79484416
#33735
üzenetére
mondom, a december közepe előtti infók ebből a szempontból irrelevánsak, mert ott használatban van a gép. amikor azt látszik, hogy hirtelen nagyon felugrik a memóriahasználat, ott valószínűleg épp elindítottam egy VM-et. de az a memória mindig fel is szabadul, amint a VM leáll.
láthatod is, hogy pl október 1 körül, vagy október 7 körül, ami hétvége, szépen alacsonyan marad a görbe, mert hétvégén nem történt semmi. ez lenne a normális.
most meg december közepe óta unalmában malmozik a gép, mégis egyenletesen emelkedik a memóriahasználat, ahogy azt a görbe jobb oldala mutatja is -
Lenry
félisten
válasz
bambano
#33732
üzenetére
én úgy látom nem
lenry@vavatch:~$ cat /proc/meminfo
MemTotal: 65769168 kB
MemFree: 973844 kB
MemAvailable: 51837440 kB
Buffers: 677280 kB
Cached: 50765676 kB
SwapCached: 0 kB
Active: 2061772 kB
Inactive: 51819556 kB
Active(anon): 18040 kB
Inactive(anon): 2582792 kB
Active(file): 2043732 kB
Inactive(file): 49236764 kB
Unevictable: 64 kB
Mlocked: 64 kB
SwapTotal: 4117508 kB
SwapFree: 4116996 kB
Zswap: 0 kB
Zswapped: 0 kB
Dirty: 876 kB
Writeback: 0 kB
AnonPages: 2403540 kB
Mapped: 1269580 kB
Shmem: 162444 kB
KReclaimable: 581068 kB
Slab: 780972 kB
SReclaimable: 581068 kB
SUnreclaim: 199904 kB
KernelStack: 22176 kB
PageTables: 49540 kB
SecPageTables: 0 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 37002092 kB
Committed_AS: 12910736 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 259584 kB
VmallocChunk: 0 kB
Percpu: 21120 kB
HardwareCorrupted: 0 kB
AnonHugePages: 610304 kB
ShmemHugePages: 0 kB
ShmemPmdMapped: 0 kB
FileHugePages: 0 kB
FilePmdMapped: 0 kB
Unaccepted: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
Hugetlb: 0 kB
DirectMap4k: 1580052 kB
DirectMap2M: 20348928 kB
DirectMap1G: 45088768 kB -
Lenry
félisten
válasz
#79484416
#33731
üzenetére
de tudja, de most mivel vagyok előrébb pl ezzel a grafikonnal?
tudom enélkül is hogy elfogy
per-process meg nem tudja figyelni (legalábbis nem tudok róla)ha legalább az látszódna belőle, hogy mikor kezdett meglódulni, azzal hasznomra lenne, de csak most a karácsonyi időszak alatt látszik igazán, hogy nulla használat mellett is elfogy a RAM, hogy korábban is tele volt, az azért, mert dolgoztam vele.
(bár az a november végétől kezdődő lendületes felívelés kicsit gyanús) -
Lenry
félisten
a neten kutakodva találtam egy memwatch nevű programot, ami ezt mondta:
ő szerinte az X-ből folyik a RAM, úgyhogy próbaképp leállítottam a grafikus alrendszert (itthonról úgyis csak az SSH-t látom a gépből 
). persze az elfolyt memória már nem szabadult fel, így most le is tiltottam azt, majd restart.
újraindulás után 1.68GB a foglalt RAM, holnap ránézek mi a helyzet. -
Lenry
félisten
ez egy sima egyszerű asztali számítógép, az én céges munkaállomásom, Arch Linux fut rajta KDE-vel. ez a napi használós gépem.
1-1 VM-et időnként elindítok Virtualboxban, de a memóriafoglaltság konzisztens a VM-ek futásával, tehát lefoglalásra kerül a VM indításakor és felszabadul, amint az leáll.
adatbázisokat nem futtatok.tmpfs-ben van a /tmp, de az szintén egyértelműen látszik, ha van ott valami, az növeli a memóriahasználatot, letöltési mappának használom. viszont mint írtam is: be se voltam jelentkezve reboot után 5 napig, semmi se volt a /tmp-ben (sem)
alább az aktuális állapot, 1 nap uptime, reboot után kb 2GB RAM volt foglalt, azóta hozzá se nyúltam, mostanra 7.3GB RAM már elfogyott
lenry@vavatch:~$ cat /proc/meminfo
MemTotal: 65769164 kB
MemFree: 45873408 kB
MemAvailable: 58073872 kB
Buffers: 576056 kB
Cached: 12126224 kB
SwapCached: 0 kB
Active: 1691784 kB
Inactive: 11438444 kB
Active(anon): 1656 kB
Inactive(anon): 434648 kB
Active(file): 1690128 kB
Inactive(file): 11003796 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 4117508 kB
SwapFree: 4117508 kB
Zswap: 0 kB
Zswapped: 0 kB
Dirty: 384 kB
Writeback: 0 kB
AnonPages: 425664 kB
Mapped: 371904 kB
Shmem: 8356 kB
KReclaimable: 504508 kB
Slab: 633000 kB
SReclaimable: 504508 kB
SUnreclaim: 128492 kB
KernelStack: 10384 kB
PageTables: 8244 kB
SecPageTables: 0 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 37002088 kB
Committed_AS: 2138360 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 256328 kB
VmallocChunk: 0 kB
Percpu: 17280 kB
HardwareCorrupted: 0 kB
AnonHugePages: 272384 kB
ShmemHugePages: 0 kB
ShmemPmdMapped: 0 kB
FileHugePages: 0 kB
FilePmdMapped: 0 kB
Unaccepted: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
Hugetlb: 0 kB
DirectMap4k: 390164 kB
DirectMap2M: 4761600 kB
DirectMap1G: 61865984 kB -
Lenry
félisten
lenry@vavatch:/mnt/adat/docker/pxe$ sudo smem -t -a -k --realmem=65536M -w
Area Used Cache Noncache
firmware/hardware 1.3G 0 1.3G
kernel image 0 0 0
kernel dynamic memory 46.4G 13.2G 33.2G
userspace memory 191.2M 87.6M 103.6M
free memory 16.1G 16.1G 0
-----------------------------------------------
64.0G 29.4G 34.6G -
Lenry
félisten
passz, egy docker fut (egy pxe szerver, a docker stats szerint eszik vagy 60 mega RAM-ot)
leállítottam a dockert meg a containerd-t, nem szabadult fel memória.egyébként azt nézem, hogy más gépemen is ennyiszer fut, még olyanon is, ahol nem is fut egyetlen konténer se
most egymás után kilövök mindent, aztán hátha látszik valami csökkenés
-
Lenry
félisten
Nem hiszem hogy ilyen lett volna korábban, de igazából csak most tűnt fel, amikor egyszercsak kifogyott a 32GB-ból és elkezdett minden akadozni.
Ezért is bővítettem gyors tapaszként 64-re, de nyilván ez is csak az időtávot nyújtja meg, amíg tele tudja szemetelni.Smem-et megnézem, köszi
-
#33662
Lenry
félisten
fatpingvin
#33661
Lenry
félisten
válasz
fatpingvin
#33661
üzenetére
Igen
-
#33660
Lenry
félisten
fatpingvin
#33659
Lenry
félisten
válasz
fatpingvin
#33659
üzenetére
nem lettem előrébb
-
Lenry
félisten
valahol valamiből folyik a memória, mert 2 nap uptime után úgy fogyott el 40GB, hogy semmi se fut, a KDE bejelentkező képernyője, meg én SSH-n belépve.
lenry@vavatch:~$ free -m
total used free shared buff/cache available
Mem: 64227 41003 2994 10 21215 23224
Swap: 4021 2 4018akármivel nézem, sehol sem látszik, hogy mi ette meg a RAM-ot
hol kellene néznem vagy milyen toollal? -
#33644
Lenry
félisten
lionhearted
#33643
Lenry
félisten
válasz
lionhearted
#33643
üzenetére
256GB RAM van a gépekben, 1-2-3 GB átmásolása után dobja el magát. teljesen egyforma telepítések, így igen, az rsync is egyforma.
jumbo frame sem segítettzfs snapshotokat küldenék ssh-n, ugyanígy eldobja magát
-
Lenry
félisten
adott két gép, 10G-s ethernettel összekötve.
tök faszán működik a kapcsolat közöttük, amíg csak bohóckodok, tehát pl egy iperf a végtelenségig fut hibátlanul.
viszont amint elkezdenék fájlokat másolni közöttük rsync-kel, akkor némi másolgatás után client_loop: send disconnect: Broken pipe
sehol nem látszik semmi hiba. nem szakad meg a kapcsolat. cseréltem kábelt. kötöttem össze őket routeren keresztül és közvetlenül is. mindig ugyanez az eredmény, hogy eldobja magát valamiért.
miért?két egyforma Dell R540-ről van szó, Broadcom BCM57416 NetXtreme-E Dual-Media 10G kártya van köztük, amikor router is volt, az egy Mikrotik CRS309-1G-8S+ volt. Ubuntu Server fut rajta.
-
Lenry
félisten
a scrub indítható akár kézzel is
hdd csere nem nagy truváj, elfaileled a diszket, amit ki akarsz venni, kicseréled, aztán azt mondod, hogyzpool replace kötetNév régiHDD újHDD
átméretezést egyszer csináltam (miután kicserélgettem a diszkeket), úgy rémlik kifejezetten fájdalommentes volt az is, de a konkrét parancsokra már nem emlékszem.
az ArchWikin sokmindenre kiterjedő leírás van a ZFS-ről, érdemes átböngésznisebesség tekintetében viszont passz. nem rémlik, hogy valaha lett volna tapasztalatom RAID5-tel
-
Lenry
félisten
tizenéve használok ZFS-t, eddig a legnagyobb megelégedésemre, azóta a ZFS Kisegyház elkötelezett híve vagyok
öt lemezzel pont faszán össze tudsz rakni egy RAID-Z tömböt, az egy lemez kihalását gond nélkül átvészeli. havonta automatikusan fut egy scrub, az átvakarja a tömböt, szól ha gebasz van.
egyébként meg fasza snapshot kezelés, stb stb. szóval forrón ajánlom a ZFS-t -
-
Lenry
félisten
válasz
bambano
#33383
üzenetére
de, írtam:
"egy olyan parancs kellene, ami a parancs kiadástól legkésőbb rebootig érvényes"egy hordozható pxe szervert csinálok éppen dockerben.
odaviszem a laptopomat az akárhova, összekötöm a klienssel, elindítom a docker stacket, és onnantól az én gépem a DHCP szerver, és róla lehet bootolni is.
ez tök jól működik, egyetlen szépséghibája van a dolognak, hogy a laptopomnak az az eth0-ja, amin keresztül mindez bonyolódik, is szeretne IP címet kapni a dockerben futó DHCP szervertől, amire ez idő alatt semmi szüksége.
ez igazából gondot nem okoz, azon kívül, hogy fél percenként kapok egy hibaüzenetet, hogy nem sikerült, de ha ki tudnám küszöbölni, annak nagyon örülnék.tehát csak addig kellene letiltva lennie a DHCP kérésnek, amíg ez a docker fut, tehát egy disable az elejére, meg egy enable a végére tökéletesen kielégítené az igényemet
közben azt már megtaláltam, hogy mondhatom, hogy
systemctl stop dhcpcd@eth0.servicecsak sajnos a NetworkManager akkor is kér IP-t, ha meg azt lövöm le, az mindent hálózati kapcsolatomat eldobja (márpedig az nem baj, ha WiFi pl továbbra is van) -
-
Lenry
félisten
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. -
Lenry
félisten
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?
-
Lenry
félisten
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. -
Lenry
félisten
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"
-
#32693
Lenry
félisten
fatpingvin
#32692
Lenry
félisten
válasz
fatpingvin
#32692
üzenetére
szerintem a systemd-nek tudnia kellene ilyesmit, de nézz körül a manual vonatkozó oldalán
-
Lenry
félisten
válasz
Dißnäëß
#32647
üzenetére
rákeresel a fájlra és törlöd, ha megtalálod
find . -type f -name "*.txt" -exec rm -rf {} \;
aztán lefuttatsz egy második kört és ugyanígy törölteted az üres könyvtárakatfind . -type d -empty -exec rmdir {} \;mit csinál az rm-nél a d kapcsoló? a man szerint nincs neki olyanja
-
Lenry
félisten
válasz
bambano
#32601
üzenetére
azért a teljesség kedvéért azt tegyük hozzá, hogy nem ez a stable kernel, amit ma Debianéktól megkapsz, hanem ez:
lenry@Echo-Five:~$ cat /proc/version
Linux version 5.10.0-18-amd64 (debian-kernel@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.140-1 (2022-09-02)illetve ez a múlt havi, mert azóta nem indítottam újra, de az aktuális se sokkal újabb
-
#32587
Lenry
félisten
fatpingvin
#32586
Lenry
félisten
válasz
fatpingvin
#32586
üzenetére
-
Lenry
félisten
(k)Ubuntu:
többedszerre szaladok bele, de nem hiszem, hogy én vagyok a hülye, próbálja már ki valaki, akinek van lehetősége rá:
PXE-n keresztül indított live Ubuntut tegyél fel UEFI rendszerre.
egyszerűen képtelen megcsinálni a bootot rendesen az installer. nem lesz Grub, se EFISTUB, semmi. látszólag faszán feltelepül, épp csak képtelenség a telepített rendszert elindítani.tökugyanazt pendriveról tökugyanúgy telepítve meg jó.
-
Lenry
félisten
nem teljesen irreleváns, de ha Linuxról osztod meg, akkor érdemes Linuxos fájlrendszert használni (pl ext4-et), Sambán keresztül ugyanúgy meg tudod osztani, a Windows ugyanúgy el fogja érni (és NTFS-nek fogja látni)
az NTFS-t sokkal lassabban és nagyobb CPU terheléssel kezeli a Linux
-
Lenry
félisten
válasz
TMisi92
#32186
üzenetére
find . -type d -mtime +1460 -mindepth X -maxdepth Y -exec du -h {} \;
ahol
-type d - 4 évnél öregebb almappákat és fájlokat - na most a mappa legyen 4 éves, vagy a fájl, ami benne van? ha fájlt akarsz, akkor -type f
-mtime +1460 - a mappa (vagy fájl) modifytime értéke legyen 1460-nál több (4*365)
-mindepth X -maxdepth Y - keresési mélység, pl min 1 max 2 azt jelenti, hogy az adott mappaszinten és eggyel alatta fog keresni.
-exec du -h {} \; - a keresési feltételeknek megfelelő fájlok méretét kilistázza human-readable formában -
#32184
Lenry
félisten
Speeedfire
#32182
Lenry
félisten
válasz
Speeedfire
#32182
üzenetére
De ennek nincs netbootja? A HC4 indulás után hozza a petitboot nevű rendszerbetöltőt, annak azt mondod, hogy netboot_default és akkor elkezdi listázni a hálózatról telepíthető OS-eket. Indítasz egy szimpatikusat, utána már ugyanolyan, mint minden más gépen.
-
#32181
Lenry
félisten
Speeedfire
#32176
Lenry
félisten
válasz
Speeedfire
#32176
üzenetére
ha telepítéskor már van HDD az odroidban, akkor a telepítőben simán ki tudod választani, hogy az legyen a
/, az SD kártya meg a/boot.
ennek elméletileg out-of-the-box működnie kellenevan egy HP szerverünk, aminek a RAID vezérlője vagy RAID-módban van, akkor virtuáldiszkeket hozol létre, azt adja oda az OS-nek, és tud bootolni, vagy HBA módban van, akkor közvetlenül el tudja érni az OS a diszkeket, cserébe nem lehet róla bootolni.
na ebben a gépben oldottam meg a fenti módon a bootolást, miután felfedeztem, hogy van az alaplapon egy SD foglalat, amiről hajlandó bootolniamúgy nekem szimpi cucc ez az odroid, pár hete vettünk egy HC4-et a céghez, ha csak be kell pattintani valamibe egy HDD-t, arra tökéletes
-
#32175
Lenry
félisten
Speeedfire
#32174
Lenry
félisten
válasz
Speeedfire
#32174
üzenetére
szerintem működhet az ötlet
-
#32163
Lenry
félisten
MasterMark
#32162
Lenry
félisten
válasz
MasterMark
#32162
üzenetére
SSD-n van egyáltalán értelme a defragnak?
nincs -
Lenry
félisten
válasz
janos666
#32153
üzenetére
most sincs defrag. mondjuk fragmentáció se nagyon, így nem is hiányzik.
a munkahelyemen nagyjából minden szerveren ZFS-t használunk (meg én a saját gépeimen is), mission critical gépeken is, eddig semmiféle lassulást nem vettünk észre, szóval nem tudom nálad mi történhetett.mindenesetre én boldog vagyok a ZFS-el, csak ajánlani tudom
-
#32141
Lenry
félisten
fatpingvin
#32140
Lenry
félisten
válasz
fatpingvin
#32140
üzenetére
fedorán néztem, azon se jó.
de most kipróbáltam egy sima MS irodai egérrel, azzal faja - emez valami géniusz gémer cucc, világít minden irányba.
itt lesz a probléma gyökere akkor...
ő szerinte az X-ből folyik a RAM, úgyhogy próbaképp leállítottam a grafikus alrendszert (itthonról úgyis csak az SSH-t látom a gépből 
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
- Hobby elektronika
- Bemutatkozott a Fairphone 6
- Pánik a memóriapiacon
- Eredeti játékok OFF topik
- Energiaital topic
- Soundbar, soundplate, hangprojektor
- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
- MWC 2026: Kezünkben a minden tekintetben európai okostelefon
- Napelem
- Milyen belső merevlemezt vegyek?
- További aktív témák...
- Apple iPhone 14 Pro 128GB,újszerű, Adatkabel,12 hónap garanciával
- Gamer PC-Számítógép! Csere-Beszámítás! R5 3600 / RX 5700XT / 16GB DDR4 / 500 SSD + 1TB HDD
- Apple iPhone 16 Pro Max 256GB Desert Titanium használt, megkímélt 100% akku (13 ciklus) 6 hón
- BESZÁMÍTÁS! ASUS ROG B760 i9 14900K 32GB DDR5 1TB SSD Asus ROG RTX 3090 24GB Zalman Z1 1000W
- iKing.Hu - Apple iPhone 13 Pro Max Graphite ProMotion 120 Hz, Pro kamerák 256 GB-100%-3 hó gari!
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest