VPN-এর কম থ্রুপুট কি এনট্রপির সমস্যা? সাধারণত না
এলোমেলো সংখ্যার জন্য অপেক্ষারত স্টার্টআপ স্থবিরতা আর ধীর টানেল দুটি আলাদা ত্রুটি। সিডিং বা বাফার বদলানোর আগে মাপুন কোনটি আপনার আছে।
টানেলের মধ্য দিয়ে ধীর থ্রুপুট আর এলোমেলো সংখ্যার জন্য অপেক্ষায় আটকে থাকা মেশিন খুব আলাদা অভিজ্ঞতা দেয়, তবুও তাদের একই অভিযোগের নিচে নথিভুক্ত করা হয়। একটি কাজ শুরু হওয়ার আগেই বিরতি হিসেবে দেখা যায়। অন্যটি এমন সংযোগ হিসেবে দেখা যায় যা কাজ করে এবং আপনি যতক্ষণ দেখেন ততক্ষণ ধীরে ডেটা সরায়। কোনটি আপনার আছে তা ঠিক করতে দশ মিনিট লাগে এবং এক সপ্তাহের অনুমান বাঁচায়।
একই রকম দেখতে দুটি উপসর্গ
নতুন বুটের পরে, একটি সংযোগও গ্রহণ করার আগে আটকে যাওয়া সেবা কিছু একটা অপেক্ষা করছে। যে টানেল দ্রুত প্রতিষ্ঠিত হয় এবং তারপর প্রত্যাশিত হারের একটি ভগ্নাংশে স্থানান্তর করে, তা অন্য কিছু দ্বারা সীমিত। এনক্রিপশন শব্দটি দুই গল্পেই আসে, তাই তাদের একত্র করা হয়। কনফিগারেশন ফাইল স্পর্শ করার আগে তাদের আলাদা করুন।
স্টার্টআপ, প্রমাণীকরণ, কী পুনরায় আলোচনা এবং স্থানান্তরের চারপাশে টাইমস্ট্যাম্প বসান। টানেল ব্যবহারযোগ্য হওয়ার আগে দীর্ঘ বিলম্ব কম স্থির হার নয়, আর দুটিকে একটি সংখ্যায় গড় করলে প্রমাণ নষ্ট হয়।
systemd-analyze blame | head -10 journalctl -u [email protected] -o short-precise | head -40 cat /proc/sys/kernel/random/entropy_avail
প্রথম দুটি কমান্ড স্টার্টআপের কাজকে একটি সময়রেখায় বসায়। তৃতীয়টি কার্নেলের এনট্রপি হিসাবের মান ছাপে, যা একক ডেটা পয়েন্ট হিসেবে উপযোগী এবং ব্যান্ডউইথ মিটার হিসেবে অকেজো।
এলোমেলো সংখ্যার অপেক্ষা আসলে কেমন দেখায়
নিরাপদ এলোমেলো বাইটের অনুরোধ কার্নেল তার এলোমেলো উৎস চালু না করা পর্যন্ত ব্লক হতে পারে। এটি সবচেয়ে বেশি গুরুত্বপূর্ণ ভার্চুয়াল মেশিনে এবং ছোট এমবেডেড বোর্ডে বুটের শুরুতে, যখন সামান্য পরিবেশগত শব্দ সংগ্রহ করা হয়েছে। এটি থেকে বোঝায় না যে প্রতিটি এনক্রিপ্টেড বাইট নতুন এনট্রপি খরচ করে।
আধুনিক জেনারেটর একবার সিড করে এবং তারপর একটি নির্ধারক গঠন থেকে আউটপুট তৈরি করে, নিজেদের সময়সূচিতে পুনরায় সিড করে। বাল্ক স্থানান্তর পুলকে বাইটে বাইটে নিঃশেষ করে না, তাই ধীর স্থানান্তরের সময় কম পুল মান কারণ সম্পর্কে কিছুই প্রমাণ করে না।
strace -f -e trace=getrandom -p $(pidof openvpn) 2>&1 | head -20 dmesg | grep -i 'random\|crng'
প্রথম কমান্ড দেখায় প্রক্রিয়াটি আপনার দেখার সময় এলোমেলো সংখ্যার কলে বসে আছে কি না। দ্বিতীয়টি কার্নেলের নিজস্ব প্রারম্ভিক বার্তা দেখায়, এবং সেখানেই প্রাথমিক বুটের স্থবিরতা দৃশ্যমান হয়।
কার্নেলের সংস্করণ এবং সেবাটি প্রকৃতপক্ষে যে লাইব্রেরির সঙ্গে লিংক করে তা লিখে রাখুন, কারণ আচরণ বাস্তবায়ন এবং সংস্করণভেদে ভিন্ন। পুনরুদ্ধারের পরে নেওয়া ট্রেস সাধারণত বিরতিটি সম্পূর্ণভাবে মিস করে।
দীর্ঘস্থায়ী ধীরতা আসলে কেমন দেখায়
যে টানেল সর্বক্ষণ ধীরে স্থানান্তর করে তা ডেটা পথ দ্বারা সীমিত। একটি সম্পৃক্ত থ্রেড, বাইরের প্যাকেট ক্ষতি, পুনঃপ্রেরণ বা পূর্ণ সকেট সারি — প্রত্যেকে এই ধাঁচ তৈরি করে এবং প্রত্যেকের নিজস্ব সমাধান আছে। সমষ্টিগত CPU শতাংশ একটি ব্যস্ত থ্রেড লুকায়, যা সবচেয়ে সাধারণ ভুল পাঠ। মোট লোড দেখার আগে থ্রেডপ্রতি সময় দেখুন।
তুলনীয় ভিত্তিরেখা দিয়ে উভয় দিকে মাপুন, এবং অ্যাপ্লিকেশনের নিজস্ব প্রতিবেদনের বদলে ইন্টারফেস কাউন্টার দেখুন।
ss -tin dst 203.0.113.10 nstat -az | grep -i 'drop\|retrans' ethtool -S eth0 | grep -i 'drop\|error'
প্রথম কমান্ড একটি সহকর্মীর জন্য সারি ও যানজটের অবস্থা দেখায়। দ্বিতীয় ও তৃতীয়টি স্ট্যাক এবং ইন্টারফেসে ড্রপ ও পুনঃপ্রেরণ জানায়, যেখানে কারণ সাধারণত আগে দেখা যায়।
আপনি যে বাধা মেপেছেন তার জন্য সংশোধন বেছে নিন
যদি প্রমাণ প্রাথমিক বুটের প্রারম্ভিকতার দিকে ইঙ্গিত করে, তবে প্ল্যাটফর্মের সমর্থিত সিডিং পথ দেখুন, যা ভার্চুয়াল মেশিনে হোস্ট-প্রদত্ত এলোমেলো ডিভাইস অন্তর্ভুক্ত করতে পারে। অপরিবর্তিতভাবে অনেক গেস্টে কপি করা সিড ইমেজ স্বাধীন প্রারম্ভিকতার বিকল্প নয়।
যদি প্রমাণ ডেটা পথের দিকে ইঙ্গিত করে, কাউন্টাররা যা ইঙ্গিত করে তা টিউন করুন। সারি উপচে পড়লে বাফার আকার সাহায্য করে এবং একটি থ্রেড সম্পৃক্ত হলে কিছুই করে না। কাউন্টার বাড়ানোর জন্য এনট্রপি ডেমন ইনস্টল করা থ্রুপুট মেরামত নয়, আর গ্রাফ ভালো দেখাতে সিডিং অনুমান বদলানো নিরাপত্তার বৈশিষ্ট্যের বিনিময়ে একটি সংখ্যা কেনা।
পরিবর্তনটি কেবল তখনই গ্রহণ করুন যখন একই পরিমাপ একই অবস্থায় উন্নত হয়। বড় কাউন্টার ফলাফল নয়; সংক্ষিপ্ত মাপা অপেক্ষা বা চিহ্নিত কারণসহ দ্রুততর স্থানান্তরই ফলাফল।