net.core.somaxconnউচ্চতর মানগুলিতে সেট করা কেবল উচ্চ লোড সার্ভারগুলিতে প্রয়োজন যেখানে নতুন সংযোগের হারটি এত বেশি / বিস্ফোরিত যে 128 (BSD এর মধ্যে 50% বেশি: 128 backlog+ 64 half-open) এখনও-স্বীকৃত সংযোগগুলি স্বাভাবিক হিসাবে বিবেচিত হয় না। অথবা যখন আপনাকে কোনও অ্যাপ্লিকেশনে নিজেই "স্বাভাবিক" সংজ্ঞা অর্পণ করতে হয়।
কিছু প্রশাসক net.core.somaxconnতাদের পরিষেবাগুলির সাথে সমস্যাগুলি আড়াল করতে উচ্চ ব্যবহার করে , তাই ব্যবহারকারীর দৃষ্টিকোণ প্রক্রিয়া থেকে এটি সংযোগ বিঘ্নিত / সময়সীমা ( net.ipv4.tcp_abort_on_overflowলিনাক্স দ্বারা নিয়ন্ত্রিত ) পরিবর্তে একটি বিলম্বিত স্পাইকের মতো দেখাবে ।
listen(2)ম্যানুয়াল বলছে - net.core.somaxconnকোনও অ্যাপ্লিকেশনটির জন্য কেবল উপরের সীমানাটি কাজ করে যা ছোট কিছু চয়ন করতে বিনামূল্যে (সাধারণত অ্যাপ্লিকেশনটির কনফিগারেশনে সেট থাকে)। যদিও কিছু অ্যাপ্লিকেশন কেবলমাত্র listen(fd, -1)যার অর্থ সিস্টেমের দ্বারা অনুমোদিত সর্বোচ্চ মানটিতে ব্যাকলগ সেট করে।
আসল কারণ হ'ল হয় কম প্রসেসিং হার (যেমন একক থ্রেডেড ব্লকিং সার্ভার) বা কর্মীদের থ্রেড / প্রসেসের অপর্যাপ্ত সংখ্যা (যেমন মাল্টি-প্রসেস / থ্রেডেড ব্লকিং সফটওয়্যার যেমন apache/ tomcat)
গীত। কখনও কখনও দ্রুত ব্যর্থ হওয়া এবং ব্যবহারকারীর জন্য অপেক্ষা করার চেয়ে লোড-ব্যালেন্সারের কাজটি (পুনরায় চেষ্টা) করা ভাল fe সে উদ্দেশ্যে আমরা net.core.somaxconnকোনও মান সেট করি এবং উদাহরণস্বরূপ অ্যাপ্লিকেশন ব্যাকলগকে সীমাবদ্ধ করে 1 তে 10সেট net.ipv4.tcp_abort_on_overflowকরি।
PPS। লিনাক্স কার্নেলের পুরানো সংস্করণগুলিতে somaxconএটি 16 টি কম বিট (অর্থাত্ কাস্টিংয়ের মান uint16_t) এর নিকৃষ্ট বাগের ছোটাছুটি রয়েছে , সুতরাং সেই মানটিকে আরও বেশি করে তোলা 65535বিপজ্জনক হতে পারে। আরও তথ্যের জন্য দেখুন: http://patchwork.ozlabs.org/patch/255460/
আপনি যদি লিনাক্সের সমস্ত ব্যাকলগ ইন্টার্নাল সম্পর্কে আরও বিশদে যেতে চান তবে নির্দ্বিধায় পড়ুন:
টিসিপি ব্যাকলগ কীভাবে লিনাক্সে কাজ করে ।