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

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

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

ਅਸਫਲਤਾ ਵੱਲ ਅਗਵਾਈ ਕਰਨ ਵਾਲੀ ਚੇਨ ਵਿੱਚ ਬੇਲੋੜੀ ਜਟਿਲਤਾ ਨੂੰ ਖਤਮ ਕਰਨਾ

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

ਕਲਾਇੰਟ (ਵੈਜੀਟਾ) ਕਲੱਸਟਰ ਵਿੱਚ ਕਿਸੇ ਵੀ ਨੋਡ ਨਾਲ ਇੱਕ TCP ਕੁਨੈਕਸ਼ਨ ਬਣਾਉਂਦਾ ਹੈ। ਕੁਬਰਨੇਟਸ ਇੱਕ ਓਵਰਲੇ ਨੈੱਟਵਰਕ (ਮੌਜੂਦਾ ਡਾਟਾ ਸੈਂਟਰ ਨੈੱਟਵਰਕ ਦੇ ਸਿਖਰ 'ਤੇ) ਦੇ ਤੌਰ 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ ਜੋ ਵਰਤਦਾ ਹੈ ਆਈ.ਪੀ.ਆਈ.ਪੀ, ਯਾਨੀ, ਇਹ ਡਾਟਾ ਸੈਂਟਰ ਦੇ IP ਪੈਕੇਟਾਂ ਦੇ ਅੰਦਰ ਓਵਰਲੇ ਨੈੱਟਵਰਕ ਦੇ IP ਪੈਕੇਟਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ। ਪਹਿਲੇ ਨੋਡ ਨਾਲ ਜੁੜਨ ਵੇਲੇ, ਨੈੱਟਵਰਕ ਐਡਰੈੱਸ ਅਨੁਵਾਦ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਨੈੱਟਵਰਕ ਐਡਰੈੱਸ ਅਨੁਵਾਦ ਕੁਬਰਨੇਟਸ ਨੋਡ ਦੇ IP ਐਡਰੈੱਸ ਅਤੇ ਪੋਰਟ ਨੂੰ ਓਵਰਲੇ ਨੈੱਟਵਰਕ (ਖਾਸ ਤੌਰ 'ਤੇ, ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਨਾਲ ਪੋਡ) ਵਿੱਚ IP ਐਡਰੈੱਸ ਅਤੇ ਪੋਰਟ ਵਿੱਚ ਅਨੁਵਾਦ ਕਰਨ ਲਈ (NAT) ਸਟੇਟਫੁੱਲ। ਆਉਣ ਵਾਲੇ ਪੈਕੇਟਾਂ ਲਈ, ਕਿਰਿਆਵਾਂ ਦਾ ਉਲਟਾ ਕ੍ਰਮ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇਹ ਬਹੁਤ ਸਾਰੇ ਰਾਜਾਂ ਅਤੇ ਬਹੁਤ ਸਾਰੇ ਤੱਤਾਂ ਦੇ ਨਾਲ ਇੱਕ ਗੁੰਝਲਦਾਰ ਪ੍ਰਣਾਲੀ ਹੈ ਜੋ ਸੇਵਾਵਾਂ ਦੇ ਤੈਨਾਤ ਅਤੇ ਤਬਦੀਲ ਹੋਣ ਦੇ ਨਾਲ ਲਗਾਤਾਰ ਅੱਪਡੇਟ ਅਤੇ ਬਦਲੀਆਂ ਜਾਂਦੀਆਂ ਹਨ।

ਉਪਯੋਗਤਾ tcpdump ਵੈਜੀਟਾ ਟੈਸਟ ਵਿੱਚ TCP ਹੈਂਡਸ਼ੇਕ (SYN ਅਤੇ SYN-ACK ਵਿਚਕਾਰ) ਦੌਰਾਨ ਦੇਰੀ ਹੁੰਦੀ ਹੈ। ਇਸ ਬੇਲੋੜੀ ਗੁੰਝਲਤਾ ਨੂੰ ਦੂਰ ਕਰਨ ਲਈ, ਤੁਸੀਂ ਵਰਤ ਸਕਦੇ ਹੋ hping3 SYN ਪੈਕੇਟਾਂ ਦੇ ਨਾਲ ਸਧਾਰਨ "ਪਿੰਗਾਂ" ਲਈ। ਅਸੀਂ ਜਾਂਚ ਕਰਦੇ ਹਾਂ ਕਿ ਕੀ ਜਵਾਬ ਪੈਕੇਟ ਵਿੱਚ ਦੇਰੀ ਹੋਈ ਹੈ, ਅਤੇ ਫਿਰ ਕੁਨੈਕਸ਼ਨ ਰੀਸੈਟ ਕਰੋ। ਅਸੀਂ ਸਿਰਫ 100ms ਤੋਂ ਵੱਧ ਪੈਕੇਟਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰਨ ਲਈ ਡੇਟਾ ਨੂੰ ਫਿਲਟਰ ਕਰ ਸਕਦੇ ਹਾਂ ਅਤੇ Vegeta ਦੇ ਪੂਰੇ ਨੈੱਟਵਰਕ ਲੇਅਰ 7 ਟੈਸਟ ਨਾਲੋਂ ਸਮੱਸਿਆ ਨੂੰ ਦੁਬਾਰਾ ਪੈਦਾ ਕਰਨ ਦਾ ਆਸਾਨ ਤਰੀਕਾ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹਾਂ। ਇੱਥੇ 30927ms ਅੰਤਰਾਲਾਂ 'ਤੇ ਸੇਵਾ "ਨੋਡ ਪੋਰਟ" (10) 'ਤੇ TCP SYN/SYN-ACK ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ Kubernetes ਨੋਡ "ਪਿੰਗਜ਼" ਹਨ, ਸਭ ਤੋਂ ਹੌਲੀ ਜਵਾਬਾਂ ਦੁਆਰਾ ਫਿਲਟਰ ਕੀਤੇ ਗਏ ਹਨ:

theojulienne@shell ~ $ sudo hping3 172.16.47.27 -S -p 30927 -i u10000 | egrep --line-buffered 'rtt=[0-9]{3}.'

len=46 ip=172.16.47.27 ttl=59 DF id=0 sport=30927 flags=SA seq=1485 win=29200 rtt=127.1 ms

len=46 ip=172.16.47.27 ttl=59 DF id=0 sport=30927 flags=SA seq=1486 win=29200 rtt=117.0 ms

len=46 ip=172.16.47.27 ttl=59 DF id=0 sport=30927 flags=SA seq=1487 win=29200 rtt=106.2 ms

len=46 ip=172.16.47.27 ttl=59 DF id=0 sport=30927 flags=SA seq=1488 win=29200 rtt=104.1 ms

len=46 ip=172.16.47.27 ttl=59 DF id=0 sport=30927 flags=SA seq=5024 win=29200 rtt=109.2 ms

len=46 ip=172.16.47.27 ttl=59 DF id=0 sport=30927 flags=SA seq=5231 win=29200 rtt=109.2 ms

ਤੁਰੰਤ ਪਹਿਲੀ ਨਿਰੀਖਣ ਕਰ ਸਕਦਾ ਹੈ. ਕ੍ਰਮ ਸੰਖਿਆਵਾਂ ਅਤੇ ਸਮੇਂ ਦੁਆਰਾ ਨਿਰਣਾ ਕਰਦੇ ਹੋਏ, ਇਹ ਸਪੱਸ਼ਟ ਹੈ ਕਿ ਇਹ ਇੱਕ ਵਾਰ ਦੀਆਂ ਭੀੜਾਂ ਨਹੀਂ ਹਨ। ਦੇਰੀ ਅਕਸਰ ਇਕੱਠੀ ਹੁੰਦੀ ਹੈ ਅਤੇ ਅੰਤ ਵਿੱਚ ਕਾਰਵਾਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।

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

ਖੁਸ਼ਕਿਸਮਤੀ ਨਾਲ, ਲੀਨਕਸ ਸਿੱਧੇ IP ਓਵਰਲੇ ਲੇਅਰ ਤੱਕ ਪਹੁੰਚ ਕਰਨਾ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ ਜੇਕਰ ਮਸ਼ੀਨ ਉਸੇ ਨੈੱਟਵਰਕ 'ਤੇ ਹੈ:

theojulienne@kube-node-client ~ $ sudo hping3 10.125.20.64 -S -i u10000 | egrep --line-buffered 'rtt=[0-9]{3}.'

len=40 ip=10.125.20.64 ttl=64 DF id=0 sport=0 flags=RA seq=7346 win=0 rtt=127.3 ms

len=40 ip=10.125.20.64 ttl=64 DF id=0 sport=0 flags=RA seq=7347 win=0 rtt=117.3 ms

len=40 ip=10.125.20.64 ttl=64 DF id=0 sport=0 flags=RA seq=7348 win=0 rtt=107.2 ms

ਨਤੀਜਿਆਂ ਦੁਆਰਾ ਨਿਰਣਾ ਕਰਦੇ ਹੋਏ, ਸਮੱਸਿਆ ਅਜੇ ਵੀ ਰਹਿੰਦੀ ਹੈ! ਇਸ ਵਿੱਚ iptables ਅਤੇ NAT ਸ਼ਾਮਲ ਨਹੀਂ ਹਨ। ਇਸ ਲਈ ਸਮੱਸਿਆ TCP ਹੈ? ਆਓ ਦੇਖੀਏ ਕਿ ਇੱਕ ਨਿਯਮਤ ICMP ਪਿੰਗ ਕਿਵੇਂ ਚਲਦੀ ਹੈ:

theojulienne@kube-node-client ~ $ sudo hping3 10.125.20.64 --icmp -i u10000 | egrep --line-buffered 'rtt=[0-9]{3}.'

len=28 ip=10.125.20.64 ttl=64 id=42594 icmp_seq=104 rtt=110.0 ms

len=28 ip=10.125.20.64 ttl=64 id=49448 icmp_seq=4022 rtt=141.3 ms

len=28 ip=10.125.20.64 ttl=64 id=49449 icmp_seq=4023 rtt=131.3 ms

len=28 ip=10.125.20.64 ttl=64 id=49450 icmp_seq=4024 rtt=121.2 ms

len=28 ip=10.125.20.64 ttl=64 id=49451 icmp_seq=4025 rtt=111.2 ms

len=28 ip=10.125.20.64 ttl=64 id=49452 icmp_seq=4026 rtt=101.1 ms

len=28 ip=10.125.20.64 ttl=64 id=50023 icmp_seq=4343 rtt=126.8 ms

len=28 ip=10.125.20.64 ttl=64 id=50024 icmp_seq=4344 rtt=116.8 ms

len=28 ip=10.125.20.64 ttl=64 id=50025 icmp_seq=4345 rtt=106.8 ms

len=28 ip=10.125.20.64 ttl=64 id=59727 icmp_seq=9836 rtt=106.1 ms

ਨਤੀਜੇ ਦਰਸਾਉਂਦੇ ਹਨ ਕਿ ਸਮੱਸਿਆ ਦੂਰ ਨਹੀਂ ਹੋਈ ਹੈ. ਸ਼ਾਇਦ ਇਹ ਇੱਕ ਆਈਪੀਆਈਪੀ ਸੁਰੰਗ ਹੈ? ਆਉ ਟੈਸਟ ਨੂੰ ਹੋਰ ਸਰਲ ਕਰੀਏ:

ਕੀ ਸਾਰੇ ਪੈਕੇਟ ਇਹਨਾਂ ਦੋ ਮੇਜ਼ਬਾਨਾਂ ਵਿਚਕਾਰ ਭੇਜੇ ਗਏ ਹਨ?

theojulienne@kube-node-client ~ $ sudo hping3 172.16.47.27 --icmp -i u10000 | egrep --line-buffered 'rtt=[0-9]{3}.'

len=46 ip=172.16.47.27 ttl=61 id=41127 icmp_seq=12564 rtt=140.9 ms

len=46 ip=172.16.47.27 ttl=61 id=41128 icmp_seq=12565 rtt=130.9 ms

len=46 ip=172.16.47.27 ttl=61 id=41129 icmp_seq=12566 rtt=120.8 ms

len=46 ip=172.16.47.27 ttl=61 id=41130 icmp_seq=12567 rtt=110.8 ms

len=46 ip=172.16.47.27 ttl=61 id=41131 icmp_seq=12568 rtt=100.7 ms

len=46 ip=172.16.47.27 ttl=61 id=9062 icmp_seq=31443 rtt=134.2 ms

len=46 ip=172.16.47.27 ttl=61 id=9063 icmp_seq=31444 rtt=124.2 ms

len=46 ip=172.16.47.27 ttl=61 id=9064 icmp_seq=31445 rtt=114.2 ms

len=46 ip=172.16.47.27 ttl=61 id=9065 icmp_seq=31446 rtt=104.2 ms

ਅਸੀਂ ਇੱਕ ਦੂਜੇ ਨੂੰ ਕੋਈ ਵੀ ਪੈਕੇਟ, ਇੱਥੋਂ ਤੱਕ ਕਿ ਇੱਕ ICMP ਪਿੰਗ ਭੇਜਣ ਵਾਲੇ ਦੋ ਕੁਬਰਨੇਟਸ ਨੋਡਾਂ ਲਈ ਸਥਿਤੀ ਨੂੰ ਸਰਲ ਬਣਾਇਆ ਹੈ। ਉਹ ਅਜੇ ਵੀ ਲੇਟੈਂਸੀ ਦੇਖਦੇ ਹਨ ਜੇਕਰ ਟੀਚਾ ਹੋਸਟ "ਬੁਰਾ" ਹੈ (ਕੁਝ ਦੂਜਿਆਂ ਨਾਲੋਂ ਮਾੜਾ)।

ਹੁਣ ਆਖਰੀ ਸਵਾਲ: ਦੇਰੀ ਸਿਰਫ ਕਿਊਬ-ਨੋਡ ਸਰਵਰਾਂ 'ਤੇ ਕਿਉਂ ਹੁੰਦੀ ਹੈ? ਅਤੇ ਕੀ ਇਹ ਉਦੋਂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਕਿਊਬ-ਨੋਡ ਭੇਜਣ ਵਾਲਾ ਜਾਂ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲਾ ਹੁੰਦਾ ਹੈ? ਖੁਸ਼ਕਿਸਮਤੀ ਨਾਲ, ਕੁਬਰਨੇਟਸ ਦੇ ਬਾਹਰ ਇੱਕ ਹੋਸਟ ਤੋਂ ਇੱਕ ਪੈਕੇਟ ਭੇਜ ਕੇ ਇਹ ਪਤਾ ਲਗਾਉਣਾ ਵੀ ਕਾਫ਼ੀ ਆਸਾਨ ਹੈ, ਪਰ ਉਸੇ "ਜਾਣਿਆ ਬੁਰਾ" ਪ੍ਰਾਪਤਕਰਤਾ ਨਾਲ। ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਵੇਖ ਸਕਦੇ ਹੋ, ਸਮੱਸਿਆ ਅਲੋਪ ਨਹੀਂ ਹੋਈ ਹੈ:

theojulienne@shell ~ $ sudo hping3 172.16.47.27 -p 9876 -S -i u10000 | egrep --line-buffered 'rtt=[0-9]{3}.'

len=46 ip=172.16.47.27 ttl=61 DF id=0 sport=9876 flags=RA seq=312 win=0 rtt=108.5 ms

len=46 ip=172.16.47.27 ttl=61 DF id=0 sport=9876 flags=RA seq=5903 win=0 rtt=119.4 ms

len=46 ip=172.16.47.27 ttl=61 DF id=0 sport=9876 flags=RA seq=6227 win=0 rtt=139.9 ms

len=46 ip=172.16.47.27 ttl=61 DF id=0 sport=9876 flags=RA seq=7929 win=0 rtt=131.2 ms

ਅਸੀਂ ਫਿਰ ਉਹੀ ਬੇਨਤੀਆਂ ਪਿਛਲੇ ਸਰੋਤ ਕਿਊਬ-ਨੋਡ ਤੋਂ ਬਾਹਰੀ ਹੋਸਟ ਨੂੰ ਚਲਾਵਾਂਗੇ (ਜੋ ਕਿ ਸਰੋਤ ਹੋਸਟ ਨੂੰ ਸ਼ਾਮਲ ਨਹੀਂ ਕਰਦਾ ਕਿਉਂਕਿ ਪਿੰਗ ਵਿੱਚ ਇੱਕ RX ਅਤੇ TX ਦੋਵੇਂ ਭਾਗ ਸ਼ਾਮਲ ਹਨ):

theojulienne@kube-node-client ~ $ sudo hping3 172.16.33.44 -p 9876 -S -i u10000 | egrep --line-buffered 'rtt=[0-9]{3}.'
^C
--- 172.16.33.44 hping statistic ---
22352 packets transmitted, 22350 packets received, 1% packet loss
round-trip min/avg/max = 0.2/7.6/1010.6 ms

ਲੇਟੈਂਸੀ ਪੈਕੇਟ ਕੈਪਚਰ ਦੀ ਜਾਂਚ ਕਰਕੇ, ਅਸੀਂ ਕੁਝ ਵਾਧੂ ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤ ਕੀਤੀ। ਖਾਸ ਤੌਰ 'ਤੇ, ਕਿ ਭੇਜਣ ਵਾਲਾ (ਹੇਠਾਂ) ਇਹ ਸਮਾਂ ਸਮਾਪਤ ਦੇਖਦਾ ਹੈ, ਪਰ ਪ੍ਰਾਪਤਕਰਤਾ (ਉੱਪਰ) ਨਹੀਂ ਦੇਖਦਾ - ਡੈਲਟਾ ਕਾਲਮ (ਸਕਿੰਟਾਂ ਵਿੱਚ):

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

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

ਇਕ ਹੋਰ ਨਵਾਂ ਨਿਰੀਖਣ: ਇਸ ਮਿਆਦ ਦੇ ਦੌਰਾਨ ਅਸੀਂ ਦੋ ਮੇਜ਼ਬਾਨਾਂ ਵਿਚਕਾਰ ਸਾਰੇ ਸੰਚਾਰਾਂ 'ਤੇ ICMP ਦੇਰੀ ਦੇਖਦੇ ਹਾਂ, ਪਰ TCP ਅਜਿਹਾ ਨਹੀਂ ਕਰਦਾ। ਇਹ ਸਾਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਕਾਰਨ ਸੰਭਾਵਤ ਤੌਰ 'ਤੇ RX ਕਤਾਰ ਹੈਸ਼ਿੰਗ ਨਾਲ ਸਬੰਧਤ ਹੈ: ਭੀੜ ਲਗਭਗ ਨਿਸ਼ਚਿਤ ਤੌਰ 'ਤੇ RX ਪੈਕੇਟਾਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਹੈ, ਜਵਾਬ ਭੇਜਣ ਵਿੱਚ ਨਹੀਂ।

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

ਲੀਨਕਸ ਕਰਨਲ ਵਿੱਚ ਪੈਕੇਟ ਪ੍ਰੋਸੈਸਿੰਗ ਨੂੰ ਸਮਝਣਾ

ਇਹ ਸਮਝਣ ਲਈ ਕਿ ਕੁਝ ਕਿਊਬ-ਨੋਡ ਸਰਵਰਾਂ 'ਤੇ ਰਿਸੀਵਰ 'ਤੇ ਸਮੱਸਿਆ ਕਿਉਂ ਆਉਂਦੀ ਹੈ, ਆਓ ਦੇਖੀਏ ਕਿ ਲੀਨਕਸ ਕਰਨਲ ਪੈਕੇਟਾਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਿਵੇਂ ਕਰਦਾ ਹੈ।

ਸਭ ਤੋਂ ਸਰਲ ਪਰੰਪਰਾਗਤ ਲਾਗੂਕਰਨ 'ਤੇ ਵਾਪਸ ਜਾਣਾ, ਨੈੱਟਵਰਕ ਕਾਰਡ ਪੈਕੇਟ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ ਅਤੇ ਭੇਜਦਾ ਹੈ ਵਿਘਨ ਲੀਨਕਸ ਕਰਨਲ ਹੈ, ਜੋ ਕਿ ਇੱਕ ਪੈਕੇਜ ਹੈ, ਜੋ ਕਿ ਕਾਰਵਾਈ ਕਰਨ ਦੀ ਲੋੜ ਹੈ. ਕਰਨਲ ਦੂਜੇ ਕੰਮ ਨੂੰ ਰੋਕਦਾ ਹੈ, ਇੰਟਰੱਪਟ ਹੈਂਡਲਰ ਲਈ ਸੰਦਰਭ ਬਦਲਦਾ ਹੈ, ਪੈਕੇਟ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਮੌਜੂਦਾ ਕੰਮਾਂ 'ਤੇ ਵਾਪਸ ਆਉਂਦਾ ਹੈ।

ਇਹ ਸੰਦਰਭ ਸਵਿਚਿੰਗ ਹੌਲੀ ਹੈ: 10 ਦੇ ਦਹਾਕੇ ਵਿੱਚ 90Mbps ਨੈੱਟਵਰਕ ਕਾਰਡਾਂ 'ਤੇ ਲੇਟੈਂਸੀ ਧਿਆਨ ਦੇਣ ਯੋਗ ਨਹੀਂ ਸੀ, ਪਰ 10 ਮਿਲੀਅਨ ਪੈਕੇਟ ਪ੍ਰਤੀ ਸਕਿੰਟ ਦੇ ਵੱਧ ਤੋਂ ਵੱਧ ਥ੍ਰਰੂਪੁਟ ਵਾਲੇ ਆਧੁਨਿਕ 15G ਕਾਰਡਾਂ 'ਤੇ, ਇੱਕ ਛੋਟੇ ਅੱਠ-ਕੋਰ ਸਰਵਰ ਦੇ ਹਰੇਕ ਕੋਰ ਨੂੰ ਲੱਖਾਂ ਵਿੱਚ ਵਿਘਨ ਪਾਇਆ ਜਾ ਸਕਦਾ ਹੈ। ਪ੍ਰਤੀ ਸਕਿੰਟ ਵਾਰ.

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

ਇਹ ਬਹੁਤ ਤੇਜ਼ ਹੈ, ਪਰ ਇੱਕ ਵੱਖਰੀ ਸਮੱਸਿਆ ਦਾ ਕਾਰਨ ਬਣਦਾ ਹੈ। ਜੇ ਬਹੁਤ ਸਾਰੇ ਪੈਕੇਟ ਹਨ, ਤਾਂ ਸਾਰਾ ਸਮਾਂ ਨੈਟਵਰਕ ਕਾਰਡ ਤੋਂ ਪੈਕੇਟਾਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਨ ਵਿੱਚ ਖਰਚਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਉਪਭੋਗਤਾ ਸਪੇਸ ਪ੍ਰਕਿਰਿਆਵਾਂ ਕੋਲ ਇਹਨਾਂ ਕਤਾਰਾਂ ਨੂੰ ਅਸਲ ਵਿੱਚ ਖਾਲੀ ਕਰਨ ਲਈ ਸਮਾਂ ਨਹੀਂ ਹੁੰਦਾ (ਟੀਸੀਪੀ ਕਨੈਕਸ਼ਨਾਂ ਤੋਂ ਪੜ੍ਹਨਾ, ਆਦਿ)। ਆਖਰਕਾਰ ਕਤਾਰਾਂ ਭਰ ਜਾਂਦੀਆਂ ਹਨ ਅਤੇ ਅਸੀਂ ਪੈਕੇਟ ਸੁੱਟਣੇ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦੇ ਹਾਂ। ਸੰਤੁਲਨ ਲੱਭਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਵਿੱਚ, ਕਰਨਲ softirq ਸੰਦਰਭ ਵਿੱਚ ਸੰਸਾਧਿਤ ਪੈਕੇਟਾਂ ਦੀ ਵੱਧ ਤੋਂ ਵੱਧ ਸੰਖਿਆ ਲਈ ਇੱਕ ਬਜਟ ਸੈੱਟ ਕਰਦਾ ਹੈ। ਇੱਕ ਵਾਰ ਜਦੋਂ ਇਹ ਬਜਟ ਵੱਧ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇੱਕ ਵੱਖਰਾ ਧਾਗਾ ਜਾਗ ਜਾਂਦਾ ਹੈ ksoftirqd (ਤੁਸੀਂ ਉਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨੂੰ ਵੇਖੋਗੇ ps ਪ੍ਰਤੀ ਕੋਰ) ਜੋ ਇਹਨਾਂ ਸਾਫਟਿਰਕ ਨੂੰ ਸਧਾਰਣ ਸਿਸਕੈਲ/ਇੰਟਰੱਪਟ ਮਾਰਗ ਤੋਂ ਬਾਹਰ ਹੈਂਡਲ ਕਰਦਾ ਹੈ। ਇਹ ਥਰਿੱਡ ਮਿਆਰੀ ਪ੍ਰਕਿਰਿਆ ਸ਼ਡਿਊਲਰ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਤਹਿ ਕੀਤਾ ਗਿਆ ਹੈ, ਜੋ ਕਿ ਸਰੋਤਾਂ ਨੂੰ ਨਿਰਪੱਖ ਢੰਗ ਨਾਲ ਵੰਡਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ।

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

ਪ੍ਰੋਸੈਸਿੰਗ ਨੂੰ ਕੋਰ ਜਾਂ ਵਿਧੀ ਤੱਕ ਸੰਕੁਚਿਤ ਕਰਨਾ

Softirq ਦੇਰੀ ਹੁਣ ਲਈ ਸਿਰਫ ਇੱਕ ਅਨੁਮਾਨ ਹੈ. ਪਰ ਇਹ ਸਮਝਦਾਰ ਹੈ, ਅਤੇ ਅਸੀਂ ਜਾਣਦੇ ਹਾਂ ਕਿ ਅਸੀਂ ਕੁਝ ਅਜਿਹਾ ਹੀ ਦੇਖ ਰਹੇ ਹਾਂ। ਇਸ ਲਈ ਅਗਲਾ ਕਦਮ ਇਸ ਸਿਧਾਂਤ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨਾ ਹੈ। ਅਤੇ ਜੇਕਰ ਇਸਦੀ ਪੁਸ਼ਟੀ ਹੋ ​​ਜਾਂਦੀ ਹੈ, ਤਾਂ ਦੇਰੀ ਦਾ ਕਾਰਨ ਲੱਭੋ.

ਆਉ ਸਾਡੇ ਹੌਲੀ ਪੈਕੇਟ ਤੇ ਵਾਪਸ ਆਓ:

len=46 ip=172.16.53.32 ttl=61 id=29573 icmp_seq=1953 rtt=99.3 ms

len=46 ip=172.16.53.32 ttl=61 id=29574 icmp_seq=1954 rtt=89.3 ms

len=46 ip=172.16.53.32 ttl=61 id=29575 icmp_seq=1955 rtt=79.2 ms

len=46 ip=172.16.53.32 ttl=61 id=29576 icmp_seq=1956 rtt=69.1 ms

len=46 ip=172.16.53.32 ttl=61 id=29577 icmp_seq=1957 rtt=59.1 ms

len=46 ip=172.16.53.32 ttl=61 id=29790 icmp_seq=2070 rtt=75.7 ms

len=46 ip=172.16.53.32 ttl=61 id=29791 icmp_seq=2071 rtt=65.6 ms

len=46 ip=172.16.53.32 ttl=61 id=29792 icmp_seq=2072 rtt=55.5 ms

ਜਿਵੇਂ ਕਿ ਪਹਿਲਾਂ ਚਰਚਾ ਕੀਤੀ ਗਈ ਹੈ, ਇਹ ICMP ਪੈਕੇਟ ਇੱਕ ਸਿੰਗਲ RX NIC ਕਤਾਰ ਵਿੱਚ ਹੈਸ਼ ਕੀਤੇ ਜਾਂਦੇ ਹਨ ਅਤੇ ਇੱਕ ਸਿੰਗਲ CPU ਕੋਰ ਦੁਆਰਾ ਸੰਸਾਧਿਤ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ਜੇਕਰ ਅਸੀਂ ਇਹ ਸਮਝਣਾ ਚਾਹੁੰਦੇ ਹਾਂ ਕਿ ਲੀਨਕਸ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ, ਤਾਂ ਇਹ ਜਾਣਨਾ ਲਾਭਦਾਇਕ ਹੈ ਕਿ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਟਰੈਕ ਕਰਨ ਲਈ ਕਿੱਥੇ (ਕਿਸ CPU ਕੋਰ 'ਤੇ) ਅਤੇ ਕਿਵੇਂ (softirq, ksoftirqd) ਇਹਨਾਂ ਪੈਕੇਜਾਂ ਨੂੰ ਪ੍ਰੋਸੈਸ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

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

ਇੱਥੇ ਯੋਜਨਾ ਸਧਾਰਨ ਹੈ: ਅਸੀਂ ਜਾਣਦੇ ਹਾਂ ਕਿ ਕਰਨਲ ਇਹਨਾਂ ICMP ਪਿੰਗਾਂ ਨੂੰ ਪ੍ਰੋਸੈਸ ਕਰਦਾ ਹੈ, ਇਸਲਈ ਅਸੀਂ ਕਰਨਲ ਫੰਕਸ਼ਨ ਤੇ ਇੱਕ ਹੁੱਕ ਲਗਾਵਾਂਗੇ icmp_echo, ਜੋ ਇੱਕ ਆਉਣ ਵਾਲੇ ICMP ਈਕੋ ਬੇਨਤੀ ਪੈਕੇਟ ਨੂੰ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ ਅਤੇ ਇੱਕ ICMP ਈਕੋ ਜਵਾਬ ਭੇਜਣਾ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ। ਅਸੀਂ icmp_seq ਨੰਬਰ ਨੂੰ ਵਧਾ ਕੇ ਇੱਕ ਪੈਕੇਟ ਦੀ ਪਛਾਣ ਕਰ ਸਕਦੇ ਹਾਂ, ਜੋ ਦਿਖਾਉਂਦਾ ਹੈ hping3 ਉੱਚਾ.

ਕੋਡ bcc ਸਕ੍ਰਿਪਟ ਗੁੰਝਲਦਾਰ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ, ਪਰ ਇਹ ਇੰਨਾ ਡਰਾਉਣਾ ਨਹੀਂ ਹੈ ਜਿੰਨਾ ਇਹ ਲੱਗਦਾ ਹੈ। ਫੰਕਸ਼ਨ icmp_echo ਪ੍ਰਸਾਰਿਤ ਕਰਦਾ ਹੈ struct sk_buff *skb: ਇਹ "ਈਕੋ ਬੇਨਤੀ" ਵਾਲਾ ਇੱਕ ਪੈਕੇਟ ਹੈ। ਅਸੀਂ ਇਸਨੂੰ ਟਰੈਕ ਕਰ ਸਕਦੇ ਹਾਂ, ਕ੍ਰਮ ਨੂੰ ਬਾਹਰ ਕੱਢ ਸਕਦੇ ਹਾਂ echo.sequence (ਜੋ ਕਿ ਨਾਲ ਤੁਲਨਾ ਕਰਦਾ ਹੈ icmp_seq hping3 ਦੁਆਰਾ выше), ਅਤੇ ਇਸਨੂੰ ਉਪਭੋਗਤਾ ਸਪੇਸ ਵਿੱਚ ਭੇਜੋ। ਮੌਜੂਦਾ ਪ੍ਰਕਿਰਿਆ ਦੇ ਨਾਮ/ਆਈਡੀ ਨੂੰ ਕੈਪਚਰ ਕਰਨਾ ਵੀ ਸੁਵਿਧਾਜਨਕ ਹੈ। ਹੇਠਾਂ ਉਹ ਨਤੀਜੇ ਹਨ ਜੋ ਅਸੀਂ ਸਿੱਧੇ ਦੇਖਦੇ ਹਾਂ ਜਦੋਂ ਕਰਨਲ ਪੈਕੇਟਾਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਦਾ ਹੈ:

TGID PID ਪ੍ਰਕਿਰਿਆ ਦਾ ਨਾਮ ICMP_SEQ 0 0 ਸਵੈਪਰ/11 770 0 0 ਸਵੈਪਰ/11 771 0 0 ਸਵੈਪਰ/11 772 0 0 ਸਵੈਪਰ/11 773 0 0 ਸਵੈਪਰ/11 774 20041 20086 ਸਵੈਪਰ/775 0 0me 11me 776me 0 0 11 777 ਸਵੈਪਰ/0 0 11 778 4512 ਸਵੈਪਰ/4542 779 XNUMX XNUMX ਬੁਲਾਰੇ-ਰਿਪੋਰਟ-ਸ XNUMX

ਇੱਥੇ ਇਹ ਨੋਟ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਸੰਦਰਭ ਵਿੱਚ softirq ਸਿਸਟਮ ਕਾਲਾਂ ਕਰਨ ਵਾਲੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ "ਪ੍ਰਕਿਰਿਆਵਾਂ" ਵਜੋਂ ਦਿਖਾਈ ਦੇਣਗੀਆਂ ਜਦੋਂ ਅਸਲ ਵਿੱਚ ਇਹ ਕਰਨਲ ਹੈ ਜੋ ਕਰਨਲ ਦੇ ਸੰਦਰਭ ਵਿੱਚ ਪੈਕੇਟਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਪ੍ਰੋਸੈਸ ਕਰਦਾ ਹੈ।

ਇਸ ਟੂਲ ਨਾਲ ਅਸੀਂ ਖਾਸ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਖਾਸ ਪੈਕੇਜਾਂ ਨਾਲ ਜੋੜ ਸਕਦੇ ਹਾਂ ਜੋ ਦੀ ਦੇਰੀ ਦਿਖਾਉਂਦੇ ਹਨ hping3. ਆਓ ਇਸਨੂੰ ਸਧਾਰਨ ਕਰੀਏ grep ਕੁਝ ਮੁੱਲਾਂ ਲਈ ਇਸ ਕੈਪਚਰ 'ਤੇ icmp_seq. ਉਪਰੋਕਤ icmp_seq ਮੁੱਲਾਂ ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਪੈਕਟਾਂ ਨੂੰ ਉਹਨਾਂ ਦੇ RTT ਦੇ ਨਾਲ ਨੋਟ ਕੀਤਾ ਗਿਆ ਸੀ ਜੋ ਅਸੀਂ ਉੱਪਰ ਦੇਖਿਆ ਹੈ (ਬਰੈਕਟਸ ਵਿੱਚ ਉਹਨਾਂ ਪੈਕੇਟਾਂ ਲਈ ਸੰਭਾਵਿਤ RTT ਮੁੱਲ ਹਨ ਜੋ ਅਸੀਂ 50 ms ਤੋਂ ਘੱਟ RTT ਮੁੱਲਾਂ ਕਾਰਨ ਫਿਲਟਰ ਕੀਤੇ ਹਨ):

TGID PID ਪ੍ਰਕਿਰਿਆ ਦਾ ਨਾਮ ICMP_SEQ ** RTT -- 10137 10436 cadvisor 1951 10137 10436 cadvisor 1952 76 76 ksoftirqd/11 1953 ** 99ms 76 d76 d11 softq/k1954 soft ** ir qd/89 76 ** 76ms 11 1955 ksoftirqd/ 79 76 ** 76ms 11 1956 ksoftirqd/69 76 ** 76ms 11 1957 ksoftirqd/59 76 ** (76ms) 11 1958 ksoftirqd/49 76 ** (76ms) 11 ksoftirqd/1959 39 ** (76ms) 76 ksoftirqd/11 ms** (1960 ksoftirqd/29 ms) 76 ksoft irqd/ 76 11 ** (1961ms) 19 76 ksoftirqd/76 11 ** (1962ms) -- 9 10137 cadvisor 10436 2068 10137 cadvisor 10436 2069 76 ksoftirqd/76 11 softirqd ** qd/2070 75 ** 76ms 76 11 ksoftirqd/ 2071 65 ** 76ms 76 11 ksoftirqd/2072 55 ** (76ms) 76 11 ksoftirqd/2073 45 ** (76ms) 76 11 ksoftirqd/2074 35 ** (76 ਸੌਫਟਵੇਅਰ ** (76ms) ms ) 11 2075 ksoftirqd/25 76 ** (76ms)

ਨਤੀਜੇ ਸਾਨੂੰ ਕਈ ਗੱਲਾਂ ਦੱਸਦੇ ਹਨ। ਪਹਿਲਾਂ, ਇਹ ਸਾਰੇ ਪੈਕੇਜ ਸੰਦਰਭ ਦੁਆਰਾ ਸੰਸਾਧਿਤ ਕੀਤੇ ਜਾਂਦੇ ਹਨ ksoftirqd/11. ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਮਸ਼ੀਨਾਂ ਦੇ ਇਸ ਖਾਸ ਜੋੜੇ ਲਈ, ICMP ਪੈਕੇਟ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੇ ਸਿਰੇ 'ਤੇ ਕੋਰ 11 ਲਈ ਹੈਸ਼ ਕੀਤੇ ਗਏ ਸਨ। ਅਸੀਂ ਇਹ ਵੀ ਦੇਖਦੇ ਹਾਂ ਕਿ ਜਦੋਂ ਵੀ ਜਾਮ ਹੁੰਦਾ ਹੈ, ਉੱਥੇ ਪੈਕੇਟ ਹੁੰਦੇ ਹਨ ਜੋ ਸਿਸਟਮ ਕਾਲ ਦੇ ਸੰਦਰਭ ਵਿੱਚ ਪ੍ਰੋਸੈਸ ਕੀਤੇ ਜਾਂਦੇ ਹਨ cadvisor. ਫਿਰ ksoftirqd ਕੰਮ ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ ਅਤੇ ਇਕੱਠੀ ਹੋਈ ਕਤਾਰ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਦਾ ਹੈ: ਪੈਕਟਾਂ ਦੀ ਬਿਲਕੁਲ ਸੰਖਿਆ ਜੋ ਬਾਅਦ ਵਿੱਚ ਇਕੱਠੇ ਹੋਏ ਹਨ cadvisor.

ਤੱਥ ਇਹ ਹੈ ਕਿ ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਤੁਰੰਤ ਕੰਮ ਕਰਦਾ ਹੈ cadvisor, ਸਮੱਸਿਆ ਵਿੱਚ ਉਸਦੀ ਸ਼ਮੂਲੀਅਤ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ। ਵਿਅੰਗਾਤਮਕ ਤੌਰ 'ਤੇ, ਉਦੇਸ਼ cadvisor - "ਚਲ ਰਹੇ ਕੰਟੇਨਰਾਂ ਦੀਆਂ ਸਰੋਤਾਂ ਦੀ ਵਰਤੋਂ ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰੋ" ਨਾ ਕਿ ਇਸ ਪ੍ਰਦਰਸ਼ਨ ਦੇ ਮੁੱਦੇ ਨੂੰ ਪੈਦਾ ਕਰਨ ਦੀ ਬਜਾਏ।

ਜਿਵੇਂ ਕਿ ਕੰਟੇਨਰਾਂ ਦੇ ਦੂਜੇ ਪਹਿਲੂਆਂ ਦੇ ਨਾਲ, ਇਹ ਸਾਰੇ ਬਹੁਤ ਹੀ ਉੱਨਤ ਟੂਲ ਹਨ ਅਤੇ ਕੁਝ ਅਣਕਿਆਸੇ ਹਾਲਾਤਾਂ ਵਿੱਚ ਪ੍ਰਦਰਸ਼ਨ ਸਮੱਸਿਆਵਾਂ ਦਾ ਅਨੁਭਵ ਕਰਨ ਦੀ ਉਮੀਦ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ।

ਕੈਡਵਾਈਜ਼ਰ ਕੀ ਕਰਦਾ ਹੈ ਜੋ ਪੈਕੇਟ ਕਤਾਰ ਨੂੰ ਹੌਲੀ ਕਰਦਾ ਹੈ?

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

ਇਹ ਇੱਕ ਥਿਊਰੀ ਹੈ, ਪਰ ਇਸਨੂੰ ਕਿਵੇਂ ਪਰਖਿਆ ਜਾਵੇ? ਅਸੀਂ ਇਸ ਪ੍ਰਕਿਰਿਆ ਦੌਰਾਨ CPU ਕੋਰ ਨੂੰ ਟਰੇਸ ਕਰ ਸਕਦੇ ਹਾਂ, ਉਹ ਬਿੰਦੂ ਲੱਭੋ ਜਿੱਥੇ ਪੈਕੇਟਾਂ ਦੀ ਗਿਣਤੀ ਬਜਟ ਤੋਂ ਵੱਧ ਜਾਂਦੀ ਹੈ ਅਤੇ ksoftirqd ਕਿਹਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਇਹ ਦੇਖਣ ਲਈ ਥੋੜ੍ਹਾ ਅੱਗੇ ਪਿੱਛੇ ਦੇਖੋ ਕਿ ਉਸ ਬਿੰਦੂ ਤੋਂ ਠੀਕ ਪਹਿਲਾਂ CPU ਕੋਰ 'ਤੇ ਕੀ ਚੱਲ ਰਿਹਾ ਸੀ। . ਇਹ ਹਰ ਕੁਝ ਮਿਲੀਸਕਿੰਟ ਵਿੱਚ CPU ਦਾ ਐਕਸ-ਰੇ ਕਰਨ ਵਰਗਾ ਹੈ। ਇਹ ਕੁਝ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦੇਵੇਗਾ:

ਸੁਵਿਧਾਜਨਕ ਤੌਰ 'ਤੇ, ਇਹ ਸਭ ਮੌਜੂਦਾ ਸਾਧਨਾਂ ਨਾਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ. ਉਦਾਹਰਣ ਲਈ, perf ਰਿਕਾਰਡ ਇੱਕ ਦਿੱਤੇ CPU ਕੋਰ ਨੂੰ ਇੱਕ ਨਿਸ਼ਚਿਤ ਬਾਰੰਬਾਰਤਾ 'ਤੇ ਚੈੱਕ ਕਰਦਾ ਹੈ ਅਤੇ ਚੱਲ ਰਹੇ ਸਿਸਟਮ ਲਈ ਕਾਲਾਂ ਦਾ ਸਮਾਂ-ਸਾਰਣੀ ਤਿਆਰ ਕਰ ਸਕਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਯੂਜ਼ਰ ਸਪੇਸ ਅਤੇ ਲੀਨਕਸ ਕਰਨਲ ਦੋਵੇਂ ਸ਼ਾਮਲ ਹਨ। ਤੁਸੀਂ ਇਸ ਰਿਕਾਰਡ ਨੂੰ ਲੈ ਸਕਦੇ ਹੋ ਅਤੇ ਪ੍ਰੋਗਰਾਮ ਦੇ ਇੱਕ ਛੋਟੇ ਫੋਰਕ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇਸਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰ ਸਕਦੇ ਹੋ ਫਲੇਮਗ੍ਰਾਫ ਬ੍ਰੈਂਡਨ ਗ੍ਰੇਗ ਤੋਂ, ਜੋ ਸਟੈਕ ਟਰੇਸ ਦੇ ਕ੍ਰਮ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖਦਾ ਹੈ। ਅਸੀਂ ਹਰ 1 ms ਵਿੱਚ ਸਿੰਗਲ-ਲਾਈਨ ਸਟੈਕ ਟਰੇਸ ਨੂੰ ਬਚਾ ਸਕਦੇ ਹਾਂ, ਅਤੇ ਫਿਰ ਟਰੇਸ ਹਿੱਟ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ 100 ਮਿਲੀਸਕਿੰਟ ਇੱਕ ਨਮੂਨੇ ਨੂੰ ਹਾਈਲਾਈਟ ਅਤੇ ਸੁਰੱਖਿਅਤ ਕਰ ਸਕਦੇ ਹਾਂ। ksoftirqd:

# record 999 times a second, or every 1ms with some offset so not to align exactly with timers
sudo perf record -C 11 -g -F 999
# take that recording and make a simpler stack trace.
sudo perf script 2>/dev/null | ./FlameGraph/stackcollapse-perf-ordered.pl | grep ksoftir -B 100

ਇੱਥੇ ਨਤੀਜੇ ਹਨ:

(сотни следов, которые выглядят похожими)

cadvisor;[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];entry_SYSCALL_64_after_swapgs;do_syscall_64;sys_read;vfs_read;seq_read;memcg_stat_show;mem_cgroup_nr_lru_pages;mem_cgroup_node_nr_lru_pages cadvisor;[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];entry_SYSCALL_64_after_swapgs;do_syscall_64;sys_read;vfs_read;seq_read;memcg_stat_show;mem_cgroup_nr_lru_pages;mem_cgroup_node_nr_lru_pages cadvisor;[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];entry_SYSCALL_64_after_swapgs;do_syscall_64;sys_read;vfs_read;seq_read;memcg_stat_show;mem_cgroup_iter cadvisor;[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];entry_SYSCALL_64_after_swapgs;do_syscall_64;sys_read;vfs_read;seq_read;memcg_stat_show;mem_cgroup_nr_lru_pages;mem_cgroup_node_nr_lru_pages cadvisor;[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];entry_SYSCALL_64_after_swapgs;do_syscall_64;sys_read;vfs_read;seq_read;memcg_stat_show;mem_cgroup_nr_lru_pages;mem_cgroup_node_nr_lru_pages ksoftirqd/11;ret_from_fork;kthread;kthread;smpboot_thread_fn;smpboot_thread_fn;run_ksoftirqd;__do_softirq;net_rx_action;ixgbe_poll;ixgbe_clean_rx_irq;napi_gro_receive;netif_receive_skb_internal;inet_gro_receive;bond_handle_frame;__netif_receive_skb_core;ip_rcv_finish;ip_rcv;ip_forward_finish;ip_forward;ip_finish_output;nf_iterate;ip_output;ip_finish_output2;__dev_queue_xmit;dev_hard_start_xmit;ipip_tunnel_xmit;ip_tunnel_xmit;iptunnel_xmit;ip_local_out;dst_output;__ip_local_out;nf_hook_slow;nf_iterate;nf_conntrack_in;generic_packet;ipt_do_table;set_match_v4;ip_set_test;hash_net4_kadt;ixgbe_xmit_frame_ring;swiotlb_dma_mapping_error;hash_net4_test ksoftirqd/11;ret_from_fork;kthread;kthread;smpboot_thread_fn;smpboot_thread_fn;run_ksoftirqd;__do_softirq;net_rx_action;gro_cell_poll;napi_gro_receive;netif_receive_skb_internal;inet_gro_receive;__netif_receive_skb_core;ip_rcv_finish;ip_rcv;ip_forward_finish;ip_forward;ip_finish_output;nf_iterate;ip_output;ip_finish_output2;__dev_queue_xmit;dev_hard_start_xmit;dev_queue_xmit_nit;packet_rcv;tpacket_rcv;sch_direct_xmit;validate_xmit_skb_list;validate_xmit_skb;netif_skb_features;ixgbe_xmit_frame_ring;swiotlb_dma_mapping_error;__dev_queue_xmit;dev_hard_start_xmit;__bpf_prog_run;__bpf_prog_run

ਇੱਥੇ ਬਹੁਤ ਸਾਰੀਆਂ ਚੀਜ਼ਾਂ ਹਨ, ਪਰ ਮੁੱਖ ਗੱਲ ਇਹ ਹੈ ਕਿ ਅਸੀਂ "ksoftirqd ਤੋਂ ਪਹਿਲਾਂ ਕੈਡਵਾਈਜ਼ਰ" ਪੈਟਰਨ ਲੱਭਦੇ ਹਾਂ ਜੋ ਅਸੀਂ ਪਹਿਲਾਂ ICMP ਟਰੇਸਰ ਵਿੱਚ ਦੇਖਿਆ ਸੀ। ਇਸਦਾ ਮਤਲੱਬ ਕੀ ਹੈ?

ਹਰੇਕ ਲਾਈਨ ਸਮੇਂ ਦੇ ਇੱਕ ਨਿਸ਼ਚਿਤ ਬਿੰਦੂ ਤੇ ਇੱਕ CPU ਟਰੇਸ ਹੁੰਦੀ ਹੈ। ਇੱਕ ਲਾਈਨ 'ਤੇ ਸਟੈਕ ਡਾਊਨ ਹਰੇਕ ਕਾਲ ਨੂੰ ਇੱਕ ਸੈਮੀਕੋਲਨ ਦੁਆਰਾ ਵੱਖ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਲਾਈਨਾਂ ਦੇ ਮੱਧ ਵਿੱਚ ਅਸੀਂ ਦੇਖਦੇ ਹਾਂ ਕਿ ਸਿਸਕੈਲ ਨੂੰ ਬੁਲਾਇਆ ਜਾ ਰਿਹਾ ਹੈ: read(): .... ;do_syscall_64;sys_read; .... ਇਸ ਲਈ ਕੈਡਵਾਈਜ਼ਰ ਸਿਸਟਮ ਕਾਲ 'ਤੇ ਬਹੁਤ ਸਮਾਂ ਬਿਤਾਉਂਦਾ ਹੈ read()ਫੰਕਸ਼ਨ ਨਾਲ ਸਬੰਧਤ mem_cgroup_* (ਕਾਲ ਸਟੈਕ ਦਾ ਸਿਖਰ/ਲਾਈਨ ਦਾ ਅੰਤ)।

ਕਾਲ ਟਰੇਸ ਵਿੱਚ ਇਹ ਦੇਖਣਾ ਅਸੁਵਿਧਾਜਨਕ ਹੈ ਕਿ ਅਸਲ ਵਿੱਚ ਕੀ ਪੜ੍ਹਿਆ ਜਾ ਰਿਹਾ ਹੈ, ਇਸ ਲਈ ਚਲੋ strace ਅਤੇ ਆਓ ਦੇਖੀਏ ਕਿ ਕੈਡਵਾਈਜ਼ਰ ਕੀ ਕਰਦਾ ਹੈ ਅਤੇ 100 ms ਤੋਂ ਵੱਧ ਲੰਬੇ ਸਿਸਟਮ ਕਾਲਾਂ ਨੂੰ ਲੱਭਦਾ ਹੈ:

theojulienne@kube-node-bad ~ $ sudo strace -p 10137 -T -ff 2>&1 | egrep '<0.[1-9]'
[pid 10436] <... futex resumed> ) = 0 <0.156784>
[pid 10432] <... futex resumed> ) = 0 <0.258285>
[pid 10137] <... futex resumed> ) = 0 <0.678382>
[pid 10384] <... futex resumed> ) = 0 <0.762328>
[pid 10436] <... read resumed> "cache 154234880nrss 507904nrss_h"..., 4096) = 658 <0.179438>
[pid 10384] <... futex resumed> ) = 0 <0.104614>
[pid 10436] <... futex resumed> ) = 0 <0.175936>
[pid 10436] <... read resumed> "cache 0nrss 0nrss_huge 0nmapped_"..., 4096) = 577 <0.228091>
[pid 10427] <... read resumed> "cache 0nrss 0nrss_huge 0nmapped_"..., 4096) = 577 <0.207334>
[pid 10411] <... epoll_ctl resumed> ) = 0 <0.118113>
[pid 10382] <... pselect6 resumed> ) = 0 (Timeout) <0.117717>
[pid 10436] <... read resumed> "cache 154234880nrss 507904nrss_h"..., 4096) = 660 <0.159891>
[pid 10417] <... futex resumed> ) = 0 <0.917495>
[pid 10436] <... futex resumed> ) = 0 <0.208172>
[pid 10417] <... futex resumed> ) = 0 <0.190763>
[pid 10417] <... read resumed> "cache 0nrss 0nrss_huge 0nmapped_"..., 4096) = 576 <0.154442>

ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਉਮੀਦ ਕਰ ਸਕਦੇ ਹੋ, ਅਸੀਂ ਇੱਥੇ ਹੌਲੀ ਕਾਲਾਂ ਦੇਖਦੇ ਹਾਂ read(). ਰੀਡ ਓਪਰੇਸ਼ਨ ਅਤੇ ਸੰਦਰਭ ਦੀ ਸਮੱਗਰੀ ਤੋਂ mem_cgroup ਇਹ ਸਪੱਸ਼ਟ ਹੈ ਕਿ ਇਹ ਚੁਣੌਤੀਆਂ read() ਫਾਇਲ ਨੂੰ ਵੇਖੋ memory.stat, ਜੋ ਮੈਮੋਰੀ ਵਰਤੋਂ ਅਤੇ cgroup ਸੀਮਾਵਾਂ (ਡੌਕਰ ਦੀ ਸਰੋਤ ਆਈਸੋਲੇਸ਼ਨ ਤਕਨਾਲੋਜੀ) ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ। ਕੈਡਵਾਈਜ਼ਰ ਟੂਲ ਕੰਟੇਨਰਾਂ ਲਈ ਸਰੋਤ ਵਰਤੋਂ ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਇਸ ਫਾਈਲ ਦੀ ਪੁੱਛਗਿੱਛ ਕਰਦਾ ਹੈ। ਚਲੋ ਜਾਂਚ ਕਰੀਏ ਕਿ ਕੀ ਇਹ ਕਰਨਲ ਜਾਂ ਕੈਡਵਾਈਜ਼ਰ ਕੁਝ ਅਚਾਨਕ ਕਰ ਰਿਹਾ ਹੈ:

theojulienne@kube-node-bad ~ $ time cat /sys/fs/cgroup/memory/memory.stat >/dev/null

real 0m0.153s
user 0m0.000s
sys 0m0.152s
theojulienne@kube-node-bad ~ $

ਹੁਣ ਅਸੀਂ ਬੱਗ ਨੂੰ ਦੁਬਾਰਾ ਤਿਆਰ ਕਰ ਸਕਦੇ ਹਾਂ ਅਤੇ ਸਮਝ ਸਕਦੇ ਹਾਂ ਕਿ ਲੀਨਕਸ ਕਰਨਲ ਇੱਕ ਪੈਥੋਲੋਜੀ ਦਾ ਸਾਹਮਣਾ ਕਰ ਰਿਹਾ ਹੈ।

ਰੀਡ ਓਪਰੇਸ਼ਨ ਇੰਨਾ ਹੌਲੀ ਕਿਉਂ ਹੈ?

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

ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ cgroups ਨਾਮ-ਸਪੇਸ (ਕੰਟੇਨਰ) ਦੇ ਅੰਦਰ ਮੈਮੋਰੀ ਵਰਤੋਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹਨ। ਜਦੋਂ ਇਸ cgroup ਵਿੱਚ ਸਾਰੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਬੰਦ ਹੋ ਜਾਂਦੀਆਂ ਹਨ, Docker ਮੈਮੋਰੀ cgroup ਨੂੰ ਜਾਰੀ ਕਰਦਾ ਹੈ। ਹਾਲਾਂਕਿ, "ਮੈਮੋਰੀ" ਕੇਵਲ ਪ੍ਰਕਿਰਿਆ ਮੈਮੋਰੀ ਨਹੀਂ ਹੈ. ਹਾਲਾਂਕਿ ਪ੍ਰੋਸੈਸ ਮੈਮੋਰੀ ਹੁਣ ਖੁਦ ਨਹੀਂ ਵਰਤੀ ਗਈ ਹੈ, ਇਹ ਜਾਪਦਾ ਹੈ ਕਿ ਕਰਨਲ ਅਜੇ ਵੀ ਕੈਸ਼ ਕੀਤੀਆਂ ਸਮੱਗਰੀਆਂ, ਜਿਵੇਂ ਕਿ ਡੈਂਟਰੀਜ਼ ਅਤੇ ਇਨੋਡਸ (ਡਾਇਰੈਕਟਰੀ ਅਤੇ ਫਾਈਲ ਮੈਟਾਡੇਟਾ), ਜੋ ਕਿ ਮੈਮੋਰੀ cgroup ਵਿੱਚ ਕੈਸ਼ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ। ਸਮੱਸਿਆ ਦੇ ਵਰਣਨ ਤੋਂ:

zombie cgroups: cgroups ਜਿਨ੍ਹਾਂ ਦੀ ਕੋਈ ਪ੍ਰਕਿਰਿਆ ਨਹੀਂ ਹੈ ਅਤੇ ਮਿਟਾਏ ਗਏ ਹਨ, ਪਰ ਅਜੇ ਵੀ ਮੈਮੋਰੀ ਨਿਰਧਾਰਤ ਕੀਤੀ ਗਈ ਹੈ (ਮੇਰੇ ਕੇਸ ਵਿੱਚ, ਡੈਂਟਰੀ ਕੈਸ਼ ਤੋਂ, ਪਰ ਇਹ ਪੇਜ ਕੈਸ਼ ਜਾਂ tmpfs ਤੋਂ ਵੀ ਨਿਰਧਾਰਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ)।

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

ਪ੍ਰਦਰਸ਼ਨ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ, ਉਹਨਾਂ ਨੇ ਪ੍ਰਦਰਸ਼ਨ ਲਈ ਮੈਮੋਰੀ ਦੀ ਬਲੀ ਦਿੱਤੀ: ਕੁਝ ਕੈਸ਼ ਮੈਮੋਰੀ ਨੂੰ ਪਿੱਛੇ ਛੱਡ ਕੇ ਸ਼ੁਰੂਆਤੀ ਸਫਾਈ ਨੂੰ ਤੇਜ਼ ਕਰਨਾ। ਇਹ ਠੀਕ ਹੈ। ਜਦੋਂ ਕਰਨਲ ਕੈਸ਼ਡ ਮੈਮੋਰੀ ਦੀ ਆਖਰੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਤਾਂ cgroup ਨੂੰ ਅੰਤ ਵਿੱਚ ਸਾਫ਼ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਇਸਲਈ ਇਸਨੂੰ "ਲੀਕ" ਨਹੀਂ ਕਿਹਾ ਜਾ ਸਕਦਾ ਹੈ। ਬਦਕਿਸਮਤੀ ਨਾਲ, ਖੋਜ ਵਿਧੀ ਦੇ ਖਾਸ ਲਾਗੂਕਰਨ memory.stat ਇਸ ਕਰਨਲ ਸੰਸਕਰਣ (4.9) ਵਿੱਚ, ਸਾਡੇ ਸਰਵਰਾਂ 'ਤੇ ਵੱਡੀ ਮਾਤਰਾ ਵਿੱਚ ਮੈਮੋਰੀ ਦੇ ਨਾਲ, ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਨਵੀਨਤਮ ਕੈਸ਼ ਕੀਤੇ ਡੇਟਾ ਨੂੰ ਬਹਾਲ ਕਰਨ ਅਤੇ cgroup zombies ਨੂੰ ਸਾਫ਼ ਕਰਨ ਵਿੱਚ ਬਹੁਤ ਜ਼ਿਆਦਾ ਸਮਾਂ ਲੱਗਦਾ ਹੈ।

ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਸਾਡੇ ਕੁਝ ਨੋਡਾਂ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ cgroup zombies ਸਨ ਕਿ ਪੜ੍ਹਨ ਅਤੇ ਲੇਟੈਂਸੀ ਇੱਕ ਸਕਿੰਟ ਤੋਂ ਵੱਧ ਗਈ ਸੀ।

ਕੈਡਵਾਈਜ਼ਰ ਸਮੱਸਿਆ ਦਾ ਹੱਲ ਪੂਰੇ ਸਿਸਟਮ ਵਿੱਚ ਡੈਂਟਰੀ/ਇਨੋਡਜ਼ ਕੈਚਾਂ ਨੂੰ ਤੁਰੰਤ ਮੁਕਤ ਕਰਨਾ ਹੈ, ਜੋ ਕਿ ਹੋਸਟ 'ਤੇ ਰੀਡ ਲੇਟੈਂਸੀ ਦੇ ਨਾਲ-ਨਾਲ ਨੈੱਟਵਰਕ ਲੇਟੈਂਸੀ ਨੂੰ ਤੁਰੰਤ ਖਤਮ ਕਰ ਦਿੰਦਾ ਹੈ, ਕਿਉਂਕਿ ਕੈਸ਼ ਕਲੀਅਰ ਕਰਨ ਨਾਲ ਕੈਸ਼ ਕੀਤੇ ਜ਼ੋਂਬੀ ਸੀਗਰੁੱਪ ਪੰਨਿਆਂ ਨੂੰ ਚਾਲੂ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਵੀ ਮੁਕਤ ਕਰਦਾ ਹੈ। ਇਹ ਕੋਈ ਹੱਲ ਨਹੀਂ ਹੈ, ਪਰ ਇਹ ਸਮੱਸਿਆ ਦੇ ਕਾਰਨ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ.

ਇਹ ਪਤਾ ਚਲਿਆ ਕਿ ਨਵੇਂ ਕਰਨਲ ਸੰਸਕਰਣਾਂ (4.19+) ਵਿੱਚ ਕਾਲ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਵਿੱਚ ਸੁਧਾਰ ਕੀਤਾ ਗਿਆ ਸੀ memory.stat, ਇਸ ਲਈ ਇਸ ਕਰਨਲ 'ਤੇ ਜਾਣ ਨਾਲ ਸਮੱਸਿਆ ਹੱਲ ਹੋ ਗਈ ਹੈ। ਇਸ ਦੇ ਨਾਲ ਹੀ, ਸਾਡੇ ਕੋਲ ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰਾਂ ਵਿੱਚ ਸਮੱਸਿਆ ਵਾਲੇ ਨੋਡਾਂ ਦਾ ਪਤਾ ਲਗਾਉਣ, ਉਹਨਾਂ ਨੂੰ ਸ਼ਾਨਦਾਰ ਢੰਗ ਨਾਲ ਕੱਢਣ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਰੀਬੂਟ ਕਰਨ ਲਈ ਟੂਲ ਸਨ। ਅਸੀਂ ਸਾਰੇ ਕਲੱਸਟਰਾਂ ਨੂੰ ਕੰਬ ਕੀਤਾ, ਕਾਫ਼ੀ ਉੱਚੀ ਲੇਟੈਂਸੀ ਵਾਲੇ ਨੋਡ ਲੱਭੇ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਰੀਬੂਟ ਕੀਤਾ। ਇਸ ਨੇ ਸਾਨੂੰ ਬਾਕੀ ਸਰਵਰਾਂ 'ਤੇ OS ਨੂੰ ਅੱਪਡੇਟ ਕਰਨ ਦਾ ਸਮਾਂ ਦਿੱਤਾ।

ਸੰਖੇਪ ਵਿੱਚ

ਕਿਉਂਕਿ ਇਸ ਬੱਗ ਨੇ ਸੈਂਕੜੇ ਮਿਲੀਸਕਿੰਟਾਂ ਲਈ RX NIC ਕਤਾਰ ਪ੍ਰੋਸੈਸਿੰਗ ਨੂੰ ਰੋਕ ਦਿੱਤਾ, ਇਸ ਨਾਲ ਇੱਕੋ ਸਮੇਂ ਛੋਟੇ ਕਨੈਕਸ਼ਨਾਂ ਅਤੇ ਮੱਧ-ਕੁਨੈਕਸ਼ਨ ਲੇਟੈਂਸੀ, ਜਿਵੇਂ ਕਿ MySQL ਬੇਨਤੀਆਂ ਅਤੇ ਜਵਾਬ ਪੈਕੇਟਾਂ ਵਿਚਕਾਰ ਉੱਚ ਲੇਟੈਂਸੀ ਦਾ ਕਾਰਨ ਬਣਿਆ।

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

ਸਰੋਤ: www.habr.com