VMware vSphere ਵਿੱਚ VM ਪ੍ਰਦਰਸ਼ਨ ਵਿਸ਼ਲੇਸ਼ਣ। ਭਾਗ 2: ਮੈਮੋਰੀ

ਭਾਗ 1. CPU ਬਾਰੇ

ਇਸ ਲੇਖ ਵਿੱਚ, ਅਸੀਂ vSphere ਵਿੱਚ ਰੈਂਡਮ ਐਕਸੈਸ ਮੈਮੋਰੀ (RAM) ਦੇ ਪ੍ਰਦਰਸ਼ਨ ਕਾਊਂਟਰਾਂ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗੇ।
ਅਜਿਹਾ ਲਗਦਾ ਹੈ ਕਿ ਪ੍ਰੋਸੈਸਰ ਨਾਲੋਂ ਮੈਮੋਰੀ ਦੇ ਨਾਲ ਸਭ ਕੁਝ ਵਧੇਰੇ ਸਪੱਸ਼ਟ ਹੈ: ਜੇ ਇੱਕ VM ਵਿੱਚ ਪ੍ਰਦਰਸ਼ਨ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਹਨ, ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਣਾ ਮੁਸ਼ਕਲ ਹੈ. ਪਰ ਜੇ ਉਹ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ, ਤਾਂ ਉਹਨਾਂ ਨਾਲ ਨਜਿੱਠਣਾ ਬਹੁਤ ਮੁਸ਼ਕਲ ਹੈ. ਪਰ ਪਹਿਲੀਆਂ ਚੀਜ਼ਾਂ ਪਹਿਲਾਂ.

ਥਿਊਰੀ ਦਾ ਕੁਝ ਹਿੱਸਾ

ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਦੀ RAM ਸਰਵਰ ਦੀ ਮੈਮੋਰੀ ਤੋਂ ਲਈ ਜਾਂਦੀ ਹੈ ਜਿਸ 'ਤੇ VM ਚੱਲ ਰਹੇ ਹਨ। ਇਹ ਕਾਫ਼ੀ ਸਪੱਸ਼ਟ ਹੈ :). ਜੇਕਰ ਸਰਵਰ ਦੀ RAM ਹਰ ਕਿਸੇ ਲਈ ਕਾਫੀ ਨਹੀਂ ਹੈ, ਤਾਂ ESXi ਮੈਮੋਰੀ ਰੀਕਲੇਮੇਸ਼ਨ ਤਕਨੀਕਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦਾ ਹੈ। ਨਹੀਂ ਤਾਂ, VM ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ RAM ਪਹੁੰਚ ਗਲਤੀਆਂ ਨਾਲ ਕਰੈਸ਼ ਹੋ ਜਾਵੇਗਾ।

ESXi ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ ਕਿਹੜੀਆਂ ਤਕਨੀਕਾਂ ਰੈਮ ਦੇ ਲੋਡ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ:

ਮੈਮੋਰੀ ਸਥਿਤੀ

ਬਾਰਡਰ

ਕਾਰਵਾਈਆਂ

ਹਾਈ

ਘੱਟੋ-ਘੱਟ 400% ਮੁਫ਼ਤ

ਉਪਰਲੀ ਸੀਮਾ ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਬਾਅਦ, ਵੱਡੇ ਮੈਮੋਰੀ ਪੰਨਿਆਂ ਨੂੰ ਛੋਟੇ ਪੰਨਿਆਂ ਵਿੱਚ ਵੰਡਿਆ ਜਾਂਦਾ ਹੈ (TPS ਸਟੈਂਡਰਡ ਮੋਡ ਵਿੱਚ ਕੰਮ ਕਰਦਾ ਹੈ)।

ਆਸਮਾਨ

ਘੱਟੋ-ਘੱਟ 100% ਮੁਫ਼ਤ

ਵੱਡੇ ਮੈਮੋਰੀ ਪੰਨਿਆਂ ਨੂੰ ਛੋਟੇ ਵਿੱਚ ਵੰਡਿਆ ਜਾਂਦਾ ਹੈ, TPS ਨੂੰ ਕੰਮ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਸਾਫਟ

ਘੱਟੋ-ਘੱਟ 64% ਮੁਫ਼ਤ

TPS + ਬੈਲੂਨ

ਹਾਰਡ

ਘੱਟੋ-ਘੱਟ 32% ਮੁਫ਼ਤ

TPS + ਕੰਪਰੈੱਸ + ਸਵੈਪ

ਖੋਜੋ wego.co.in

ਘੱਟੋ-ਘੱਟ 16% ਮੁਫ਼ਤ

ਸੰਕੁਚਿਤ + ਸਵੈਪ + ਬਲਾਕ

ਸਰੋਤ

minFree ਹਾਈਪਰਵਾਈਜ਼ਰ ਦੇ ਕੰਮ ਕਰਨ ਲਈ ਲੋੜੀਂਦੀ RAM ਹੈ।

ESXi 4.1 ਸੰਮਲਿਤ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ, minFree ਨੂੰ ਮੂਲ ਰੂਪ ਵਿੱਚ ਫਿਕਸ ਕੀਤਾ ਗਿਆ ਸੀ - ਸਰਵਰ ਦੀ RAM ਦਾ 6% (ਪ੍ਰਤੀਸ਼ਤ ਨੂੰ ESXi 'ਤੇ Mem.MinFreePct ਵਿਕਲਪ ਰਾਹੀਂ ਬਦਲਿਆ ਜਾ ਸਕਦਾ ਹੈ)। ਬਾਅਦ ਦੇ ਸੰਸਕਰਣਾਂ ਵਿੱਚ, ਸਰਵਰਾਂ ਉੱਤੇ ਮੈਮੋਰੀ ਦੇ ਆਕਾਰ ਵਿੱਚ ਵਾਧੇ ਦੇ ਕਾਰਨ, minFree ਦੀ ਗਣਨਾ ਹੋਸਟ ਮੈਮੋਰੀ ਦੀ ਮਾਤਰਾ ਦੇ ਅਧਾਰ ਤੇ ਕੀਤੀ ਜਾਣੀ ਸ਼ੁਰੂ ਹੋਈ, ਨਾ ਕਿ ਇੱਕ ਨਿਸ਼ਚਤ ਪ੍ਰਤੀਸ਼ਤ ਦੇ ਤੌਰ ਤੇ।

ਮਿਨਫ੍ਰੀ (ਡਿਫੌਲਟ) ਮੁੱਲ ਦੀ ਗਣਨਾ ਇਸ ਤਰ੍ਹਾਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ:

minFree ਲਈ ਰਾਖਵੀਂ ਮੈਮੋਰੀ ਦਾ ਪ੍ਰਤੀਸ਼ਤ

ਮੈਮੋਰੀ ਸੀਮਾ

6%

0-4 ਜੀ.ਬੀ

4%

4-12 ਜੀ.ਬੀ

2%

12-28 ਜੀ.ਬੀ

1%

ਬਾਕੀ ਮੈਮੋਰੀ

ਸਰੋਤ

ਉਦਾਹਰਨ ਲਈ, 128 GB RAM ਵਾਲੇ ਸਰਵਰ ਲਈ, MinFree ਮੁੱਲ ਇਹ ਹੋਵੇਗਾ:
ਮਿਨਫ੍ਰੀ = 245,76 + 327,68 + 327,68 + 1024 = 1925,12MB = 1,88GB
ਅਸਲ ਮੁੱਲ ਕੁਝ ਸੌ MB ਤੋਂ ਵੱਖਰਾ ਹੋ ਸਕਦਾ ਹੈ, ਇਹ ਸਰਵਰ ਅਤੇ ਰੈਮ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ।

minFree ਲਈ ਰਾਖਵੀਂ ਮੈਮੋਰੀ ਦਾ ਪ੍ਰਤੀਸ਼ਤ

ਮੈਮੋਰੀ ਸੀਮਾ

128 GB ਲਈ ਮੁੱਲ

6%

0-4 ਜੀ.ਬੀ

245,76 MB

4%

4-12 ਜੀ.ਬੀ

327,68 MB

2%

12-28 ਜੀ.ਬੀ

327,68 MB

1%

ਬਾਕੀ ਮੈਮੋਰੀ (100 GB)

1024 MB

ਆਮ ਤੌਰ 'ਤੇ, ਉਤਪਾਦਕ ਸਟੈਂਡਾਂ ਲਈ, ਸਿਰਫ ਉੱਚ ਅਵਸਥਾ ਨੂੰ ਆਮ ਮੰਨਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਟੈਸਟ ਅਤੇ ਵਿਕਾਸ ਬੈਂਚਾਂ ਲਈ, ਸਾਫ਼/ਨਰਮ ਸਥਿਤੀਆਂ ਸਵੀਕਾਰਯੋਗ ਹੋ ਸਕਦੀਆਂ ਹਨ। ਜੇਕਰ ਹੋਸਟ 'ਤੇ RAM 64% MinFree ਤੋਂ ਘੱਟ ਹੈ, ਤਾਂ ਇਸ 'ਤੇ ਚੱਲ ਰਹੇ VMs ਵਿੱਚ ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਪ੍ਰਦਰਸ਼ਨ ਸਮੱਸਿਆਵਾਂ ਹਨ।

ਹਰੇਕ ਰਾਜ ਵਿੱਚ, ਕੁਝ ਖਾਸ ਮੈਮੋਰੀ ਮੁੜ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀਆਂ ਤਕਨੀਕਾਂ ਲਾਗੂ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, TPS ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀਆਂ ਹਨ, ਜੋ ਅਮਲੀ ਤੌਰ 'ਤੇ VM ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਨੂੰ ਪ੍ਰਭਾਵਤ ਨਹੀਂ ਕਰਦੀਆਂ, ਅਤੇ ਸਵੈਪਿੰਗ ਨਾਲ ਖਤਮ ਹੁੰਦੀਆਂ ਹਨ। ਮੈਂ ਤੁਹਾਨੂੰ ਉਹਨਾਂ ਬਾਰੇ ਹੋਰ ਦੱਸਾਂਗਾ।

ਪਾਰਦਰਸ਼ੀ ਪੰਨਾ ਸ਼ੇਅਰਿੰਗ (TPS)। TPS, ਮੋਟੇ ਤੌਰ 'ਤੇ, ਇੱਕ ਸਰਵਰ 'ਤੇ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਮੈਮੋਰੀ ਪੰਨਿਆਂ ਦੀ ਡੁਪਲੀਕੇਸ਼ਨ ਹੈ।

ESXi ਪੰਨਿਆਂ ਦੇ ਹੈਸ਼ ਜੋੜ ਦੀ ਗਿਣਤੀ ਅਤੇ ਤੁਲਨਾ ਕਰਕੇ ਵਰਚੁਅਲ ਮਸ਼ੀਨ RAM ਦੇ ਇੱਕੋ ਜਿਹੇ ਪੰਨਿਆਂ ਦੀ ਖੋਜ ਕਰਦਾ ਹੈ, ਅਤੇ ਡੁਪਲੀਕੇਟ ਪੰਨਿਆਂ ਨੂੰ ਹਟਾ ਦਿੰਦਾ ਹੈ, ਉਹਨਾਂ ਨੂੰ ਸਰਵਰ ਦੀ ਭੌਤਿਕ ਮੈਮੋਰੀ ਵਿੱਚ ਉਸੇ ਪੰਨੇ ਦੇ ਲਿੰਕਾਂ ਨਾਲ ਬਦਲਦਾ ਹੈ। ਨਤੀਜੇ ਵਜੋਂ, ਭੌਤਿਕ ਮੈਮੋਰੀ ਦੀ ਖਪਤ ਘੱਟ ਜਾਂਦੀ ਹੈ ਅਤੇ ਕੁਝ ਮੈਮੋਰੀ ਓਵਰਸਬਸਕ੍ਰਿਪਸ਼ਨ ਨੂੰ ਥੋੜ੍ਹੇ ਜਾਂ ਬਿਨਾਂ ਪ੍ਰਦਰਸ਼ਨ ਦੇ ਵਿਗਾੜ ਨਾਲ ਪ੍ਰਾਪਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਸਰੋਤ

ਇਹ ਵਿਧੀ ਸਿਰਫ਼ 4 KB ਮੈਮੋਰੀ ਪੰਨਿਆਂ (ਛੋਟੇ ਪੰਨਿਆਂ) ਲਈ ਕੰਮ ਕਰਦੀ ਹੈ। ਹਾਈਪਰਵਾਈਜ਼ਰ 2 MB (ਵੱਡੇ ਪੰਨਿਆਂ) ਦੇ ਪੰਨਿਆਂ ਨੂੰ ਕੱਢਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਵੀ ਨਹੀਂ ਕਰਦਾ ਹੈ: ਇਸ ਆਕਾਰ ਦੇ ਇੱਕੋ ਜਿਹੇ ਪੰਨਿਆਂ ਨੂੰ ਲੱਭਣ ਦਾ ਮੌਕਾ ਬਹੁਤ ਵਧੀਆ ਨਹੀਂ ਹੈ।

ਮੂਲ ਰੂਪ ਵਿੱਚ, ESXi ਮੈਮੋਰੀ ਨੂੰ ਵੱਡੇ ਪੰਨਿਆਂ ਲਈ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ। ਵੱਡੇ ਪੰਨਿਆਂ ਨੂੰ ਛੋਟੇ ਪੰਨਿਆਂ ਵਿੱਚ ਤੋੜਨਾ ਉਦੋਂ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਹਾਈ ਸਟੇਟ ਥ੍ਰੈਸ਼ਹੋਲਡ ਤੱਕ ਪਹੁੰਚ ਜਾਂਦੀ ਹੈ ਅਤੇ ਕਲੀਅਰ ਸਟੇਟ 'ਤੇ ਪਹੁੰਚਣ 'ਤੇ ਮਜਬੂਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ (ਹਾਈਪਰਵਾਈਜ਼ਰ ਸਟੇਟ ਟੇਬਲ ਦੇਖੋ)।

ਜੇਕਰ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ TPS ਹੋਸਟ RAM ਦੇ ਭਰਨ ਦੀ ਉਡੀਕ ਕੀਤੇ ਬਿਨਾਂ ਕੰਮ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰੇ, ਤਾਂ ਐਡਵਾਂਸਡ ਵਿਕਲਪ ESXi ਵਿੱਚ ਤੁਹਾਨੂੰ ਮੁੱਲ ਸੈੱਟ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। “Mem.AllocGuestLargePage” ਤੋਂ 0 (ਮੂਲ 1)। ਫਿਰ ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਲਈ ਵੱਡੇ ਮੈਮੋਰੀ ਪੰਨਿਆਂ ਦੀ ਵੰਡ ਨੂੰ ਅਯੋਗ ਕਰ ਦਿੱਤਾ ਜਾਵੇਗਾ।

ਦਸੰਬਰ 2014 ਤੋਂ, ESXi ਦੀਆਂ ਸਾਰੀਆਂ ਰੀਲੀਜ਼ਾਂ ਵਿੱਚ, VMs ਵਿਚਕਾਰ TPS ਨੂੰ ਡਿਫੌਲਟ ਤੌਰ 'ਤੇ ਅਸਮਰੱਥ ਕਰ ਦਿੱਤਾ ਗਿਆ ਹੈ, ਕਿਉਂਕਿ ਇੱਕ ਕਮਜ਼ੋਰੀ ਪਾਈ ਗਈ ਸੀ ਜੋ ਸਿਧਾਂਤਕ ਤੌਰ 'ਤੇ ਇੱਕ VM ਤੋਂ ਦੂਜੇ VM ਦੀ RAM ਤੱਕ ਪਹੁੰਚ ਦੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ। ਵੇਰਵੇ ਇੱਥੇ. ਮੈਨੂੰ TPS ਕਮਜ਼ੋਰੀ ਦਾ ਸ਼ੋਸ਼ਣ ਕਰਨ ਦੇ ਅਮਲੀ ਅਮਲ ਬਾਰੇ ਜਾਣਕਾਰੀ ਨਹੀਂ ਮਿਲੀ ਹੈ।

TPS ਨੀਤੀ ਤਕਨੀਕੀ ਵਿਕਲਪ ਦੁਆਰਾ ਨਿਯੰਤਰਿਤ ਹੈ "Mem.ShareForceSalting" ESXi 'ਤੇ:
0 - ਅੰਤਰ-VM TPS। TPS ਵੱਖ-ਵੱਖ VM ਦੇ ਪੰਨਿਆਂ ਲਈ ਕੰਮ ਕਰਦਾ ਹੈ;
1 - VMX ਵਿੱਚ ਉਸੇ "sched.mem.pshare.salt" ਮੁੱਲ ਦੇ ਨਾਲ VM ਲਈ TPS;
2 (ਪੂਰਵ-ਨਿਰਧਾਰਤ) - ਅੰਤਰ-VM TPS। TPS VM ਦੇ ਅੰਦਰਲੇ ਪੰਨਿਆਂ ਲਈ ਕੰਮ ਕਰਦਾ ਹੈ।

ਇਹ ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਵੱਡੇ ਪੰਨਿਆਂ ਨੂੰ ਬੰਦ ਕਰਨਾ ਅਤੇ ਟੈਸਟ ਬੈਂਚਾਂ 'ਤੇ ਇੰਟਰ-ਵੀਐਮ ਟੀਪੀਐਸ ਨੂੰ ਚਾਲੂ ਕਰਨਾ ਸਮਝਦਾਰ ਹੈ। ਇਹ ਇੱਕੋ ਕਿਸਮ ਦੀ VM ਦੀ ਵੱਡੀ ਗਿਣਤੀ ਵਾਲੇ ਸਟੈਂਡਾਂ ਲਈ ਵੀ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, VDI ਵਾਲੇ ਸਟੈਂਡਾਂ 'ਤੇ, ਭੌਤਿਕ ਮੈਮੋਰੀ ਵਿੱਚ ਬੱਚਤ XNUMX ਪ੍ਰਤੀਸ਼ਤ ਤੱਕ ਪਹੁੰਚ ਸਕਦੀ ਹੈ।

ਮੈਮੋਰੀ ਬੈਲੂਨਿੰਗ ਬੈਲੂਨਿੰਗ ਹੁਣ VM ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਲਈ TPS ਵਰਗੀ ਕੋਈ ਨੁਕਸਾਨਦੇਹ ਅਤੇ ਪਾਰਦਰਸ਼ੀ ਤਕਨੀਕ ਨਹੀਂ ਹੈ। ਪਰ ਸਹੀ ਐਪਲੀਕੇਸ਼ਨ ਨਾਲ, ਤੁਸੀਂ ਬੈਲੂਨਿੰਗ ਦੇ ਨਾਲ ਰਹਿ ਸਕਦੇ ਹੋ ਅਤੇ ਕੰਮ ਵੀ ਕਰ ਸਕਦੇ ਹੋ।

Vmware ਟੂਲਸ ਦੇ ਨਾਲ, VM 'ਤੇ ਬੈਲੂਨ ਡ੍ਰਾਈਵਰ (ਉਰਫ਼ vmmemctl) ਨਾਮਕ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਡਰਾਈਵਰ ਸਥਾਪਤ ਕੀਤਾ ਗਿਆ ਹੈ। ਜਦੋਂ ਹਾਈਪਰਵਾਈਜ਼ਰ ਦੀ ਭੌਤਿਕ ਮੈਮੋਰੀ ਖਤਮ ਹੋਣੀ ਸ਼ੁਰੂ ਹੋ ਜਾਂਦੀ ਹੈ ਅਤੇ ਸਾਫਟ ਸਟੇਟ ਵਿੱਚ ਦਾਖਲ ਹੁੰਦਾ ਹੈ, ਤਾਂ ESXi VM ਨੂੰ ਇਸ ਬੈਲੂਨ ਡ੍ਰਾਈਵਰ ਦੁਆਰਾ ਅਣਵਰਤੀ RAM ਨੂੰ ਮੁੜ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਕਹਿੰਦਾ ਹੈ। ਡਰਾਈਵਰ, ਬਦਲੇ ਵਿੱਚ, ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਪੱਧਰ 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਇਸ ਤੋਂ ਮੁਫਤ ਮੈਮੋਰੀ ਦੀ ਬੇਨਤੀ ਕਰਦਾ ਹੈ। ਹਾਈਪਰਵਾਈਜ਼ਰ ਦੇਖਦਾ ਹੈ ਕਿ ਬੈਲੂਨ ਡਰਾਈਵਰ ਨੇ ਭੌਤਿਕ ਮੈਮੋਰੀ ਦੇ ਕਿਹੜੇ ਪੰਨਿਆਂ 'ਤੇ ਕਬਜ਼ਾ ਕੀਤਾ ਹੈ, ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਤੋਂ ਮੈਮੋਰੀ ਲੈਂਦਾ ਹੈ ਅਤੇ ਇਸਨੂੰ ਹੋਸਟ ਨੂੰ ਵਾਪਸ ਕਰਦਾ ਹੈ। ਓਐਸ ਦੇ ਸੰਚਾਲਨ ਵਿੱਚ ਕੋਈ ਸਮੱਸਿਆ ਨਹੀਂ ਹੈ, ਕਿਉਂਕਿ ਓਐਸ ਪੱਧਰ 'ਤੇ ਮੈਮੋਰੀ ਬੈਲੂਨ ਡਰਾਈਵਰ ਦੁਆਰਾ ਰੱਖੀ ਜਾਂਦੀ ਹੈ. ਮੂਲ ਰੂਪ ਵਿੱਚ ਬੈਲੂਨ ਡਰਾਈਵਰ VM ਮੈਮੋਰੀ ਦਾ 65% ਤੱਕ ਲੈ ਸਕਦਾ ਹੈ।

ਜੇਕਰ VMਵੇਅਰ ਟੂਲ VM 'ਤੇ ਸਥਾਪਤ ਨਹੀਂ ਹਨ ਜਾਂ ਬੈਲੂਨਿੰਗ ਅਸਮਰੱਥ ਹੈ (ਮੈਂ ਸਿਫ਼ਾਰਿਸ਼ ਨਹੀਂ ਕਰਦਾ, ਪਰ ਇੱਥੇ ਹਨ KB:), ਹਾਈਪਰਵਾਈਜ਼ਰ ਤੁਰੰਤ ਹੋਰ ਸਖ਼ਤ ਮੈਮੋਰੀ ਹਟਾਉਣ ਦੀਆਂ ਤਕਨੀਕਾਂ 'ਤੇ ਸਵਿਚ ਕਰਦਾ ਹੈ। ਸਿੱਟਾ: ਯਕੀਨੀ ਬਣਾਓ ਕਿ VMware ਟੂਲ VM 'ਤੇ ਹਨ।

ਬੈਲੂਨ ਡ੍ਰਾਈਵਰ ਦੇ ਓਪਰੇਸ਼ਨ ਦੀ ਜਾਂਚ OS ਤੋਂ VMware ਟੂਲਸ ਦੁਆਰਾ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ.

ਮੈਮੋਰੀ ਕੰਪਰੈਸ਼ਨ. ਇਹ ਤਕਨੀਕ ਉਦੋਂ ਵਰਤੀ ਜਾਂਦੀ ਹੈ ਜਦੋਂ ESXi ਹਾਰਡ ਸਟੇਟ 'ਤੇ ਪਹੁੰਚ ਜਾਂਦੀ ਹੈ। ਜਿਵੇਂ ਕਿ ਨਾਮ ਤੋਂ ਭਾਵ ਹੈ, ESXi RAM ਦੇ ਇੱਕ 4KB ਪੰਨੇ ਨੂੰ 2KB ਵਿੱਚ ਸੁੰਗੜਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਸਰਵਰ ਦੀ ਭੌਤਿਕ ਮੈਮੋਰੀ ਵਿੱਚ ਕੁਝ ਥਾਂ ਖਾਲੀ ਕਰਦਾ ਹੈ। ਇਹ ਤਕਨੀਕ VM RAM ਪੰਨਿਆਂ ਦੀ ਸਮੱਗਰੀ ਤੱਕ ਪਹੁੰਚ ਦੇ ਸਮੇਂ ਨੂੰ ਮਹੱਤਵਪੂਰਨ ਤੌਰ 'ਤੇ ਵਧਾਉਂਦੀ ਹੈ, ਕਿਉਂਕਿ ਪੰਨੇ ਨੂੰ ਪਹਿਲਾਂ ਸੰਕੁਚਿਤ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਕਈ ਵਾਰ ਸਾਰੇ ਪੰਨਿਆਂ ਨੂੰ ਸੰਕੁਚਿਤ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਅਤੇ ਪ੍ਰਕਿਰਿਆ ਆਪਣੇ ਆਪ ਵਿੱਚ ਕੁਝ ਸਮਾਂ ਲੈਂਦੀ ਹੈ। ਇਸ ਲਈ, ਇਹ ਤਕਨੀਕ ਅਭਿਆਸ ਵਿੱਚ ਬਹੁਤ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਨਹੀਂ ਹੈ.

ਮੈਮੋਰੀ ਸਵੈਪਿੰਗ. ਇੱਕ ਛੋਟੇ ਮੈਮੋਰੀ ਕੰਪਰੈਸ਼ਨ ਪੜਾਅ ਤੋਂ ਬਾਅਦ, ESXi ਲਗਭਗ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ (ਜੇਕਰ VM ਹੋਰ ਮੇਜ਼ਬਾਨਾਂ ਲਈ ਨਹੀਂ ਛੱਡਿਆ ਗਿਆ ਹੈ ਜਾਂ ਬੰਦ ਕੀਤਾ ਗਿਆ ਹੈ) ਸਵੈਪਿੰਗ ਵਿੱਚ ਬਦਲ ਜਾਵੇਗਾ। ਅਤੇ ਜੇਕਰ ਬਹੁਤ ਘੱਟ ਮੈਮੋਰੀ ਬਚੀ ਹੈ (ਲੋਅ ਸਟੇਟ), ਤਾਂ ਹਾਈਪਰਵਾਈਜ਼ਰ VM ਨੂੰ ਮੈਮੋਰੀ ਪੰਨਿਆਂ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਨਾ ਵੀ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ, ਜੋ VM ਦੇ ਗੈਸਟ OS ਵਿੱਚ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ।

ਇੱਥੇ ਸਵੈਪਿੰਗ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਨੂੰ ਚਾਲੂ ਕਰਦੇ ਹੋ, ਤਾਂ ਇਸਦੇ ਲਈ .vswp ਐਕਸਟੈਂਸ਼ਨ ਵਾਲੀ ਇੱਕ ਫਾਈਲ ਬਣਾਈ ਜਾਂਦੀ ਹੈ। ਇਹ VM ਦੀ ਅਣਰਿਜ਼ਰਵਡ RAM ਦੇ ਆਕਾਰ ਵਿੱਚ ਬਰਾਬਰ ਹੈ: ਇਹ ਸੰਰਚਿਤ ਅਤੇ ਰਾਖਵੀਂ ਮੈਮੋਰੀ ਵਿੱਚ ਅੰਤਰ ਹੈ। ਜਦੋਂ ਸਵੈਪਿੰਗ ਚੱਲ ਰਹੀ ਹੈ, ESXi ਇਸ ਫਾਈਲ ਵਿੱਚ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਮੈਮੋਰੀ ਪੰਨਿਆਂ ਨੂੰ ਅਨਲੋਡ ਕਰਦਾ ਹੈ ਅਤੇ ਸਰਵਰ ਦੀ ਭੌਤਿਕ ਮੈਮੋਰੀ ਦੀ ਬਜਾਏ ਇਸਦੇ ਨਾਲ ਕੰਮ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ। ਬੇਸ਼ੱਕ, ਅਜਿਹੀ "ਆਪਰੇਟਿਵ" ਮੈਮੋਰੀ ਅਸਲ ਨਾਲੋਂ ਹੌਲੀ ਮੈਮੋਰੀ ਦੇ ਕਈ ਆਰਡਰ ਹੈ, ਭਾਵੇਂ .vswp ਤੇਜ਼ ਸਟੋਰੇਜ 'ਤੇ ਹੈ।

ਬੈਲੂਨਿੰਗ ਦੇ ਉਲਟ, ਜਦੋਂ ਅਣਵਰਤੇ ਪੰਨਿਆਂ ਨੂੰ VM ਤੋਂ ਲਿਆ ਜਾਂਦਾ ਹੈ, ਸਵੈਪਿੰਗ ਨਾਲ, ਪੰਨੇ ਜੋ OS ਜਾਂ VM ਦੇ ਅੰਦਰ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੁਆਰਾ ਸਰਗਰਮੀ ਨਾਲ ਵਰਤੇ ਜਾਂਦੇ ਹਨ, ਡਿਸਕ 'ਤੇ ਜਾ ਸਕਦੇ ਹਨ। ਨਤੀਜੇ ਵਜੋਂ, VM ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਠੰਢ ਦੇ ਬਿੰਦੂ ਤੱਕ ਹੇਠਾਂ ਆ ਜਾਂਦੀ ਹੈ। VM ਰਸਮੀ ਤੌਰ 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਘੱਟੋ-ਘੱਟ ਇਸਨੂੰ OS ਤੋਂ ਠੀਕ ਤਰ੍ਹਾਂ ਅਯੋਗ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਸਬਰ ਰੱਖਦੇ ਹੋ 😉

ਜੇਕਰ VMs ਸਵੈਪ 'ਤੇ ਚਲੇ ਗਏ, ਤਾਂ ਇਹ ਇੱਕ ਅਸਧਾਰਨ ਸਥਿਤੀ ਹੈ, ਜਿਸ ਤੋਂ ਜੇਕਰ ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਬਚਿਆ ਜਾਵੇ।

ਕੁੰਜੀ VM ਮੈਮੋਰੀ ਪ੍ਰਦਰਸ਼ਨ ਕਾਊਂਟਰ

ਇਸ ਲਈ ਅਸੀਂ ਮੁੱਖ ਬਿੰਦੂ ਤੇ ਪਹੁੰਚ ਗਏ. VM ਵਿੱਚ ਮੈਮੋਰੀ ਦੀ ਸਥਿਤੀ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨ ਲਈ, ਹੇਠਾਂ ਦਿੱਤੇ ਕਾਊਂਟਰ ਹਨ:

ਸਰਗਰਮ — RAM (KB) ਦੀ ਮਾਤਰਾ ਦਿਖਾਉਂਦਾ ਹੈ ਜਿਸ ਤੱਕ VM ਨੂੰ ਪਿਛਲੀ ਮਾਪ ਦੀ ਮਿਆਦ ਵਿੱਚ ਪਹੁੰਚ ਮਿਲੀ ਸੀ।

ਉਪਯੋਗਤਾ - ਐਕਟਿਵ ਦੇ ਸਮਾਨ, ਪਰ VM ਦੀ ਕੌਂਫਿਗਰ ਕੀਤੀ RAM ਦੇ ਪ੍ਰਤੀਸ਼ਤ ਵਜੋਂ। ਹੇਠਾਂ ਦਿੱਤੇ ਫਾਰਮੂਲੇ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਗਣਨਾ ਕੀਤੀ ਗਈ: ਕਿਰਿਆਸ਼ੀਲ ÷ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਕੌਂਫਿਗਰ ਕੀਤੀ ਮੈਮੋਰੀ ਦਾ ਆਕਾਰ।
ਉੱਚ ਵਰਤੋਂ ਅਤੇ ਕਿਰਿਆਸ਼ੀਲ, ਕ੍ਰਮਵਾਰ, ਹਮੇਸ਼ਾ VM ਪ੍ਰਦਰਸ਼ਨ ਸਮੱਸਿਆਵਾਂ ਦਾ ਸੂਚਕ ਨਹੀਂ ਹੁੰਦੇ ਹਨ। ਜੇ VM ਹਮਲਾਵਰ ਤੌਰ 'ਤੇ ਮੈਮੋਰੀ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ (ਘੱਟੋ ਘੱਟ ਇਸ ਤੱਕ ਪਹੁੰਚ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ), ਤਾਂ ਇਸਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਹੈ ਕਿ ਲੋੜੀਂਦੀ ਮੈਮੋਰੀ ਨਹੀਂ ਹੈ। ਇਸ ਦੀ ਬਜਾਏ, ਇਹ ਦੇਖਣ ਦਾ ਮੌਕਾ ਹੈ ਕਿ OS ਵਿੱਚ ਕੀ ਹੋ ਰਿਹਾ ਹੈ.
VMs ਲਈ ਇੱਕ ਮਿਆਰੀ ਮੈਮੋਰੀ ਵਰਤੋਂ ਅਲਾਰਮ ਹੈ:

ਸ਼ੇਅਰਡ - TPS (VM ਦੇ ਅੰਦਰ ਜਾਂ VM ਦੇ ਵਿਚਕਾਰ) ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕੱਟੀ ਗਈ VM RAM ਦੀ ਮਾਤਰਾ।

ਇਹ ਸੱਚ ਹੈ - ਭੌਤਿਕ ਹੋਸਟ ਮੈਮੋਰੀ (KB) ਦੀ ਮਾਤਰਾ ਜੋ VM ਨੂੰ ਦਿੱਤੀ ਗਈ ਸੀ। ਸ਼ੇਅਰਡ ਵੀ ਸ਼ਾਮਲ ਹੈ।

ਖਪਤ (ਪ੍ਰਵਾਨਤ - ਸ਼ੇਅਰਡ) - ਭੌਤਿਕ ਮੈਮੋਰੀ (KB) ਦੀ ਮਾਤਰਾ ਜੋ VM ਹੋਸਟ ਤੋਂ ਖਪਤ ਕਰਦੀ ਹੈ। ਸ਼ੇਅਰਡ ਸ਼ਾਮਲ ਨਹੀਂ ਹੈ।

ਜੇਕਰ VM ਮੈਮੋਰੀ ਦਾ ਹਿੱਸਾ ਹੋਸਟ ਦੀ ਭੌਤਿਕ ਮੈਮੋਰੀ ਤੋਂ ਨਹੀਂ ਦਿੱਤਾ ਗਿਆ ਹੈ, ਪਰ ਸਵੈਪ ਫਾਈਲ ਤੋਂ, ਜਾਂ ਮੈਮੋਰੀ ਨੂੰ VM ਤੋਂ ਬੈਲੂਨ ਡ੍ਰਾਈਵਰ ਦੁਆਰਾ ਲਿਆ ਗਿਆ ਹੈ, ਤਾਂ ਇਸ ਰਕਮ ਨੂੰ ਗ੍ਰਾਂਟਡ ਅਤੇ ਕੰਜ਼ਿਊਮਡ ਵਿੱਚ ਨਹੀਂ ਲਿਆ ਜਾਂਦਾ ਹੈ।
ਉੱਚ ਗ੍ਰਾਂਟ ਕੀਤੇ ਅਤੇ ਖਪਤ ਕੀਤੇ ਮੁੱਲ ਬਿਲਕੁਲ ਆਮ ਹਨ। ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਹੌਲੀ-ਹੌਲੀ ਹਾਈਪਰਵਾਈਜ਼ਰ ਤੋਂ ਮੈਮੋਰੀ ਲੈਂਦਾ ਹੈ ਅਤੇ ਇਸਨੂੰ ਵਾਪਸ ਨਹੀਂ ਦਿੰਦਾ। ਸਮੇਂ ਦੇ ਨਾਲ, ਇੱਕ ਸਰਗਰਮੀ ਨਾਲ ਚੱਲ ਰਹੇ VM ਵਿੱਚ, ਇਹਨਾਂ ਕਾਊਂਟਰਾਂ ਦੇ ਮੁੱਲ ਕੌਂਫਿਗਰ ਕੀਤੀ ਮੈਮੋਰੀ ਦੀ ਮਾਤਰਾ ਤੱਕ ਪਹੁੰਚਦੇ ਹਨ, ਅਤੇ ਉੱਥੇ ਹੀ ਰਹਿੰਦੇ ਹਨ।

ਜ਼ੀਰੋ — VM RAM (KB) ਦੀ ਮਾਤਰਾ, ਜਿਸ ਵਿੱਚ ਜ਼ੀਰੋ ਹੁੰਦੇ ਹਨ। ਅਜਿਹੀ ਮੈਮੋਰੀ ਹਾਈਪਰਵਾਈਜ਼ਰ ਦੁਆਰਾ ਮੁਫਤ ਮੰਨੀ ਜਾਂਦੀ ਹੈ ਅਤੇ ਹੋਰ ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਨੂੰ ਦਿੱਤੀ ਜਾ ਸਕਦੀ ਹੈ। ਗੈਸਟ OS ਦੁਆਰਾ ਜ਼ੀਰੋਡ ਮੈਮੋਰੀ ਵਿੱਚ ਕੁਝ ਲਿਖਣ ਤੋਂ ਬਾਅਦ, ਇਹ ਖਪਤ ਵਿੱਚ ਚਲਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਵਾਪਸ ਨਹੀਂ ਆਉਂਦਾ।

ਰਾਖਵਾਂ ਓਵਰਹੈੱਡ — VM RAM ਦੀ ਮਾਤਰਾ, (KB) VM ਓਪਰੇਸ਼ਨ ਲਈ ਹਾਈਪਰਵਾਈਜ਼ਰ ਦੁਆਰਾ ਰਾਖਵੀਂ ਹੈ। ਇਹ ਇੱਕ ਛੋਟੀ ਰਕਮ ਹੈ, ਪਰ ਇਹ ਹੋਸਟ 'ਤੇ ਉਪਲਬਧ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਨਹੀਂ ਤਾਂ VM ਸ਼ੁਰੂ ਨਹੀਂ ਹੋਵੇਗਾ।

ਬੈਲੂਨ - ਬੈਲੂਨ ਡਰਾਈਵਰ ਦੀ ਵਰਤੋਂ ਕਰਕੇ VM ਤੋਂ ਜ਼ਬਤ ਕੀਤੀ ਗਈ RAM (KB) ਦੀ ਮਾਤਰਾ।

ਸੰਕੁਚਿਤ - RAM (KB) ਦੀ ਮਾਤਰਾ ਜੋ ਸੰਕੁਚਿਤ ਕੀਤੀ ਗਈ ਸੀ।

ਬਦਲਿਆ - RAM (KB) ਦੀ ਮਾਤਰਾ ਜੋ, ਸਰਵਰ 'ਤੇ ਭੌਤਿਕ ਮੈਮੋਰੀ ਦੀ ਘਾਟ ਕਾਰਨ, ਡਿਸਕ 'ਤੇ ਚਲੀ ਗਈ ਹੈ।
ਬੈਲੂਨ ਅਤੇ ਹੋਰ ਮੈਮੋਰੀ ਰੀਕਲੇਮੇਸ਼ਨ ਤਕਨੀਕ ਕਾਊਂਟਰ ਜ਼ੀਰੋ ਹਨ।

ਇਸ ਤਰ੍ਹਾਂ ਮੈਮੋਰੀ ਕਾਊਂਟਰਾਂ ਵਾਲਾ ਗ੍ਰਾਫ 150 GB RAM ਦੇ ਨਾਲ ਆਮ ਤੌਰ 'ਤੇ ਕੰਮ ਕਰਨ ਵਾਲੇ VM ਲਈ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ।

ਹੇਠਾਂ ਦਿੱਤੇ ਗ੍ਰਾਫ ਵਿੱਚ, VM ਵਿੱਚ ਸਪੱਸ਼ਟ ਸਮੱਸਿਆਵਾਂ ਹਨ। ਗ੍ਰਾਫ ਦੇ ਹੇਠਾਂ, ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ ਕਿ ਇਸ VM ਲਈ, RAM ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਸਾਰੀਆਂ ਦੱਸੀਆਂ ਗਈਆਂ ਤਕਨੀਕਾਂ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਗਈ ਸੀ. ਇਸ VM ਲਈ ਬੈਲੂਨ ਖਪਤ ਤੋਂ ਬਹੁਤ ਵੱਡਾ ਹੈ। ਅਸਲ ਵਿੱਚ, VM ਜਿੰਦਾ ਨਾਲੋਂ ਵੱਧ ਮਰਿਆ ਹੋਇਆ ਹੈ।

ESXTOP

ਜਿਵੇਂ ਕਿ CPU ਦੇ ਨਾਲ, ਜੇਕਰ ਅਸੀਂ ਹੋਸਟ 'ਤੇ ਸਥਿਤੀ ਦਾ ਤੁਰੰਤ ਮੁਲਾਂਕਣ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ, ਅਤੇ ਨਾਲ ਹੀ 2 ਸਕਿੰਟਾਂ ਤੱਕ ਦੇ ਅੰਤਰਾਲ ਨਾਲ ਇਸਦੀ ਗਤੀਸ਼ੀਲਤਾ ਦਾ ਮੁਲਾਂਕਣ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ, ਤਾਂ ਸਾਨੂੰ ESXTOP ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ।

ਮੈਮੋਰੀ ਦੁਆਰਾ ESXTOP ਸਕਰੀਨ ਨੂੰ "m" ਕੁੰਜੀ ਨਾਲ ਬੁਲਾਇਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ (ਫੀਲਡ B, D, H, J, K, L, O ਚੁਣੇ ਗਏ ਹਨ):

ਹੇਠਾਂ ਦਿੱਤੇ ਮਾਪਦੰਡ ਸਾਡੇ ਲਈ ਦਿਲਚਸਪੀ ਦੇ ਹੋਣਗੇ:

Mem ਓਵਰਕਮਿਟ ਔਸਤ - 1, 5 ਅਤੇ 15 ਮਿੰਟ ਲਈ ਹੋਸਟ 'ਤੇ ਮੈਮੋਰੀ ਓਵਰਸਬਸਕ੍ਰਿਪਸ਼ਨ ਦਾ ਔਸਤ ਮੁੱਲ। ਜੇ ਇਹ ਜ਼ੀਰੋ ਤੋਂ ਉੱਪਰ ਹੈ, ਤਾਂ ਇਹ ਦੇਖਣ ਦਾ ਮੌਕਾ ਹੈ ਕਿ ਕੀ ਹੋ ਰਿਹਾ ਹੈ, ਪਰ ਹਮੇਸ਼ਾ ਸਮੱਸਿਆਵਾਂ ਦਾ ਸੂਚਕ ਨਹੀਂ ਹੁੰਦਾ.

ਲਾਈਨਾਂ ਵਿੱਚ PMEM/MB и VMKMEM/MB - ਸਰਵਰ ਦੀ ਭੌਤਿਕ ਮੈਮੋਰੀ ਅਤੇ VMkernel ਲਈ ਉਪਲਬਧ ਮੈਮੋਰੀ ਬਾਰੇ ਜਾਣਕਾਰੀ। ਇੱਥੇ ਦਿਲਚਸਪ ਤੋਂ ਤੁਸੀਂ ਮਿਨਫ੍ਰੀ (MB ਵਿੱਚ), ਮੈਮੋਰੀ ਵਿੱਚ ਹੋਸਟ ਦੀ ਸਥਿਤੀ (ਸਾਡੇ ਕੇਸ ਵਿੱਚ, ਉੱਚ) ਦਾ ਮੁੱਲ ਦੇਖ ਸਕਦੇ ਹੋ।

ਇਨ ਲਾਇਨ NUMA/MB ਤੁਸੀਂ NUMA ਨੋਡਸ (ਸਾਕਟਾਂ) ਦੁਆਰਾ RAM ਦੀ ਵੰਡ ਨੂੰ ਦੇਖ ਸਕਦੇ ਹੋ। ਇਸ ਉਦਾਹਰਨ ਵਿੱਚ, ਵੰਡ ਅਸਮਾਨ ਹੈ, ਜੋ ਕਿ, ਸਿਧਾਂਤ ਵਿੱਚ, ਬਹੁਤ ਵਧੀਆ ਨਹੀਂ ਹੈ।

ਹੇਠਾਂ ਮੈਮੋਰੀ ਰੀਕਲੇਮੇਸ਼ਨ ਤਕਨੀਕਾਂ 'ਤੇ ਆਮ ਸਰਵਰ ਅੰਕੜੇ ਹਨ:

PSHARE/MB TPS ਅੰਕੜੇ ਹਨ;

ਸਵੈਪ/MB - ਸਵੈਪ ਵਰਤੋਂ ਦੇ ਅੰਕੜੇ;

ZIP/MB - ਮੈਮੋਰੀ ਪੇਜ ਕੰਪਰੈਸ਼ਨ ਅੰਕੜੇ;

MEMCTL/MB - ਬੈਲੂਨ ਡਰਾਈਵਰ ਵਰਤੋਂ ਦੇ ਅੰਕੜੇ।

ਵਿਅਕਤੀਗਤ VM ਲਈ, ਸਾਨੂੰ ਹੇਠਾਂ ਦਿੱਤੀ ਜਾਣਕਾਰੀ ਵਿੱਚ ਦਿਲਚਸਪੀ ਹੋ ਸਕਦੀ ਹੈ। ਮੈਂ VM ਦੇ ਨਾਮ ਲੁਕਾਏ ਹਨ ਤਾਂ ਜੋ ਦਰਸ਼ਕਾਂ ਨੂੰ ਉਲਝਣ ਵਿੱਚ ਨਾ ਪਵੇ :). ਜੇਕਰ ESXTOP ਮੈਟ੍ਰਿਕ vSphere ਵਿੱਚ ਕਾਊਂਟਰ ਦੇ ਸਮਾਨ ਹੈ, ਤਾਂ ਮੈਂ ਸੰਬੰਧਿਤ ਕਾਊਂਟਰ ਦਿੰਦਾ ਹਾਂ।

MEMSZ — VM (MB) ਉੱਤੇ ਸੰਰਚਿਤ ਕੀਤੀ ਮੈਮੋਰੀ ਦੀ ਮਾਤਰਾ।
MEMSZ = GRANT + MCTLSZ + SWCUR + ਅਛੂਤ।

ਗ੍ਰਾਂਟ — MB ਨੂੰ ਦਿੱਤੀ ਗਈ।

TCHD - MB ਵਿੱਚ ਕਿਰਿਆਸ਼ੀਲ।

MCTL? - ਕੀ ਬੈਲੂਨ ਡਰਾਈਵਰ VM 'ਤੇ ਸਥਾਪਿਤ ਹੈ।

MCTLSZ - ਬੈਲੂਨ ਤੋਂ ਐਮ.ਬੀ.

MCTLGT — RAM (MB) ਦੀ ਮਾਤਰਾ ਜੋ ESXi VM ਤੋਂ ਬੈਲੂਨ ਡਰਾਈਵਰ (Memctl ਟਾਰਗੇਟ) ਰਾਹੀਂ ਲੈਣਾ ਚਾਹੁੰਦਾ ਹੈ।

MCTLMAX - RAM (MB) ਦੀ ਵੱਧ ਤੋਂ ਵੱਧ ਮਾਤਰਾ ਜੋ ESXi ਬੈਲੂਨ ਡਰਾਈਵਰ ਦੁਆਰਾ VM ਤੋਂ ਲੈ ਸਕਦਾ ਹੈ।

SWCUR — ਸਵੈਪ ਫਾਈਲ ਤੋਂ VM ਨੂੰ ਨਿਰਧਾਰਤ ਕੀਤੀ RAM (MB) ਦੀ ਮੌਜੂਦਾ ਮਾਤਰਾ।

S.W.G.T. - RAM (MB) ਦੀ ਮਾਤਰਾ ਜੋ ESXi ਸਵੈਪ ਫਾਈਲ (ਸਵੈਪ ਟਾਰਗੇਟ) ਤੋਂ VM ਨੂੰ ਦੇਣਾ ਚਾਹੁੰਦਾ ਹੈ।

ਨਾਲ ਹੀ, ESXTOP ਦੁਆਰਾ, ਤੁਸੀਂ VM ਦੇ NUMA ਟੋਪੋਲੋਜੀ ਬਾਰੇ ਵਧੇਰੇ ਵਿਸਤ੍ਰਿਤ ਜਾਣਕਾਰੀ ਦੇਖ ਸਕਦੇ ਹੋ। ਅਜਿਹਾ ਕਰਨ ਲਈ, D, G ਖੇਤਰ ਦੀ ਚੋਣ ਕਰੋ:

ਐਨ.ਐੱਨ.ਐੱਚ - NUMA ਨੋਡ ਜਿਸ 'ਤੇ VM ਸਥਿਤ ਹੈ। ਇੱਥੇ ਤੁਸੀਂ ਤੁਰੰਤ ਵਿਆਪਕ vm ਦੇਖ ਸਕਦੇ ਹੋ, ਜੋ ਕਿ ਇੱਕ NUMA ਨੋਡ 'ਤੇ ਫਿੱਟ ਨਹੀਂ ਹੁੰਦੇ ਹਨ।

NRMEM - VM ਰਿਮੋਟ NUMA ਨੋਡ ਤੋਂ ਕਿੰਨੀ ਮੈਗਾਬਾਈਟ ਮੈਮੋਰੀ ਲੈਂਦਾ ਹੈ।

NLMEM - VM ਸਥਾਨਕ NUMA ਨੋਡ ਤੋਂ ਕਿੰਨੀ ਮੈਗਾਬਾਈਟ ਮੈਮੋਰੀ ਲੈਂਦਾ ਹੈ।

N%L - ਸਥਾਨਕ NUMA ਨੋਡ 'ਤੇ VM ਮੈਮੋਰੀ ਦੀ ਪ੍ਰਤੀਸ਼ਤਤਾ (ਜੇਕਰ 80% ਤੋਂ ਘੱਟ ਹੈ, ਪ੍ਰਦਰਸ਼ਨ ਸਮੱਸਿਆਵਾਂ ਹੋ ਸਕਦੀਆਂ ਹਨ)।

ਹਾਈਪਰਵਾਈਜ਼ਰ 'ਤੇ ਮੈਮੋਰੀ

ਜੇਕਰ ਹਾਈਪਰਵਾਈਜ਼ਰ ਲਈ CPU ਕਾਊਂਟਰ ਆਮ ਤੌਰ 'ਤੇ ਖਾਸ ਦਿਲਚਸਪੀ ਨਹੀਂ ਰੱਖਦੇ, ਤਾਂ ਸਥਿਤੀ ਮੈਮੋਰੀ ਨਾਲ ਉਲਟ ਜਾਂਦੀ ਹੈ। ਇੱਕ VM 'ਤੇ ਉੱਚ ਮੈਮੋਰੀ ਵਰਤੋਂ ਹਮੇਸ਼ਾ ਇੱਕ ਪ੍ਰਦਰਸ਼ਨ ਸਮੱਸਿਆ ਨੂੰ ਦਰਸਾਉਂਦੀ ਨਹੀਂ ਹੈ, ਪਰ ਇੱਕ ਹਾਈਪਰਵਾਈਜ਼ਰ 'ਤੇ ਉੱਚ ਮੈਮੋਰੀ ਵਰਤੋਂ ਮੈਮੋਰੀ ਪ੍ਰਬੰਧਨ ਤਕਨੀਕਾਂ ਨੂੰ ਚਾਲੂ ਕਰਦੀ ਹੈ ਅਤੇ VM ਵਿੱਚ ਪ੍ਰਦਰਸ਼ਨ ਸਮੱਸਿਆਵਾਂ ਦਾ ਕਾਰਨ ਬਣਦੀ ਹੈ। VM ਨੂੰ ਸਵੈਪ ਵਿੱਚ ਆਉਣ ਤੋਂ ਰੋਕਣ ਲਈ ਹੋਸਟ ਮੈਮੋਰੀ ਵਰਤੋਂ ਅਲਾਰਮ ਦੀ ਨਿਗਰਾਨੀ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ।

ਅਦਲਾ-ਬਦਲੀ

ਜੇਕਰ ਇੱਕ VM ਸਵੈਪ ਵਿੱਚ ਹੈ, ਤਾਂ ਇਸਦਾ ਪ੍ਰਦਰਸ਼ਨ ਬਹੁਤ ਘੱਟ ਜਾਂਦਾ ਹੈ। ਹੋਸਟ 'ਤੇ ਮੁਫਤ RAM ਦਿਖਾਈ ਦੇਣ ਤੋਂ ਬਾਅਦ ਬੈਲੂਨਿੰਗ ਅਤੇ ਕੰਪਰੈਸ਼ਨ ਦੇ ਨਿਸ਼ਾਨ ਤੇਜ਼ੀ ਨਾਲ ਅਲੋਪ ਹੋ ਜਾਂਦੇ ਹਨ, ਪਰ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਸਵੈਪ ਤੋਂ ਸਰਵਰ ਰੈਮ 'ਤੇ ਵਾਪਸ ਜਾਣ ਦੀ ਕੋਈ ਜਲਦੀ ਨਹੀਂ ਹੈ।
ESXi 6.0 ਤੋਂ ਪਹਿਲਾਂ, ਸਵੈਪ ਤੋਂ ਇੱਕ VM ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਦਾ ਇੱਕੋ ਇੱਕ ਭਰੋਸੇਯੋਗ ਅਤੇ ਤੇਜ਼ ਤਰੀਕਾ ਰੀਬੂਟ ਕਰਨਾ ਸੀ (ਵਧੇਰੇ ਸਟੀਕ ਹੋਣ ਲਈ, ਕੰਟੇਨਰ ਨੂੰ ਬੰਦ/ਬੰਦ ਕਰੋ)। ESXi 6.0 ਨਾਲ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋਏ, ਹਾਲਾਂਕਿ ਬਹੁਤ ਅਧਿਕਾਰਤ ਨਹੀਂ ਹੈ, ਸਵੈਪ ਤੋਂ VM ਨੂੰ ਹਟਾਉਣ ਦਾ ਇੱਕ ਕਾਰਜਸ਼ੀਲ ਅਤੇ ਭਰੋਸੇਮੰਦ ਤਰੀਕਾ ਪ੍ਰਗਟ ਹੋਇਆ ਹੈ। ਇੱਕ ਕਾਨਫਰੰਸ ਵਿੱਚ, ਮੈਂ CPU ਸ਼ਡਿਊਲਰ ਦੇ ਇੰਚਾਰਜ VMware ਇੰਜੀਨੀਅਰਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨਾਲ ਗੱਲ ਕਰਨ ਦੇ ਯੋਗ ਸੀ। ਉਸਨੇ ਪੁਸ਼ਟੀ ਕੀਤੀ ਕਿ ਇਹ ਤਰੀਕਾ ਕਾਫ਼ੀ ਕੰਮ ਕਰਨ ਵਾਲਾ ਅਤੇ ਸੁਰੱਖਿਅਤ ਹੈ। ਸਾਡੇ ਤਜ਼ਰਬੇ ਵਿੱਚ, ਇਸ ਵਿੱਚ ਕੋਈ ਸਮੱਸਿਆ ਨਹੀਂ ਸੀ.

ਸਵੈਪ ਤੋਂ VM ਨੂੰ ਹਟਾਉਣ ਲਈ ਅਸਲ ਕਮਾਂਡਾਂ ਦੱਸਿਆ ਗਿਆ ਹੈ ਡੰਕਨ ਏਪਿੰਗ. ਮੈਂ ਵਿਸਤ੍ਰਿਤ ਵਰਣਨ ਨੂੰ ਨਹੀਂ ਦੁਹਰਾਵਾਂਗਾ, ਸਿਰਫ ਇਸਦੀ ਵਰਤੋਂ ਦੀ ਇੱਕ ਉਦਾਹਰਣ ਦੇਵਾਂਗਾ. ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਸਕ੍ਰੀਨਸ਼ੌਟ ਵਿੱਚ ਦੇਖ ਸਕਦੇ ਹੋ, ਨਿਰਧਾਰਤ ਕਮਾਂਡਾਂ ਦੇ ਲਾਗੂ ਹੋਣ ਤੋਂ ਕੁਝ ਸਮੇਂ ਬਾਅਦ, ਸਵੈਪ VM 'ਤੇ ਗਾਇਬ ਹੋ ਜਾਂਦਾ ਹੈ।

ESXi ਮੈਮੋਰੀ ਪ੍ਰਬੰਧਨ ਸੁਝਾਅ

ਅੰਤ ਵਿੱਚ, ਇੱਥੇ ਕੁਝ ਸੁਝਾਅ ਹਨ ਜੋ ਤੁਹਾਨੂੰ RAM ਦੇ ਕਾਰਨ VM ਪ੍ਰਦਰਸ਼ਨ ਨਾਲ ਸਮੱਸਿਆਵਾਂ ਤੋਂ ਬਚਣ ਵਿੱਚ ਮਦਦ ਕਰਨਗੇ:

• ਉਤਪਾਦਕ ਕਲੱਸਟਰਾਂ ਵਿੱਚ ਮੈਮੋਰੀ ਓਵਰਸਬਸਕ੍ਰਿਪਸ਼ਨ ਤੋਂ ਬਚੋ। ਕਲੱਸਟਰ ਵਿੱਚ ਹਮੇਸ਼ਾਂ ~ 20-30% ਮੁਫਤ ਮੈਮੋਰੀ ਰੱਖਣਾ ਫਾਇਦੇਮੰਦ ਹੁੰਦਾ ਹੈ ਤਾਂ ਜੋ DRS (ਅਤੇ ਪ੍ਰਬੰਧਕ) ਕੋਲ ਅਭਿਆਸ ਕਰਨ ਲਈ ਜਗ੍ਹਾ ਹੋਵੇ, ਅਤੇ VM ਮਾਈਗ੍ਰੇਸ਼ਨ ਦੌਰਾਨ ਸਵੈਪ ਵਿੱਚ ਨਾ ਜਾਣ। ਨਾਲ ਹੀ, ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ ਲਈ ਹਾਸ਼ੀਏ ਬਾਰੇ ਨਾ ਭੁੱਲੋ. ਇਹ ਦੁਖਦਾਈ ਹੈ ਜਦੋਂ, ਜਦੋਂ ਇੱਕ ਸਰਵਰ ਫੇਲ ਹੁੰਦਾ ਹੈ ਅਤੇ VM ਨੂੰ HA ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਰੀਬੂਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਕੁਝ ਮਸ਼ੀਨਾਂ ਸਵੈਪ ਵਿੱਚ ਵੀ ਜਾਂਦੀਆਂ ਹਨ।
• ਬਹੁਤ ਜ਼ਿਆਦਾ ਏਕੀਕ੍ਰਿਤ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਵਿੱਚ, ਅੱਧੇ ਤੋਂ ਵੱਧ ਹੋਸਟ ਮੈਮੋਰੀ ਵਾਲੇ VM ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਾ ਕਰੋ। ਇਹ DRS ਨੂੰ ਬਿਨਾਂ ਕਿਸੇ ਸਮੱਸਿਆ ਦੇ ਕਲੱਸਟਰ ਸਰਵਰਾਂ ਵਿੱਚ ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਨੂੰ ਵੰਡਣ ਵਿੱਚ ਮਦਦ ਕਰੇਗਾ। ਇਹ ਨਿਯਮ, ਬੇਸ਼ਕ, ਸਰਵ ਵਿਆਪਕ ਨਹੀਂ ਹੈ :).
• ਹੋਸਟ ਮੈਮੋਰੀ ਵਰਤੋਂ ਅਲਾਰਮ ਲਈ ਦੇਖੋ।
• VM 'ਤੇ VMware Tools ਨੂੰ ਇੰਸਟਾਲ ਕਰਨਾ ਨਾ ਭੁੱਲੋ ਅਤੇ Ballooning ਨੂੰ ਬੰਦ ਨਾ ਕਰੋ।
• ਇੰਟਰ-VM TPS ਨੂੰ ਸਮਰੱਥ ਕਰਨ ਅਤੇ VDI ਅਤੇ ਟੈਸਟ ਵਾਤਾਵਰਨ ਵਿੱਚ ਵੱਡੇ ਪੰਨਿਆਂ ਨੂੰ ਅਯੋਗ ਕਰਨ ਬਾਰੇ ਵਿਚਾਰ ਕਰੋ।
• ਜੇਕਰ VM ਕਾਰਗੁਜ਼ਾਰੀ ਸਮੱਸਿਆਵਾਂ ਦਾ ਸਾਹਮਣਾ ਕਰ ਰਿਹਾ ਹੈ, ਤਾਂ ਇਹ ਦੇਖਣ ਲਈ ਜਾਂਚ ਕਰੋ ਕਿ ਕੀ ਇਹ ਰਿਮੋਟ NUMA ਨੋਡ ਤੋਂ ਮੈਮੋਰੀ ਦੀ ਵਰਤੋਂ ਕਰ ਰਿਹਾ ਹੈ।
• ਆਪਣੇ VM ਨੂੰ ਜਿੰਨੀ ਜਲਦੀ ਹੋ ਸਕੇ ਸਵੈਪ ਤੋਂ ਬਾਹਰ ਕੱਢੋ! ਹੋਰ ਚੀਜ਼ਾਂ ਦੇ ਨਾਲ, ਜੇਕਰ VM ਸਵੈਪ ਵਿੱਚ ਹੈ, ਤਾਂ ਸਪੱਸ਼ਟ ਕਾਰਨਾਂ ਕਰਕੇ, ਸਟੋਰੇਜ ਸਿਸਟਮ ਨੂੰ ਨੁਕਸਾਨ ਹੁੰਦਾ ਹੈ।

ਮੇਰੇ ਲਈ ਇਹ ਸਭ RAM ਬਾਰੇ ਹੈ। ਹੇਠਾਂ ਉਹਨਾਂ ਲਈ ਇੱਕ ਸੰਬੰਧਿਤ ਲੇਖ ਹੈ ਜੋ ਵੇਰਵਿਆਂ ਵਿੱਚ ਖੁਦਾਈ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਨ। ਅਗਲਾ ਲੇਖ storadzh ਨੂੰ ਸਮਰਪਿਤ ਕੀਤਾ ਜਾਵੇਗਾ.

ਉਪਯੋਗੀ ਲਿੰਕhttp://www.yellow-bricks.com/2015/03/02/what-happens-at-which-vsphere-memory-state/
http://www.yellow-bricks.com/2013/06/14/how-does-mem-minfreepct-work-with-vsphere-5-0-and-up/
https://www.vladan.fr/vmware-transparent-page-sharing-tps-explained/
http://www.yellow-bricks.com/2016/06/02/memory-pages-swapped-can-unswap/
https://kb.vmware.com/s/article/1002586
https://www.vladan.fr/what-is-vmware-memory-ballooning/
https://kb.vmware.com/s/article/2080735
https://kb.vmware.com/s/article/2017642
https://labs.vmware.com/vmtj/vmware-esx-memory-resource-management-swap
https://blogs.vmware.com/vsphere/2013/10/understanding-vsphere-active-memory.html
https://www.vmware.com/support/developer/converter-sdk/conv51_apireference/memory_counters.html
https://docs.vmware.com/en/VMware-vSphere/6.5/vsphere-esxi-vcenter-server-65-monitoring-performance-guide.pdf

ਸਰੋਤ: www.habr.com