VMware vSphere ਵਿੱਚ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ। ਭਾਗ 1: CPU

ਜੇਕਰ ਤੁਸੀਂ VMware vSphere (ਜਾਂ ਕੋਈ ਹੋਰ ਤਕਨਾਲੋਜੀ ਸਟੈਕ) 'ਤੇ ਆਧਾਰਿਤ ਇੱਕ ਵਰਚੁਅਲ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਸ਼ਾਇਦ ਅਕਸਰ ਉਪਭੋਗਤਾਵਾਂ ਤੋਂ ਸ਼ਿਕਾਇਤਾਂ ਸੁਣਦੇ ਹੋ: "ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਹੌਲੀ ਹੈ!" ਲੇਖਾਂ ਦੀ ਇਸ ਲੜੀ ਵਿੱਚ ਮੈਂ ਪ੍ਰਦਰਸ਼ਨ ਮੈਟ੍ਰਿਕਸ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਾਂਗਾ ਅਤੇ ਤੁਹਾਨੂੰ ਦੱਸਾਂਗਾ ਕਿ ਇਹ ਕੀ ਅਤੇ ਕਿਉਂ ਹੌਲੀ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ ਇਹ ਕਿਵੇਂ ਯਕੀਨੀ ਬਣਾਇਆ ਜਾਵੇ ਕਿ ਇਹ ਹੌਲੀ ਨਾ ਹੋਵੇ।

ਮੈਂ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਪ੍ਰਦਰਸ਼ਨ ਦੇ ਹੇਠਾਂ ਦਿੱਤੇ ਪਹਿਲੂਆਂ 'ਤੇ ਵਿਚਾਰ ਕਰਾਂਗਾ:

• ਸੀਪੀਯੂ,
• ਫਰੈਮ,
• ਡਿਸਕ,
• ਨੈੱਟਵਰਕ

ਮੈਂ CPU ਨਾਲ ਸ਼ੁਰੂ ਕਰਾਂਗਾ।

ਕਾਰਗੁਜ਼ਾਰੀ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨ ਲਈ ਸਾਨੂੰ ਲੋੜ ਹੋਵੇਗੀ:

• vCenter ਪ੍ਰਦਰਸ਼ਨ ਕਾਊਂਟਰ - ਪ੍ਰਦਰਸ਼ਨ ਕਾਊਂਟਰ, ਜਿਨ੍ਹਾਂ ਦੇ ਗ੍ਰਾਫ਼ vSphere ਕਲਾਇੰਟ ਦੁਆਰਾ ਦੇਖੇ ਜਾ ਸਕਦੇ ਹਨ। ਇਹਨਾਂ ਕਾਉਂਟਰਾਂ 'ਤੇ ਜਾਣਕਾਰੀ ਕਲਾਇੰਟ ਦੇ ਕਿਸੇ ਵੀ ਸੰਸਕਰਣ ਵਿੱਚ ਉਪਲਬਧ ਹੈ (C# ਵਿੱਚ "ਮੋਟਾ" ਕਲਾਇੰਟ, ਫਲੈਕਸ ਵਿੱਚ ਵੈੱਬ ਕਲਾਇੰਟ ਅਤੇ HTML5 ਵਿੱਚ ਵੈਬ ਕਲਾਇੰਟ)। ਇਹਨਾਂ ਲੇਖਾਂ ਵਿੱਚ ਅਸੀਂ C# ਕਲਾਇੰਟ ਤੋਂ ਸਕ੍ਰੀਨਸ਼ੌਟਸ ਦੀ ਵਰਤੋਂ ਕਰਾਂਗੇ, ਸਿਰਫ ਇਸ ਲਈ ਕਿਉਂਕਿ ਉਹ ਛੋਟੇ ਰੂਪ ਵਿੱਚ ਬਿਹਤਰ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ :)
• ESXTOP - ਇੱਕ ਉਪਯੋਗਤਾ ਜੋ ESXi ਕਮਾਂਡ ਲਾਈਨ ਤੋਂ ਚੱਲਦੀ ਹੈ। ਇਸਦੀ ਮਦਦ ਨਾਲ, ਤੁਸੀਂ ਅਸਲ ਸਮੇਂ ਵਿੱਚ ਪ੍ਰਦਰਸ਼ਨ ਕਾਊਂਟਰਾਂ ਦੇ ਮੁੱਲ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ ਜਾਂ ਇਹਨਾਂ ਮੁੱਲਾਂ ਨੂੰ ਇੱਕ ਨਿਸ਼ਚਿਤ ਮਿਆਦ ਲਈ ਹੋਰ ਵਿਸ਼ਲੇਸ਼ਣ ਲਈ ਇੱਕ .csv ਫਾਈਲ ਵਿੱਚ ਅੱਪਲੋਡ ਕਰ ਸਕਦੇ ਹੋ। ਅੱਗੇ, ਮੈਂ ਤੁਹਾਨੂੰ ਇਸ ਟੂਲ ਬਾਰੇ ਹੋਰ ਦੱਸਾਂਗਾ ਅਤੇ ਇਸ ਵਿਸ਼ੇ 'ਤੇ ਦਸਤਾਵੇਜ਼ਾਂ ਅਤੇ ਲੇਖਾਂ ਲਈ ਕਈ ਉਪਯੋਗੀ ਲਿੰਕ ਪ੍ਰਦਾਨ ਕਰਾਂਗਾ।

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

ESXi ਵਿੱਚ, ਇੱਕ ਵੱਖਰੀ ਪ੍ਰਕਿਰਿਆ - VMware ਸ਼ਬਦਾਵਲੀ ਵਿੱਚ ਸੰਸਾਰ - ਹਰੇਕ vCPU (ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਕੋਰ) ਦੇ ਸੰਚਾਲਨ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੈ। ਸੇਵਾ ਪ੍ਰਕਿਰਿਆਵਾਂ ਵੀ ਹਨ, ਪਰ VM ਪ੍ਰਦਰਸ਼ਨ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ ਉਹ ਘੱਟ ਦਿਲਚਸਪ ਹਨ.

ESXi ਵਿੱਚ ਇੱਕ ਪ੍ਰਕਿਰਿਆ ਚਾਰ ਰਾਜਾਂ ਵਿੱਚੋਂ ਇੱਕ ਵਿੱਚ ਹੋ ਸਕਦੀ ਹੈ:

• ਚਲਾਓ - ਪ੍ਰਕਿਰਿਆ ਕੁਝ ਲਾਭਦਾਇਕ ਕੰਮ ਕਰਦੀ ਹੈ।
• ਉਡੀਕ ਕਰੋ - ਪ੍ਰਕਿਰਿਆ ਕੋਈ ਕੰਮ (ਵਿਹਲੀ) ਨਹੀਂ ਕਰ ਰਹੀ ਹੈ ਜਾਂ ਇੰਪੁੱਟ/ਆਊਟਪੁੱਟ ਦੀ ਉਡੀਕ ਕਰ ਰਹੀ ਹੈ।
• ਕੋਸਟੌਪ - ਇੱਕ ਅਜਿਹੀ ਸਥਿਤੀ ਜੋ ਮਲਟੀ-ਕੋਰ ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਵਿੱਚ ਹੁੰਦੀ ਹੈ। ਇਹ ਉਦੋਂ ਵਾਪਰਦਾ ਹੈ ਜਦੋਂ ਹਾਈਪਰਵਾਈਜ਼ਰ CPU ਸ਼ਡਿਊਲਰ (ESXi CPU ਸ਼ਡਿਊਲਰ) ਭੌਤਿਕ ਸਰਵਰ ਕੋਰਾਂ 'ਤੇ ਸਾਰੇ ਸਰਗਰਮ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਕੋਰਾਂ ਦੇ ਨਾਲ-ਨਾਲ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਨੂੰ ਤਹਿ ਨਹੀਂ ਕਰ ਸਕਦਾ ਹੈ। ਭੌਤਿਕ ਸੰਸਾਰ ਵਿੱਚ, ਸਾਰੇ ਪ੍ਰੋਸੈਸਰ ਕੋਰ ਸਮਾਨਾਂਤਰ ਵਿੱਚ ਕੰਮ ਕਰਦੇ ਹਨ, VM ਦੇ ਅੰਦਰ ਗੈਸਟ OS ਸਮਾਨ ਵਿਵਹਾਰ ਦੀ ਉਮੀਦ ਕਰਦਾ ਹੈ, ਇਸਲਈ ਹਾਈਪਰਵਾਈਜ਼ਰ ਨੂੰ VM ਕੋਰਾਂ ਨੂੰ ਹੌਲੀ ਕਰਨਾ ਪੈਂਦਾ ਹੈ ਜੋ ਆਪਣੇ ਕਲਾਕ ਚੱਕਰ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਖਤਮ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਰੱਖਦੇ ਹਨ। ESXi ਦੇ ਆਧੁਨਿਕ ਸੰਸਕਰਣਾਂ ਵਿੱਚ, CPU ਸ਼ਡਿਊਲਰ ਇੱਕ ਵਿਧੀ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ ਜਿਸਨੂੰ ਆਰਾਮਦਾਇਕ ਕੋ-ਸ਼ਡਿਊਲਿੰਗ ਕਿਹਾ ਜਾਂਦਾ ਹੈ: ਹਾਈਪਰਵਾਈਜ਼ਰ "ਸਭ ਤੋਂ ਤੇਜ਼" ਅਤੇ "ਸਭ ਤੋਂ ਹੌਲੀ" ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਕੋਰ (ਸਕਿਊ) ਵਿਚਕਾਰ ਪਾੜੇ ਨੂੰ ਸਮਝਦਾ ਹੈ। ਜੇਕਰ ਅੰਤਰ ਇੱਕ ਨਿਸ਼ਚਿਤ ਥ੍ਰੈਸ਼ਹੋਲਡ ਤੋਂ ਵੱਧ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਤੇਜ਼ ਕੋਰ ਕੋਸਟੌਪ ਅਵਸਥਾ ਵਿੱਚ ਦਾਖਲ ਹੁੰਦਾ ਹੈ। ਜੇ VM ਕੋਰ ਇਸ ਸਥਿਤੀ ਵਿੱਚ ਬਹੁਤ ਸਮਾਂ ਬਿਤਾਉਂਦੇ ਹਨ, ਤਾਂ ਇਹ ਪ੍ਰਦਰਸ਼ਨ ਦੇ ਮੁੱਦੇ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ।
• ਰੈਡੀ - ਪ੍ਰਕਿਰਿਆ ਇਸ ਸਥਿਤੀ ਵਿੱਚ ਦਾਖਲ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਹਾਈਪਰਵਾਈਜ਼ਰ ਇਸਦੇ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਲਈ ਸਰੋਤ ਨਿਰਧਾਰਤ ਕਰਨ ਵਿੱਚ ਅਸਮਰੱਥ ਹੁੰਦਾ ਹੈ। ਉੱਚ ਤਿਆਰ ਮੁੱਲ VM ਪ੍ਰਦਰਸ਼ਨ ਸਮੱਸਿਆਵਾਂ ਦਾ ਕਾਰਨ ਬਣ ਸਕਦੇ ਹਨ।

ਬੁਨਿਆਦੀ ਵਰਚੁਅਲ ਮਸ਼ੀਨ CPU ਪ੍ਰਦਰਸ਼ਨ ਕਾਊਂਟਰ

CPU ਵਰਤੋਂ, %. ਦਿੱਤੀ ਗਈ ਮਿਆਦ ਲਈ CPU ਵਰਤੋਂ ਦੀ ਪ੍ਰਤੀਸ਼ਤਤਾ ਦਿਖਾਉਂਦਾ ਹੈ।

ਵਿਸ਼ਲੇਸ਼ਣ ਕਿਵੇਂ ਕਰੀਏ? ਜੇਕਰ ਇੱਕ VM ਲਗਾਤਾਰ 90% 'ਤੇ CPU ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ ਜਾਂ 100% ਤੱਕ ਸਿਖਰਾਂ ਹਨ, ਤਾਂ ਸਾਨੂੰ ਸਮੱਸਿਆਵਾਂ ਹਨ। ਸਮੱਸਿਆਵਾਂ ਕੇਵਲ VM ਦੇ ਅੰਦਰ ਐਪਲੀਕੇਸ਼ਨ ਦੇ "ਹੌਲੀ" ਓਪਰੇਸ਼ਨ ਵਿੱਚ ਹੀ ਨਹੀਂ, ਸਗੋਂ ਨੈੱਟਵਰਕ ਉੱਤੇ VM ਦੀ ਅਸਮਰਥਤਾ ਵਿੱਚ ਵੀ ਪ੍ਰਗਟ ਕੀਤੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ। ਜੇਕਰ ਨਿਗਰਾਨੀ ਸਿਸਟਮ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ VM ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਡਿੱਗਦਾ ਹੈ, ਤਾਂ CPU ਵਰਤੋਂ ਗ੍ਰਾਫ ਵਿੱਚ ਸਿਖਰਾਂ ਵੱਲ ਧਿਆਨ ਦਿਓ।

ਇੱਕ ਮਿਆਰੀ ਅਲਾਰਮ ਹੈ ਜੋ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਦਾ CPU ਲੋਡ ਦਿਖਾਉਂਦਾ ਹੈ:

ਮੈਨੂੰ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ? ਜੇਕਰ ਇੱਕ VM ਦੀ CPU ਵਰਤੋਂ ਲਗਾਤਾਰ ਛੱਤ ਵਿੱਚੋਂ ਲੰਘ ਰਹੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ vCPUs ਦੀ ਗਿਣਤੀ ਵਧਾਉਣ ਬਾਰੇ ਸੋਚ ਸਕਦੇ ਹੋ (ਬਦਕਿਸਮਤੀ ਨਾਲ, ਇਹ ਹਮੇਸ਼ਾ ਮਦਦ ਨਹੀਂ ਕਰਦਾ) ਜਾਂ VM ਨੂੰ ਵਧੇਰੇ ਸ਼ਕਤੀਸ਼ਾਲੀ ਪ੍ਰੋਸੈਸਰਾਂ ਵਾਲੇ ਸਰਵਰ 'ਤੇ ਲਿਜਾਣ ਬਾਰੇ ਸੋਚ ਸਕਦੇ ਹੋ।

MHz ਵਿੱਚ CPU ਵਰਤੋਂ

% ਵਿੱਚ vCenter ਵਰਤੋਂ ਦੇ ਗ੍ਰਾਫਾਂ ਵਿੱਚ ਤੁਸੀਂ ਸਿਰਫ਼ ਪੂਰੀ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਲਈ ਦੇਖ ਸਕਦੇ ਹੋ (Extop ਵਿੱਚ ਕੋਰ ਲਈ % ਮੁੱਲ ਹਨ) ਲਈ ਕੋਈ ਗ੍ਰਾਫ਼ ਨਹੀਂ ਹਨ; ਹਰੇਕ ਕੋਰ ਲਈ ਤੁਸੀਂ MHz ਵਿੱਚ ਵਰਤੋਂ ਦੇਖ ਸਕਦੇ ਹੋ।

ਵਿਸ਼ਲੇਸ਼ਣ ਕਿਵੇਂ ਕਰੀਏ? ਅਜਿਹਾ ਹੁੰਦਾ ਹੈ ਕਿ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਮਲਟੀ-ਕੋਰ ਆਰਕੀਟੈਕਚਰ ਲਈ ਅਨੁਕੂਲਿਤ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ: ਇਹ ਸਿਰਫ ਇੱਕ ਕੋਰ 100% ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਅਤੇ ਬਾਕੀ ਲੋਡ ਤੋਂ ਬਿਨਾਂ ਵਿਹਲੇ ਹਨ। ਉਦਾਹਰਨ ਲਈ, ਡਿਫੌਲਟ ਬੈਕਅੱਪ ਸੈਟਿੰਗਾਂ ਦੇ ਨਾਲ, MS SQL ਕੇਵਲ ਇੱਕ ਕੋਰ 'ਤੇ ਪ੍ਰਕਿਰਿਆ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ। ਨਤੀਜੇ ਵਜੋਂ, ਡਿਸਕਾਂ ਦੀ ਹੌਲੀ ਗਤੀ ਦੇ ਕਾਰਨ ਬੈਕਅੱਪ ਹੌਲੀ ਨਹੀਂ ਹੁੰਦਾ (ਇਹ ਉਹੀ ਹੈ ਜਿਸ ਬਾਰੇ ਉਪਭੋਗਤਾ ਨੇ ਸ਼ੁਰੂ ਵਿੱਚ ਸ਼ਿਕਾਇਤ ਕੀਤੀ ਸੀ), ਪਰ ਕਿਉਂਕਿ ਪ੍ਰੋਸੈਸਰ ਇਸਦਾ ਮੁਕਾਬਲਾ ਨਹੀਂ ਕਰ ਸਕਦਾ ਹੈ. ਪੈਰਾਮੀਟਰਾਂ ਨੂੰ ਬਦਲ ਕੇ ਸਮੱਸਿਆ ਦਾ ਹੱਲ ਕੀਤਾ ਗਿਆ ਸੀ: ਬੈਕਅੱਪ ਕਈ ਫਾਈਲਾਂ (ਕ੍ਰਮਵਾਰ, ਕਈ ਪ੍ਰਕਿਰਿਆਵਾਂ ਵਿੱਚ) ਵਿੱਚ ਸਮਾਨਾਂਤਰ ਚੱਲਣਾ ਸ਼ੁਰੂ ਹੋਇਆ.

ਕੋਰ 'ਤੇ ਅਸਮਾਨ ਲੋਡ ਦੀ ਇੱਕ ਉਦਾਹਰਨ.

ਇੱਕ ਸਥਿਤੀ ਵੀ ਹੁੰਦੀ ਹੈ (ਜਿਵੇਂ ਕਿ ਉੱਪਰ ਦਿੱਤੇ ਗ੍ਰਾਫ ਵਿੱਚ) ਜਦੋਂ ਕੋਰ ਅਸਮਾਨ ਤੌਰ 'ਤੇ ਲੋਡ ਕੀਤੇ ਜਾਂਦੇ ਹਨ ਅਤੇ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੁਝ 100% ਦੀਆਂ ਚੋਟੀਆਂ ਹੁੰਦੀਆਂ ਹਨ। ਜਿਵੇਂ ਕਿ ਸਿਰਫ਼ ਇੱਕ ਕੋਰ ਲੋਡ ਕਰਨ ਦੇ ਨਾਲ, CPU ਵਰਤੋਂ ਲਈ ਅਲਾਰਮ ਕੰਮ ਨਹੀਂ ਕਰੇਗਾ (ਇਹ ਪੂਰੇ VM ਲਈ ਹੈ), ਪਰ ਪ੍ਰਦਰਸ਼ਨ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਹੋਣਗੀਆਂ।

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

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

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

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

CPU ਤਿਆਰ ਹੈ

ਜੇਕਰ VM ਕੋਰ (vCPU) ਤਿਆਰ ਸਥਿਤੀ ਵਿੱਚ ਹੈ, ਤਾਂ ਇਹ ਉਪਯੋਗੀ ਕੰਮ ਨਹੀਂ ਕਰਦਾ ਹੈ। ਇਹ ਸਥਿਤੀ ਉਦੋਂ ਵਾਪਰਦੀ ਹੈ ਜਦੋਂ ਹਾਈਪਰਵਾਈਜ਼ਰ ਇੱਕ ਮੁਫਤ ਭੌਤਿਕ ਕੋਰ ਨਹੀਂ ਲੱਭਦਾ ਜਿਸ ਲਈ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਦੀ vCPU ਪ੍ਰਕਿਰਿਆ ਨਿਰਧਾਰਤ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ।

ਵਿਸ਼ਲੇਸ਼ਣ ਕਿਵੇਂ ਕਰੀਏ? ਆਮ ਤੌਰ 'ਤੇ, ਜੇਕਰ ਇੱਕ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਦੇ ਕੋਰ 10% ਤੋਂ ਵੱਧ ਸਮੇਂ ਲਈ ਤਿਆਰ ਸਥਿਤੀ ਵਿੱਚ ਹੁੰਦੇ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਪ੍ਰਦਰਸ਼ਨ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਵੇਖੋਗੇ। ਸਿੱਧੇ ਸ਼ਬਦਾਂ ਵਿੱਚ, VM ਭੌਤਿਕ ਸਰੋਤਾਂ ਦੇ ਉਪਲਬਧ ਹੋਣ ਦੀ ਉਡੀਕ ਕਰਨ ਦੇ 10% ਤੋਂ ਵੱਧ ਸਮੇਂ ਵਿੱਚ।

vCenter ਵਿੱਚ ਤੁਸੀਂ CPU ਤਿਆਰ ਨਾਲ ਸਬੰਧਤ 2 ਕਾਊਂਟਰ ਦੇਖ ਸਕਦੇ ਹੋ:

• ਤਿਆਰੀ,
• ਤਿਆਰ

ਦੋਵੇਂ ਕਾਊਂਟਰਾਂ ਦੇ ਮੁੱਲ ਪੂਰੇ VM ਅਤੇ ਵਿਅਕਤੀਗਤ ਕੋਰਾਂ ਲਈ ਦੇਖੇ ਜਾ ਸਕਦੇ ਹਨ।
ਤਿਆਰੀ ਇੱਕ ਪ੍ਰਤੀਸ਼ਤ ਦੇ ਤੌਰ 'ਤੇ ਮੁੱਲ ਨੂੰ ਤੁਰੰਤ ਦਿਖਾਉਂਦਾ ਹੈ, ਪਰ ਸਿਰਫ਼ ਰੀਅਲ-ਟਾਈਮ ਵਿੱਚ (ਆਖਰੀ ਘੰਟੇ ਲਈ ਡੇਟਾ, ਮਾਪ ਅੰਤਰਾਲ 20 ਸਕਿੰਟ)। ਇਸ ਕਾਊਂਟਰ ਦੀ ਵਰਤੋਂ ਸਿਰਫ "ਏੜੀ 'ਤੇ ਗਰਮ" ਸਮੱਸਿਆਵਾਂ ਦੀ ਖੋਜ ਕਰਨ ਲਈ ਕਰਨਾ ਬਿਹਤਰ ਹੈ।

ਤਿਆਰ ਵਿਰੋਧੀ ਮੁੱਲਾਂ ਨੂੰ ਇਤਿਹਾਸਕ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ ਵੀ ਦੇਖਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਇਹ ਪੈਟਰਨ ਸਥਾਪਤ ਕਰਨ ਅਤੇ ਸਮੱਸਿਆ ਦੇ ਡੂੰਘੇ ਵਿਸ਼ਲੇਸ਼ਣ ਲਈ ਲਾਭਦਾਇਕ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਜੇਕਰ ਇੱਕ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਇੱਕ ਨਿਸ਼ਚਿਤ ਸਮੇਂ 'ਤੇ ਪ੍ਰਦਰਸ਼ਨ ਸਮੱਸਿਆਵਾਂ ਦਾ ਅਨੁਭਵ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ CPU ਤਿਆਰ ਮੁੱਲ ਦੇ ਅੰਤਰਾਲਾਂ ਦੀ ਤੁਲਨਾ ਸਰਵਰ ਦੇ ਕੁੱਲ ਲੋਡ ਨਾਲ ਕਰ ਸਕਦੇ ਹੋ ਜਿੱਥੇ ਇਹ VM ਚੱਲ ਰਿਹਾ ਹੈ, ਅਤੇ ਲੋਡ ਨੂੰ ਘਟਾਉਣ ਲਈ ਉਪਾਅ ਕਰ ਸਕਦੇ ਹੋ (ਜੇ ਡੀ.ਆਰ.ਐੱਸ. ਅਸਫਲ ਹੁੰਦਾ ਹੈ).

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

(CPU ਤਿਆਰ ਸਮਾਲਨ ਮੁੱਲ / (ਸਕਿੰਟਾਂ ਵਿੱਚ ਚਾਰਟ ਡਿਫੌਲਟ ਅੱਪਡੇਟ ਅੰਤਰਾਲ * 1000)) * 100 = CPU ਤਿਆਰ %

ਉਦਾਹਰਨ ਲਈ, ਹੇਠਾਂ ਦਿੱਤੇ ਗ੍ਰਾਫ ਵਿੱਚ VM ਲਈ, ਸਮੁੱਚੀ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਲਈ ਪੀਕ ਰੈਡੀ ਵੈਲਯੂ ਇਸ ਤਰ੍ਹਾਂ ਹੋਵੇਗੀ:

ਤਿਆਰ ਪ੍ਰਤੀਸ਼ਤ ਦੀ ਗਣਨਾ ਕਰਦੇ ਸਮੇਂ, ਤੁਹਾਨੂੰ ਦੋ ਨੁਕਤਿਆਂ ਵੱਲ ਧਿਆਨ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ:

• ਪੂਰੇ VM ਲਈ ਤਿਆਰ ਮੁੱਲ ਸਾਰੇ ਕੋਰਾਂ ਵਿੱਚ ਤਿਆਰ ਦਾ ਜੋੜ ਹੈ।
• ਮਾਪ ਅੰਤਰਾਲ। ਰੀਅਲ-ਟਾਈਮ ਲਈ ਇਹ 20 ਸਕਿੰਟ ਹੈ, ਅਤੇ, ਉਦਾਹਰਨ ਲਈ, ਰੋਜ਼ਾਨਾ ਚਾਰਟ 'ਤੇ ਇਹ 300 ਸਕਿੰਟ ਹੈ।

ਸਰਗਰਮ ਸਮੱਸਿਆ-ਨਿਪਟਾਰਾ ਕਰਨ ਦੇ ਨਾਲ, ਇਹ ਸਧਾਰਨ ਬਿੰਦੂ ਆਸਾਨੀ ਨਾਲ ਗੁਆਏ ਜਾ ਸਕਦੇ ਹਨ ਅਤੇ ਗੈਰ-ਮੌਜੂਦ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਕੀਮਤੀ ਸਮਾਂ ਬਰਬਾਦ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਆਉ ਹੇਠਾਂ ਦਿੱਤੇ ਗ੍ਰਾਫ ਦੇ ਡੇਟਾ ਦੇ ਅਧਾਰ ਤੇ ਤਿਆਰ ਦੀ ਗਣਨਾ ਕਰੀਏ। (324474/(20*1000))*100 = 1622% ਪੂਰੇ VM ਲਈ। ਜੇ ਤੁਸੀਂ ਕੋਰਾਂ ਨੂੰ ਦੇਖਦੇ ਹੋ ਤਾਂ ਇਹ ਇੰਨਾ ਡਰਾਉਣਾ ਨਹੀਂ ਹੈ: 1622/64 = 25% ਪ੍ਰਤੀ ਕੋਰ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਕੈਚ ਨੂੰ ਲੱਭਣਾ ਕਾਫ਼ੀ ਆਸਾਨ ਹੈ: ਤਿਆਰ ਮੁੱਲ ਅਵਾਸਤਵਿਕ ਹੈ। ਪਰ ਜੇਕਰ ਅਸੀਂ ਕਈ ਕੋਰਾਂ ਵਾਲੇ ਪੂਰੇ VM ਲਈ 10-20% ਬਾਰੇ ਗੱਲ ਕਰ ਰਹੇ ਹਾਂ, ਤਾਂ ਹਰੇਕ ਕੋਰ ਲਈ ਮੁੱਲ ਆਮ ਸੀਮਾ ਦੇ ਅੰਦਰ ਹੋ ਸਕਦਾ ਹੈ।

ਮੈਨੂੰ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ? ਇੱਕ ਉੱਚ ਰੈਡੀ ਮੁੱਲ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਸਰਵਰ ਕੋਲ ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਦੇ ਆਮ ਸੰਚਾਲਨ ਲਈ ਲੋੜੀਂਦੇ ਪ੍ਰੋਸੈਸਰ ਸਰੋਤ ਨਹੀਂ ਹਨ। ਅਜਿਹੀ ਸਥਿਤੀ ਵਿੱਚ, ਪ੍ਰੋਸੈਸਰ (vCPU:pCPU) ਦੁਆਰਾ ਓਵਰਸਬਸਕ੍ਰਿਪਸ਼ਨ ਨੂੰ ਘਟਾਉਣਾ ਬਾਕੀ ਬਚਦਾ ਹੈ। ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ, ਇਹ ਮੌਜੂਦਾ VMs ਦੇ ਮਾਪਦੰਡਾਂ ਨੂੰ ਘਟਾ ਕੇ ਜਾਂ VMs ਦੇ ਹਿੱਸੇ ਨੂੰ ਦੂਜੇ ਸਰਵਰਾਂ 'ਤੇ ਮਾਈਗਰੇਟ ਕਰਕੇ ਪ੍ਰਾਪਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਸਹਿ-ਸਟਾਪ

ਵਿਸ਼ਲੇਸ਼ਣ ਕਿਵੇਂ ਕਰੀਏ? ਇਹ ਕਾਊਂਟਰ ਸਮਾਲਟ ਕਿਸਮ ਦਾ ਵੀ ਹੈ ਅਤੇ ਇਸ ਨੂੰ ਤਿਆਰ ਵਾਂਗ ਪ੍ਰਤੀਸ਼ਤ ਵਿੱਚ ਬਦਲਿਆ ਜਾਂਦਾ ਹੈ:

(CPU ਕੋ-ਸਟੌਪ ਸਮਾਲਟ ਮੁੱਲ / (ਸਕਿੰਟਾਂ ਵਿੱਚ ਚਾਰਟ ਡਿਫਾਲਟ ਅੱਪਡੇਟ ਅੰਤਰਾਲ * 1000)) * 100 = CPU ਕੋ-ਸਟਾਪ %

ਇੱਥੇ ਤੁਹਾਨੂੰ VM 'ਤੇ ਕੋਰਾਂ ਦੀ ਗਿਣਤੀ ਅਤੇ ਮਾਪ ਦੇ ਅੰਤਰਾਲ 'ਤੇ ਵੀ ਧਿਆਨ ਦੇਣ ਦੀ ਲੋੜ ਹੈ।
ਕੋਸਟੌਪ ਸਥਿਤੀ ਵਿੱਚ, ਕਰਨਲ ਉਪਯੋਗੀ ਕੰਮ ਨਹੀਂ ਕਰਦਾ ਹੈ। ਸਰਵਰ 'ਤੇ VM ਆਕਾਰ ਅਤੇ ਆਮ ਲੋਡ ਦੀ ਸਹੀ ਚੋਣ ਦੇ ਨਾਲ, ਕੋ-ਸਟਾਪ ਕਾਊਂਟਰ ਜ਼ੀਰੋ ਦੇ ਨੇੜੇ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਲੋਡ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਅਸਧਾਰਨ ਹੈ :)

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

ਨਾਲ ਹੀ, ਕੋ-ਸਟਾਪ ਵਧੇਗਾ ਜੇਕਰ ਇੱਕ VM ਦੇ ਐਕਟਿਵ ਕੋਰ ਹਾਈਪਰ-ਟ੍ਰੇਡਿੰਗ ਸਮਰਥਿਤ ਇੱਕ ਭੌਤਿਕ ਸਰਵਰ ਕੋਰ 'ਤੇ ਥਰਿੱਡਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ। ਇਹ ਸਥਿਤੀ ਪੈਦਾ ਹੋ ਸਕਦੀ ਹੈ, ਉਦਾਹਰਨ ਲਈ, ਜੇਕਰ VM ਕੋਲ ਸਰਵਰ 'ਤੇ ਭੌਤਿਕ ਤੌਰ 'ਤੇ ਉਪਲਬਧ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਕੋਰ ਹਨ ਜਿੱਥੇ ਇਹ ਚੱਲ ਰਿਹਾ ਹੈ, ਜਾਂ ਜੇ VM ਲਈ "preferHT" ਸੈਟਿੰਗ ਸਮਰਥਿਤ ਹੈ। ਤੁਸੀਂ ਇਸ ਸੈਟਿੰਗ ਬਾਰੇ ਪੜ੍ਹ ਸਕਦੇ ਹੋ ਇੱਥੇ.

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

ਰਿਜ਼ਰਵ ਵਿੱਚ ਕੋਰ ਨਾ ਜੋੜੋ; ਇਸ ਨਾਲ ਨਾ ਸਿਰਫ਼ VM ਲਈ, ਸਗੋਂ ਸਰਵਰ 'ਤੇ ਇਸਦੇ ਗੁਆਂਢੀਆਂ ਲਈ ਵੀ ਕਾਰਗੁਜ਼ਾਰੀ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਹੋ ਸਕਦੀਆਂ ਹਨ।

ਹੋਰ ਉਪਯੋਗੀ CPU ਮੈਟ੍ਰਿਕਸ

ਚਲਾਓ - ਮਾਪ ਦੀ ਮਿਆਦ ਦੇ ਦੌਰਾਨ ਕਿੰਨਾ ਸਮਾਂ (ms) VCPU RUN ਅਵਸਥਾ ਵਿੱਚ ਸੀ, ਯਾਨੀ ਕਿ ਇਹ ਅਸਲ ਵਿੱਚ ਉਪਯੋਗੀ ਕੰਮ ਕਰ ਰਿਹਾ ਸੀ।

ਨਿਸ਼ਕਿਰਿਆ - ਮਾਪ ਦੀ ਮਿਆਦ ਦੇ ਦੌਰਾਨ ਕਿੰਨਾ ਸਮਾਂ (ms) vCPU ਅਕਿਰਿਆਸ਼ੀਲਤਾ ਦੀ ਸਥਿਤੀ ਵਿੱਚ ਸੀ। ਉੱਚ ਨਿਸ਼ਕਿਰਿਆ ਮੁੱਲ ਕੋਈ ਸਮੱਸਿਆ ਨਹੀਂ ਹਨ, vCPU ਕੋਲ "ਕਰਨ ਲਈ ਕੁਝ ਨਹੀਂ" ਸੀ।

ਉਡੀਕ ਕਰੋ - ਮਾਪ ਦੀ ਮਿਆਦ ਦੇ ਦੌਰਾਨ ਕਿੰਨਾ ਸਮਾਂ (ms) vCPU ਉਡੀਕ ਸਥਿਤੀ ਵਿੱਚ ਸੀ। ਕਿਉਂਕਿ IDLE ਇਸ ਕਾਊਂਟਰ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤਾ ਗਿਆ ਹੈ, ਉੱਚ ਉਡੀਕ ਮੁੱਲ ਵੀ ਕਿਸੇ ਸਮੱਸਿਆ ਦਾ ਸੰਕੇਤ ਨਹੀਂ ਦਿੰਦੇ ਹਨ। ਪਰ ਜੇਕਰ Wait ਵੱਧ ਹੋਣ 'ਤੇ Wait IDLE ਘੱਟ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ VM I/O ਓਪਰੇਸ਼ਨਾਂ ਦੇ ਪੂਰਾ ਹੋਣ ਦੀ ਉਡੀਕ ਕਰ ਰਿਹਾ ਸੀ, ਅਤੇ ਇਹ, ਬਦਲੇ ਵਿੱਚ, ਹਾਰਡ ਡਰਾਈਵ ਜਾਂ VM ਦੇ ਕਿਸੇ ਵੀ ਵਰਚੁਅਲ ਡਿਵਾਈਸ ਦੇ ਪ੍ਰਦਰਸ਼ਨ ਵਿੱਚ ਸਮੱਸਿਆ ਦਾ ਸੰਕੇਤ ਦੇ ਸਕਦਾ ਹੈ।

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

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

ESXTOP

ਜੇਕਰ vCenter ਵਿੱਚ ਪ੍ਰਦਰਸ਼ਨ ਕਾਊਂਟਰ ਇਤਿਹਾਸਕ ਡੇਟਾ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨ ਲਈ ਚੰਗੇ ਹਨ, ਤਾਂ ਸਮੱਸਿਆ ਦਾ ਸੰਚਾਲਨ ਵਿਸ਼ਲੇਸ਼ਣ ESXTOP ਵਿੱਚ ਬਿਹਤਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇੱਥੇ, ਸਾਰੇ ਮੁੱਲ ਤਿਆਰ ਕੀਤੇ ਰੂਪ ਵਿੱਚ ਪੇਸ਼ ਕੀਤੇ ਗਏ ਹਨ (ਕਿਸੇ ਵੀ ਚੀਜ਼ ਦਾ ਅਨੁਵਾਦ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ), ਅਤੇ ਘੱਟੋ ਘੱਟ ਮਾਪ ਦੀ ਮਿਆਦ 2 ਸਕਿੰਟ ਹੈ।
CPU ਲਈ ESXTOP ਸਕਰੀਨ ਨੂੰ "c" ਕੁੰਜੀ ਨਾਲ ਬੁਲਾਇਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ:

ਸਹੂਲਤ ਲਈ, ਤੁਸੀਂ Shift-V ਦਬਾ ਕੇ ਸਿਰਫ਼ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਛੱਡ ਸਕਦੇ ਹੋ।
ਵਿਅਕਤੀਗਤ VM ਕੋਰਾਂ ਲਈ ਮੈਟ੍ਰਿਕਸ ਦੇਖਣ ਲਈ, "e" ਦਬਾਓ ਅਤੇ ਦਿਲਚਸਪੀ ਵਾਲੇ VM ਦਾ GID ਦਾਖਲ ਕਰੋ (ਹੇਠਾਂ ਦਿੱਤੇ ਸਕ੍ਰੀਨਸ਼ਾਟ ਵਿੱਚ 30919):

ਮੈਨੂੰ ਸੰਖੇਪ ਰੂਪ ਵਿੱਚ ਉਹਨਾਂ ਕਾਲਮਾਂ ਵਿੱਚ ਜਾਣ ਦਿਓ ਜੋ ਮੂਲ ਰੂਪ ਵਿੱਚ ਪੇਸ਼ ਕੀਤੇ ਗਏ ਹਨ। "f" ਦਬਾ ਕੇ ਵਾਧੂ ਕਾਲਮ ਸ਼ਾਮਲ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ।

NWLD (ਵਿਸ਼ਵ ਦੀ ਸੰਖਿਆ) - ਸਮੂਹ ਵਿੱਚ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੀ ਗਿਣਤੀ। ਸਮੂਹ ਦਾ ਵਿਸਤਾਰ ਕਰਨ ਅਤੇ ਹਰੇਕ ਪ੍ਰਕਿਰਿਆ ਲਈ ਮੈਟ੍ਰਿਕਸ ਦੇਖਣ ਲਈ (ਉਦਾਹਰਨ ਲਈ, ਮਲਟੀ-ਕੋਰ VM ਵਿੱਚ ਹਰੇਕ ਕੋਰ ਲਈ), “e” ਦਬਾਓ। ਜੇਕਰ ਇੱਕ ਸਮੂਹ ਵਿੱਚ ਇੱਕ ਤੋਂ ਵੱਧ ਪ੍ਰਕਿਰਿਆਵਾਂ ਹਨ, ਤਾਂ ਸਮੂਹ ਲਈ ਮੀਟ੍ਰਿਕ ਮੁੱਲ ਵਿਅਕਤੀਗਤ ਪ੍ਰਕਿਰਿਆਵਾਂ ਲਈ ਮੈਟ੍ਰਿਕਸ ਦੇ ਜੋੜ ਦੇ ਬਰਾਬਰ ਹਨ।

%ਵਰਤਿਆ - ਇੱਕ ਪ੍ਰਕਿਰਿਆ ਜਾਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੇ ਸਮੂਹ ਦੁਆਰਾ ਕਿੰਨੇ ਸਰਵਰ CPU ਚੱਕਰ ਵਰਤੇ ਜਾਂਦੇ ਹਨ।

%ਰਨ - ਮਾਪ ਦੀ ਮਿਆਦ ਦੇ ਦੌਰਾਨ ਕਿੰਨੀ ਦੇਰ ਤੱਕ ਪ੍ਰਕਿਰਿਆ RUN ਅਵਸਥਾ ਵਿੱਚ ਸੀ, ਜਿਵੇਂ ਕਿ ਲਾਭਦਾਇਕ ਕੰਮ ਕੀਤਾ. ਇਹ %USED ਤੋਂ ਵੱਖਰਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਹਾਈਪਰ-ਥ੍ਰੈਡਿੰਗ, ਬਾਰੰਬਾਰਤਾ ਸਕੇਲਿੰਗ ਅਤੇ ਸਿਸਟਮ ਕਾਰਜਾਂ (%SYS) 'ਤੇ ਖਰਚੇ ਗਏ ਸਮੇਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਨਹੀਂ ਰੱਖਦਾ ਹੈ।

%SYS - ਸਿਸਟਮ ਕਾਰਜਾਂ 'ਤੇ ਖਰਚਿਆ ਸਮਾਂ, ਉਦਾਹਰਨ ਲਈ: ਇੰਟਰੱਪਟ ਪ੍ਰੋਸੈਸਿੰਗ, I/O, ਨੈੱਟਵਰਕ ਓਪਰੇਸ਼ਨ, ਆਦਿ। ਜੇਕਰ VM ਕੋਲ ਵੱਡਾ I/O ਹੈ ਤਾਂ ਮੁੱਲ ਉੱਚਾ ਹੋ ਸਕਦਾ ਹੈ।

% OVRLP - ਭੌਤਿਕ ਕੋਰ ਜਿਸ 'ਤੇ VM ਪ੍ਰਕਿਰਿਆ ਚੱਲ ਰਹੀ ਹੈ, ਹੋਰ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੇ ਕੰਮਾਂ 'ਤੇ ਕਿੰਨਾ ਸਮਾਂ ਬਿਤਾਇਆ ਹੈ।

ਇਹ ਮੈਟ੍ਰਿਕਸ ਇੱਕ ਦੂਜੇ ਨਾਲ ਇਸ ਤਰ੍ਹਾਂ ਸੰਬੰਧਿਤ ਹਨ:

%USED = %RUN + %SYS - %OVRLP।

ਆਮ ਤੌਰ 'ਤੇ %USED ਮੀਟ੍ਰਿਕ ਵਧੇਰੇ ਜਾਣਕਾਰੀ ਭਰਪੂਰ ਹੁੰਦਾ ਹੈ।

%ਉਡੀਕ ਕਰੋ - ਮਾਪ ਦੀ ਮਿਆਦ ਦੇ ਦੌਰਾਨ ਕਿੰਨੀ ਦੇਰ ਤੱਕ ਪ੍ਰਕਿਰਿਆ ਉਡੀਕ ਸਥਿਤੀ ਵਿੱਚ ਸੀ। IDLE ਨੂੰ ਸਮਰੱਥ ਬਣਾਉਂਦਾ ਹੈ।

%IDLE - ਮਾਪ ਦੀ ਮਿਆਦ ਦੇ ਦੌਰਾਨ ਕਿੰਨੀ ਦੇਰ ਤੱਕ ਪ੍ਰਕਿਰਿਆ IDLE ਸਥਿਤੀ ਵਿੱਚ ਸੀ।

%SWPWT - ਮਾਪ ਦੀ ਮਿਆਦ ਦੇ ਦੌਰਾਨ ਕਿੰਨੀ ਦੇਰ ਤੱਕ vCPU ਨੇ VMkernel ਸਵੈਪ ਨਾਲ ਇੱਕ ਓਪਰੇਸ਼ਨ ਦੀ ਉਡੀਕ ਕੀਤੀ।

% VMWAIT - ਮਾਪ ਦੀ ਮਿਆਦ ਦੇ ਦੌਰਾਨ vCPU ਇੱਕ ਇਵੈਂਟ ਦੀ ਉਡੀਕ ਕਰਨ ਦੀ ਸਥਿਤੀ ਵਿੱਚ ਕਿੰਨਾ ਸਮਾਂ ਸੀ (ਆਮ ਤੌਰ 'ਤੇ I/O)। vCenter ਵਿੱਚ ਕੋਈ ਸਮਾਨ ਕਾਊਂਟਰ ਨਹੀਂ ਹੈ। ਉੱਚ ਮੁੱਲ VM 'ਤੇ I/O ਨਾਲ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਦਰਸਾਉਂਦੇ ਹਨ।

% WAIT = % VMWAIT + % ਆਈਡਲ + % SWPWT।

ਜੇਕਰ VM VMkernel ਸਵੈਪ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਦਾ ਹੈ, ਤਾਂ ਪ੍ਰਦਰਸ਼ਨ ਸਮੱਸਿਆਵਾਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਦੇ ਸਮੇਂ %VMWAIT ਨੂੰ ਦੇਖਣ ਦੀ ਸਲਾਹ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਮੈਟ੍ਰਿਕ ਉਸ ਸਮੇਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਨਹੀਂ ਰੱਖਦਾ ਜਦੋਂ VM ਕੁਝ ਨਹੀਂ ਕਰ ਰਿਹਾ ਸੀ (%IDLE)।

%RDY - ਮਾਪ ਦੀ ਮਿਆਦ ਦੇ ਦੌਰਾਨ ਪ੍ਰਕਿਰਿਆ ਤਿਆਰ ਸਥਿਤੀ ਵਿੱਚ ਕਿੰਨੀ ਦੇਰ ਸੀ।

%CSTP - ਮਾਪ ਦੀ ਮਿਆਦ ਦੇ ਦੌਰਾਨ ਕਿੰਨੀ ਦੇਰ ਤੱਕ ਪ੍ਰਕਿਰਿਆ ਕੋਸਟੌਪ ਸਥਿਤੀ ਵਿੱਚ ਸੀ।

%MLMTD - ਨਿਰਧਾਰਿਤ ਸਰੋਤ ਸੀਮਾ ਦੇ ਕਾਰਨ ਮਾਪ ਦੀ ਮਿਆਦ ਦੇ ਦੌਰਾਨ ਕਿੰਨਾ ਸਮਾਂ vCPU ਤਿਆਰ ਸਥਿਤੀ ਵਿੱਚ ਸੀ।

% WAIT + % RDY + % CSTP + % RUN = 100% - VM ਕੋਰ ਹਮੇਸ਼ਾ ਇਹਨਾਂ ਚਾਰ ਰਾਜਾਂ ਵਿੱਚੋਂ ਇੱਕ ਵਿੱਚ ਹੁੰਦਾ ਹੈ।

ਹਾਈਪਰਵਾਈਜ਼ਰ 'ਤੇ CPU

vCenter ਕੋਲ ਹਾਈਪਰਵਾਈਜ਼ਰ ਲਈ CPU ਪ੍ਰਦਰਸ਼ਨ ਕਾਊਂਟਰ ਵੀ ਹਨ, ਪਰ ਉਹ ਕੁਝ ਵੀ ਦਿਲਚਸਪ ਨਹੀਂ ਹਨ - ਉਹ ਸਿਰਫ਼ ਸਰਵਰ 'ਤੇ ਸਾਰੇ VM ਲਈ ਕਾਊਂਟਰਾਂ ਦਾ ਜੋੜ ਹਨ।
ਸਰਵਰ 'ਤੇ CPU ਸਥਿਤੀ ਨੂੰ ਦੇਖਣ ਦਾ ਸਭ ਤੋਂ ਸੁਵਿਧਾਜਨਕ ਤਰੀਕਾ ਸੰਖੇਪ ਟੈਬ 'ਤੇ ਹੈ:

ਸਰਵਰ ਲਈ, ਨਾਲ ਹੀ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਲਈ, ਇੱਕ ਮਿਆਰੀ ਅਲਾਰਮ ਹੈ:

ਜਦੋਂ ਸਰਵਰ CPU ਲੋਡ ਵੱਧ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਇਸ 'ਤੇ ਚੱਲ ਰਹੇ VM ਨੂੰ ਪ੍ਰਦਰਸ਼ਨ ਸਮੱਸਿਆਵਾਂ ਦਾ ਅਨੁਭਵ ਕਰਨਾ ਸ਼ੁਰੂ ਹੋ ਜਾਂਦਾ ਹੈ।

ESXTOP ਵਿੱਚ, ਸਰਵਰ CPU ਲੋਡ ਡੇਟਾ ਸਕ੍ਰੀਨ ਦੇ ਸਿਖਰ 'ਤੇ ਪੇਸ਼ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਸਟੈਂਡਰਡ CPU ਲੋਡ ਤੋਂ ਇਲਾਵਾ, ਜੋ ਕਿ ਹਾਈਪਰਵਾਈਜ਼ਰਾਂ ਲਈ ਬਹੁਤ ਜਾਣਕਾਰੀ ਭਰਪੂਰ ਨਹੀਂ ਹੈ, ਇੱਥੇ ਤਿੰਨ ਹੋਰ ਮੈਟ੍ਰਿਕਸ ਹਨ:

ਕੋਰ UTIL(%) - ਭੌਤਿਕ ਸਰਵਰ ਕੋਰ ਲੋਡ ਕਰ ਰਿਹਾ ਹੈ. ਇਹ ਕਾਊਂਟਰ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਮਾਪ ਦੀ ਮਿਆਦ ਦੇ ਦੌਰਾਨ ਕੋਰ ਨੇ ਕਿੰਨਾ ਸਮਾਂ ਕੰਮ ਕੀਤਾ।

PCPU UTIL(%) - ਜੇਕਰ ਹਾਈਪਰ-ਥ੍ਰੈਡਿੰਗ ਸਮਰਥਿਤ ਹੈ, ਤਾਂ ਪ੍ਰਤੀ ਭੌਤਿਕ ਕੋਰ ਦੋ ਥ੍ਰੈਡਸ (PCPU) ਹਨ। ਇਹ ਮੈਟ੍ਰਿਕ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਹਰੇਕ ਥ੍ਰੈਡ ਨੇ ਕੰਮ ਪੂਰਾ ਕਰਨ ਵਿੱਚ ਕਿੰਨਾ ਸਮਾਂ ਲਿਆ।

PCPU ਵਰਤਿਆ(%) - PCPU UTIL(%) ਦੇ ਸਮਾਨ ਹੈ, ਪਰ ਬਾਰੰਬਾਰਤਾ ਸਕੇਲਿੰਗ (ਜਾਂ ਤਾਂ ਊਰਜਾ ਬਚਾਉਣ ਦੇ ਉਦੇਸ਼ਾਂ ਲਈ ਕੋਰ ਬਾਰੰਬਾਰਤਾ ਨੂੰ ਘਟਾਉਣਾ, ਜਾਂ ਟਰਬੋ ਬੂਸਟ ਤਕਨਾਲੋਜੀ ਦੇ ਕਾਰਨ ਕੋਰ ਬਾਰੰਬਾਰਤਾ ਨੂੰ ਵਧਾਉਣਾ) ਅਤੇ ਹਾਈਪਰ-ਥ੍ਰੈਡਿੰਗ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦਾ ਹੈ।

PCPU_USED% = PCPU_UTIL% * ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਕੋਰ ਬਾਰੰਬਾਰਤਾ / ਨਾਮਾਤਰ ਕੋਰ ਬਾਰੰਬਾਰਤਾ।

ਇਸ ਸਕ੍ਰੀਨਸ਼ੌਟ ਵਿੱਚ, ਕੁਝ ਕੋਰਾਂ ਲਈ, ਟਰਬੋ ਬੂਸਟ ਦੇ ਕਾਰਨ, USED ਮੁੱਲ 100% ਤੋਂ ਵੱਧ ਹੈ, ਕਿਉਂਕਿ ਕੋਰ ਬਾਰੰਬਾਰਤਾ ਨਾਮਾਤਰ ਨਾਲੋਂ ਵੱਧ ਹੈ।

ਹਾਈਪਰ-ਥ੍ਰੈਡਿੰਗ ਨੂੰ ਕਿਵੇਂ ਧਿਆਨ ਵਿੱਚ ਰੱਖਿਆ ਜਾਂਦਾ ਹੈ ਇਸ ਬਾਰੇ ਕੁਝ ਸ਼ਬਦ। ਜੇਕਰ ਪ੍ਰਕਿਰਿਆਵਾਂ ਸਰਵਰ ਦੇ ਭੌਤਿਕ ਕੋਰ ਦੇ ਦੋਵਾਂ ਥ੍ਰੈੱਡਾਂ 'ਤੇ 100% ਸਮੇਂ ਨੂੰ ਲਾਗੂ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਜਦੋਂ ਕਿ ਕੋਰ ਨਾਮਾਤਰ ਬਾਰੰਬਾਰਤਾ 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ, ਫਿਰ:

• ਕੋਰ ਲਈ CORE UTIL 100% ਹੋਵੇਗਾ,
• ਦੋਵਾਂ ਥਰਿੱਡਾਂ ਲਈ PCPU UTIL 100% ਹੋਵੇਗਾ,
• ਦੋਵਾਂ ਥ੍ਰੈੱਡਾਂ ਲਈ ਵਰਤੀ ਗਈ PCPU 50% ਹੋਵੇਗੀ।

ਜੇਕਰ ਦੋਵੇਂ ਥ੍ਰੈੱਡ ਮਾਪ ਦੀ ਮਿਆਦ ਦੇ ਦੌਰਾਨ 100% ਸਮਾਂ ਕੰਮ ਨਹੀਂ ਕਰਦੇ ਹਨ, ਤਾਂ ਉਹਨਾਂ ਪੀਰੀਅਡਾਂ ਦੌਰਾਨ ਜਦੋਂ ਥ੍ਰੈੱਡ ਸਮਾਨਾਂਤਰ ਵਿੱਚ ਕੰਮ ਕਰਦੇ ਸਨ, ਤਾਂ ਕੋਰਾਂ ਲਈ ਵਰਤੀ ਗਈ PCPU ਅੱਧੇ ਵਿੱਚ ਵੰਡਿਆ ਜਾਂਦਾ ਹੈ।

ESXTOP ਕੋਲ ਸਰਵਰ CPU ਪਾਵਰ ਖਪਤ ਪੈਰਾਮੀਟਰਾਂ ਵਾਲੀ ਇੱਕ ਸਕ੍ਰੀਨ ਵੀ ਹੈ। ਇੱਥੇ ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ ਕਿ ਕੀ ਸਰਵਰ ਊਰਜਾ ਬਚਾਉਣ ਵਾਲੀਆਂ ਤਕਨੀਕਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ: ਸੀ-ਸਟੇਟਸ ਅਤੇ ਪੀ-ਸਟੇਟਸ। "p" ਕੁੰਜੀ ਨਾਲ ਕਾਲ ਕੀਤੀ ਗਈ:

ਆਮ CPU ਪ੍ਰਦਰਸ਼ਨ ਮੁੱਦੇ

ਅੰਤ ਵਿੱਚ, ਮੈਂ VM CPU ਪ੍ਰਦਰਸ਼ਨ ਨਾਲ ਸਮੱਸਿਆਵਾਂ ਦੇ ਖਾਸ ਕਾਰਨਾਂ 'ਤੇ ਜਾਵਾਂਗਾ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਛੋਟੇ ਸੁਝਾਅ ਦੇਵਾਂਗਾ:

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

ਗਲਤ VM ਆਕਾਰ (ਬਹੁਤ ਜ਼ਿਆਦਾ/ਕੁਝ ਕੋਰ)। ਜੇਕਰ ਤੁਸੀਂ ਕੁਝ ਕੋਰ ਇੰਸਟਾਲ ਕਰਦੇ ਹੋ, ਤਾਂ VM 'ਤੇ ਇੱਕ ਉੱਚ CPU ਲੋਡ ਹੋਵੇਗਾ। ਜੇ ਬਹੁਤ ਕੁਝ ਹੈ, ਤਾਂ ਉੱਚ ਕੋ-ਸਟਾਪ ਨੂੰ ਫੜੋ.

ਸਰਵਰ 'ਤੇ CPU ਦੀ ਵੱਡੀ ਓਵਰਸਬਸਕ੍ਰਿਪਸ਼ਨ। ਜੇਕਰ VM ਕੋਲ ਉੱਚ ਰੈਡੀ ਹੈ, ਤਾਂ CPU ਓਵਰਸਬਸਕ੍ਰਿਪਸ਼ਨ ਘਟਾਓ।

ਵੱਡੇ VM 'ਤੇ ਗਲਤ NUMA ਟੋਪੋਲੋਜੀ। VM (vNUMA) ਦੁਆਰਾ ਦੇਖਿਆ ਗਿਆ NUMA ਟੌਪੌਲੋਜੀ ਸਰਵਰ (pNUMA) ਦੇ NUMA ਟੋਪੋਲੋਜੀ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਸ ਸਮੱਸਿਆ ਦੇ ਨਿਦਾਨ ਅਤੇ ਸੰਭਵ ਹੱਲ ਲਿਖੇ ਗਏ ਹਨ, ਉਦਾਹਰਨ ਲਈ, ਕਿਤਾਬ ਵਿੱਚ "VMware vSphere 6.5 ਹੋਸਟ ਸਰੋਤ ਡੀਪ ਡਾਈਵ". ਜੇ ਤੁਸੀਂ ਡੂੰਘਾਈ ਵਿੱਚ ਨਹੀਂ ਜਾਣਾ ਚਾਹੁੰਦੇ ਹੋ ਅਤੇ ਤੁਹਾਡੇ ਕੋਲ VM 'ਤੇ ਸਥਾਪਤ OS 'ਤੇ ਲਾਇਸੈਂਸ ਪਾਬੰਦੀਆਂ ਨਹੀਂ ਹਨ, ਤਾਂ VM 'ਤੇ ਕਈ ਵਰਚੁਅਲ ਸਾਕਟ ਬਣਾਓ, ਇੱਕ ਸਮੇਂ ਵਿੱਚ ਇੱਕ ਕੋਰ। ਤੁਸੀਂ ਬਹੁਤ ਕੁਝ ਨਹੀਂ ਗੁਆਓਗੇ :)

ਇਹ ਸਭ ਮੇਰੇ ਲਈ CPU ਬਾਰੇ ਹੈ. ਸਵਾਲ ਪੁੱਛੋ. ਅਗਲੇ ਭਾਗ ਵਿੱਚ ਮੈਂ ਰੈਮ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗਾ।

ਉਪਯੋਗੀ ਲਿੰਕhttp://virtual-red-dot.info/vm-cpu-counters-vsphere/
https://kb.vmware.com/kb/1017926
http://www.yellow-bricks.com/2012/07/17/why-is-wait-so-high/
https://communities.vmware.com/docs/DOC-9279
https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/performance/whats-new-vsphere65-perf.pdf
https://pages.rubrik.com/host-resources-deep-dive_request.html

ਸਰੋਤ: www.habr.com