ਵੱਡੇ ਅੱਪਲੋਡਾਂ ਦੌਰਾਨ VPN ਕੱਟ ਜਾਂਦਾ ਹੈ: ਪਹਿਲਾਂ ਕਤਾਰ ਪੜ੍ਹੋ

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

ਹਰ ਰਨ ਵਿੱਚ ਇੱਕ ਵੇਰੀਏਬਲ ਬਦਲੋ ਅਤੇ ਐਂਡਪੁਆਇੰਟ ਸਥਿਰ ਰੱਖੋ।

ਦੁਹਰਾਉਣ ਯੋਗ ਭਾਰ ਤੁਲਨਾ ਬਣਾਓ

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

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

ਆਉਟਪੁੱਟ ਨੂੰ ਸਮਾਂ-ਛਾਪਾਂ ਨਾਲ ਸੰਭਾਲੋ ਤਾਂ ਜੋ ਭਾਰ ਵਾਲੇ ਅਤੇ ਨਿਸ਼ਕਿਰਿਆ ਰਨ ਦੀ ਲਾਈਨ-ਦਰ-ਲਾਈਨ ਤੁਲਨਾ ਹੋ ਸਕੇ।

ਗਤੀ ਨਹੀਂ, ਕਤਾਰ ਪੜ੍ਹੋ

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

ping -c 20 -i 0.2 203.0.113.10
mtr -rwc 20 203.0.113.10
tc -s qdisc show dev eth0
ss -ti dst 203.0.113.10
nstat -az | grep -E 'Retrans|Timeout'

ਭਾਰ ਵਾਲੀ ਦੇਰੀ ਦੇ ਅੰਕਾਂ ਦੀ ਨਿਸ਼ਕਿਰਿਆ ਅੰਕਾਂ ਨਾਲ ਤੁਲਨਾ ਕਰੋ। ਪੈਕਟ ਨੁਕਸਾਨ ਤੋਂ ਬਿਨਾਂ ਦਸਾਂ ਤੋਂ ਵੱਧ ਮਿਲੀਸਕਿੰਟ ਤੋਂ ਸੈਂਕੜਿਆਂ ਤੱਕ ਛਾਲ ਕਤਾਰ ਹੈ; ਸਥਿਰ ਦੇਰੀ ਨਾਲ ਨੁਕਸਾਨ ਕਿਸੇ ਹੋਰ ਖਰਾਬੀ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ।

ਡਿਵਾਈਸ ਅਤੇ ਨਿਯੰਤਰਣ ਮਾਰਗ ਦੀ ਜਾਂਚ ਕਰੋ

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

uptime
mpstat -P ALL 1 3
dmesg | grep -i -E 'thermal|throttl'
journalctl -u openvpn-server@server --since '10 min ago' | tail -20

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

ਇੱਕ ਚੀਜ਼ ਬਦਲੋ ਅਤੇ ਦੁਹਰਾਓ

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

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

ਨਵੀਂ ਬੇਨਤੀ ਅਤੇ ਉਸ ਮੁੜ-ਕੁਨੈਕਸ਼ਨ ਵਿਵਹਾਰ ਦੀ ਜਾਂਚ ਕਰਕੇ ਸਮਾਪਤ ਕਰੋ ਜਿਸ 'ਤੇ ਵਰਤੋਂਕਾਰ ਸੱਚਮੁੱਚ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। ਜਿਸ ਭਾਰ ਨੇ ਸ਼ਿਕਾਇਤ ਪੈਦਾ ਕੀਤੀ, ਉਸ ਹੇਠ ਸਥਿਰਤਾ ਹੀ ਦਰਜ ਕਰਨ ਯੋਗ ਇੱਕੋ-ਇੱਕ ਨਤੀਜਾ ਹੈ।