TPS (Transparent Page Sharing) változások II.

Az előző bejegyzésben arról volt szó, hogy miért változtatták meg a TPS eddigi jól bevált működését. Azt mindenkinek magának kell eldöntenie, hogy alkalmazkodik az új alapértelmezéshez, vagy azt felülírva visszatér a szokásos beállításokhoz.

Az elején fontos megjegyezni, hogy ami ebben a leírásban van, a mostani állapotot tükrözik. De a bevezetése tulajdonképpen két fontos lépésben történt:

• A bejelentés utáni első nagyobb javítások már tartalmazták a két advanced paramétert, de még nem változtatták meg a TPS működését, illetve a Mem.ShareForceSalting értéke csak 0 vagy 1 lehetett
• A végleges verzióban már alapértelmezett lett a TPS megváltozott működése, és a Mem.ShareForceSalting értéke a 0 vagy 1 mellett 2 is lehet. Illetve nem csak lehet, hanem ez a default érték.

Akkor nézzük meg, hogyan is működik a "salting".

• Bevezettek egy új host konfigurációs paramétert, a Mem.ShareForceSalting-ot. Ezzel szabhatjuk meg, hogy egy adott host hogyan kezelje az inter-vm (virtuális gépek közötti) TPS-t. Ha az értéke nulla, akkor minden marad a régiben, ha pedig 1 vagy 2, akkor megváltozik a működés.
• A megváltozott működés azt jelenti, hogy most már az kevés, ha két vagy több virtuális gépnek van azonos memória lapja, ahhoz hogy a TPS ezeket egy fizikai lapon tárolja, ahhoz az kell, hogy a virtuális gépeknek azonos legyen a "salt" értéke is. 
• Ehhez bevezettek egy új vm szintű paraméter, aminek a neve sched.mem.pshare.salt, és értéke egy tetszőleges string lehet. 
• Ezzel a paraméterrel meghatározhatunk virtuális gép csoportokat, amik között a TPS mégis működhet annak ellenére, hogy a Mem.ShareForceSalting értéke 1 vagy 2. Ehhez csak annyit kell tennünk, hogy ezt a paramétert a csoport minden tagján azonos értékre állítjuk be. Ennek értelme az, hogy bár alkalmazzuk az új biztonságosabb TPS beállításokat, de ha akarunk, tehetünk kivételeket. (pl. security szempontból kevésbé érzékeny gépek esetében)
• Ha a sched.mem.pshare.salt paraméter hiányzik, de a "salting" be van kapcsolva, akkor a "salt" vagy a vc,uuid, gépenként egyedi paraméter vagy a nulla érték lesz. Ez attól függ, hogy a Mem.ShareForceSalting 2 vagy 1. 
• Bármilyen beállítások is vannak, az intra-vm TPS működni fog, azaz egy gépen belül képes lesz a rendszer az azonos memória lapokat összevonni.

A fentiek ismeretében nézzük meg, hogy milyen különböző esetek lehetségesek.

Mem.ShareForceSalting=0
A TPS hagyományos módon működik, azaz  ha van is a virtuális géphez beállított sched.mem.pshare.salt érték, azt nem veszi figyelembe.

Mem.ShareForceSalting=1
A "salting" be van kapcsolva. Ha létezik a sched.mem.pshare.salt paraméter, akkor azt fogja használni (azaz azonos értékkel bíró gépeknél lesz inter-vm TPS), ha viszont nincs, akkor a "salt" értéke nulla lesz, azaz szintén működni fog a TPS

Mem.ShareForceSalting=2
Ez az alapértelmezett. A "salting" be van kapcsolva. Ha nem létezik a sched.mem.pshare.salt paraméter (ez a default), akkor a .vmx-ben lévő vc.uuid értéke lesz a "salt". Mivel ez gépenként egyedi érték, ez gyakorlatilag azt jelenti, hogy az inter-vm TPS nem működik. Ha a paraméter létezik, akkor viszont azt fogja használni, így azonos "salt" érték esetében lesz inter-vm TPS. Itt elméletileg előfordulhat az is, hogy sem a sched.mem.pshare.salt, sem a vc.uuid nem létezik. Ilyen esetben a host véletlen számokat használ, így szintén nem lesz inter-vm TPS.

Végül nézzük meg egy frissen telepített ESXi 6.0U1 esetében mit is látunk:

Mem.ShareForceSalting default értéke

Nincs sched.mem.pshare.salt paraméter, ez a default

A "salt" értéke default esetben

A jó megoldásnak az tűnik, ha ellenőrizzük egy esetleges host upgrade előtt, hogy általában a TPS mekkora memória megtakarítást jelent, van e balloon használat, memória tömörítés esetleg swap használat, mert ha igen, akkor az upgrade után egészen biztos, hogy még tovább fog romlani a helyzet.

Ha valami nem tiszta vagy szerintetek nem így van, kérem jelezzétek.

Update: Megtaláltam azt a cikket, ami leírja, miért is jelent a TPS kockázatot: Ez lenne az.