সময়ের সাথে প্রক্সির ধীরগতি: conntrack ও রিসোর্স সীমা যাচাই করুন

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

কানেকশন ট্র্যাকিং ব্যবহার করা Linux পথে একটি সম্ভাব্য কারণ conntrack টেবিল। মেশিনে এবং ট্রাফিক পরিচালনা করা নেটওয়ার্ক নেমস্পেসে এই বিদ্যমান মানগুলো যাচাই করুন:

/proc/sys/net/netfilter/nf_conntrack_count
/proc/sys/net/netfilter/nf_conntrack_max

প্রথমটি বরাদ্দ করা ফ্লো এন্ট্রি জানায়; দ্বিতীয়টি সেগুলো সীমিত করে। এগুলো Squid ব্যবহারকারী বা HTTP অনুরোধের সংখ্যা নয়। কার্নেলের ফ্লো অবস্থা অ্যাপ্লিকেশনের সক্রিয় কাজের চেয়ে বেশি দিন টিকে থাকতে পারে।

শুধু বড় সংখ্যা নয়, সম্পর্ক খুঁজুন

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

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

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

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

দরকারি ফল হলো সঞ্চয়ের একটি ব্যাখ্যা এবং তার সাথে মানানসই সক্ষমতা বা জীবনচক্রের পরিবর্তন। বাড়ানো নিরাপদ — এটি এমন বৈশিষ্ট্য নয় যা প্রতিটি প্রক্সি সার্ভার ভাগ করে।