Fórumok
Lassúnak tűnt Windows 10 alatt a Java fordítás, csináltam teszteket és valóban lassú, de nagyon. Viszont nem az NTFS önmagában lassú, a FUSE-os NTGS-3G csak dupla idő.
A lassú rész az, amikor sok (1000-1500) apró fájlt kell másolnia. Mit kellene javítanom, hogy gyors legyen?
Linux-ext4:
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 19.813 s
[INFO] Finished at: 2019-10-06T14:29:47+02:00
[INFO] ------------------------------------------------------------------------
Linux-ntfs-3g:
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 40.799 s
[INFO] Finished at: 2019-10-06T14:30:32+02:00
[INFO] ------------------------------------------------------------------------
Windows-ntfs:
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 06:04 min
[INFO] Finished at: 2019-10-06T15:46:18+02:00
[INFO] ------------------------------------------------------------------------
Hozzászólások
Kikapcsolt Windows Defender esetén drasztikusan javult a fordítási idő:
Azért a Linux-ext4 idő elérése jó lenne, de ezzel már meg tudok barátkozni.
--
https://iotguru.live
Win Defender kivetelekhez add hozzá a java/fejlesztői mappákat. Az ntfs sebesség pedig kozelitoleg egyezik az ext4-gyel. Azon nem fogsz gyorsítani. Kész vagy.
"Az ntfs sebesség pedig kozelitoleg egyezik az ext4-gyel."
Én egyelőre még kétszeres különbséget látok az Ext4 javára, de ezzel azért meg tudok békélni, ha néha-néha Windows 10 alatt kell valamit fejleszteni.
--
https://iotguru.live
Még segíthet: https://forums.guru3d.com/threads/ntfs-disable-last-access-update-file-…
Linux alatt is kioffolható:
noatime
- Nem frissíti az inode-ok elérési idejét a fájlrendszeren - növelheti a teljesítményt, lásd atime opciók.
https://wiki.archlinux.org/index.php/Fstab_%28Magyar%29
Arra azért kíváncsi lennék, hogy milyen felhasználás esetén sikerült ezt tapasztalnod?
Java/Korlin/Android toolchain-ek esetén a személyes tapasztalatom az, hogy Linux/ext4 használata esetén a fordítási idő kb. a fele a Win7/NTFS illetve Win10/NTFS párosokhoz képest. Természetesen ugyanazon a vason, win esetén kikapcsolt vírusvédelemmel.
Topicnyitó teszteredméynére írtam, hogy 364mp-ről sikerült 36-ra csökkenteni az időt, ami már majdnem a 20mp.
"sikerült 36-ra csökkenteni az időt, ami már majdnem a 20mp"
Azért az még mindig majdnem a duplája, ami azért egy nagyobb projekt esetén jelentős idő... nem mindegy, hogy tesztekkel 10 perc vagy 5 perc egy teljes build. Az, hogy 19 vagy vagy 36 másodperc, az valóban nem annyira fájdalmas különbség, de akkor is a duplája.
--
https://iotguru.live
A precíz eredményhez nem ártana tudni, hogy a két ntfs az két külöböző volt-e, és az fs-ek melyik zónán voltak, avagy ssd.
Ha számítana, akkor odaírnám. Egyébként ugyanaz az NTFS partíció és ugyanaz az SSD, ugyanazon a gépen, amin minden ugyanaz.
--
https://iotguru.live
Csodás. Azonban az már nagyon nem mindegy, hogy 3,5 perc vagy 7 perc a build idő. Vagy esetleg 30 perc vs 1 óra.
Közelítőleg a ’ggem, ext4 alatt kétszeres sebességet mért, ami még szerény is, mert extrém esetben lehet sokkal nagyobb. Az NTFS egy bűn lassú, elavult fájlrendszer, amihez a MS érdemben 27 éve nem nyúlt hozzá. Úgy értve, hogy adott hozzá feature-öket, de a koncepció alapjaihoz nem nyúlt hozzá, meg az ReFS-nél sem. Nem lehet vele mit csinálni, meg lehet köszönni a MS-nak, meg lehet váltani Linux ext4-re (nem, itt nem WSL-re gondolok, hanem rendesen feltelepített natív Linuxra), sebességben dimenzióugrás. Főleg kis fájloknál veri el nagyon csúnyán, mint itt a topikindításban is olvasni, meg én is tapasztaltam, pl. nem indexelt fájlkeresésnél, hogy a Windows 40 ezer fájl között mire megtalálta a vonatkozó fájlt bizonyos tartalmat keresve, az 10 percnél is hosszabb volt, ennyi idő alatt a Linux ext4-en 20-30 másodperc alatt végigpörgette 200 ezer fájl között a keresést, úgy, hogy a HDD (akkor még azt használtam) is halkabban működött közben. Ezt hívják technológiai fölénynek, és nem csak az ex4 gyorsabb, de bármilyen linuxos fájlrendszer, még egy btrfs, ZFS is, bekapcsolt extra feature-ökkel.
Egy enyhítése van az NTFS lassúsági nyűgjének, alá kell tenni valami (lehetőleg nagyon durva NVMe-s) SSD-t, az elfedi ezeket a gyengeségeket.
Persze ne legyünk elégedetlenek az NTFS-sel se. Ezt a MS megfelelően kompenzálja azzal, hogy ingyen van (ja, nem), meg legalább megy a Telemetria, Cortana, és a Candy Crusht sem kell telepíteni, hanem már feltelepítve jön és könnyen indítható Live csempéről. Nem tudom mi másra lenne akárkinek szüksége. Komoly fejlesztőknek meg cégeknek is elég ez. Az ilyen 2-20× I/O teljesítmény nem érdekel senkit, csak ilyen borostás, elhízott hobbiprogramozó verik erre, akik még anyu lakásának tetőtéri szintjén kötött mellénykében programoznak Linux terminálban, mert magányosak és nincs életük. Ezt mindenki tudja, a MS-nál is. És mielőtt jönne valaki hőbörögni, hogy nem igaz, azt emlékeztetném, hogy a MS jobban tudja mit igényel a piatcz meg a cakkma, mert ott ilyen komoly diplomákkal meg mindenféle hosszú rövidítéses minősítéssel rendelkező sztárfejlesztők meg trendet jobban átlátó mánággerek dolgoznak, nem ilyen hobbista noname lúzerek. Nekik nem kell magyarázni, hogy minek hogy kell működjön. Ha szerintük jó az NTFS, akkor az jó, nem kell hozzányúlni.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
Ez notebook, vagy szünetmentesen van? Mert akkor be lehet kapcsolni jobban a cache-t az SSD-nek, és amíg van szabad memóriád, addig elsőnek oda ír és onnan olvas.
Device Manager-ben az SSD-re kattintva lehet ezeket állítani.
Az NTFS-en mekkora a cluster méret? Tömörítés nincs használva?
NTFS Last Access Time Updates in Windows 10? Ez ki van kapcsolva?
https://winaero.com/blog/disable-ntfs-last-access-time-updates-in-windo…
Továbbá ezt is kikapcsolhatod: DOS 8.3 Name creation
http://www.ntfs.com/ntfs_optimization.htm
Továbbá az is segíthet, ha egy külön partícióra raksz mondjuk egy 2-8 GB page file-t, ami NTFS lesz, kikapcsolt 8.3 + last access time.
Régi teszt, de releváns, hogy befolyásolja a cluster méret a sebességet:
https://ejrh.wordpress.com/2012/10/26/cluster-size-experiment/
Én adatra 4K-s cluster méretet javaslok, főként az SSD blokkméret miatt.
Sakk-matt,
KaTT :)
Default fájlrendszer, ahogy a Windows 10 telepítő létrehozta azt, tömörítés nincs, last access valószínűleg van, de mivel itt sok apró fájl írása folyik, kevéssé hiszem, hogy ez jelentősen gyorsítana a dolgokon.
--
https://iotguru.live
Akkor még marad ez: Ez notebook, vagy szünetmentesen van? Mert akkor be lehet kapcsolni jobban a cache-t az SSD-nek, és amíg van szabad memóriád, addig elsőnek oda ír és onnan olvas. Device Manager-ben az SSD-re kattintva lehet ezeket állítani.
Alapból nincs bekapcsolva ez a jobb cache lehetőség.
Sakk-matt,
KaTT :)
Laptop. Megnézem majd, hogy mi van beállítva és ez segít-e.
Update: nem segített.
--
https://iotguru.cloud
Amennyire tudom, a 4K cluster size már eléggé régóta alapértelmezett NTFS-en, mellesleg partíció létrehozásakor lekérdezi a háttértár sector size-át, és ahhoz igazodik. Azaz 4K-s sector size-ú HDD-n sem fog 512-es cluster méretet csinálni.
A Last Access Time írása pedig leginkább az ext4-es relatime opcióhoz hasonló (lásd https://docs.microsoft.com/en-us/windows-server/administration/windows-…), azaz egyáltalán nem biztos, hogy van észrevehető teljesítmény romlás a fent említett use-case-ben. Másrészt Linuxon ext4-en is relatime az alapértelmezett sok disztribúcióban, szóval emiatt nem kellene lassabb legyen az NTFS az ext4-nél.
A last access time kapcsolgatása lófaszt se számít, valószínűleg HDD-n lassított valamennyit, SSD-n meg inkább csak feleslegesen öregít, mint lassít.
--
https://iotguru.cloud
Ezek szerint nem olvastad el a linket, és nem ismered a linuxos relatime beállítást sem.
A Last Access Time nem lassít, mert nem írja ki lemezre azonnal, hanem csak akkor, amikor amúgy is írna más okból. Másrészről SSD-n is lassítana, ha mindig kiírná, mert pl. Java fordításnál nem a háttértár adatátviteli sebessége számít, hanem a másodpercenként elvégezhető IO műveletek száma (iops), ami szintén korlátos.
4K a legkisebb cluster méret amit formázáskor használ a windows ekkora háttértárakon, 512bájtos cluster méretet csak kézzel erőszakolva fog
Esetleg az NTFS partíció alignment ment félre?
--
"After successfully ignoring Google, FAQ's, the board search and leaving a undecipherable post in the wrong sub-forum don't expect an intelligent reply."
Bármi lehet, de nem gondolom, hogy így lenne. Megnézem, amint a Windows 10 alatt járok.
Update: az alignment oké.
--
https://iotguru.cloud
Az már 11+ éve (Vista óta) nem lehet probléma, hacsak nem XP alatt lett létrehozva eredetileg a partició.
--
Nekem is az a tapasztalatom, hogy ugyanazon vason, ugyanaz a projekt, ugyanazzal a toolchain-el eléggé eltérő teljesítménnyel fog fordulni Win/NTFS-en illetve Linux/ext4-en.
Egy Android-os projektünk Ubuntu-n kb 3,5 perc alatt készül el, Win-en kb 7 perc, ráadásul clean build, "bemelegítve", azaz a második clean build futást mérve. Win-en figyeltem arra, hogy a Defender és az indexelő szolgáltatás hagyja ki a projekt könyvtárat, és nem tweak-eltem semmit. RAM is van bőven, azaz az OS diszk cache-ébe is bőven befér minden.
Összességében ugyanazon a vason a Java-s fejlesztő eszközök számomra sokkal fürgébben tűnnek egy Kubuntu-n, mint Win7-en vagy Win10-en. Maga az IntelliJ IDEA is érezhetően gyorsabb. Akkus üzemidőben nem találtam észlelhető különbséget a két OS között.
Ja. Valahogy így.
--
https://iotguru.cloud
Mértem még kettőt, ha már Windows 10 alatt jártam, szóval a WSL2 azért még messze van attól, hogy értelmes munkát lehessen rábízni, különösen a meglévő NTFS drive elérése DrvFs mount használatával durva (becsatolja például a /mnt/d alá a D: meghajtót).
Windows-WSL2-ext4 (virtual-disk):
Windows-WSL2-ntfs (DrvFs mount):
--
https://iotguru.cloud
Előre s elnézést hogy egy ilyen régi topicot felélesztek.
Kíváncsiságból megnéztem, hogy mi a helyzet a natív Windows/WSL1 és drvfs/lxfs viszonylatban. Nyilván mindegyik esetben NTFS a fájlrendszer, de eltérő módon elérve.
A teszteléshez a Flyway 6.5.0-s verzióját fordítottam Maven 3.6.3-mal és 11-es JDK-val. Utóbbi esetén a patch level eltérő, amit sajnos csak utólag vettem észre, így Windowson 11.0.6, Linuxon 11.0.7-es verziót használtam. Mindegyik esetben a mérések előtt futtattam egy
mvn compile-t, majd 3xmvn clean; mvn compile-t.Eredmény: https://imgur.com/a/pK7PpQA
A legjobban mindig az az FS teljesít, amelyik "natív" az adott platformon. Vagyis Windowsos JDK esetén a natív Windowsos elérés, WSL1-ben az lxfs. Összességében a natív Windowsos megoldás a legjobb, a P9 szerveren keresztüli elérés (\\wsl$) a legrosszabb. Ez utóbbival a
mvn packagemár le sem fut nálam, különféle furcsa hibákkal száll el.Windows környezet:
WSL1 környezet:
Windows-os JDK + drvfs:
Windows-os JDK + lxfs:
Linux-os JDK + drvfs:
Linux-os JDK + lxfs:
A megdöbbentő az, hogy Linux+ext4 mennyivel gyorsabb...
Anno azon rökönyödtem meg, hogy a Mass Effect 3 wine alatt Linuxon sokkal gyorsabban töltött, mint windózon, így inkább azon játszottam. Grafikai probléma nem volt
Csak egy halovány gondolat: A májusi frissítés ígért, indexeléssel kapcsolatos optimalizálása, - esetleg.., - ezen nem javíthat?
A gépemen a Windows 10 Fast Ring insider telepítés, az utóbbi időben leporoltam az Elite Dangerous-t, mert két hete kiműtötték a bölcsességfogamat és a játékon kívül nem nagyon volt kedvem az élethez, kicsit dolgozgattam is, amennyire tudtam, nem vettem észre szignifikáns változást, de majd mérek újra.
https://iotguru.cloud