Vmware rejtélyes lassulás

Ubuntu Linux

Korábban UHU 1.1 alatt jól működö win2k átkerült Ubuntu alá. Ez elég nagy változtatás, mert a vmware is frissült a legújabb verzióra (5.5.1), meg az Ubuntu is lényegesen frissebb kernelt szállít. A módosítás óta a w2k tökéletesen megy, ha folyamatosan dolgozunk vele, (disk művelet is lényeges) viszont ~5 perc üresjárat után az addig gyorsan futó programok felére/harmadára lassulnak. Innentől néha segít az illető program újra indítása, de nem mindíg. A tárgybeli program egy Progress compiler, ami aránylag sokat olvas a lemezről is.
Olyan érzésem van, hogy valamitől elalszik a diszk, pedig a win folyamatos üzemre van (és volt is)állítva, meg az Ubuntuban sem állítottam be ilyesmit.
Most próbáltam UHU 1.2+Vmware 5.0 párossal, és ott nincs ilyen gond.
Megpróbálom még a két régebbi verziót az Ubuntun, de ha valakinek van használható ötlete, az ne fogja vissza magát :)

  • 1581 megtekintés

( rigidus | 2006. 02. 24., p – 23:11 )

1. erre mit mond:
# hdparm -I /dev/hdaX

2. "~5 perc üresjárat után"
Ez minek az ures jaratara vonatkozik, a guest es/vagy a host gepere?

3. Memoria mennyire van beallitva a guest gepnek, mekkora swap fajlt hasznal es mennyi memoriat hasznal az alkalmazas?

4. A guest gep time schedulerjenek nincsen beallitva vmi fondorlatossag? (pl: defrag, indexeles)

5. Kapcsolj ki minden energiatakarekossagi megoldast a guest gepen, lehetoleg a hozzatartozo szolgaltatas leallitasaval.

---------------------
Ригидус а бетегадьбол

1.:
laci@lacinpc:~$ sudo hdparm -I /dev/hda

/dev/hda:

ATA device, with non-removable media
Model Number: SAMSUNG MP0804H
Serial Number: S042J10XC17908
Firmware Revision: UE100-14
Standards:
Supported: 7 6 5 4
Likely used: 7
Configuration:
Logical max current
cylinders 16383 65535
heads 16 1
sectors/track 63 63
--
CHS current addressable sectors: 4128705
LBA user addressable sectors: 156368016
LBA48 user addressable sectors: 156368016
device size with M = 1024*1024: 76351 MBytes
device size with M = 1000*1000: 80060 MBytes (80 GB)
Capabilities:
LBA, IORDY(can be disabled)
Queue depth: 1
Standby timer values: spec'd by Standard, no device specific minimum
R/W multiple sector transfer: Max = 16 Current = 16
Recommended acoustic management value: 254, current value: 0
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=120ns IORDY flow control=120ns
Commands/features:
Enabled Supported:
* READ BUFFER cmd
* WRITE BUFFER cmd
* Host Protected Area feature set
* Look-ahead
* Write cache
* Power Management feature set
Security Mode feature set
* SMART feature set
* FLUSH CACHE EXT command
* Mandatory FLUSH CACHE command
* Device Configuration Overlay feature set
* 48-bit Address feature set
Automatic Acoustic Management feature set
SET MAX security extension
* DOWNLOAD MICROCODE cmd
* SMART self-test
* SMART error logging
Security:
Master password revision code = 65534
supported
not enabled
not locked
frozen
not expired: security count
supported: enhanced erase
88min for SECURITY ERASE UNIT. 88min for ENHANCED SECURITY ERASE UNIT.
HW reset results:
CBLID- above Vih
Device num = 0 determined by the jumper
Checksum: correct

2. A guest üresjárata, a host használata indiferens.

3. 312M és 1 GB van a gépben swapot nem használ se a guest, se a host.

4. Tudomásom szerint minden kikapcsolva, de eddig is így ment.

5. Mint a 4.

Közben kipróbáltam 5.5.0-val, ott ugyanezt produkálja. Az 5.0.0 már nem ennyire egyszerű, azt majd reggel.

( uid_1683 | 2006. 02. 25., szo – 21:14 )

Tettem fel egy Dapper-t, hátha javul a dolog. Na nem. Annyival rosszabb, hogy a lassulás hamarabb kezdődik, és másfélszeres az eddigiekhez képest. Most már semmi tippem, azt hiszem inkább sörözni fogok ....
Próbáltam már az IO schedulert változtatni, kikapcsolni minden fölös szolgáltatást de semmi javulás.

"Most már semmi tippem, azt hiszem inkább sörözni fogok ...."

Ez nem egy rossz otlet, de eppen az jutott eszembe, hogy volt egy keveredes az udev korul a 2.6.13-as kernel utan. Kilapatoltak belole a devfs-t. Esetleg meg ez is osszefugghet vele.

A masik amit nezzel meg, hogy az uhu-n milyen csoportokba vagy felveve es az ubuntun mi a helyzet. Lehet, h pl nem tud irni a /dev-be valamelyik eszkozfajlba. (pl csak tippelek: /dev/rtc)

A vmx processzek rootkent futnak, de probald meg a frontendet is rootkent.

Aztan ami meg erdekes lehet az a /proc. Nehany disztro alapbol bekapcsolgat ezt-azt, nemelyik nem (az rtc-n is lehet allitani). Ezeknek is utana lehetne meg nezni.

---------------------
Ригидус а бетегадьбол

Mivel a fentiek se segítettek, elkezdtem telepítgetni.
Centos 4.2 (RHEL4)
UHU1.2
UHU1.1
És a fentiek mind produkálták a hibát az ominózus gépen.

Végül feltettem egy VMware 4.5.3-mat az eredeti Ubuntu 5.10-re, és a hiba megszűnt. Itt most örömködhetnék, de több okból sem teszem. Egyrészt a 4.5.3 használhatatlan fglrx driverrel, másrészt eléggé régi darab, és külön felhívja a figyelmet, hogy 2.6.x kernelen nincs garancia a helyes működésre.

A megoldás valahol a processzor energia gazdálkodásában rejlik, ugyanis intel p4 3GHz gépeken produkálja a hibát az 5.x vmware, egy amd64-en viszont nem. Ott rekalmál a kernel, hogy "powernow-k8 Bios error.." így gondolom nem is működik.

Amúgy jobbulást.

A megoldás valahol a processzor energia gazdálkodásában rejlik, ugyanis intel p4 3GHz gépeken produkálja a hibát az 5.x vmware, egy amd64-en viszont nem. Ott rekalmál a kernel, hogy "powernow-k8 Bios error.." így gondolom nem is működik."

En eppen most tettem fel egy xp-t az 5.5.1-es vmware-re P4-es 2GHz proci. De nem tapasztalom a fenti jelenseget.

Ami meg eszembejutott, a vmware virtualis diszkje egy fajlba firkal es elkepzelheto, hogy raferne egy defragmentalas a guest gepre, (lehetoleg egy normalisabb defrag progival mint a default) ugyanis maga a virtualis fajl is hajlamos a host gepen valo fragmentalodasra ami csak halmozza a lemezmuveleteket.

Nem tartom kizartnak, hogy a vmware csapat ujrairhatta az 5.0 I/O alrendszeret es ez hatassal lehetett regebbi telepitesekre. Lehet, hogy erdemes lenne egy kulon fizikai diszken megprobalni.

"Amúgy jobbulást."
Koszi :)

---------------------
Ригидус а бетегадьбол

Na most már volt egy teljesen szűz telepítés is. Most én is XP-vel próbálkoztam, de a helyzet változatlan. Egyenlőre visszateszem a 4.5.3-mat, és megpróbálok bugreportolni a vmware felé.
Egyébként még a Progress hülyesége is lehet, de azon nem tudok változtatni per pillanat. Azért kösz az eddigi tippeket.

Laci

( uid_1683 | 2007. 03. 23., p – 12:59 )

Csak az archivum kedvéért a megoldás:

MemTrimRate = "0"
sched.mem.pshare.enable="FALSE"

Mindez Workstation 5.x illetve Server 1.x alatt működik.