বছর দুয়েক আগে কুবারনেটস ইতিমধ্যে আলোচনা করা হয়েছে অফিসিয়াল গিটহাব ব্লগে। তারপর থেকে, এটি পরিষেবাগুলি স্থাপনের জন্য আদর্শ প্রযুক্তি হয়ে উঠেছে। Kubernetes এখন অভ্যন্তরীণ এবং পাবলিক পরিষেবাগুলির একটি উল্লেখযোগ্য অংশ পরিচালনা করে। যেহেতু আমাদের ক্লাস্টারগুলি বেড়েছে এবং কর্মক্ষমতা প্রয়োজনীয়তা আরও কঠোর হয়ে উঠেছে, আমরা লক্ষ্য করতে শুরু করেছি যে Kubernetes-এর কিছু পরিষেবা বিক্ষিপ্তভাবে লেটেন্সি অনুভব করছে যা অ্যাপ্লিকেশনের লোড দ্বারা ব্যাখ্যা করা যায় না।

মূলত, অ্যাপ্লিকেশনগুলি 100ms বা তার বেশি পর্যন্ত র্যান্ডম নেটওয়ার্ক লেটেন্সি অনুভব করে, যার ফলে টাইমআউট বা পুনরায় চেষ্টা করা হয়। পরিষেবাগুলি 100ms এর চেয়ে অনেক দ্রুত অনুরোধগুলির প্রতিক্রিয়া জানাতে সক্ষম হবে বলে আশা করা হয়েছিল৷ কিন্তু এটি অসম্ভব যদি সংযোগ নিজেই এত সময় নেয়। আলাদাভাবে, আমরা খুব দ্রুত MySQL প্রশ্নগুলি লক্ষ্য করেছি যেগুলি মিলিসেকেন্ডে নেওয়া উচিত, এবং MySQL মিলিসেকেন্ডে সম্পূর্ণ করেছে, কিন্তু অনুরোধকারী অ্যাপ্লিকেশনের দৃষ্টিকোণ থেকে, প্রতিক্রিয়া 100 ms বা তার বেশি সময় নিয়েছে৷

এটি অবিলম্বে স্পষ্ট হয়ে গেল যে সমস্যাটি শুধুমাত্র একটি Kubernetes নোডের সাথে সংযোগ করার সময় ঘটেছে, এমনকি যদি কুবারনেটসের বাইরে থেকে কল আসে। সমস্যাটি পুনরুত্পাদন করার সবচেয়ে সহজ উপায় হল একটি পরীক্ষা Vegeta, যা যেকোনো অভ্যন্তরীণ হোস্ট থেকে চলে, একটি নির্দিষ্ট পোর্টে Kubernetes পরিষেবা পরীক্ষা করে এবং বিক্ষিপ্তভাবে উচ্চ লেটেন্সি নিবন্ধন করে। এই প্রবন্ধে, আমরা দেখব কিভাবে আমরা এই সমস্যার কারণ খুঁজে বের করতে পেরেছি।

শৃঙ্খলে অপ্রয়োজনীয় জটিলতা দূর করা যা ব্যর্থতার দিকে নিয়ে যায়

একই উদাহরণ পুনরুত্পাদন করে, আমরা সমস্যার ফোকাস সংকীর্ণ করতে এবং জটিলতার অপ্রয়োজনীয় স্তরগুলি সরাতে চেয়েছিলাম। প্রাথমিকভাবে, ভেজিটা এবং কুবারনেটস শুঁটির মধ্যে প্রবাহে অনেক উপাদান ছিল। একটি গভীর নেটওয়ার্ক সমস্যা শনাক্ত করার জন্য, আপনাকে সেগুলির কয়েকটিকে বাতিল করতে হবে৷

ক্লায়েন্ট (ভেজিটা) ক্লাস্টারের যেকোনো নোডের সাথে একটি TCP সংযোগ তৈরি করে। Kubernetes একটি ওভারলে নেটওয়ার্ক হিসাবে কাজ করে (বিদ্যমান ডেটা সেন্টার নেটওয়ার্কের উপরে) যা ব্যবহার করে আইপিআইপি, অর্থাৎ, এটি ডেটা সেন্টারের আইপি প্যাকেটের ভিতরে ওভারলে নেটওয়ার্কের আইপি প্যাকেটগুলিকে এনক্যাপসুলেট করে। প্রথম নোডের সাথে সংযোগ করার সময়, নেটওয়ার্ক ঠিকানা অনুবাদ সঞ্চালিত হয় নেটওয়ার্ক ঠিকানা অনুবাদ (NAT) ওভারলে নেটওয়ার্কে (বিশেষ করে, অ্যাপ্লিকেশন সহ পড) আইপি ঠিকানা এবং পোর্টে Kubernetes নোডের IP ঠিকানা এবং পোর্ট অনুবাদ করার জন্য রাষ্ট্রীয়। ইনকামিং প্যাকেটের জন্য, কর্মের বিপরীত ক্রম সঞ্চালিত হয়। এটি একটি জটিল সিস্টেম যেখানে অনেকগুলি রাষ্ট্র এবং অনেক উপাদান রয়েছে যা ক্রমাগত আপডেট করা হয় এবং পরিবর্তিত হয় যখন পরিষেবাগুলি স্থাপন এবং স্থানান্তরিত হয়।

ইউটিলিটি tcpdump ভেজিটা পরীক্ষায় TCP হ্যান্ডশেকের সময় (SYN এবং SYN-ACK-এর মধ্যে) বিলম্ব হয়। এই অপ্রয়োজনীয় জটিলতা দূর করতে, আপনি ব্যবহার করতে পারেন hping3 SYN প্যাকেট সহ সাধারণ "পিংস" এর জন্য। প্রতিক্রিয়া প্যাকেটে বিলম্ব হয়েছে কিনা তা আমরা পরীক্ষা করি এবং তারপর সংযোগটি পুনরায় সেট করি। আমরা শুধুমাত্র 100ms এর বেশি প্যাকেট অন্তর্ভুক্ত করার জন্য ডেটা ফিল্টার করতে পারি এবং Vegeta-এর সম্পূর্ণ নেটওয়ার্ক স্তর 7 পরীক্ষার চেয়ে সমস্যাটি পুনরুত্পাদন করার একটি সহজ উপায় পেতে পারি। এখানে কুবারনেটস নোড "পিংস" রয়েছে যা TCP SYN/SYN-ACK ব্যবহার করে পরিষেবা "নোড পোর্ট" (30927) 10ms বিরতিতে, সবচেয়ে ধীর প্রতিক্রিয়া দ্বারা ফিল্টার করা হয়েছে:

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

অবিলম্বে প্রথম পর্যবেক্ষণ করতে পারেন. ক্রম সংখ্যা এবং সময় বিচার করে, এটা স্পষ্ট যে এগুলি এককালীন যানজট নয়। বিলম্ব প্রায়ই জমা হয় এবং শেষ পর্যন্ত প্রক্রিয়া করা হয়।

এর পরে, আমরা খুঁজে বের করতে চাই যে কোন উপাদানগুলি যানজটের ঘটনার সাথে জড়িত হতে পারে। হয়তো এগুলি ন্যাটের শত শত iptables নিয়মগুলির মধ্যে কিছু? অথবা নেটওয়ার্কে IPIP টানেলিং নিয়ে কোন সমস্যা আছে? এটি পরীক্ষা করার একটি উপায় হ'ল সিস্টেমের প্রতিটি ধাপ এটি নির্মূল করে পরীক্ষা করা। আপনি যদি NAT এবং ফায়ারওয়াল লজিক মুছে ফেলেন, শুধুমাত্র IPIP অংশটি রেখে কি হবে:

সৌভাগ্যবশত, যদি মেশিন একই নেটওয়ার্কে থাকে তবে লিনাক্স সরাসরি আইপি ওভারলে স্তর অ্যাক্সেস করা সহজ করে তোলে:

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 বাদ দেয়। তাহলে কি সমস্যা টিসিপি? আসুন দেখি কিভাবে একটি নিয়মিত 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

ফলাফল দেখায় যে সমস্যা দূর হয়নি। সম্ভবত এটি একটি IPIP টানেল? আসুন পরীক্ষাটি আরও সহজ করা যাক:

সমস্ত প্যাকেট কি এই দুই হোস্টের মধ্যে পাঠানো হয়?

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

আমরা পরিস্থিতিকে সরলীকৃত করেছি দুটি Kubernetes নোডে একে অপরকে যেকোনো প্যাকেট, এমনকি একটি ICMP ping পাঠাতে। লক্ষ্য হোস্ট "খারাপ" (অন্যদের চেয়ে কিছু খারাপ) হলে তারা এখনও লেটেন্সি দেখতে পায়।

এখন শেষ প্রশ্ন: কেন বিলম্ব শুধুমাত্র kube-নোড সার্ভারে ঘটবে? এবং এটা কি ঘটবে যখন kube-নোড প্রেরক বা গ্রহণকারী হয়? ভাগ্যক্রমে, Kubernetes এর বাইরে একটি হোস্ট থেকে একটি প্যাকেট পাঠানোর মাধ্যমে এটি বের করাও বেশ সহজ, কিন্তু একই "পরিচিত খারাপ" প্রাপকের সাথে। আপনি দেখতে পাচ্ছেন, সমস্যাটি অদৃশ্য হয়নি:

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 প্যাকেটগুলি সর্বদা একই ক্রমানুসারে আসে যেখানে সেগুলি পাঠানো হয়েছিল, কিন্তু ভিন্ন সময়ের সাথে। একই সময়ে, টিসিপি প্যাকেট কখনও কখনও ইন্টারলিভ করে, এবং তাদের মধ্যে কিছু আটকে যায়। বিশেষ করে, আপনি যদি SYN প্যাকেটগুলির পোর্টগুলি পরীক্ষা করেন, তবে সেগুলি প্রেরকের দিকে ঠিক আছে, কিন্তু প্রাপকের দিকে নয়৷

কিভাবে একটি সূক্ষ্ম পার্থক্য আছে নেটওয়ার্ক কার্ড আধুনিক সার্ভারগুলি (যেমন আমাদের ডেটা সেন্টারে) TCP বা ICMP ধারণকারী প্যাকেটগুলি প্রক্রিয়া করে৷ যখন একটি প্যাকেট আসে, নেটওয়ার্ক অ্যাডাপ্টার "সংযোগ প্রতি এটি হ্যাশ করে", অর্থাৎ, এটি সংযোগগুলিকে সারিতে ভাঙ্গার চেষ্টা করে এবং প্রতিটি সারিকে একটি পৃথক প্রসেসর কোরে পাঠায়। TCP-এর জন্য, এই হ্যাশে উৎস এবং গন্তব্য IP ঠিকানা এবং পোর্ট উভয়ই অন্তর্ভুক্ত। অন্য কথায়, প্রতিটি সংযোগ আলাদাভাবে (সম্ভাব্য) হ্যাশ করা হয়। ICMP-এর জন্য, শুধুমাত্র IP ঠিকানাগুলি হ্যাশ করা হয়, যেহেতু সেখানে কোনো পোর্ট নেই৷

আরেকটি নতুন পর্যবেক্ষণ: এই সময়ের মধ্যে আমরা দুটি হোস্টের মধ্যে সমস্ত যোগাযোগে ICMP বিলম্ব দেখতে পাই, কিন্তু TCP তা করে না। এটি আমাদের বলে যে কারণটি সম্ভবত RX কিউ হ্যাশিংয়ের সাথে সম্পর্কিত: ভিড় প্রায় নিশ্চিতভাবেই RX প্যাকেটের প্রক্রিয়াকরণে, প্রতিক্রিয়া পাঠানোর ক্ষেত্রে নয়।

এটি সম্ভাব্য কারণগুলির তালিকা থেকে প্যাকেট পাঠানোকে সরিয়ে দেয়। আমরা এখন জানি যে প্যাকেট প্রসেসিং সমস্যাটি কিছু কুব-নোড সার্ভারে রিসিভের দিকে রয়েছে।

লিনাক্স কার্নেলে প্যাকেট প্রক্রিয়াকরণ বোঝা

কিছু কিউব-নোড সার্ভারে রিসিভারে কেন সমস্যা হয় তা বোঝার জন্য, লিনাক্স কার্নেল কীভাবে প্যাকেটগুলি প্রক্রিয়া করে তা দেখা যাক।

সহজতম ঐতিহ্যগত বাস্তবায়নে ফিরে, নেটওয়ার্ক কার্ড প্যাকেট গ্রহণ করে এবং পাঠায় বাধা লিনাক্স কার্নেল একটি প্যাকেজ আছে যে প্রক্রিয়া করা প্রয়োজন. কার্নেল অন্যান্য কাজ বন্ধ করে, ইন্টারপ্ট হ্যান্ডলারে প্রসঙ্গ স্যুইচ করে, প্যাকেট প্রক্রিয়া করে এবং তারপর বর্তমান কাজগুলিতে ফিরে আসে।

এই প্রসঙ্গ স্যুইচিং ধীর: 10-এর দশকে 90Mbps নেটওয়ার্ক কার্ডগুলিতে লেটেন্সি লক্ষণীয় নাও হতে পারে, কিন্তু আধুনিক 10G কার্ডে প্রতি সেকেন্ডে সর্বাধিক 15 মিলিয়ন প্যাকেটের থ্রুপুট সহ, একটি ছোট আট-কোর সার্ভারের প্রতিটি কোর লক্ষ লক্ষ ব্যাহত হতে পারে প্রতি সেকেন্ডে বার।

ক্রমাগত বাধাগুলি পরিচালনা না করার জন্য, বহু বছর আগে লিনাক্স যোগ করেছে NAPI: নেটওয়ার্ক API যা সমস্ত আধুনিক ড্রাইভার উচ্চ গতিতে কর্মক্ষমতা উন্নত করতে ব্যবহার করে। কম গতিতে কার্নেল এখনও পুরানো পদ্ধতিতে নেটওয়ার্ক কার্ড থেকে বাধা পায়। একবার পর্যাপ্ত প্যাকেট পৌঁছে যা থ্রেশহোল্ড অতিক্রম করে, কার্নেল বাধা নিষ্ক্রিয় করে এবং পরিবর্তে নেটওয়ার্ক অ্যাডাপ্টারের পোলিং শুরু করে এবং টুকরো টুকরো করে প্যাকেট তোলা শুরু করে। প্রসেসিং সফ্টরকিতে সঞ্চালিত হয়, অর্থাৎ ইন সফ্টওয়্যার বাধা প্রসঙ্গ সিস্টেম কল এবং হার্ডওয়্যার বাধার পরে, যখন কার্নেল (ব্যবহারকারী স্থানের বিপরীতে) ইতিমধ্যেই চলছে।

এটি অনেক দ্রুত, কিন্তু একটি ভিন্ন সমস্যা সৃষ্টি করে। যদি অনেকগুলি প্যাকেট থাকে, তাহলে নেটওয়ার্ক কার্ড থেকে প্যাকেট প্রক্রিয়াকরণের জন্য সমস্ত সময় ব্যয় করা হয় এবং ব্যবহারকারীর স্থান প্রক্রিয়াগুলির কাছে এই সারিগুলি খালি করার সময় নেই (টিসিপি সংযোগগুলি থেকে পড়া ইত্যাদি)৷ অবশেষে সারিগুলি পূর্ণ হয়ে যায় এবং আমরা প্যাকেট ফেলে দিতে শুরু করি। একটি ভারসাম্য খুঁজে বের করার প্রয়াসে, কার্নেল softirq প্রসঙ্গে প্রক্রিয়াকৃত সর্বাধিক সংখ্যক প্যাকেটের জন্য একটি বাজেট নির্ধারণ করে। একবার এই বাজেট ছাড়িয়ে গেলে, একটি পৃথক থ্রেড জেগে ওঠে ksoftirqd (আপনি তাদের মধ্যে একজনকে দেখতে পাবেন ps প্রতি কোর) যা সাধারণ syscall/interrupt পাথের বাইরে এই softirqগুলি পরিচালনা করে। এই থ্রেডটি স্ট্যান্ডার্ড প্রসেস সিডিউলার ব্যবহার করে নির্ধারিত হয়েছে, যা ন্যায্যভাবে সম্পদ বরাদ্দ করার চেষ্টা করে।

কার্নেল কীভাবে প্যাকেটগুলিকে প্রক্রিয়া করে তা অধ্যয়ন করার পরে, আপনি দেখতে পারেন যে ভিড়ের একটি নির্দিষ্ট সম্ভাবনা রয়েছে। যদি 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 কোর দ্বারা প্রক্রিয়া করা হয়। আমরা যদি বুঝতে চাই যে লিনাক্স কীভাবে কাজ করে, তাহলে প্রক্রিয়াটি ট্র্যাক করার জন্য কোথায় (কোন সিপিইউ কোরে) এবং কীভাবে (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 পিআইডি প্রক্রিয়ার নাম ICMP_SEQ 0 0 সোয়াপার/11 770 0 0 সোয়াপার/11 771 0 0 সোয়াপার/11 772 0 0 সোয়াপার/11 773 0 0 সোয়াপার/11 774 20041 20086me 775 0 0 সোয়াপার/11 776 0 0 সোয়াপার/11 777 0 0 স্পোক-রিপোর্ট-এস 11

এখানে উল্লেখ্য যে, প্রেক্ষাপটে ড softirq যে প্রক্রিয়াগুলি সিস্টেম কল করেছে সেগুলি "প্রসেস" হিসাবে প্রদর্শিত হবে যখন প্রকৃতপক্ষে এটি কার্নেল যা কার্নেলের প্রসঙ্গে প্যাকেটগুলিকে নিরাপদে প্রক্রিয়া করে।

এই টুলের সাহায্যে আমরা নির্দিষ্ট প্যাকেজগুলির সাথে নির্দিষ্ট প্রক্রিয়াগুলিকে সংযুক্ত করতে পারি যা একটি বিলম্ব দেখায় hping3. এটা সহজ করা যাক grep নির্দিষ্ট মান জন্য এই ক্যাপচার উপর icmp_seq. উপরের icmp_seq মানগুলির সাথে মিলে যাওয়া প্যাকেটগুলি তাদের RTT এর সাথে উল্লেখ করা হয়েছে যা আমরা উপরে পর্যবেক্ষণ করেছি (বন্ধনীতে প্রত্যাশিত RTT মানগুলি প্যাকেটগুলির জন্য যা আমরা RTT মান 50 ms এর কম হওয়ার কারণে ফিল্টার আউট করেছি):

টিজিআইডি পিআইডি প্রক্রিয়ার নাম ICMP_SEQ ** RTT -- 10137 10436 ক্যাডভাইজার 1951 10137 10436 ক্যাডভাইজার 1952 76 76 ksoftirqd/11 1953 ** 99ms 76 76 d11 সফট্কিউ d /1954 89 ** 76ms 76 11 ksoftirqd/1955 79 ** 76ms 76 11 ksoftirqd/1956 69 ** 76ms 76 11 ksoftirqd/1957 59 ** (76ms) 76 11 ksoftirqd/1958 49 ** (76ms) 76 11 ksoftirqd/1959 softirqd** (39ms) 76 76 ksoftirqd/11 1960 d / 29 76 ** (76ms) 11 1961 ksoftirqd/19 76 ** (76ms) -- 11 1962 cadvisor 9 10137 10436 cadvisor 2068 10137 10436 ksoftirqd/2069ms 76 softirqd/76ms ** 11 2070 ** 75ms 76 76 ksoftirqd/ 11 2071 ** 65ms 76 76 ksoftirqd/11 2072 ** (55ms) 76 76 ksoftirqd/11 2073 ** (45ms) 76 76 ksoftirqd/11 2074 ** (35ms ** (76d76 soft) ) 11 2075 ksoftirqd/25 76 ** (76ms)

ফলাফল আমাদের বিভিন্ন জিনিস বলে. প্রথমত, এই সমস্ত প্যাকেজ প্রসঙ্গ দ্বারা প্রক্রিয়া করা হয় ksoftirqd/11. এর মানে হল এই নির্দিষ্ট জোড়া মেশিনের জন্য, ICMP প্যাকেটগুলি প্রাপ্তির শেষে কোর 11-এ হ্যাশ করা হয়েছিল। আমরা আরও দেখি যে যখনই জ্যাম হয়, সেখানে প্যাকেটগুলি থাকে যা সিস্টেম কলের প্রেক্ষাপটে প্রক্রিয়া করা হয় cadvisor। তারপর ksoftirqd কাজটি গ্রহণ করে এবং জমে থাকা সারিটি প্রক্রিয়া করে: ঠিক কতগুলি প্যাকেট পরে জমা হয়েছে cadvisor.

সত্য যে অবিলম্বে আগে এটি সবসময় কাজ করে cadvisor, সমস্যায় তার সম্পৃক্ততা বোঝায়। হাস্যকরভাবে, উদ্দেশ্য ক্যাডভাইজার - "সম্পদ ব্যবহার এবং চলমান পাত্রে কর্মক্ষমতা বৈশিষ্ট্য বিশ্লেষণ করুন" এই কর্মক্ষমতা সমস্যা সৃষ্টি করার পরিবর্তে।

কনটেইনারগুলির অন্যান্য দিকগুলির মতো, এগুলি সমস্ত অত্যন্ত উন্নত সরঞ্জাম এবং কিছু অপ্রত্যাশিত পরিস্থিতিতে কর্মক্ষমতা সমস্যাগুলি অনুভব করার আশা করা যেতে পারে।

ক্যাডভাইজার কী করে যা প্যাকেটের সারির গতি কমিয়ে দেয়?

ক্র্যাশ কিভাবে ঘটছে, কোন প্রক্রিয়ার কারণে এটি ঘটছে এবং কোন সিপিইউতে আমরা এখন ভালোভাবে বুঝতে পেরেছি। আমরা দেখতে পাই যে হার্ড ব্লকিংয়ের কারণে, লিনাক্স কার্নেলের সময়সূচী করার সময় নেই ksoftirqd. এবং আমরা দেখি যে প্যাকেটগুলি প্রসঙ্গে প্রক্রিয়া করা হয় cadvisor. এটা ধরে নেওয়া যৌক্তিক cadvisor একটি ধীর syscall চালু করে, যার পরে সেই সময়ে জমা হওয়া সমস্ত প্যাকেট প্রক্রিয়া করা হয়:

এটি একটি তত্ত্ব, তবে এটি কীভাবে পরীক্ষা করবেন? আমরা যা করতে পারি তা হল এই প্রক্রিয়া জুড়ে CPU কোরকে ট্রেস করা, প্যাকেটের সংখ্যা বাজেটের চেয়ে বেশি হওয়া পয়েন্টটি খুঁজে বের করুন এবং ksoftirqd বলা হয় এবং তারপরে সেই বিন্দুর ঠিক আগে CPU কোরে ঠিক কী চলছিল তা দেখতে একটু পিছনে তাকান। . এটি প্রতি কয়েক মিলিসেকেন্ডে CPU-এর এক্স-রে করার মতো। এটি এই মত কিছু দেখাবে:

সুবিধামত, এই সব বিদ্যমান সরঞ্জাম দিয়ে করা যেতে পারে. উদাহরণ স্বরূপ, পারফ রেকর্ড একটি নির্দিষ্ট ফ্রিকোয়েন্সিতে একটি প্রদত্ত CPU কোর চেক করে এবং ব্যবহারকারীর স্থান এবং Linux কার্নেল উভয় সহ চলমান সিস্টেমে কলের একটি সময়সূচী তৈরি করতে পারে। আপনি এই রেকর্ডটি নিতে পারেন এবং প্রোগ্রামের একটি ছোট কাঁটা ব্যবহার করে এটি প্রক্রিয়া করতে পারেন ফ্লেমগ্রাফ ব্রেন্ডন গ্রেগ থেকে, যা স্ট্যাক ট্রেসের ক্রম সংরক্ষণ করে। আমরা প্রতি 1 মিসে একক-লাইন স্ট্যাক ট্রেস সংরক্ষণ করতে পারি, এবং তারপর ট্রেস হিট হওয়ার আগে একটি নমুনা 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 এর আগে cadvisor" প্যাটার্নটি খুঁজে পাই যা আমরা আগে ICMP ট্রেসারে দেখেছি। এর মানে কী?

প্রতিটি লাইন একটি নির্দিষ্ট সময়ে একটি CPU ট্রেস। একটি লাইনের স্ট্যাকের ডাউন প্রতিটি কল একটি সেমিকোলন দ্বারা পৃথক করা হয়। লাইনের মাঝখানে আমরা দেখতে পাই যে syscall বলা হচ্ছে: 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 জম্বিগুলি পরিষ্কার করতে অনেক বেশি সময় লাগে।

দেখা যাচ্ছে যে আমাদের কিছু নোডে এত বেশি cgroup জোম্বি ছিল যে পড়া এবং লেটেন্সি এক সেকেন্ড ছাড়িয়ে গেছে।

ক্যাডভাইজার সমস্যার সমাধান হল পুরো সিস্টেম জুড়ে অবিলম্বে ডেন্ট্রি/ইনোড ক্যাশে মুক্ত করা, যা হোস্টের রিড লেটেন্সি এবং নেটওয়ার্ক লেটেন্সি দূর করে, যেহেতু ক্যাশে সাফ করা ক্যাশে জম্বি cgroup পৃষ্ঠাগুলি চালু করে এবং সেগুলিকেও মুক্ত করে। এটি একটি সমাধান নয়, তবে এটি সমস্যার কারণ নিশ্চিত করে।

দেখা যাচ্ছে যে নতুন কার্নেল সংস্করণে (4.19+) কল কর্মক্ষমতা উন্নত হয়েছে memory.stat, তাই এই কার্নেলে স্যুইচ করা সমস্যার সমাধান করেছে। একই সময়ে, আমাদের কাছে কুবারনেটস ক্লাস্টারে সমস্যাযুক্ত নোডগুলি সনাক্ত করার জন্য সরঞ্জাম ছিল, তাদের সুন্দরভাবে নিষ্কাশন করা এবং সেগুলি পুনরায় বুট করা। আমরা সমস্ত ক্লাস্টারগুলিকে চিরুনি দিয়েছি, যথেষ্ট উচ্চ লেটেন্সি সহ নোডগুলি খুঁজে পেয়েছি এবং সেগুলি পুনরায় বুট করেছি৷ এটি আমাদের অবশিষ্ট সার্ভারগুলিতে OS আপডেট করার জন্য সময় দিয়েছে।

সংক্ষিপ্ত বিবরণ

কারণ এই বাগটি শত শত মিলিসেকেন্ডের জন্য RX NIC সারি প্রক্রিয়াকরণ বন্ধ করে দিয়েছে, এটি একই সাথে ছোট সংযোগে উচ্চ লেটেন্সি এবং মিড-কানেকশন লেটেন্সি, যেমন MySQL অনুরোধ এবং প্রতিক্রিয়া প্যাকেটের মধ্যে উভয়েরই সৃষ্টি করেছে।

সবচেয়ে মৌলিক সিস্টেমগুলির কার্যকারিতা বোঝা এবং বজায় রাখা, যেমন Kubernetes, তাদের উপর ভিত্তি করে সমস্ত পরিষেবার নির্ভরযোগ্যতা এবং গতির জন্য গুরুত্বপূর্ণ। আপনি চালান প্রতিটি সিস্টেম কুবারনেটস কর্মক্ষমতা উন্নতি থেকে উপকৃত হয়।

উত্স: www.habr.com