io_stall_writes_ms টেম্পডিবির জন্য এত বেশি কেন?

আমাদের একই ডিস্ক ড্রাইভে ব্যবহারকারী এবং সিস্টেমের ডেটা ফাইল রয়েছে। (Io_stall_writ_ms / (1.0 + num_of_writes)) ব্যবহারকারীর ফাইলগুলির জন্য 2 এর নীচে তবে টেম্পিডবি ফাইলগুলি সাধারণত 400 এর বেশি হয় see আমি দেখতে পাচ্ছি যে কয়েকটি সার্ভারে এবং আমি আগ্রহী যদি কোনও কারণ থাকতে পারে যদি টেম্পডিবিতে লিখতে বেশি সময় লাগে একটি নিয়মিত ডাটাবেস ডেটা ফাইলের চেয়ে।

SELECT DISTINCT UPPER(LEFT(mf.physical_name, 1)) AS Directory,
( io_stall_write_ms / ( 1.0 + num_of_writes ) ) as result, 
io_stall_write_ms, num_of_writes, 
fs.database_id, 
fs.[file_id]
FROM sys.dm_io_virtual_file_stats(NULL, NULL) AS fs
INNER JOIN sys.master_files AS mf ON fs.database_id = mf.database_id
AND fs.[file_id] = mf.[file_id]

ধন্যবাদ,

sql-server sql-server-2008

স্ন্যাপশট বা আরসিএসআই ব্যবহার করছেন? ডেটা / লগ ফাইল হিসাবে একই অ্যারে / ড্রাইভে টেম্পিডবি? অন্যান্য ফাইলের তুলনায় টেম্পডবিতে কতজন লেখেন? নিজস্ব পরিসংখ্যানটি তার প্রসঙ্গে যে প্রেক্ষাপটে ঘটেছে তা ছাড়াই কিছুটা অর্থহীন।

— মার্ক স্টোরি-স্মিথ

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

দীর্ঘ আলোচনা / উত্তর:

এখানে খেলতে দুটি প্রশ্ন রয়েছে -

১) উচ্চ আইও স্টলগুলি দেখলে আমি কী করব?

প্রথমত, "উচ্চ" দর্শকের চোখে পড়ে। আইও স্টলগুলির জন্য যদি আপনাকে 10 ডিবিএ জিজ্ঞাসা করা হয় যে আপনি সম্ভবত তাদের সংখ্যাগুলির সাথে ২-৩ টি বিভিন্ন উত্তর পেয়েছেন, 5-6 "এটি নির্ভর করে" উত্তর এবং একটি ফাঁকা তাকানো। আমার ধারণাটি এখানে গড়ে 400 মাইলের সম্ভাবনা খুব বেশি, বিশেষত যখন অন্যান্য ডিবিগুলি স্টল সময়ের জন্য 2 মিমি বা তার চেয়ে কম হয়।

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

তবে যখন আমার সন্দেহ হয় যে আমার একটি ডিস্ক পারফরম্যান্স সমস্যা রয়েছে বা এই জাতীয় কোনও প্রশ্নের মধ্যে কিছু বন্ধ রয়েছে, তখন আমি সাধারণত একটি প্রক্রিয়া অনুসরণ করি যা দেখে মনে হয়:

সার্ভারে অপেক্ষার পরিসংখ্যান দেখুন। @ সোওয়াশেক নীচের উত্তরে মন্তব্য হিসাবে একটি দুর্দান্ত লিঙ্ক ভাগ করেছেন । এটি আপনাকে এসকিউএল সার্ভারে অপেক্ষার পরিসংখ্যানটি দেখার এবং বিশ্লেষণের বিষয়ে পল রান্ডালের পোস্টে নিয়ে যায়। সেখানে যাও. আপনি কি ধরনের অপেক্ষা করছেন? আপনি আই কর্মক্ষমতা (এর সাথে সম্পর্কিত অপেক্ষা করছে দেখতে পান কি PAGEIOLATCH_*, IO_COMPLETION, WRITELOG, ইত্যাদি?)। আপনি যদি এটি করেন তবে আপনি যদি আইও স্টলের মতো কিছু আইও সম্পর্কিত পারফরম্যান্স সমস্যা পান তবে এটি অন্য একটি ইঙ্গিত দেয় is তবে এটি আপনাকে চুক্তির অন্য রূপ দেয়।
আইও পারফরম্যান্স দেখুন। বিশেষ করে, এ perfmon চেহারা ভিতরে Physical Disk:Avg Disk Sec/Readএবং Avg Sec Disk Sec/Writeকাউন্টারে। এগুলি আপনার বিলম্বকে পরিমাপ করে। পারফরম্যান্স লগ ফাইলে সংরক্ষণ হওয়া সময়ের মধ্যে এই কাউন্টারগুলি দেখুন। গড় হিসাবে আপনি কি দেখেছেন? আপনি যদি 0.020 সেকেন্ড (20 মিমি) এর বেশি নম্বর দেখতে পান তবে এটি একটি সমস্যা হতে পারে। আপনি যদি 40-50ms গড় বা তারও বেশি নম্বর দেখতে পান তবে এটি সমস্যার আরও দৃ a় ইঙ্গিত। আপনার স্পাইকগুলি দেখুন? তারা কত উঁচুতে যায় এবং কত দিন স্থায়ী হয়? আপনি যদি কয়েকশো এমএসে স্পাইকগুলি দেখতে পান এবং সে দশক বা স্কোর কয়েক সেকেন্ড বা তার বেশি সময় ধরে এবং / বা ঘন ঘন ঘটে তবে আপনার কাজের চাপের জন্য আপনার আইও পারফরম্যান্স নিয়ে কোনও সমস্যা হওয়ার সম্ভাবনা বেশি।
আপনার আইও সেটআপটি দেখুন। এটা কি? লোকাল ডিস্ক? সান? স্টোরেজ অ্যারে? এর বাইরে আপনার কী ধরণের এবং আইওপিগুলি দেখতে হবে? আপনি যা করার চেষ্টা করছেন তা কি যথেষ্ট? আপনার কাজের চাপের জন্য আপনি নিজের আইওকে আন্ডারস্কৃত করতে পারেন। কেবল আপনার শারীরিক স্পিন্ডল, RAID সেটিংস ইত্যাদির দিকে নজর রাখবেন না your আপনি কি খুব বেশি অন্যান্য ট্র্যাফিকের সাথে ভাগ করে নিচ্ছেন এমন একক 1 জিবি লিঙ্কের মাধ্যমে সমস্ত কিছুতে চাপ দিচ্ছেন? আপনি কি স্টোরেজের দৃষ্টিকোণ থেকে ডিস্ক পারফরম্যান্সের মেট্রিকগুলিতে দেখতে পারেন?

( দ্রষ্টব্য: এই অপেক্ষার পরিসংখ্যান বিশ্লেষণ এবং পারফমন বিশ্লেষণের জন্য - বিভিন্ন সময়সীমার এবং ব্যবহারের ধরণটি দেখুন day দিনের বেলা থেকে আপনি কি রাতের বেলা বিভিন্ন ব্যবহারের পরিসংখ্যান রাখেন? ব্যাচ প্রসেসিং উইন্ডো? রক্ষণাবেক্ষণ উইন্ডো যেখানে আপনি প্রচুর সূচি পুনর্নির্মাণ করেন? এই প্রতিটি সময়কালে এই সরঞ্জামগুলি দেখুন এবং আপনি প্রতিটিটির জন্য কী দেখছেন তা বুঝতে পারেন)

এখানে অন্য আইও পারফরম্যান্স বিবেচনা -

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

২) টেম্পডিবি উচ্চতর হতে পারে এমন কিছু কারণ কী?

সুতরাং টেম্পডিবি একটি ডাটাবেস এবং এটি যেমন আমি আলোচনা করেছি তেমন অন্য কোনও ডাটাবেসের মতো আইও স্টল থাকতে পারে। তবে টেম্পডিবিতে উচ্চতর পড়ার কিছু কারণ কী? (সম্পূর্ণ নয়, আমি সম্পাদনা, অন্যান্য উত্তর বা মন্তব্যে সংযোজন বা চিন্তাকে স্বাগত জানাই) -

আপনার কোডের কারণে - আপনি উদ্দেশ্যমূলকভাবে কোডে টেম্পডিবি ব্যবহার করছেন? প্রচুর টেম্প টেবিল এবং টেবিলের ভেরিয়েবলগুলি তৈরি এবং ধ্বংস? টেম্পডিবিতে এভাবে প্রচুর কাজ করা হচ্ছে? এটি অগত্যা খারাপ বা ভাল নয় তবে আপনি এটি দেখতে পারেন এবং আপনার উদ্দেশ্যমূলক টেম্পডিবি ব্যবহারের ধরণটি বুঝতে পারেন।
টেম্পডিবি একটি ভাগ করা ওয়ার্কহর্স - টেম্পডিবি হ'ল একটি ডাটাবেস যা ব্যবহারকারীর দ্বারা সংজ্ঞায়িত অস্থায়ী বস্তু এবং আপনার সম্পূর্ণ এসকিউএল উদাহরণ দ্বারা ব্যবহৃত বিভিন্ন কাজের টেবিল এবং ক্রিয়াকলাপের জন্য অস্থায়ী স্থান হিসাবে ব্যবহৃত হয়। কতজন ব্যবহারকারী ডিবি রয়েছে? আপনি সাধারণত কোন ধরণের কাজের চাপ দেখতে পান? সমস্ত জিনিস ভাগ করে নেওয়ার জন্য টেম্পডিবি হ'ল একটি উত্স।
অপর্যাপ্ত ক্যোয়ারী এবং অপর্যাপ্ত মেমরি - সম্ভবত এমন কিছু প্রশ্ন রয়েছে যা সূচিগুলি যথাযথভাবে ব্যবহার করছে না বা বড় স্ক্যান এবং সাজানোর ক্রিয়াকলাপ করছে। বড় হ্যাশ অপারেশন, এবং সার্ভারে থাকা মেমরি এগুলির জন্য পর্যাপ্ত নয়। এই অপারেশনগুলি পর্দার আড়ালের ওয়ার্ক টেবিল হিসাবে টেম্পডিবিতে "ছড়িয়ে পড়বে"। কখনও কখনও এটি আপনার ক্যোয়ারী পরিকল্পনা এবং সূচীকরণ বা কোয়েরি টিউনিংয়ের সাথে এড়ানো যায়। কখনও কখনও এটি ঘটে (গুদামের কাজের চাপের উপর আরও বেশি, আমি খুঁজে পাই)। আপনার যদি পর্যাপ্ত স্মৃতি থাকে তবে এটি সহায়তা করতে পারে তবে এই কোয়েরিগুলি এখনও মাঝে মাঝে ছড়িয়ে দিতে পারে। এটিও দেখুন Look
আপনি কি আপনার সিস্টেমে ন্যায্য সংখ্যক আপডেটের সাথে প্রতিশ্রুতিবদ্ধ স্ন্যাপশট বিচ্ছিন্নতা স্তরটি ব্যবহার করছেন? এর ফলে টেম্পডিবি ক্রিয়াকলাপ বাড়তে পারে।

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

— মাইক ওয়ালশ
সূত্র

-4

টেম্পডিবি সমস্ত ডাটাবেসের মধ্যে উদাহরণ হিসাবে ভাগ করা আছে। তাই মাঝে মাঝে নির্দিষ্ট পৃষ্ঠাগুলির জন্য টেম্পডিবি-র মধ্যে বিতর্ক থাকতে পারে: এসজিএএম , গ্যাম এবং পিএফএস । সংক্ষেপে, এই পৃষ্ঠাগুলি এখনও অবধি টেম্পডিবিতে কী ব্যবহার করা হয়েছে এবং যেখানে নতুন ব্যবহারের জন্য স্থান উপলব্ধ তা ট্র্যাক করে।

সাধারণত, এটি টেম্পডিবিতে একাধিক ডেটা ফাইল যুক্ত করে মোকাবেলা করা হয়। সঠিক সংখ্যা হিসাবে কয়েকটি পৃথক দর্শন রয়েছে, তবে সকলেই সম্মত হন যে আপনার একাধিক হওয়া উচিত।

এখানে চালানোর জন্য কয়েকটি প্রশ্ন রয়েছে ...

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

-- tempdb layout
use tempdb
go
exec sp_helpfile
go

এটি আপনাকে দেখায় যে আপনার কতটি সিপিইউ এবং কোর রয়েছে।

-- cores and hyperthreading
select cpu_count, hyperthread_ratio 
from sys.dm_os_sys_info
go

এটি আপনাকে দেখিয়ে দেবে যে আপনার প্রতি NUMA নোডের জন্য কতগুলি NUMA নোড এবং কোর রয়েছে।

-- numa nodes and schedulers
select node_id, online_scheduler_count
from sys.dm_os_nodes
order by node_id
go

টেম্পডিবিতে কোন পৃষ্ঠাগুলি অপেক্ষা করছে তা এইটি আপনাকে দেখায়।

-- see if anything is waiting on tempdb
select * 
from sys.dm_os_waiting_tasks
where resource_description like '2:%'
go

এখানে একটি নিবন্ধ যা পৃষ্ঠা বিষয়বস্তু ইস্যুতে কিছুটা গভীরতায় যায়।

ঠিক আছে, তাই এখন দর্শনের অংশ ... :-)

নিজের জন্য, আমি যদি কোনও এসএমপি সিস্টেমে থাকি তবে আমি কেবলমাত্র মোট কোরের অর্ধেক ফাইল চাই ।

আমি যদি একটি NUMA সিস্টেমে থাকি তবে আমি কেবলমাত্র NUMA নোডের চেয়ে বেশি ফাইল চাই ।

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

আমি যদি সমস্যাটি দেখতেই থাকে তবে আমি আরও দুটি যুক্ত করব। আবার চেক করুন, আরও যুক্ত করুন এবং বিতর্ক অদৃশ্য হওয়া পর্যন্ত পুনরাবৃত্তি করুন।

— স্টিভেন
সূত্র

-1 দুঃখিত, এখানেও FUD এর ন্যায্য অংশ রয়েছে। গ্যাম / এসজিএএম / পিএফএসের বিতর্কটি ল্যাচ কনটেন্ট হিসাবে উদ্ভাসিত হয়, এটি বর্ধিত আইও অপেক্ষা করতে পারে না, যা ওপিএস প্রশ্নের কেন্দ্রবিন্দু।

— মার্ক স্টোরি-স্মিথ

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

— সোয়াশেক

এখানেই

— স্বশেক করুন

@ মার্ক - স্পষ্টির জন্য আপনাকে ধন্যবাদ। আমি প্রতিক্রিয়া প্রশংসা করি।

— স্টিভেন