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

ਤਿੰਨ ਸੀਮਾਵਾਂ, ਇੱਕ ਸਾਰਣੀ, ਤਿੰਨ ਸੁਧਾਰ

LimitReading during a transferFirst move
Single threadone core near 100%, siblings idlespread flows across workers
Aggregate CPUevery core busy, load average climbscapacity, or less work per byte
Path or providerlow CPU, retransmits or steal time highMTU, loss, host contention

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

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

ਫਸੇ ਥ੍ਰੈਡ ਨੂੰ ਰੁੱਝੇ ਹੋਸਟ ਤੋਂ ਵੱਖ ਕਰੋ

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

mpstat -P ALL 1 5

ਰੁੱਝੇ ਕੋਰ ਨੂੰ ਇੱਕ ਪ੍ਰੋਸੈਸ ਨਾਲ, ਫਿਰ ਥ੍ਰੈਡ ਨਾਲ ਜੋੜੋ। ਹੇਠਾਂ ਦਿੱਤਾ ਫਾਲੋ-ਅੱਪ ਰਨ ਮਾਪੇ ਅਤੇ ਬੱਚੇ ਥ੍ਰੈਡ ਨੂੰ ਇਕੱਠੇ ਰੱਖਦਾ ਹੈ, ਜੋ ਉਦੋਂ ਮਹੱਤਵਪੂਰਨ ਹੈ ਜਦੋਂ ਡੀਮਨ ਹਰ ਕਨੈਕਸ਼ਨ ਲਈ ਫੋਰਕ ਕਰਦਾ ਹੈ:

pidstat -u -t -p $(pgrep -f 'openvpn|wireguard|ipsec') 1 10

ਕਰਨਲ ਕ੍ਰਿਪਟੋ ਕਦੇ ਵੀ ਯੂਜ਼ਰਸਪੇਸ ਪ੍ਰੋਸੈਸ ਕਾਊਂਟਰ ਵਿੱਚ ਨਹੀਂ ਦਿਖਦਾ। ਥ੍ਰੈਡਾਂ ਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਸੈਂਪਲ ਕਰੋ ਅਤੇ ਉਸ ਨਜ਼ਰ ਦੀ ਪ੍ਰੋਸੈਸ ਲੇਖਾਕਾਰੀ ਨਾਲ ਤੁਲਨਾ ਕਰੋ:

top -H -b -n 1 | head -20

ਸਾਕਟ ਕਾਊਂਟਰ ਸਭ ਤੋਂ ਆਖ਼ਰ ਵਿੱਚ ਪੜ੍ਹੋ, ਕਿਉਂਕਿ ਉਹੀ ਤੈਅ ਕਰਦੇ ਹਨ ਕਿ ਵਧੇਰੇ CPU ਬਿਲਕੁਲ ਮਦਦ ਕਰੇਗਾ ਜਾਂ ਨਹੀਂ। CPU ਸਥਿਰ ਹੁੰਦਿਆਂ ਰੀਟ੍ਰਾਂਸਮਿਟ ਵਧਣਾ ਪ੍ਰੋਸੈਸਰ ਦੀ ਸਮੱਸਿਆ ਨਹੀਂ ਹੈ। ਸੈਂਪਲ ਕਰਦਿਆਂ ਟ੍ਰਾਂਸਫਰ ਚਾਲੂ ਰੱਖੋ, ਨਹੀਂ ਤਾਂ ਸੰਖਿਆਵਾਂ ਖਾਲੀ ਮਸ਼ੀਨ ਦਾ ਵਰਣਨ ਕਰਨਗੀਆਂ:

ss -ti | grep -E 'retrans|cwnd|rtt'

ਨਿਯੰਤਰਿਤ ਟ੍ਰਾਂਸਫਰ, ਦੋ ਵਾਰ ਚਲਾਇਆ

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

ਕਈ ਸਮਾਨਾਂਤਰ ਫਲੋ ਨਾਲ ਰਨ ਨੂੰ ਦੁਹਰਾਓ। ਫਲੋ ਵਿੱਚ ਵਾਧਾ ਪ੍ਰਤੀ-ਫਲੋ ਵਿੰਡੋ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ; ਇੱਕ ਕੋਰ ਫਸਿਆ ਹੋਣ 'ਤੇ ਵੀ ਸਮਤਲ ਰਹਿਣਾ ਪ੍ਰੋਸੈਸਿੰਗ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ।

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

ਹਾਰਡਵੇਅਰ ਖਰੀਦਣ ਤੋਂ ਪਹਿਲਾਂ ਰਾਹ ਨੂੰ ਬਾਹਰ ਰੱਖੋ

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

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

ਇੱਕ ਬਦਲਾਅ, ਇੱਕ ਮਾਪ

ਸਬੂਤ ਜਿਸ ਪਰਿਕਲਪਨਾ ਦਾ ਸਮਰਥਨ ਕਰਦੇ ਹਨ ਉਹ ਚੁਣੋ, ਫਿਰ ਠੀਕ ਇੱਕ ਸਮਰਥਿਤ ਸੈਟਿੰਗ ਬਦਲੋ: ਵਰਕਰ ਗਿਣਤੀ, ਦਸਤਾਵੇਜ਼ੀ ਆਫਲੋਡ ਵਿਕਲਪ, ਜਾਂ ਇੰਸਟੈਂਸ ਦਾ ਆਕਾਰ। OpenVPN ਪ੍ਰੋਸੈਸਿੰਗ ਅਤੇ ਆਵਾਜਾਈ ਵਿਚਕਾਰ ਉਸੇ ਵੰਡ ਬਾਰੇ ਪ੍ਰਦਰਸ਼ਨ ਸਮੱਸਿਆ ਨਿਵਾਰਣ ਗਾਈਡ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦਾ ਹੈ: OpenVPN ਪ੍ਰਦਰਸ਼ਨ ਸਮੱਸਿਆ ਨਿਵਾਰਣ।

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

ਗ੍ਰਾਫ਼ ਵਧੀਆ ਦਿਖਾਉਣ ਲਈ ਪ੍ਰਮਾਣਿਕਤਾ ਜਾਂ ਸਾਈਫਰ ਸੂਟ ਕਮਜ਼ੋਰ ਨਾ ਕਰੋ। ਜੇ CPU ਅਜੇ ਵੀ ਲੱਛਣ ਦਾ ਪਿੱਛਾ ਨਹੀਂ ਕਰ ਰਿਹਾ, ਤਾਂ ਅੰਦਾਜ਼ੇ 'ਤੇ ਅੱਪਗ੍ਰੇਡ ਕਰਨ ਦੀ ਬਜਾਏ ਰਾਹ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਜਾਂਚ ਵੱਲ ਵਾਪਸ ਜਾਓ।

ਸੰਬੰਧਿਤ ਲੇਖ