Sp_reset_connication কার্যকর করার জন্য দীর্ঘ সময় নিচ্ছে এর সম্ভাব্য কারণগুলি কী কী?


9

sp_reset_connectionএসকিউএল সার্ভার প্রোফাইলারের মাধ্যমে দেখা হিসাবে কেন সিস্টেম সঞ্চিত পদ্ধতিটি কার্যকর হতে কয়েক মিলিসেকেন্ডের চেয়ে বেশি সময় নিবে ?

আমি এসকিউএল সার্ভার প্রোফাইলার ব্যবহার করে একটি প্রোডাকশন সিস্টেমের থেকে একটি সাধারণ ট্রেস নিয়েছি এবং এরপরে এটি বিশ্লেষণ করতে SqlNexus ব্যবহার করেছি। SQLlNexus নির্দেশ করে যে sp_reset_connication এর সর্বাধিক সংখ্যক সময়কাল রয়েছে - সামগ্রিক ট্রেসের 33%। পর্যবেক্ষণ সময়কাল 0-7 সেকেন্ড (12 থেকে 6,833,270 মাইক্রোসেকেন্ড) থেকে শুরু করে তবে গড় গড়ে 0.956s হয়।

আমি বুঝতে পারি যে যখন পুলের সংযোগটি পুনরায় ব্যবহার করা হয় তখন sp_reset_connication বলা হচ্ছে। আমি একটি পরামর্শ দেখেছি যে বহিরাগত ট্রেসগুলির কারণে এটি ঘটতে পারে তবে এটি মনে হয় না।

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

আমি /server/199974/sp-reset-connication-taking-a-long-time-to-run এও দেখেছি কিন্তু এটি কার্যকর হয়নি।

সম্পাদনা (২০১৩-১২-২৩): সমস্ত ক্ষেত্রে, পঠন এবং লেখার সংখ্যা 0 হয় এবং সিপিইউ প্রায় সর্বদা 0 হয় (16 মিমিতে উভয়ই শূন্য নয় এমন সিপিইউয়ের দুটি উদাহরণ)।


আপনি এই ইভেন্টে পড়া এবং লেখার জন্য কী ধরণের মান দেখছেন?
মার্টিন স্মিথ

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

@ মার্টিন 0 টি লিখেছেন এবং প্রশ্ন 0 টি আপডেট করেছেন। (উইকএন্ডে ডেটাতে অ্যাক্সেস নেই))
হলিস্টিক বিকাশকারী

@ এডওয়ার্ডডোর্টল্যান্ড বেশিরভাগ প্রশ্নের স্পষ্ট লেনদেন বা টেম্প টেবিল ব্যবহার ছাড়াই মোটামুটি সহজ নির্বাচন এবং আপডেট। প্রকৃতপক্ষে, সাধারণত এই সংযোগগুলিতে সম্পাদিত প্রকৃত ক্যোয়ারীগুলি খুব দ্রুত - কেবলমাত্র কয়েক এমএস।
হলিস্টিক বিকাশকারী

@ হলিস্টিক ডেভেলপার - আমি একটি উন্মুক্ত লেনদেন ছেড়ে দিয়ে পরীক্ষা করেছিলাম এবং সেখানে শূন্য নন এমনটি পড়তে এবং লিখতে দেখতে পেলাম তাই সম্মত হলাম এটি তখনকার মতো দেখায় না। এই পরিস্থিতি কি কম বেশি স্থায়ী? যদি তাই হয় আমি একটি বর্ধিত ক্যাপচারিং ঘটনা ট্রেস দৌড়ানো উচিৎ RPC:Starting, RPC:Completedএবং ধরনের অপেক্ষা অল্প সময়ের পরে তথ্য মাধ্যমে সন্ধান কী ধরনের spids সময়ে সম্মুখীন অপেক্ষা দেখতে।
মার্টিন স্মিথ

উত্তর:


9

অবশেষে আরও বিস্তারিত উত্তর লেখার জন্য কিছু সময় পেলাম।

সাধারণত তিনটি প্রধান কারণ রয়েছে যেমন একটি সাধারণ পদ্ধতি sp_reset_connectionচালাতে অনেক বেশি সময় লাগবে।

  1. আপনি সিপিইউ সংস্থানগুলির জন্য অপেক্ষা করছেন
  2. আপনি কোথাও কোনও লককে অবরুদ্ধ করেছেন (সম্ভবত ডিএমএল বা প্রতিযোগিতামূলক লেনদেনের ফলে)
  3. আপনার নেটওয়ার্কটি ধীর গতির এবং ক্লায়েন্টের কাছে ফলাফলটি ফিরিয়ে আনতে অনেক সময় লাগে

বিজ্ঞাপন 1) আপনি যদি সিপিইউ সংস্থানগুলির জন্য অপেক্ষা করেন তবে এটি সিগন্যাল অপেক্ষা হওয়ার সাথে দেখা উচিত। এটি যদি সমস্যা হয় তবে কীভাবে নির্ণয় করতে হবে সে সম্পর্কে আপনার প্রশ্নে আমার মন্তব্য দেখুন

বিজ্ঞাপন 2) আপনি যদি কোনও লকের জন্য অপেক্ষা করেন, তবে দুটি স্ন্যাপশটের তুলনা করে এটি সবচেয়ে ভাল নির্ণয় করা হয় sys.dm_os_wait_stats। এটি করার জন্য এই নিবন্ধটি দেখুন:

আপনি যদি LCK_ [কিছু কিছু] এর জন্য অপেক্ষা করতে দেখেন তবে sys.dm_tran_locksকোন বস্তুটি লক করা হচ্ছে তা অনুসন্ধান করার জন্য ক্যোয়ারী । আপনার ক্ষেত্রে, আমি প্রত্যাশা করব যে কোনও রূপের এসসিএইচ- [কিছু কিছু]> লকগুলি আপনাকে অবরুদ্ধ করছে।

বিজ্ঞাপন 3) প্রথমে OLEDB এবং ASYNC_NETWORK_IO সন্ধানের জন্য নেটওয়ার্ক সমস্যাগুলি নির্ণয়ের সহজতম উপায়টি দ্বিতীয় ধাপে অপেক্ষা করছে (যদি আপনি নেটওয়ার্কের জন্য দীর্ঘ সময় অপেক্ষা করেন, তবে তাদের মধ্যে একটি)। যদি এই অপেক্ষাগুলি বেশি হয়, তবে xperf -on latencyআপনার লেটেন্সিগুলি পরীক্ষা করতে নেটমন বা ওয়্যারশার্কের মতো কোনও নেটওয়ার্ক মনিটরিং প্রোগ্রাম ব্যবহার করুন । যদি নেটওয়ার্কটি ধীর দেখায়, কলিং অ্যাপ্লিকেশন সার্ভারটির সংযোগটি পুনর্ব্যবহারযোগ্য হওয়ার জন্য দ্রুত পর্যাপ্ত সাড়া না দেওয়ার কারণেও এটি হতে পারে।


আমি এখনও সমস্যাটি পুনরাবৃত্তি করতে দেখিনি তাই আমি এই মুহুর্তে আরও নির্ণয়ের জন্য প্রদত্ত উত্তরটি ব্যবহার করতে পারি না। তবে, আমি এসকিউএল সার্ভারের পারফরম্যান্স বিশেষজ্ঞ হিসাবে আপনার খ্যাতির ভিত্তিতে উত্তরটি গ্রহণ করছি accepting
হলিস্টিক বিকাশকারী

2

আমি এই বাগের সাথে সম্পর্কিত হতে পারে এমন একটি বাগের জন্য কেবল একটি কেবি নিবন্ধ জুড়ে এসেছি । ইন ফিক্স: পারফরমেন্স সমস্যার যখন SQL সার্ভার ডাটাবেস লক কার্যকলাপ বৃদ্ধি ঘটতে (কিলোবাইট 2926217), উপসর্গের এক বর্ণনা করে sp_reset_connectionএকটি দীর্ঘ সময় সম্পূর্ণ করতে সময় লাগতে পারে। হটফিক্সটি নিম্নলিখিত আপডেটগুলিতে অন্তর্ভুক্ত রয়েছে:

  • এসকিউএল সার্ভার ২০০৮ এসপি 3 এর জন্য সংক্ষিপ্ত আপডেট 17
  • এসকিউএল সার্ভার 2008 আর 2 এসপি 2 এর জন্য 13 টি সংশ্লেষিত আপডেট
  • এসকিউএল সার্ভার 2012 এসপি 1 এর জন্য সংশ্লেষিত আপডেট 9
  • এসকিউএল সার্ভার ২০১৪ এর জন্য ক্রমবর্ধমান আপডেট 1

যে সার্ভারের উপর আমি এই আচরণটি পর্যবেক্ষণ করেছি সেগুলি এসকিউএল সার্ভার ২০০৪ এসপি 3 টি সংশ্লেষিত আপডেট 5 দিয়ে চলছে, সুতরাং এটি সম্ভবত এই বাগটিটি অনুভব করছিল। আমি এখনও ক্রমযুক্ত আপডেটটি চেষ্টা করে দেখিনি (সমস্যাটি সবসময় পুনরুক্ত হয় না) তাই এটির সমাধান হবে কিনা তা আমি যাচাই করতে পারি না। তবে, কারওর একই লক্ষণ দেখা দিলে আমি তথ্য সরবরাহ করতে চেয়েছিলাম।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.