হিসাবে অধিকাংশ পোস্ট, একটি বিতরণ করা পরিষেবাতে সমস্যা আছে, আসুন এই পরিষেবাটিকে আলভিন বলি৷ এইবার আমি নিজেই সমস্যাটি আবিষ্কার করিনি, ক্লায়েন্টের পক্ষ থেকে লোকেরা আমাকে জানিয়েছিল।

একদিন আমি অ্যালভিনের সাথে দীর্ঘ বিলম্বের কারণে একটি অসন্তুষ্ট ইমেল পেয়েছিলাম, যা আমরা অদূর ভবিষ্যতে চালু করার পরিকল্পনা করেছি। বিশেষত, ক্লায়েন্ট 99 ms এর অঞ্চলে 50 তম পার্সেন্টাইল লেটেন্সি অনুভব করেছেন, আমাদের লেটেন্সি বাজেটের অনেক উপরে। এটি আশ্চর্যজনক ছিল কারণ আমি পরিষেবাটি ব্যাপকভাবে পরীক্ষা করেছি, বিশেষত লেটেন্সিতে, যা একটি সাধারণ অভিযোগ।

আমি অ্যালভিনকে পরীক্ষা করার আগে, আমি প্রতি সেকেন্ডে (QPS) 40k ক্যোয়ারী নিয়ে অনেক পরীক্ষা-নিরীক্ষা করেছি, সবগুলোই 10ms এর কম লেটেন্সি দেখাচ্ছে। আমি ঘোষণা করতে প্রস্তুত ছিলাম যে আমি তাদের ফলাফলের সাথে একমত নই। কিন্তু চিঠির দিকে আরেকবার নজর দিয়ে, আমি নতুন কিছু লক্ষ্য করেছি: তারা যে শর্তগুলি উল্লেখ করেছে আমি তা পরীক্ষা করিনি, তাদের QPS আমার থেকে অনেক কম ছিল। আমি 40k QPS এ পরীক্ষা করেছি, কিন্তু তারা শুধুমাত্র 1k এ। আমি আরেকটি পরীক্ষা চালিয়েছিলাম, এইবার কম QPS দিয়ে, শুধুমাত্র তাদের সন্তুষ্ট করার জন্য।

যেহেতু আমি এই বিষয়ে ব্লগিং করছি, আপনি সম্ভবত ইতিমধ্যেই বুঝতে পেরেছেন যে তাদের সংখ্যা সঠিক ছিল। আমি আমার ভার্চুয়াল ক্লায়েন্টকে বারবার পরীক্ষা করেছি, একই ফলাফলের সাথে: কম সংখ্যক অনুরোধ শুধুমাত্র লেটেন্সি বাড়ায় না, কিন্তু 10 ms-এর বেশি লেটেন্সি সহ অনুরোধের সংখ্যা বাড়ায়। অন্য কথায়, যদি 40k QPS-এ প্রতি সেকেন্ডে প্রায় 50টি অনুরোধ 50 ms অতিক্রম করে, তাহলে 1k QPS-এ প্রতি সেকেন্ডে 100 ms-এর উপরে 50টি অনুরোধ ছিল। প্যারাডক্স !

অনুসন্ধান নিচে সংকীর্ণ

যখন অনেকগুলি উপাদান সহ একটি বিতরণ করা সিস্টেমে একটি লেটেন্সি সমস্যার সম্মুখীন হয়, প্রথম ধাপ হল সন্দেহভাজনদের একটি সংক্ষিপ্ত তালিকা তৈরি করা৷ আসুন আলভিনের আর্কিটেকচারে একটু গভীরে খনন করা যাক:

একটি ভাল সূচনা পয়েন্ট হল সম্পূর্ণ I/O ট্রানজিশনের একটি তালিকা (নেটওয়ার্ক কল/ডিস্ক লুকআপ, ইত্যাদি)। দেরি কোথায় তা বের করার চেষ্টা করি। ক্লায়েন্টের সাথে সুস্পষ্ট I/O ছাড়াও, অ্যালভিন একটি অতিরিক্ত পদক্ষেপ নেয়: সে ডেটা স্টোর অ্যাক্সেস করে। যাইহোক, এই স্টোরেজটি অ্যালভিনের মতো একই ক্লাস্টারে কাজ করে, তাই ক্লায়েন্টের তুলনায় সেখানে লেটেন্সি কম হওয়া উচিত। সুতরাং, সন্দেহভাজনদের তালিকা:

1. ক্লায়েন্ট থেকে অ্যালভিনে নেটওয়ার্ক কল।
2. আলভিন থেকে ডেটা স্টোরে নেটওয়ার্ক কল।
3. ডেটা স্টোরে ডিস্কে অনুসন্ধান করুন।
4. ডাটা গুদাম থেকে অ্যালভিনের কাছে নেটওয়ার্ক কল।
5. অ্যালভিনের কাছ থেকে ক্লায়েন্টের কাছে নেটওয়ার্ক কল।

এর কিছু পয়েন্ট ক্রস আউট করার চেষ্টা করা যাক.

এর সাথে ডেটা স্টোরেজের কোনো সম্পর্ক নেই

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

আপনি দেখতে পাচ্ছেন, পিং-পিং সার্ভার ব্যবহার করার সময় কোন উন্নতি নেই। এর মানে হল যে ডেটা গুদামটি বিলম্বিত করে না, এবং সন্দেহভাজনদের তালিকা অর্ধেক কাটা হয়:

1. ক্লায়েন্ট থেকে অ্যালভিনে নেটওয়ার্ক কল।
2. অ্যালভিনের কাছ থেকে ক্লায়েন্টের কাছে নেটওয়ার্ক কল।

দারুণ! তালিকা দ্রুত সঙ্কুচিত হচ্ছে। আমি ভেবেছিলাম আমি প্রায় কারণটি বের করে ফেলেছি।

gRPC

এখনই সময় আপনাকে একজন নতুন খেলোয়াড়ের সাথে পরিচয় করিয়ে দেওয়ার: gRPC. এটি প্রক্রিয়াধীন যোগাযোগের জন্য Google থেকে একটি ওপেন সোর্স লাইব্রেরি আরপিসি। যদিও gRPC ভালভাবে অপ্টিমাইজ করা এবং ব্যাপকভাবে ব্যবহৃত, এই আকারের একটি সিস্টেমে এটি ব্যবহার করা আমার প্রথমবার এবং আমি আশা করি আমার বাস্তবায়ন সাবঅপ্টিমাল হবে - অন্তত বলতে গেলে।

উপস্থিতি gRPC স্ট্যাকের মধ্যে একটি নতুন প্রশ্নের জন্ম দিয়েছে: সম্ভবত এটি আমার বাস্তবায়ন বা আমি নিজেই gRPC লেটেন্সি সমস্যা সৃষ্টি করছে? তালিকায় একটি নতুন সন্দেহভাজন যুক্ত করা হচ্ছে:

1. ক্লায়েন্ট লাইব্রেরী কল gRPC
2. লাইব্রেরি gRPC ক্লায়েন্টের লাইব্রেরিতে একটি নেটওয়ার্ক কল করে gRPC সার্ভারে
3. লাইব্রেরি gRPC অ্যালভিনের পরিচিতি (পিং-পং সার্ভারের ক্ষেত্রে কোনো অপারেশন নেই)

কোডটি কেমন দেখাচ্ছে সে সম্পর্কে আপনাকে ধারণা দিতে, আমার ক্লায়েন্ট/অ্যালভিন বাস্তবায়ন ক্লায়েন্ট-সার্ভারগুলির থেকে খুব বেশি আলাদা নয় async উদাহরণ.

দ্রষ্টব্য: উপরের তালিকাটি কিছুটা সরলীকৃত কারণ gRPC আপনার নিজস্ব (টেমপ্লেট?) থ্রেডিং মডেল ব্যবহার করা সম্ভব করে, যেখানে এক্সিকিউশন স্ট্যাকটি পরস্পর সংযুক্ত থাকে gRPC এবং ব্যবহারকারী বাস্তবায়ন। সরলতার জন্য, আমরা এই মডেলটি আটকে রাখব।

প্রোফাইলিং সবকিছু ঠিক করবে

ডেটা স্টোরগুলি অতিক্রম করার পরে, আমি ভেবেছিলাম যে আমি প্রায় শেষ করেছি: "এখন এটি সহজ! আসুন প্রোফাইলটি প্রয়োগ করি এবং কোথায় বিলম্ব হয় তা খুঁজে বের করি।" আমি নির্ভুল প্রোফাইলিংয়ের বড় ফ্যান, কারণ CPU গুলি খুব দ্রুত এবং প্রায়শই বাধা হয় না। বেশিরভাগ বিলম্ব ঘটে যখন প্রসেসরকে অন্য কিছু করার জন্য প্রক্রিয়াকরণ বন্ধ করতে হবে। সঠিক CPU প্রোফাইলিং ঠিক তাই করে: এটি সঠিকভাবে সবকিছু রেকর্ড করে প্রসঙ্গ সুইচ এবং কোথায় বিলম্ব ঘটবে তা স্পষ্ট করে।

আমি চারটি প্রোফাইল নিয়েছি: উচ্চ কিউপিএস (লো লেটেন্সি) সহ এবং কম কিউপিএস (উচ্চ লেটেন্সি) সহ একটি পিং-পং সার্ভারের সাথে, উভয় ক্লায়েন্ট এবং সার্ভারের দিকে। এবং শুধু ক্ষেত্রে, আমি একটি নমুনা প্রসেসর প্রোফাইল গ্রহণ. প্রোফাইল তুলনা করার সময়, আমি সাধারণত একটি অস্বাভাবিক কল স্ট্যাকের সন্ধান করি। উদাহরণস্বরূপ, উচ্চ লেটেন্সি সহ খারাপ দিকটিতে আরও অনেকগুলি প্রসঙ্গ সুইচ রয়েছে (10 বার বা তার বেশি)। কিন্তু আমার ক্ষেত্রে, প্রসঙ্গ সুইচের সংখ্যা প্রায় একই ছিল। আমার আতঙ্কের জন্য, সেখানে উল্লেখযোগ্য কিছুই ছিল না।

অতিরিক্ত ডিবাগিং

আমি মরিয়া ছিলাম। আমি জানতাম না যে আমি অন্য কোন সরঞ্জামগুলি ব্যবহার করতে পারি, এবং আমার পরবর্তী পরিকল্পনাটি মূলত সমস্যাটি স্পষ্টভাবে নির্ণয় করার পরিবর্তে বিভিন্ন বৈচিত্রের সাথে পরীক্ষাগুলি পুনরাবৃত্তি করা।

কি যদি

প্রথম থেকেই, আমি নির্দিষ্ট 50ms লেটেন্সি সম্পর্কে উদ্বিগ্ন ছিলাম। এটা অনেক বড় সময়। আমি সিদ্ধান্ত নিয়েছি যে আমি ঠিক কোন অংশটি এই ত্রুটিটি ঘটাচ্ছে তা বের না করা পর্যন্ত আমি কোডের অংশগুলি কেটে ফেলব। তারপরে একটি পরীক্ষা এসেছিল যা কাজ করেছিল।

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

নেটওয়ার্কে কিছু সমস্যা হয়েছে।

নেটওয়ার্ক ইঞ্জিনিয়ার দক্ষতা শেখা

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

ভাগ্যক্রমে, ইন্টারনেট যারা শিখতে চায় তাদের পছন্দ করে। পিং এবং ট্রেসার্টের সংমিশ্রণটি নেটওয়ার্ক পরিবহন সমস্যাগুলি ডিবাগ করার জন্য যথেষ্ট ভাল শুরু বলে মনে হয়েছিল।

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

তারপর চেষ্টা করলাম tracert: অ্যালভিন এবং ক্লায়েন্টের মধ্যে রুট বরাবর নোডগুলির একটিতে সমস্যা হতে পারে৷ কিন্তু ট্রেসারও ফিরেছে খালি হাতে।

সুতরাং এটি আমার কোড, জিআরপিসি বাস্তবায়ন বা নেটওয়ার্ক ছিল না যা বিলম্বের কারণ ছিল। আমি চিন্তা করতে শুরু করেছি যে আমি এটি কখনই বুঝতে পারব না।

এখন আমরা কি ওএসে আছি

gRPC লিনাক্সে ব্যাপকভাবে ব্যবহৃত, কিন্তু উইন্ডোজে বহিরাগত। আমি একটি পরীক্ষা করার সিদ্ধান্ত নিয়েছি, যা কাজ করেছে: আমি একটি লিনাক্স ভার্চুয়াল মেশিন তৈরি করেছি, লিনাক্সের জন্য অ্যালভিনকে কম্পাইল করেছি এবং এটি স্থাপন করেছি।

এবং এখানে যা ঘটেছে: লিনাক্স পিং-পং সার্ভারে অনুরূপ উইন্ডোজ হোস্টের মতো একই বিলম্ব হয়নি, যদিও ডেটা উত্স আলাদা ছিল না। দেখা যাচ্ছে যে সমস্যাটি উইন্ডোজের জন্য gRPC বাস্তবায়নে।

নাগলের অ্যালগরিদম

এই সমস্ত সময় আমি ভেবেছিলাম আমি একটি পতাকা হারিয়েছি gRPC. এখন আমি বুঝতে পারছি এটা আসলে কি gRPC উইন্ডোজ পতাকা অনুপস্থিত. আমি একটি অভ্যন্তরীণ RPC লাইব্রেরি পেয়েছি যেটি আমি নিশ্চিত ছিলাম যে সমস্ত পতাকা সেটের জন্য ভাল কাজ করবে Winsock. তারপরে আমি এই সমস্ত পতাকাগুলিকে জিআরপিসিতে যুক্ত করেছি এবং অ্যালভিনকে উইন্ডোজে মোতায়েন করেছি, একটি প্যাচযুক্ত উইন্ডোজ পিং-পং সার্ভারে!

প্রায় সম্পন্ন: রিগ্রেশন ফিরে না আসা পর্যন্ত আমি যোগ করা পতাকাগুলিকে এক এক করে সরাতে শুরু করেছি যাতে আমি কারণটি চিহ্নিত করতে পারি। এটা কুখ্যাত ছিল TCP_NODELAY, Nagle এর অ্যালগরিদম সুইচ।

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

উপসংহার

কম QPS-এ উচ্চতর বিলম্ব OS অপ্টিমাইজেশনের কারণে হয়েছিল। রেট্রোস্পেক্টে, প্রোফাইলিং লেটেন্সি সনাক্ত করেনি কারণ এটি ইনের পরিবর্তে কার্নেল মোডে করা হয়েছিল ব্যবহারকারী মোড. আমি জানি না যে নাগলের অ্যালগরিদমটি ETW ক্যাপচারের মাধ্যমে পর্যবেক্ষণ করা যেতে পারে, তবে এটি আকর্ষণীয় হবে।

লোকালহোস্ট পরীক্ষার জন্য, এটি সম্ভবত প্রকৃত নেটওয়ার্কিং কোড স্পর্শ করেনি এবং নাগলের অ্যালগরিদম চলেনি, তাই ক্লায়েন্ট লোকালহোস্টের মাধ্যমে অ্যালভিনের কাছে পৌঁছালে লেটেন্সি সমস্যাগুলি চলে যায়।

পরের বার যখন আপনি প্রতি সেকেন্ডে অনুরোধের সংখ্যা কমে যাওয়ার সাথে সাথে বিলম্বিততা বৃদ্ধি দেখতে পান, তখন Nagle এর অ্যালগরিদম আপনার সন্দেহভাজনদের তালিকায় থাকা উচিত!

উত্স: www.habr.com