আপনার VPN গেটওয়ে কি CPU-সীমিত? আগে প্রতি কোরের লোড পড়ুন
গড় মান গুরুত্বপূর্ণ থ্রেডটিকে লুকিয়ে রাখে। নিয়ন্ত্রিত ট্রান্সফারের সময় প্রতি কোরের লোড পড়ুন, পথটি বাদ দিন, তারপর প্রতি রানে একটি নথিভুক্ত সেটিং বদলান।
বড় ইনস্ট্যান্স কেনার আগে নির্ধারণ করুন তিনটি সীমার মধ্যে কোনটিতে পৌঁছেছেন। একটি কোর পুরো ব্যস্ত আর বাকিগুলো অলস থাকলে তা প্রতি-ফ্লো ক্রিপ্টো কাজ নির্দেশ করে। ট্রান্সফারের সময় সব কোর সম্পৃক্ত থাকলে তা মোট সক্ষমতা নির্দেশ করে। কম CPU আর বাড়তে থাকা রিট্রান্সমিট সংখ্যা পথ নির্দেশ করে। প্রতিটির প্রথম পদক্ষেপ আলাদা, এবং কেবল একটিরই সমাধান বড় ইনস্ট্যান্সে।
তিনটি সীমা, একটি টেবিল, তিনটি সমাধান
| Limit | Reading during a transfer | First move |
|---|---|---|
| Single thread | one core near 100%, siblings idle | spread flows across workers |
| Aggregate CPU | every core busy, load average climbs | capacity, or less work per byte |
| Path or provider | low CPU, retransmits or steal time high | MTU, 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 যদি এখনো উপসর্গ অনুসরণ না করে, অনুমানে আপগ্রেড না করে পথ ও অ্যাপ্লিকেশন পরীক্ষায় ফিরে যান।