Tiszteletem a kollégáknak!
Kifogytam az ötletekből és a google-ből, így itt kérek segítséget hátha találkozott már valaki ilyennel.
Windows 10 pro-m van és fejlesztőként igen sok virtuális gépre van szükségem párhuzamosan, illetve van egy vm, ami egy ilyen mindenes (adattároló, archiváló, crawler) szerepet is betölt. És ez a mindenes vm-el lett az utóbbi időkben probléma, főleg mióta biztonsági mentéseket tolok rclone-al google drive-ba. Az van, hogy nagyobb adatmennyiség mozgatásakor (ami 2-400G is lehet) - amit jellemzően éjszaka történik, amikor nem vagyok gép előtt - a memóriahasználat elszabadul, a 6G helyett képes 20-30G ram-ot is elfoglalni. Vagy legalábbis a hoston úgy néz ki, hogy az az egyetlen virtuális gép használ annyi ramot. Ha 3-4 napig hagyom futni a gépet (host és vm egyaránt) képes 59-61G-ra telítődni a memóriafoglaltság a hoston és a host szépen lassan kezd letérdelni, belassulni és akadozni.
A VMware support oldalán olyanokat írnak, hogy húzzam a reserved memory értékét alacsonyabb értékre, változtassak a memóriaallokálás módján, telepítsek vmware tools-t a virtuális gépekre - ezek egyike sem segített. Papírforma szerint jelenleg 24G-t kellene foglaljanak a futó vm-ek *összesen*, de jelen pillanatban is már efölött jár ez az érték.
Természetesen ha leállítom a problémás vm-et és újra elindítom nagyjából fél-egy napig használható a gép, de szeretném elkerülni, hogy állandóan újra kelljen indítgatni. Ha pedig csak leállítom a feladatkezelőben az igen látványos tud lenni: https://i.imgur.com/BMiD2TD.jpg
...és némi gyanakvásra ad okot, hogy a rengeteg lefoglalt memóriaméret miért "két lépcsőben" szabadul fel a host szerint és miért nem egyben, mint a többi vm-nél.
Ha pedig este befejeztem a melót, majd reggel bejelentkezek a gépre úgy, hogy a vm és a host futva maradt (ekkor újra elkezd statolni a feladatkezelő) ez fogad: https://i.imgur.com/hDsb95G.jpg
Btw a feladatkezelő részletek fülén a munkakészlet, munkakészlet csúcsértéke és aktív privát munkakészlet számok elég furán alakulnak már most, hogy nemrégiben indítottam újra az egész gépet: https://i.imgur.com/0TAOlTm.jpg
Host:
Asus Prime X570-P, 64G ram, Ryzen 3900X, Windows 10 pro, WMware Workstation 16.1
Problémás vm: Ubuntu 18.04, 6G ram, 12 processors, network: bridged, side channel mitigations for Hyper-V enabled hosts: tiltva. Érdemes még megemlíteni, hogy 4db 3T virtuális disk van rá csatolva, melyek különböző merevlemezekről vannak betallózva, snapshot nincs készítve.
Evidens lenne - lehet idővel sor is kerül rá -, hogy bővítsem és 128G-ra host memóriáját, de tartok attól, hogy a probléma ugyanúgy nem oldódna meg, csak később következne be a "katasztrófa".
Van valakinek ötlete mivel lehetne még próbálkozni?
Hozzászólások
Ezt meglátásom szerint nem a Vmware, hanem a host Windows 10 oldalán kellene kezelni. Az alkalmazáshoz társított memoria cache szállhat el eszelős mértékben. Gondolom sok lemezműveletet végez és az olvasásokhoz cache-el.
Simán előfordulhat. Ez a probléma akkor kezdett el felbukkanni amikor két régi 3T disk-et ki kellett selejtezzek és helyettük 4T disk került amin érzékelhető, hogy lassabb, főleg random írás-olvasási műveletekben. Viszont ha ez így van IO teljesítmény szempontjából jobban járnék több rammal.
LargeSystemCache nincs véletlenül bekapcsolva? Itt: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management
Windows 10 esetén 0 a default, Servernél 1.
(A laptopomon a vmware Workstation sem kapcsolta be telepités után.)
RAMMap-el látni fogod a memoria telitettségének összetételét:
RAMMap - Windows Sysinternals | Microsoft Docs
Azta. Konkrétan file summary-ben 11.5G-ra megkaptam pont azt a vmdk-t, amiről mennek a mentések éjszakánként...
Ez akkor biztosan disk cache.
Szerintem elsőkörben érdemes lenne a vmware környékén körbenéznünk, mielőtt szétkúrjuk a windows-odat. :)
Nézd csak meg ezt a thread-et.
Én az adott vmx fájl probálnám előszőr hangolni, a hard-disk.hostBuffer = "disabled"-el megnézne az eredményt.
Ez a hoszt NTFS cache-t nem fogja még kikapcsolni, egyáltalán nem biztos, hogy érdemben csökkeni fog a sebesség SSD-n.
Amiről backup készül az HDD-n van, nem is ssd-n, így kicsit tartottam attól amit a linkelt oldalon emlegettek az írási gyorsítótár mókolásáról. Mármint az esetemben ott a kikapcsolás lehetne releváns. Talán. De akkor megfontolandó talán plusz ramot venni és reménykedni nem fogja az egészet felzabálni. :D
Most kikapcsoltam a buffert (disk.hostBuffer = "disabled"), a konfigot megette a workstation, holnapig kiderül segített-e.
Köszönöm az infókat eddig is! :)
:)
Talált neki a Windows elég helyet a memórában, aztán betámasztotta a sarokba, hogy ne keljen folyton a diszkről nyitogatni.
0 az értéke. Most hirtelen nem világos - jót tenne a vmware workstation-nek bekapcsolni?
Annak igen, de gondolom a VM-ek mellett dolgozol is aktivan a hoszton, inkább hagyd kikapcsolva. :)
Ugy tippelem, hogy a CMR-SMR valtas okozza a parat a lemezek elromlo I/O irasi teljesitmenyevel. A problemat nem fogod tudni megoldani amennyiben a RAM-ot noveled, mert ugy is el fog indulni ez a dolog, csak kicsit odebbtoltad az erzekelesi szintet. A problemat "vissza tudod redukalni" az elozo allapotra, ha az uj SMR-es lemezeidet megprobalod CMR lemezre cserelni (amennyiben tenyleg ez a baj).
Toshiba HDWD130-ról HDWD240-re történt a váltás. Egyik sem annyira nagy "felsőpolcos" jószág... :/
Pedig de :) A https://www.toshiba-storage.com/products/toshiba-internal-hard-drives-p… link alapjan, a HDWD130 meg CMR technologiat hasznalt, a HDWD240 pedig mar SMR. Ez pedig megmagyarazza, hogy miert erzed jelentosen lassabbnak es miert szenved tole az I/O subsystem.
.. és ez hogyan kapcsolódik ahhoz, hogy a vmware az egész vmdk-t betolja a memóriába? :)
A disk bazi lassan reagal az irasi muveletekre. Ahogy nezem, ebben a lemezben meg flash sincs. A sima lemeznel van egy relative kicsi cache, majd azutan jon a szekvencialisan gyorsan irhato/olvashato fizikai lemez. Az SMR driveokban nagyobb cache szokott lenni, sokszor a memoria alapu cache utan van meg flash alapu cache is, esetlegesen van a lemezen CMR adatterulet. Mindez azert, mert az SMR technologia egymasra irja a savokat, ezert egy sav irasakor a korulotte levo savokat is meg kell javitani (emiatt lesz az irasi mulvelet akar 4-10x lassabb, ha pedig nem szekvencialis az iras, akkor borzalmasan lassu). Tehat amikor elfogy minden egyes buffer a lassu SMR lemez elott, akkor a Windows I/O alrendszere ugy talalja kivedhetonek a totalisan blokkolo helyzetet, ha irgalmatlan mertekben elkezd lemezcachet epiteni.
Hát ööö...nem tölti be az egészet memóriába, mivel kb egy 3.4T (darabolt) virtuális disk az érintett.
Keveredik kicsit már ez ki-mit-kessel téma. A HDD-n van asszem 128M saját cache, aztán a Windows is cache-el és úgy néz ki a vmware is.
Érezhető, hogy amikor a 4T vinyóra sok adatot mozgatok windózban úgy 5 gigáig semmi lassulás nem vehető észre, másol mint a huzat, aztán ez a lendület néhány giga után hopp, megtorpan a sata max sávszélességének töredékére.
Szóval az OS elkezdi az írási gyorsítótárat, megy is a vinyóra valamennyi már az adatból, elvégre annak is van cache-e, de azt is megtelik és aztán rotty. Igazából az, hogy milyen technológia és sebesség nekem másodlagos - simán csak adattároló. Viszont ezt meg kell értetni az ezt kezelő eszközökkel is. :)
Ha a hoszton nem tudod megoldani, esetleg a guest-ben az FS cache-t (page cache) hangolni?
A guest-eket vizsgáltam, ott nem történik mocorgás memóriahasználatban, sőt az esetek döntő többségében 3-4G rammal is ellennének. És mióta kijött a 18-as ubuntu azóta fut a vm, a probléma csak most jelentkezett - de mindenesetre megnézem, elvégre az rclone elég lassú (10mb/s az átviteli sebesség) és simán elképzelhető, hogy valahol valami cache-el.
UP
disk.hostBuffer = "disabled" után:
Elkezdte ugyanúgy, ugyanazzal a diskkel ma estére is enni a ramot. Közben szétnéztem és pont az a diskre azt írja a windows, hogy kattintsak a biztonságos eltávolításhoz. Merthogy az a vinyó pont egy RAID kártyában van aminek most vagy ledózerolta a windows a driverét vagy meghülyült egy update során, mert az eszköz beállításainál is ott (volt) a lehetőség - azt hiszi, hogy mintha valami USB-s adathordozó lenne.
Szóval kikapcsoltam a gyorsítótárazást.
https://imgur.com/a/gfGvbhp (a bekarikázottak voltak kiválasztva)
UP2
Nos a probléma nem oldódott meg: https://imgur.com/qBVr9mX
Poénból előkaptam egy MemAlloc programot, amit néhány példányban úgy 20G-val telecsaptam a ramot. Egyből csökkent a vmdk memóriában elfoglalt területe, mintha újraindítottam volna a vm-et. Szóval a Windows szórakozik velem, nem a vmware.
Meg mindig azt mondom, hogy ha kicsereled az SMR-es lemezt egy CMR tipusura, akkor megoldodik minden problemad. Kb minden rendszer igy viselkedik, ha nagy terhelest tolsz egy SMR lemezre (pl. HW RAID vezerlok egy mezei Raid-1 resyncet sem szoktak tudni vegigtolni, mert annyira lelassul a lemez irasa, hogy kidobjak a tombbol). Egyszeruen egy ilyen tipusu lemez nem alkalmas olyan teruletre, ahol egy kicsit is felmerul folyamatosan nagy szekvencialis vagy a random terheles gondolata.
Nos, kerítettem tegnap egy HDWD130-as disk-et átmásoltam oda a vmdk-kat. A helyzet változatlan. Ha a HDWD130 CMR típusú valóban akkor ez sem oldja meg a problémát.
Viszont fun fact: RamMap -> Empty -> "Empty system working set" felszabadítja a fölösen foglalt memóriaterületet.
Ebben nem lennék biztos, mert az, hogy a Windows memóriában tartja-e egy file tartalmát cache-elés miatt, az attól függ, hogy milyen módban nyitotta meg a program (a VMware) a file-t:
https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-c…
Itt leginkább a FILE_FLAG_NO_BUFFERING flag használata az érdekes, ekkor történne meg az, hogy nem cache-eli a Windows a file-t.
Tehát szerintem jó helyen keresgélsz, a disk.hostBuffer = "disabled" beállítással, ez szabályozná, hogy a VMware milyen módban nyitja meg a file-t.
Valaki korábban már linkelte ezt:
https://communities.vmware.com/t5/VMware-Workstation-Pro/Disk-write-cac…
Itt az utolsó hozzászólás talán a leginkább releváns ("I immediately noticed that VMs were trashing my host system's memory cache"). A beállítást megtetted globálisan (C:\ProgramData\VMware\VMware Workstation\config.ini file-ban)? Utána újraindítottad az egész gépet (vagy legalábbis a VMware service-eket)?
A globális ini fájlba nem vittem még eddig fel a disk.hostBuffer = "disabled" beállítást, csak a vm beállításaihoz. Most megtettem, újraindítottam az egész gépet és "bontottam egy popcorn-t". Este visszatérünk rá :)
UP
A helyzet változatlan maradt.