-
GAMEPOD.hu
Arch Linux topik
Új hozzászólás Aktív témák
-
Frawly
veterán
válasz ubyegon2 #6043 üzenetére
Ez lehet, hogy az SSD teszi annyira gyorssá az I/O műveleteket, hogy a proci lesz a szűk keresztmetszet.
De még simán lehet az is, amit én írtam, hogy bugos a legutóbbi verzió. Az ntfs-3g-ből nem jön ki túl sűrűn verzió, ezért simán lehet, hogy már egy régebbi LTS kiadáson is az utolsó verzió van. Vagy az is lehet, hogy a legújabb kernelekben van egy bug, ami előhozza ezt a procitúlpörgetés ntfs-3g-vel.
(#6044) Shyciii: ezt mondom én is, hogy a 100% az túl durva. Bár az is igaz, amit uby ír, hogy a procitól is függ. De nálad HDD-re megy, és nem SSD-re, ami jobban be tudná pörgetni.
-
Frawly
veterán
válasz vargalex #6049 üzenetére
Én nem néztem rá. Igaz csak most lett nemrég AMD-s gépem, és még arra is lusta voltam feltenni Linuxot, mert mikor időm van elé ülni, Win10 alatt nyomatok rajta AAA-s játékcímeket. Pedig még a partíciós hely is meg van a Linuxnak hagyva
De emlékszem, hogy régen ki volt hangsúlyozva, hogy csak Intel procikhoz kell külön microcode csomag (intel-ucode), AMD procikhoz a linux-firmware csomag tartalmazta. Ezek szerint már 1 éve külön van, de én lemaradtam róla, mert egy darab hír sem volt róla. Aki nem veszi észre, annak elég kínos.
-
BoB
Topikgazda
You may corrupt the souls of men, but I am steel. I am doom.
-
Shyciii
veterán
válasz vargalex #6048 üzenetére
vargalex, Frawly
Ezesetben viszont akkor sem az SSD-t, vagy a procit tartom hibásnak, hanem a szabványt, ahogyan kezeli a háttértárakat. Igaz már rég volt, de ha visszaemlékeztek, akkor a csatoló szabványa szabja meg, hogy a procit mennyire terheli (lásd régen PATA, SCSI). Ugyebár SCSI mérföldekkel gyorsabb volt anno bárminél, és másoláskor a proci 5% körül terhelődött, és lazán csinálhattál bármit mellette, míg PATA-s winyóknál lazán 10x, 15x-ös volt a terhelés a SCSI winyókhoz képest.
[ Szerkesztve ]
-
Frawly
veterán
válasz Shyciii #6058 üzenetére
Ebben teljesen igazad van, még ramdrive-nál és NVMe SSD-nél sem lenne szabad 100%-ig tekernie a procit, akkor sem, ha az gyengébb. Épp ezért, én inkább gyanakszok arra, hogy valami újonnan előkerült bug, de tényleg simán lehet, hogy ennyire szuboptimálisra van megírva.
-
Shyciii
veterán
Az a baj, hogy nekem notebookom van, így nem tudok belerakni még egy SSD-t, mert nincsen hely. Saját SSD-mről másolva 200GB-nyi egy fileos adatot ugyanarra az SSD-re nekem is megeszi a procit, illetőleg a proci terhelés a conky szerint 35% körül van, de az egérkurzoron látni, hogy baromira belassult a rendszer. Ez viszont a SATA csatoló egyértelmű hibája, mert ebből a szempontból nemigen van előrelépés a PATA-hoz képest. USB-s külső SSD van, de ugye ott is az USB korlátozza le.
-
Frawly
veterán
válasz Shyciii #6060 üzenetére
Morbid, amit írtok, Archon nekem meg nem eszi meg, ext4-ről másolok ugyanarra az ext4 partícióra, egy régi SATA SSD, és a proci sem erős, egy i5-2520M, ami kb. egy asztali közepes C2Q szintjén lehet mindössze, szóval kb. 10 éves szint, másolás közben 5-25% között ingadozik az össz procihasználat (ez már ki van vetítve 4 szálra, a 100% lenne az, amikor az összes szál maximumra lenne terhelve). Az idő java részében közötte van a két szélső értéknek, és 11% körül van. Az is igaz, hogy nálam az SSD sem gyors (MX300), tartós írásnál mindössze 300 MB-ra maxolódik ki, még az sincs meg mindenhol, néha beesik 200 közelébe, pedig SATA3 módban fut, nem ütközik bele SATA2 limitbe.
Kipróbáltam NTFS-ről is ext4-re, igaz az SATA2-re korlátozott SSD-ről ment (mSATA Samsung 860 EVO), de ramdrive-ra másoltam, ami kb. 6000 MB/sec-et tud. Itt sem volt több 33-37%-nál a procihasználat, igaz ezt konzisztensen tartotta, nem nagyon ingadozott. Pedig a legfrissebb rendszerem van Archon, friss ntfs-3g-vel, kernellel, meg mindennel, annyira friss, hogy a Testing tárolóból van a legtöbb minden. Talán ami nálam eltér, hogy terminálos alkalmazásokat használok, meg ultraminimalista waylandes felületet, míg nálatok a grafikus felületnek egy ilyen lemeztartalmat kijelző frissítési bugja dobhatja meg a procihasználatot.
Meg kéne nézzétek, hogy konkrétan melyik folyamat eszi annyira a procit.
[ Szerkesztve ]
-
Frawly
veterán
válasz vargalex #6062 üzenetére
Jó, de itt maximumra járatott prociról beszéltünk. Az 1 magra eső terhelés nem releváns, egy 12 szálas procinál azért ne számítson a 100% egy szálra eső terhelés, mikor az csak összességében a proci ~8%-a. Persze nem azt mondom, hogy nem magas nálam is, mert egy normálisan megírt OS-nél, drivernél max. 1-2% körül kellene, hogy legyen. De az ntfs-3g-nél megszoktam, hogy bloat, annál örülni kell, hogy támogatott az NTFS egyáltalán, hacsak lehet, tartós linuxozásnál kerülni kell az NTFS partíciók használatát.
De ext4-nél valóban én is sokallom azt az 5-25%-ot (egy magra 20-100%). Amit még nem írtam: nálam titkosítás sincs (vagyis van, de az hardveres, szoftveres szint felé transzparens). Szóval nem kellene ennyinek lennie, de azért attól messze van, hogy kimaxolja a procit, meg gondot okozzon.
[ Szerkesztve ]
-
Frawly
veterán
válasz vargalex #6064 üzenetére
Ezt tényleg nem ártana tisztázni. Van ugyanis olyan taskmanager, amit 100% terhelésnek veszi az összes mag együttes terhelését, van, amelyik többszáz %-nak (pl. négy szálas procinál 400%-ot vesznek teljes terhelésnek, 8 szálasnál 800%-ot).
Én htop-pal néztem, a CPU [Bar] oszlop van nálam bekapcsolva, ami 100%-nak veszi az összes magra számított max. terhelést. De amikor a szálaknál listázza a terhelést, meg folyamatoknál, azt viszont egy magra vetítve méri.
Még azért a proci sem lenne mindegy.
-
Shyciii
veterán
Én újra kipróbáltam a saját ssd-mről ssdm-re másolni egy 14GB-os filet, de ugyanaz. Conky és htop is átlag 27%-os cpu terhelést mutat minden magra, de közben az egérkurzort mozgatva rettentően akadozik. Viszont így elgondolva ezt 2-3 hónapja biztos nem csinálta, mert kb akkor szerveztem át a winyót, és helyezgettem ide-oda cuccokat, és közben tudtam dolgozni, szal itt valamelyik frissítés után lett nekem ilyen. Mindegy, ritkán van ilyen
-
Frawly
veterán
válasz Shyciii #6066 üzenetére
Na, a 27% már reálisabb, de amellett még mindig nem kéne akadnia az egérkurzornak. Nálam ilyen nagy SSD-ről SSD-re másolás közben is teljesen simán gördül az egérkurzor, sehol egy megakadás. Pedig mint írtam, sima vanilla Arch, meg lófütykös számítási teljesítményű régi notebook.
De, hogy ha 2-3 hónapja nem csinálta, akkor az van, amit legelőször írtam, hogy ez valami friss bug, vagy a kernelben, vagy valami userspace toolban, ami most jött elő nemrég.
-
Frawly
veterán
Egyébként én arra gyanakszok még, hogy itt a legtöbben valami ocsmány, intézőszerű fájlkezelőt használtok, Nautilus vagy Dolphin, vagy hasonló szutykot, és az bugzik be. Próbáljátok ki terminálban, mc-vel vagy hasonlóval, hogy hogyan alakul a CPU terhelés, meg ott is akad-e az egér.
-
Shyciii
veterán
Double Commander-t használok
Kipróbáltam neked terminal alóló, és ugyanaz a jelenség. Viszont itt szembetűnőbb volt még egy dolog. Semmi gond nem volt egészen addig, míg az SSD cache-e be nem telt. Ahogy betelt, onnantól kezdve akadozik a kurzor, miközben a proci most 22% átlagt mutatott. És így viszont már nagyon ismerős jelenség. Semmi bug nincsen, hanem az SSD a "szar".
Ugyanis van egy másik tapasztalatom kb 2 évvel ezelőttről. Vannak olyan szervereink, amik RAID1-es köteget használnak Samsung 850Pro SSD-vel. No ott láttam ezt a jelenségget először. Nagy file másolásakor amíg a cache nem telik gyors, és utána drasztikusan leesik a teljesítmény, de olyan szintre, hogy ha valaki távasztalozott arra a szerverre, akkor ki is esett onnan. Amióta már a az SSD-s szerverekben Intel S35 és S46-al kezdődő típusokat használunk, azóta semmi ilyen gond nincsen. Egyszerűen vannak SSD-k, amik szarok olyan nagy file-ok írásában, amik nagyobbak, mint a cache-e. -
Frawly
veterán
válasz Shyciii #6069 üzenetére
Pedig a 850 Pro egy elég jó SSD, nincs is rajta NAND cache, csak DRAM cache. Nagyon gyors, klasszik/planár MLC NAND van rajta, még nagyobb csíkszélességen gyártva, így nem csak gyors, de elég strapabíró is. NAND cache ezért is nem kell neki, mert olyan jófajta NAND van rajta, ami nem cache módban is elég gyors, konzisztensen tudja tartani az írást/olvasást, végig a meghajtó teljes tárterületén.
Ezzel a cache problémával inkább nagyon olcsó SSD-ken találkozni, ahol planár TLC, vagy gyérebb 3D TLC/QLC NAND van (A400, BX500, 660p), na, azok tényleg mocskosul be tudnak lassulni, ha kifogy alóluk a cache. Ha viszont sokat másolsz nagy tételben, akkor nyilván nem ilyen SSD-t kell venni.
Illetve nálam áll hegyekben a sok giga RAM is kernel cache-nek, meg az MX300-nak is még normális a cache-elése, nem egy sebességbajnok SSD, de azt a sebességet konzisztensen, belassulások nélkül tartja, így talán én azért nem futottam bele abba, amit írtok.
Egyébként az iotop-pal tudod nézni, ha a rendszer I/O miatt van terhelve.
-
Shyciii
veterán
Nah nekem Kingston A400-as van Mondjuk anno azért vettem, mert olcsó volt. Már nem is emlékszem, hogy hány éves.
Sok általános weboldalon én is mindig azt olvastam, hogy a Samsung 840 Pro és 850 Pro jó SSD, de sajnos amit mondtam, azt megerősítette a Rackforest, és a Doclernet is. Ha nem ismered őket, akkor mindketten hostingot végeznek, és hát mi is ezt tapasztaltuk. Otthoni használatra biztos jók ezek a Samsungok, de nagyobb másolás esetén bukováriak. És akkor még ott a trimmelési gondjuk. Mondjuk erről csak akkor olvastam, mikor elkedzem linuxozni. Viszont most olvasom vargalextől, hogy a 850 Pro is érintett ebben. Hihetetlen, hogy ezt képtelenek megoldani.
Amúgy én egy ideje szemezgetek a WD Black SN750-es SSD-vel. Persze M.2-essel. Mondjuk még nem néztem meg, hogy a notebookomba betehető-e, befér-e. -
Frawly
veterán
válasz vargalex #6072 üzenetére
A modern kernelekben jó pár hónapja csak a 840-es van már feketelistán, a 850-860-as szériát kivették belőle. Nekem is ubyegon mutatta.
Schyciii: nyilván nem konzumer SATA SSD-t kell virtual hostingra használni, arra valóban nem való. Arra enterprise NVMe SSD kell. De sima workstation, desktop, home felhasználásra teljesen jó a 850-860 Pro, még nagyobb fájlmásolásoknál is.
Minimalista felhasználásra, főleg desktop Linux alá, esetleg C2D és annál gyengébb gépekbe (amik jobb SSD-t nem hajtanának ki) az A400 is teljesen jó, WIn10, Linux 4-6 mp. alatt bootolni tud rajta, programok azonnal betöltődnek, ennyi a lényege, nem kell várni, míg HDD-t rotyogtat a rendszer. Csak nagy fájlmásolásokat ne akarj rajta, mert arra már nem való. Ha erre próbálod használni, akkor nagy csalódás lesz a vége, és rájössz, hogy nem volt értelme az SSD-n spórolnod, pár ezres árdiffiért vehettél volna valami jobbat. Ezért első kérdés a Milyen SSD-t veszek topikban, hogy mekkora anyagi keret van rá, és milyen felhasználásra lesz, milyen gépbe.
A400-nál attól is nagyon függ a belassulás, hogy mennyi írás van rajta, mennyire van betelítve adattal, és eleve mekkora tárhelyes modell. Ami az A400-ról nagyon hiányzik, az a DRAM cache, de annak a hiánya inkább random lemezműveleteknél látszik meg jobban.
-
Frawly
veterán
Igazad van, rosszul emlékeztem. Régen "Samsung SSD 8*" szerepelt benne, de végül a 860-asra feloldották, a 840 rajta maradt, a 850-esre emlékeztem teljesen rosszul.
Akkor az viszont lehet oka, hogy a 850 Pro amiatt lassul be, mert az NCQ TRIM le van tiltva, emiatt a kernel azonnal kikényszeríti a végrehajtását.
[ Szerkesztve ]
-
ubyegon2
nagyúr
Nem az online TRIM érintett ebben a dologban? (a 800-as sorozat amúgy más rég kikerült a blacklist-ból) Erre a gyűlölt systemd egyébként rég nyújt megoldást, de azelőtt is lehetett ütemezett TRIM-et használni. Sok disztró főleg Arch alapúak még default discard parancsot alkalmaznak FSTAB-ban, nekik érdemes odafigyelni, aki meg pure Archot használ, csak tudja, mit hogyan kell alkalmazni.
Egyszóval az nyilvánvaló még mindig szerintetek is, hogy a Samsung 800-as sorozatnak semmi gondja nincs a TRIM-mel, kivéve 2 tipust, aminek az online TRIM ATA parancs(discard) okoz gondot?
Ez így korrekt? Vagy megint nem jól értelmezek valamit?
[ Szerkesztve ]
-
őstag
Sajnos nemcsak ntfs-ről ext4-re másolásnál nyaldossa a 100%-ot a proci, hanem egy izmosabb gigabites torrent letöltésnél is, két 26 gb-os filmet töltöttem le, jöttek lefele úgy 60-80megabájt/s-el és legalább egy procimag a 4ből szinte mindig 100%-on volt a Ksysguard szerint. Kde-t használok. A proci X4 860K, 8GB ram, a rendszer egy Radeon R3 480GB ssd-n van. A kliens qbittorrent. Bár talán nem volt annyira drámai a rendszerlassulás a letöltés ideje alatt Arch alatt, mint Kubuntu alatt.
-||- Asrock B660M HDV -II- G.Skill Aegis 2x16GB DDR4 -II- - i3 12100f -||- Sapphire RX550 4GB -||- AOC Q27V4EA 1440p -||-
-
Laszlo733
aktív tag
Sziasztok!
A yay -t szeretném telepíteni, de a az első, vagy a második makepkg -si nél hibára fut a telepítés. Mi lehet a baj?
sudo pacman -S git
mkdir src
cd src
git clone https://aur.archlinux.org/yay.git
ls
cd yay
makepkg -si
sudo pacman -S fakeroot
makepkg -si
/home/linux/src/yay/PKGBUILD: sor: 23: make: parancs nem található
==> HIBA: Hiba történt a build()-ben.
Megszakítás...
Mi lehet a probléma, illetve van -e más módja a yay telepítésének? -
Frawly
veterán
válasz ubyegon2 #6078 üzenetére
Igen, ezeket szoktam is írni. Csak az NCQ TRIM van feketelistán, nem az egész TRIM. Tehát a fstrim, fstrim.service, discard mount paraméter működik továbbra is, de a kernel azonnal kikényszeríti a végrehajtásukat, nem ütemeződnek (queue) későbbre. Ez pedig némi belassulással járhat. 860-asnál már ez nincs, ott az NCQ TRIM sincs tiltva.
-
Laszlo733
aktív tag
Telepítettem az autoconf -ot, de utána így is hibára fut a yay -S gksu
Hunk #20 succeeded at 2876 (offset 5 lines).
Hunk #21 succeeded at 2888 (offset 5 lines).
patching file Makefile.am
patching file libgksu/Makefile.am
Hunk #1 succeeded at 27 with fuzz 2.
patching file libgksuui/Makefile.am
Hunk #1 succeeded at 10 with fuzz 2 (offset 1 line).
patching file libgksu/Makefile.am
Can't exec "aclocal": Nincs ilyen fájl vagy könyvtár at /usr/share/autoconf/Autom4te/Fil
eUtils.pm line 326.
autoreconf: failed to run aclocal: No such file or directory
==> HIBA: Hiba történt a prepare()-ben.
Megszakítás...
Error making: libgksu -
Laszlo733
aktív tag
A digiKam csak nálam fagy le mindig, vagy másnál is?
-
Laszlo733
aktív tag
Igen, terminálból is betöltődik lefagy, majd összeomlik. A kimenet hibás fájlleíróra panaszkodik.
Az utolsó pár sor:"SELECT COUNT(id) FROM Images WHERE album=:a;"
Error messages: "Unable to fetch row" "database table is locked: Images" "6" 1
Bound values: (QVariant(int, 2))
ASSERT: "!isEmpty()" in file /usr/include/qt/QtCore/qlist.h, line 363
digikam.dimg: "/home/linux/Pictures/Házi videó/2013.05.16_saját/2014_Januá
r/20140102_201319.jpg" : JPEG file identified
KCrash: crashing... crashRecursionCounter = 2
KCrash: Application Name = digikam path = /usr/bin pid = 6087
KCrash: Arguments: /usr/bin/digikam
KCrash: Attempting to start /usr/lib/drkonqi from kdeinit
sock_file=/run/user/1000/kdeinit5__0
pa_write() failed while trying to wake up the mainloop: Hibás fájlleíró
pa_write() failed while trying to wake up the mainloop: Hibás fájlleíró
pa_write() failed while trying to wake up the mainloop: Hibás fájlleíró
Invalid write to eventfd: Hibás fájlleíró
Code should not be reached at ../pulseaudio/src/pulsecore/fdsem.c:199, function pa_fdsem
_post(). Aborting.
Unable to start Dr. Konqi
Re-raising signal for core dump handling.
Félbeszakítva (core készült) -
Laszlo733
aktív tag
Sziasztok!
Mi lehet az oka annak, hogy a Bejelentkezési képernyőn / SDDM / nem tudok témát cserni?
Bármit beállíthatok, akkor is az alap marad.
-
Laszlo733
aktív tag
Sziasztok!
Kijött a pacman 5.2, de alapból nem települt, mert a yay -t még nem készítették fel rá, így a frissítéskezelőben hibára futott. Azt javasolták, hogy kerüljön törlésre a yay, majd pacman 5.2 települ és utána mehet fel a már felkészített git-yay / git clone https://aur.archlinux.org/yay-git.git yay / Ez meg is történt, de hazavágta az Octopit és sehogy sem tudom visszarakni.
Parancssoros telepítésnél bármit akarok telepíteni, többször is ezt a hibaüzenetet kapom:
Belépés a fakeroot környezetbe...
==> FIGYELMEZTETÉS: PACKAGER-nek ilyen formátumnak kell lennie: 'Példa Név <email@addres
s.invalid>'
Van ötlet, hogy ez hogyan orvosolható?
Új hozzászólás Aktív témák
- Politika
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- BestBuy topik
- Luck Dragon: Asszociációs játék. :)
- Suzuki topik
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- Xiaomi 13T és 13T Pro - nincs tétlenkedés
- Milyen cserélhető objektíves gépet?
- Milyen routert?
- Motorola Edge 40 - jó bőr
- További aktív témák...