VPN সার্ভার লোড ব্যাখ্যা: ব্যবহারকারী, CPU নাকি আপলিংক?
কম লোড স্কোর মানে ব্যবহারকারীরা নিষ্ক্রিয়, CPU উদ্বৃত্ত, বা প্রশস্ত আপলিংক হতে পারে। loadavg, ইন্টারফেস কাউন্টার ও স্টেটাস ফাইল পড়ুন, তারপর একে দ্রুত বলুন।
0.4 লোডে থাকা একটি গেটওয়ে তার পেছনের প্রতিটি ব্যবহারকারীর জন্য এখনও ধীর গতিতে চলতে পারে। লোড অ্যাভারেজ রানেবল বা অনির্বাচনযোগ্য ঘুমে আটকে থাকা টাস্ক গণনা করে, আর চার কোরের হোস্টে একটি সম্পৃক্ত প্রসেসই যথেষ্ট তাকে 1.0-এর দিকে ঠেলে দিতে, যখন তিনটি কোর অলস বসে থাকে। সেই সংখ্যাটিকে বাড়তি ক্ষমতা হিসেবে পড়া হলো এন্ডপয়েন্ট নির্বাচনের সবচেয়ে সাধারণ ভুল। আসলে একটি টানেলকে সীমাবদ্ধ করে সাধারণত চারটি জিনিসের একটি: একটি ব্যস্ত কোর, আপলিংক, তার সামনের সারি, বা এমন প্রতি-সেশন নীতি যা কেউ নথিভুক্ত করেনি।
লোড অ্যাভারেজ টাস্ক গণনা করে, প্রবাহ নয়
কার্নেল রান কিউ এবং ইনপুট-আউটপুটের জন্য অপেক্ষারত টাস্কের সংখ্যার নমুনা নেয়, তারপর দুটোই এক, পাঁচ ও পনেরো মিনিট ধরে মসৃণ করে। সেই সংজ্ঞায় বাইট, প্যাকেট বা টানেলের কথা নেই। যে হোস্টের স্টোরেজ আটকে গেছে সে প্রায় কোনো ট্রাফিক ছাড়াই উচ্চ লোড দেখাতে পারে, আর যে হোস্ট কার্নেল ডেটা পথে গিগাবিট চালায় সে আরামদায়ক লোড দেখাতে পারে।
তাই লোডকে টানেল পারফরম্যান্সের সঙ্গে সম্পর্কিত করতে প্রতি-কোর দৃষ্টিভঙ্গি দরকার। একটি কোর পুরো দখলে গেলে ড্যাশবোর্ডের সামগ্রিক শতাংশ এখনও ভালো দেখাবে:
cat /proc/loadavg
mpstat -P ALL 1 1
top -H -b -n 1 | head -n 20তৃতীয় কমান্ডটিই VPN হোস্টে সবচেয়ে গুরুত্বপূর্ণ। OpenVPN 2.x-এ ইউজারস্পেস প্যাকেট প্রসেসিং মূলত প্রতি প্রসেসে ক্রমিক, তাই একটি ব্যস্ত থ্রেডই সিলিং হয়ে উঠতে পারে, অথচ ড্যাশবোর্ড প্রচুর অব্যবহৃত ক্ষমতা দেখায়। আপনার ধীর সময়ে যদি একটি থ্রেড একটি কোরের বেশি অংশ দখল করে, হোস্টটি সামগ্রিকভাবে অপর্যাপ্ত নয়; এটি ঠিক যে মাত্রায় সীমাবদ্ধ যা গুরুত্বপূর্ণ।
সময়ের দিকেও খেয়াল করুন। পনেরো মিনিটের গড় একটি কল নষ্ট করা বিস্ফোরণ লুকায়, তাই অভিযোগের পরে নেওয়া স্ক্রিনশট দুর্বল প্রমাণ। সমস্যার সময়েই নমুনা নিন, আর আউটপুটের সঙ্গে টাইমস্ট্যাম্প রাখুন।
আপলিংক ও তার সামনের সারি
ইন্টারফেস কাউন্টার ব্যান্ডউইথের প্রশ্নের উত্তর দেয় যা প্রসেসরের সংখ্যা দিতে পারে না। তারা ক্ষমতাকে ক্ষতি থেকে আলাদাও করে, আর এগুলো ভিন্ন সমাধানের ভিন্ন ব্যর্থতা:
ip -s link show dev eth0
tc -s qdisc show dev eth0
nstat -az TcpRetransSegs TcpExtTCPLostRetransmitপরীক্ষার সময় আপনার নির্ধারিত গতির কাছাকাছি থাকা লিংকই ব্যাখ্যা, আর অতিরিক্ত প্রসেসর এর কিছুই বদলায় না। qdisc লাইনটি ইন্টারঅ্যাকটিভ ট্রাফিকের জন্য গুরুত্বপূর্ণ বিবরণ যোগ করে: ব্যাকলগ ও ড্রপ বলে দেয় প্যাকেট বেরোনোর আগে সারিতে অপেক্ষা করছে কি না। বাল্ক আপলোডের চাপে ভরে যাওয়া সারি ঠিক সেই উপসর্গ তৈরি করে যা মানুষ দূরবর্তী সার্ভারকে দোষ দেয়, অর্থাৎ এমন সংযোগে ধীর কল যা বেঞ্চমার্কে এখনও ভালো দেখায়।
পুনঃপ্রেরণ কাউন্টার সেই ক্ষেত্রটি ধরে যেখানে প্যাকেট বেরোয় কিন্তু কখনও পরিষ্কারভাবে পৌঁছায় না। ধীর সময়ে পুনঃপ্রেরণ বাড়লে এবং ইন্টারফেস ক্ষমতার কাছে না থাকলে, সমস্যা হোস্টে নয় পথে, আর একই শহরে অন্য এন্ডপয়েন্টে গেলে কাজ হবে না।
সেশন সংখ্যা চাহিদা বোঝায়, বাড়তি ক্ষমতা নয়
প্রতিটি পাবলিক ডিরেক্টরি কিছু সংখ্যক সংযুক্ত ব্যবহারকারী দেখায়, আর তাদের প্রায় কেউই বলে না ব্যবহারকারীরা কী করছে। ইন্টারঅ্যাকটিভ কাজ করা বিশটি সেশন আর বড় ফাইল টানা চারটি সেশন একই হার্ডওয়্যারে খুব ভিন্ন লোড তৈরি করে। দ্বিতীয় ধরনটি ব্যবহারকারী সংখ্যায় অদৃশ্য, আর সেটিই একটি সন্ধ্যা নষ্ট করে। তাই সেশন সংখ্যা সবচেয়ে ভালো পড়া হয় চাহিদার ইঙ্গিত হিসেবে, কখনও বাড়তি ক্ষমতার বিবৃতি হিসেবে নয়।
| Number on the page | What it is really measuring | What it cannot tell you |
|---|---|---|
| Connected users | How many sessions hold an address | How much each one is transferring |
| Load or score | Whatever the operator chose to publish | Whether that definition matches your task |
| Uptime | How long since the process started | Current capacity, queue depth or packet loss |
| Distance or ping | Round-trip time on a small probe | Throughput under sustained transfer |
আপনার নিয়ন্ত্রিত হোস্টে স্টেটাস ফাইল অনুপস্থিত মাত্রাটি দেয়। OpenVPN পর্যায়ক্রমিক স্ন্যাপশট লেখে যাতে প্রতি-ক্লায়েন্ট বাইট কাউন্টার থাকে, আর তা দেখার জন্য যথেষ্ট যে একটি সেশনই পুরো আপলিংকের জন্য দায়ী কি না:
status /run/openvpn/server.status 10
# then, after at least one interval
grep -E "^CLIENT_LIST" /run/openvpn/server.statusদশ সেকেন্ড ব্যবধানে দুটি নমুনা সেই ক্রমপুঞ্জিত কাউন্টারকে প্রতি ক্লায়েন্ট হারে বদলে দেয়। এটিই সেই পরিমাপ যার জায়গা ব্যবহারকারী সংখ্যা নেয়, আর এভাবেই আপনি আবিষ্কার করেন যে একটি ভুল কনফিগার করা ক্লায়েন্ট প্রতি রাতে একই সময়ে লিংক ভরিয়ে দেয়।
প্রতি-সেশন সীমা নীতির ভেতরে লুকিয়ে থাকে
সার্ভার অলস থাকতে পারে এবং তবু আপনাকে ব্যান্ডউইথ দিতে অস্বীকার করতে পারে। রেট সীমা, প্রতি-ক্লায়েন্ট ব্যান্ডউইথ সীমা ও ট্রাফিক শেপিং প্রায়ই সাধারণ নাম বা পুল অনুযায়ী প্রয়োগ হয়, তাই একই গেটওয়েতে দুজন ব্যবহারকারী খুব ভিন্ন ফল পেতে পারেন। প্রক্রিয়াটি সূক্ষ্ম নয়, কিন্তু বাইরে থেকে অদৃশ্য, কারণ দুই ক্ষেত্রেই টানেল স্বাভাবিকভাবে ওঠে।
শেপিং খুঁজুন টানেল ইন্টারফেসে, ভৌত ইন্টারফেসে নয়। দেখুন সীমাটি ব্যবহারকারী, সার্টিফিকেট নাকি ঠিকানা পুল অনুসরণ করে। আপনার পরীক্ষার অ্যাকাউন্ট যদি সীমাহীন পুলে পড়ে, আপনি সিদ্ধান্তে আসবেন সার্ভার ঠিক আছে আর অভিযোগকারী ব্যবহারকারী ভুল। সেই সিদ্ধান্ত কোনো সিদ্ধান্ত না থাকার চেয়েও খারাপ, কারণ এটি টিকিট বন্ধ করে দেয়।
একটি নির্দিষ্ট কাজ দিয়ে দুটি এন্ডপয়েন্ট তুলনা করুন
ক্লায়েন্ট দিকের পরীক্ষাটি এখনও চালানোর মতো, তবে কেবল যদি চলকগুলো স্থির থাকে। একই ডিভাইস, একই অ্যাক্সেস নেটওয়ার্ক, একই প্রোটোকল ও একই গন্তব্য ফাইল ব্যবহার করুন, তারপর অনুরূপ দূরত্বে দ্বিতীয় এন্ডপয়েন্টের বিরুদ্ধে পুনরাবৃত্তি করুন। রানের মধ্যে যা কিছু বদলায়, দিনের সময়সহ, ফলাফল দূষিত করে।
ব্যর্থতাগুলো সাফল্যের মতোই যত্নে লিপিবদ্ধ করুন। যে সিরিজে তিনটি এন্ডপয়েন্ট কাজ করে আর একটি সময় শেষ হয়ে যায় তা চারটি গতির সংখ্যার চেয়ে বেশি তথ্যবহুল, কারণ এটি ক্ষমতার নয় পথ বা নীতির সমস্যার দিকে ইঙ্গিত করে। প্রতিটি কেস অন্তত দুইবার চালান; শেয়ার করা নেটওয়ার্কে একটি ধীর নমুনা কিছুই প্রমাণ করে না।
পরিশেষে, আপনি যে সংখ্যাগুলো সংগ্রহ করেছেন সেগুলো যে দাবিকে সমর্থন করে তার সঙ্গে রাখুন। "এই এন্ডপয়েন্টটি যে উইন্ডোতে অন্যটি আটকে গিয়েছিল সেই একই উইন্ডোতে স্থানান্তর সামলেছে" রক্ষণযোগ্য, আর "এই এন্ডপয়েন্টটি দ্রুততর" এমন বিতর্ক ডাকে যা হোমপেজের স্কোর দিয়ে জেতা যায় না। OpenVPN 2.6 ম্যানুয়াল স্টেটাস ফাইল ও শেপিং অপশন নথিভুক্ত করে, যদি হোস্ট পক্ষের সঠিক নির্দেশনা দরকার হয়।