উইন্ডোজ ২০০৮-এ TIME_WAIT রাজ্যে প্রচুর পরিমাণ টিসিপি সংযোগ রয়েছে - অ্যামাজন এডাব্লুএসে চলছে

Question

ওএস: উইন্ডোজ সার্ভার 2008, এসপি 2 (ইসি 2 অ্যামাজনে চলছে)।

অ্যাপাচি httpd এবং টোমক্যাট সার্ভার 6.02 এবং ওয়েব সার্ভার ব্যবহার করে ওয়েব অ্যাপ্লিকেশন চালিয়ে যাওয়া- জীবিত সেটিংস রয়েছে।

TIME_WAIT রাজ্যে টিসিপি সংযোগ রয়েছে (ব্যবহৃত নেটট্যাট এবং টিসিপিভিউ) প্রায় 69,250 (HTTP পোর্ট 80) + 15000 (পোর্ট 80 ছাড়া অন্য) টিসিপি সংযোগ রয়েছে। ওয়েব সার্ভার বন্ধ করার পরেও এই সংযোগগুলি বন্ধ হবে বলে মনে হচ্ছে না (24 ঘন্টা অপেক্ষা করা হয়েছে)

পারফরম্যান্স মনিটর কাউন্টার:

• টিসিপিভি 4 সক্রিয় সংযোগগুলি: 145 কে
• টিসিপিভি 4 প্যাসিভ সংযোগগুলি: 475 কে
• টিসিপিভি 4 ব্যর্থতার সংযোগগুলি: 16 কে
• TCPv4 সংযোগগুলি পুনরায় সেট করুন: 23 কে

HKEY_LOCAL_MACHINE\System \CurrentControlSet\Services\Tcpip\Parameters TcpTimedWaitDelay কী নেই, সুতরাং মানটি ডিফল্ট হওয়া উচিত (2 * MSL, 4 মিনিট)

এমনকি যদি হাজার হাজার সংযোগের অনুরোধ একই সাথে আসে, তবে উইন্ডোজ ওএস কেন শেষ পর্যন্ত সেগুলি পরিষ্কার করতে সক্ষম হয় না?
এই পরিস্থিতির পিছনে কারণগুলি কী হতে পারে?
উইন্ডোজ ওএস পুনরায় চালু না করে এই সমস্ত TIME_WAIT সংযোগকে জোর করে বন্ধ করার কোনও উপায় আছে কি?

কিছু দিন পরে আমরা অ্যাপ্লিকেশন কোনও নতুন সংযোগ নেওয়া বন্ধ করে দেয়।

Answer 1

আমরাও এই সমস্যাটি নিয়ে কাজ করেছি। দেখে মনে হচ্ছে অ্যামাজন মূল কারণটি খুঁজে পেয়েছে এবং এটি সংশোধন করেছে। তারা আমাকে যে তথ্য দিয়েছে তা এখানে।

হাই, আমি কী কারণে এই সমস্যাটি সৃষ্টি করছিল তার একটি ব্যাখ্যা নীচে আটকানো করছি। সুসংবাদটি হ'ল এটি আমাদের ইঞ্জিনিয়ারিং টিম খুব সম্প্রতি স্থির করেছে। ঠিক করার জন্য, আপনাকে যা করতে হবে তা হ'ল উইন্ডোজ সার্ভার ২০০৮ এর উদাহরণগুলি থামাতে বা শুরু করতে হবে যেখানে আপনি এই সমস্যাটি দেখছেন। আবার, আমি রিবুট সম্পর্কে বলছি না যা ভিন্ন। স্টপ / START উদাহরণটি অন্য (স্বাস্থ্যকর) হোস্টে স্থানান্তরিত করে। যখন এই দৃষ্টান্তগুলি আবার চালু হয়, তখন তারা হোস্টগুলিতে চলছে যেখানে স্থির জায়গা ঠিক আছে তাই তাদের আর এই সমস্যা হবে না। এখন নীচে এই ইস্যুটির ইঞ্জিনিয়ারিংয়ের ব্যাখ্যা দেওয়া হল। গভীর তদন্তের পরে, আমরা খুঁজে পেয়েছি যে সর্বাধিক উপলভ্য উদাহরণস্বরূপ উইন্ডোজ 2008 x64 চালানোর সময় আমরা ' একটি সমস্যা চিহ্নিত করেছেন যার ফলে টিসিপি সংযোগগুলির ফলে অত্যধিক দীর্ঘ সময়ের জন্য TIME_WAIT / CLOSE_WAIT অবধি থাকতে পারে (কিছু ক্ষেত্রে, এই অবস্থায় অনির্দিষ্টকালের জন্য রয়ে গেছে)। এই রাজ্যগুলিতে থাকাকালীন, নির্দিষ্ট সকেট জোড়া অপ্রয়োজনীয় থেকে যায় এবং পর্যাপ্ত পরিমাণে জমে থাকলে, পোর্টগুলি প্রশ্নবিদ্ধভাবে ক্লান্তি ছাড়বে। যদি এই বিশেষ পরিস্থিতি দেখা দেয় তবে সকেট জুটিগুলি প্রশ্নে পরিষ্কার করার একমাত্র সমাধান হ'ল প্রশ্নের পুনরায় বুট করা। আমরা উইন্ডোজ ২০০৮ কার্নেল এপিআই-তে টাইমার ফাংশন দ্বারা উত্পাদিত মান হিসাবে কারণ নির্ধারণ করেছি যা আমাদের 64৪-বিট প্ল্যাটফর্মে অনেক সময় মাঝে মধ্যে এমন একটি মান পুনরুদ্ধার করে যা ভবিষ্যতে অত্যন্ত দূরে থাকে। এটি TCP সকেট জোড়ায় টাইমস্ট্যাম্পগুলি ভবিষ্যতে উল্লেখযোগ্য পরিমাণে স্ট্যাম্পের কারণে টিসিপি স্ট্যাককে প্রভাবিত করে। মাইক্রোসফ্টের মতে, এখানে একটি সঞ্চিত संचयी কাউন্টার রয়েছে যা এই এপিআই কল দ্বারা উত্পাদিত মানটি संचयी মানের চেয়ে বড় না হলে আপডেট হবে না। চূড়ান্ত ফলাফল হ'ল এই পয়েন্টের পরে তৈরি সকেটগুলি ভবিষ্যতের সময় পৌঁছানো পর্যন্ত ভবিষ্যতে খুব বেশি স্ট্যাম্প করা হবে। কিছু ক্ষেত্রে, আমরা ভবিষ্যতে কয়েকশ দিন এই মানটি দেখেছি, এইভাবে সকেটের জুড়ি চিরকালের জন্য আটকে রয়েছে।

Comments

এই থ্রেডটি দুই সপ্তাহ পুরানো মত এবং কোনওভাবে আপনি আমার প্রতিক্রিয়া সেকেন্ডের আগে পোস্ট করেছিলেন। দুর্দান্ত খবর! তারা এখন কয়েক মাস ধরে আমাদের দৌড়াদৌড়ি করছে।

— মার্ক বলিঞ্জার

@ মার্কবোলিংগার: আপনার উল্লিখিত থ্রেডের জন্য কেবলমাত্র ডাব্লুএসএস দলের প্রতিক্রিয়ার মাধ্যমে আপনার উত্তরটি খুঁজে পেয়েছে ( সিস্টেম.ডায়াগনস্টিকস।স্টপওয়াচটি কাজ করছে না ) - যে থ্রেডটি এখনও অপ্রত্যাশিত, তবে এখানে আপনার মন্তব্যটি সম্ভবত এটি ইতিমধ্যে সম্বোধন করা হয়েছে বলে মনে হচ্ছে তথ্য @ গ্রেগবি উদ্ধৃত? বা QueryPerformanceCounterইস্যুটির মূল কারণটি এখনও স্থানে থাকতে পারে এবং কেবলমাত্র টিসিপি ইস্যুটিই প্রতিকার পেয়েছে? আপনার অন্তর্দৃষ্টি জন্য ধন্যবাদ!

— স্টিফেন ওপেল

Answer 2

রায়ের উত্তরটি ভাল সাধারণ পরামর্শ ব্যতীত এটি ইসির 2 তে রবি যে অবস্থায় পড়ছে তাতে প্রযোজ্য না। আমরাও এই সমস্যাটি দেখেছি এবং যে কোনও কারণেই উইন্ডোজ পুরোপুরি TcpTimedWaitDelay উপেক্ষা করছে এবং সকেটটিকে তার TIMED_WAIT রাজ্য থেকে কখনই ছাড়বে না।

অপেক্ষা করা সাহায্য করে না ... অ্যাপ্লিকেশনটি পুনরায় চালু করা সাহায্য করে না ... ওএস পুনরায় চালু করা আমাদের একমাত্র প্রতিকার। সত্যিই কুৎসিত।

Answer 3

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

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

আমরা যা করি তা পটভূমিতে একটি পরিষেবা চালানো হয় যা TIME_WAIT রাজ্যে সকেটের সংখ্যা নিয়ে অনুসন্ধান করে এবং এটি একবার যদি একটি নির্দিষ্ট প্রান্তিকের উপর দিয়ে যায়, আমরা ব্যবস্থা নিই (সার্ভারটি পুনরায় বুট করুন)। একরকম মধ্যে গত 45 সেকেন্ডের , কেউ নির্দিষ্ট যে আপনার / বন্ধ করতে পারবেন সার্ভার আরম্ভ সমস্যাটি সমাধানের জন্য - আমি তোমাকে দম্পতি এই দুটি পন্থা সুপারিশ।

Answer 4

উইন্ডোজে টিসিপি স্ট্যাকের জন্য ডিফল্ট সেটিংস হ'ল এইচটিটিপি সার্ভার হোস্ট করতে যাওয়া সিস্টেমগুলির পক্ষে সর্বোত্তম নয়।

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

আমি কয়েক বছর আগে এটিতে নিজের কাছে একটি নোট লিখেছিলাম , যদি শুরু করতে আমার কিছু দ্রুত ডিফল্ট প্রয়োজন হয়। প্যারামিটারগুলি নির্দ্বিধায় অনুভব করুন এবং তারপরে তাদের টুইট করুন।

Answer 5

এডাব্লুএস-এর সাথে সম্পর্কিত নয়, আমরা কেবল এই সমস্যায় পড়েছি, এটি এই কেবি নিবন্ধের ফলাফল হিসাবে মনে হচ্ছে:

http://support.microsoft.com/kb/2553549/en-us

মূলত, 499 দিনের জন্য কোনও সিস্টেম আপ থাকে এবং হটফিক্স প্রয়োগ না করা হলে এটি কিক করে। একটি রিবুট অবশ্যই এটি সরিয়ে দিয়েছে - হটফিক্সটি কাজ করে কিনা আমরা পরবর্তী 16 মাসের জন্য জানতে পারি না, তবে এটি দীর্ঘকালীন সার্ভার আছে এমন কাউকে সাহায্য করতে পারে there

Comments

কত অদ্ভুত দিন। আমরা এটি দ্বারা মাত্র কামড়েছি - 500 দিন 12 ঘন্টা আপটাইম। যাইহোক এই বাক্সটি ডিকমম করার সময়।

— জোশ স্মিটন

Answer 6

আমি এসপি 1 এর সাথে উইন্ডোজ সার্ভার 2008 আর 2 এক্স 64 এর বেশিরভাগ বাক্সে প্রায় ঠিক একই জিনিসটি অনুভব করছিলাম, বেশিরভাগই CLOSE_WAIT (যা TIME_WAIT এর চেয়ে কিছুটা আলাদা)। মাইক্রোসফ্টে একটি কেবি এবং একটি হটফিক্সের রেফারেন্স দেওয়া এই উত্তরে আমি ঘাঁটাঘাঁটি করেছি যদি সার্ভারগুলি কোনও লোড ব্যালান্সারের (যা আমার হয়) এর পিছনে চলছে। হটফিক্স ইনস্টল করার পরে এবং রিবুট করার পরে, সমস্ত CLOSE_WAIT স্টাফ সমাধান করা হয়েছিল।