NTFS lassúság Windows 10 alatt

Microsoft Windows

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] ------------------------------------------------------------------------
  • 1792 megtekintés

( _Franko_ v | 2019. 10. 06., v – 16:16 )

Kikapcsolt Windows Defender esetén drasztikusan javult a fordítási idő: 


[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  36.044 s
[INFO] Finished at: 2019-10-06T16:14:30+02:00
[INFO] ------------------------------------------------------------------------

Azért a Linux-ext4 idő elérése jó lenne, de ezzel már meg tudok barátkozni.

--
https://iotguru.live

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.

"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

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.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( KaTT v | 2019. 10. 07., h – 14:53 )

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 :)

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 :)

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.

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.

( AiRLAC v | 2019. 10. 08., k – 14:09 )

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."

( deje | 2019. 10. 08., k – 14:14 )

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.

( _Franko_ v | 2019. 10. 11., p – 16:54 )

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): 


[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  06:21 min
[INFO] Finished at: 2019-10-11T13:26:26Z
[INFO] ------------------------------------------------------------------------

Windows-WSL2-ntfs (DrvFs mount): 


[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  27:37 min
[INFO] Finished at: 2019-10-11T12:56:11Z
[INFO] ------------------------------------------------------------------------

--
https://iotguru.cloud

( BaT | 2020. 06. 29., h – 18:17 )

Szerkesztve: 2020. 06. 29., h – 18:28

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 3x mvn 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 package már le sem fut nálam, különféle furcsa hibákkal száll el.

Windows környezet:

> java.exe -version
java version "11.0.6" 2020-01-14 LTS
Java(TM) SE Runtime Environment 18.9 (build 11.0.6+8-LTS)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.6+8-LTS, mixed mode)

> mvn.cmd -version
Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: C:\Users\BaT\dev\tools\maven\bin\..
Java version: 11.0.6, vendor: Oracle Corporation, runtime: C:\Program Files\Java\jdk-11.0.6
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

WSL1 környezet:

$ java -version
openjdk version "11.0.7" 2020-04-14
OpenJDK Runtime Environment (build 11.0.7+10-post-Ubuntu-2ubuntu218.04)
OpenJDK 64-Bit Server VM (build 11.0.7+10-post-Ubuntu-2ubuntu218.04, mixed mode, sharing)

$ mvn -version
Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: /mnt/c/Users/BaT/dev/tools/maven
Java version: 11.0.7, vendor: Ubuntu, runtime: /usr/lib/jvm/java-11-openjdk-amd64
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.4.0-18362-microsoft", arch: "amd64", family: "unix"

Windows-os JDK + drvfs:

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  14.721 s
[INFO] Finished at: 2020-06-29T15:56:42+02:00
[INFO] ------------------------------------------------------------------------

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  14.926 s
[INFO] Finished at: 2020-06-29T15:57:35+02:00
[INFO] ------------------------------------------------------------------------

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  15.084 s
[INFO] Finished at: 2020-06-29T15:58:13+02:00
[INFO] ------------------------------------------------------------------------

Windows-os JDK + lxfs:

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  02:12 min
[INFO] Finished at: 2020-06-29T15:48:40+02:00
[INFO] ------------------------------------------------------------------------

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  02:11 min
[INFO] Finished at: 2020-06-29T15:52:13+02:00
[INFO] ------------------------------------------------------------------------

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  02:22 min
[INFO] Finished at: 2020-06-29T15:55:27+02:00
[INFO] ------------------------------------------------------------------------

Linux-os JDK + drvfs:

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  43.229 s
[INFO] Finished at: 2020-06-29T15:59:58+02:00
[INFO] ------------------------------------------------------------------------

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  45.195 s
[INFO] Finished at: 2020-06-29T16:00:57+02:00
[INFO] ------------------------------------------------------------------------

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  44.064 s
[INFO] Finished at: 2020-06-29T16:01:54+02:00
[INFO] ------------------------------------------------------------------------

Linux-os JDK + lxfs:

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  26.687 s
[INFO] Finished at: 2020-06-29T16:03:43+02:00
[INFO] ------------------------------------------------------------------------

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  22.533 s
[INFO] Finished at: 2020-06-29T16:04:22+02:00
[INFO] ------------------------------------------------------------------------

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  22.564 s
[INFO] Finished at: 2020-06-29T16:04:59+02:00
[INFO] ------------------------------------------------------------------------

( end | 2020. 06. 30., k – 10:04 )

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