টপ কমান্ড থেকে ওয়ে (আই / ও এর জন্য অপেক্ষা করা) বড়


27

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

root@server:~# top
top - 13:22:08 up 283 days, 22:06,  1 user,  load average: 13.84, 24.75, 22.79
Tasks: 333 total,   1 running, 331 sleeping,   0 stopped,   1 zombie
Cpu(s): 20.6%us,  7.9%sy,  0.0%ni, 13.4%id, 57.1%wa,  0.1%hi,  0.9%si,  0.0%st
Mem:   4053180k total,  3868680k used,   184500k free,   136380k buffers
Swap:  9936160k total,    12144k used,  9924016k free,  2166552k cached

 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
23930 mysql     20   0  549m 122m 6580 S   90  3.1   4449:04 mysqld
17422 www-data  20   0  223m  20m  10m S    2  0.5   0:00.21 apache2
17555 www-data  20   0  222m  19m 9968 S    2  0.5   0:00.13 apache2
17264 www-data  20   0  225m  19m 8972 S    1  0.5   0:00.17 apache2
17251 www-data  20   0  220m  12m 4912 S    1  0.3   0:00.12 apache2

root@server:~# top
top - 13:39:59 up 283 days, 22:24,  1 user,  load average: 6.66, 10.39, 13.95
Tasks: 318 total,   1 running, 317 sleeping,   0 stopped,   0 zombie
Cpu(s): 13.6%us,  4.2%sy,  0.0%ni, 40.5%id, 40.6%wa,  0.2%hi,  0.8%si,  0.0%st
Mem:   4053180k total,  4010992k used,    42188k free,   119544k buffers
Swap:  9936160k total,    12160k used,  9924000k free,  2290716k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
23930 mysql     20   0  549m 122m 6580 S   44  3.1   4457:30 mysqld
19946 www-data  20   0  223m  21m  10m S    5  0.6   0:00.77 apache2
17316 www-data  20   0  226m  23m  11m S    1  0.6   0:01.76 apache2
17333 www-data  20   0  222m  21m  11m S    1  0.5   0:01.55 apache2
18212 www-data  20   0  225m  22m  11m S    1  0.6   0:01.58 apache2
19528 www-data  20   0  220m  13m 5480 S    1  0.3   0:00.63 apache2
19600 www-data  20   0  224m  20m  11m S    1  0.5   0:00.73 apache2
19942 www-data  20   0  225m  21m  10m S    1  0.5   0:00.82 apache2
20232 www-data  20   0  222m  16m 8760 S    1  0.4   0:00.65 apache2
20243 www-data  20   0  223m  21m  11m S    1  0.5   0:00.57 apache2
20299 www-data  20   0  225m  20m   9m S    1  0.5   0:00.67 apache2
20441 www-data  20   0  225m  21m  10m S    1  0.5   0:00.57 apache2
21201 www-data  20   0  220m  12m 5148 S    1  0.3   0:00.19 apache2
21362 www-data  20   0  220m  12m 5032 S    1  0.3   0:00.17 apache2
21364 www-data  20   0  220m  12m 4916 S    1  0.3   0:00.14 apache2
21366 www-data  20   0  220m  12m 5124 S    1  0.3   0:00.22 apache2
21373 www-data  20   0  222m  14m 7060 S    1  0.4   0:00.26 apache2

2
এটি কি কোনও শারীরিক সার্ভার (উত্সর্গীকৃত), বা ভিপিএস বা শেয়ার্ড হোস্টিং সার্ভার? এটি একটি বিশাল পার্থক্য করে।
টম ও'কনর

1
এটি উত্সর্গীকৃত এই সমস্যা সমাধান করা হয়। সার্ভারে চিত্রগুলির জন্য প্রচুর পড়ার অনুরোধ ছিল।
usef_ksa

উত্তর:


33

ডিস্কের ক্রিয়াকলাপ সন্ধানের জন্য কয়েকটি সরঞ্জাম এখানে দেওয়া হয়েছে:

  • iotop
  • vmstat 1
  • iostat 1
  • lsof
  • strace -e trace=open <application>
  • strace -e trace=open -p <pid>

এতে ps auxfআপনি দেখতে পাবেন যে কোন প্রক্রিয়াগুলি বোঝা যায় না এমন ডিস্ক স্লিপে রয়েছে ( D) কারণ তারা I / O এর জন্য অপেক্ষা করছে।

কিছু দিন ভিস্টর সংখ্যা না বাড়িয়ে লোড বৃদ্ধি 40 এ পৌঁছায়।

আপনি একটি ব্যাকআপ তৈরি করতে এবং হার্ডড্রাইভ আস্তে আস্তে ব্যর্থ হচ্ছে কিনা তাও দেখতে চাইতে পারেন। একটি হার্ডড্রাইভ সাধারণত এটি কমে যাওয়ার আগে ধীর হতে শুরু করে। এটি উচ্চ চাপ বোঝাতে পারে।


4

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

I / O একটি ডেটাবেস সার্ভারের জন্য অপেক্ষা করে - বিশেষত লোড স্পাইকগুলিতে - এমন একটি সূত্র যা আপনার ডিবিএমএস হতে পারে ডিস্কে আবদ্ধ (যেমন আপনার একটি দ্রুত ডিস্কের সাবসিস্টেম প্রয়োজন) অথবা এটিতে কোনও টিউনিংয়ের সমস্যা হতে পারে have আপনার ডাটাবেস সার্ভারটি প্রোফাইলিংয়ের দিকেও নজর দেওয়া উচিত - যেমন এটি কী করছে এবং কোন প্রশ্নগুলি সময় নিচ্ছে তা একটি সন্ধান করুন।

ডাটাবেস টিউনিংয়ের সমস্যাগুলি নির্ণয়ের জন্য কিছু স্টার্টার পয়েন্ট: -

  • সর্বাধিক সময় নেয় এমন প্রশ্নের সন্ধান করুন এবং ক্যোয়ারী পরিকল্পনাগুলি দেখুন look কোনও টেবিল স্ক্যানের মতো বিজোড় ক্যোয়ারী পরিকল্পনা রয়েছে কিনা তা দেখুন না। হতে পারে ডাটাবেসের জন্য একটি সূচক যুক্ত করা দরকার।

  • দীর্ঘ রিসোর্সের অপেক্ষার সময়গুলির অর্থ কয়েকটি কী সংস্থান পুলকে প্রসারিত করা দরকার।

  • দীর্ঘ I / O অপেক্ষার সময়ের অর্থ হতে পারে আপনার একটি দ্রুত ডিস্কের সাবসিস্টেম দরকার।

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

    মনে রাখবেন যে কিছু মাইএসকিউএল স্টোরেজ ইঞ্জিন লগ ব্যবহার করে না তাই এটি আপনার ক্ষেত্রে সমস্যা নাও হতে পারে।

পাদটীকা: কুইউিং সিস্টেমগুলি

সিস্টেম স্যাচুরেশনের কাছে যাওয়ার সাথে সাথে কুইউিং সিস্টেমগুলি (থ্রুপুটের জন্য একটি পরিসংখ্যানের মডেল) হাইপারবোলিকভাবে ধীর হয়ে যায়। উচ্চ স্তরের অনুমানের জন্য, 50% স্যাচুরেটেড এমন একটি সিস্টেমের গড় লাইন দৈর্ঘ্য 2 হয়। 90% স্যাচুরেটেড এমন একটি সিস্টেমের দৈর্ঘ্য 10 হয়, 99% স্যাচুরেটেড এমন একটি সিস্টেমের 100% এর ক্যু দৈর্ঘ্য থাকে।

এইভাবে, একটি সিস্টেম যা স্যাচুরেশনের কাছাকাছি রয়েছে, লোডের ছোট ছোট পরিবর্তনের ফলে অপেক্ষার সময়গুলি বড় পরিবর্তন হতে পারে, এক্ষেত্রে I / O এর জন্য অপেক্ষা করার সময় হিসাবে প্রকাশিত হয়। যদি আপনার ডিস্ক সাবসিস্টেমের I / O ক্ষমতা প্রায় স্যাচুরেটেড হয় তবে লোডের ছোট পরিবর্তনগুলির ফলে প্রতিক্রিয়া বারগুলিতে উল্লেখযোগ্য পরিবর্তন আসতে পারে।


2

চালান iotop, বা atop -dD, কি প্রসেস IO করছেন দেখতে। আপনার straceআরও নিবিড় চেহারা প্রয়োজন হলে ব্যবহার করুন ।


1

উভয় স্ক্রিনেই নিশ্চিত মনে হচ্ছে "মাইএসকিএলডি" দায়বদ্ধ।

আপনাকে দেখতে হবে ডিমনটি কী করছে ... কী অনুসন্ধান চলছে।


1

কিছু দিন ভিস্টর সংখ্যা না বাড়িয়ে লোড বৃদ্ধি 40 এ পৌঁছায়।

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

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

যেমনটি অন্যরা উল্লেখ করেছে, এর মতো সরঞ্জামগুলি iotopআপনাকে কোন কাজগুলি I / O প্রতিক্রিয়াগুলির জন্য অপেক্ষা করছে এবং কোন সময়ে তারা কোন ফাইলগুলিতে অ্যাক্সেস করছে তা গভীরভাবে দেখতে আপনাকে সহায়তা করবে।


2
এটি ডেডিকেটেড সার্ভার। আমি পৃথক সার্ভারে মাইএসকিউএল চালানোর সিদ্ধান্ত নিয়েছি। সার্ভার লোড এখন ঠিক আছে, আমি ভবিষ্যতে সমস্যাটি সনাক্ত করতে iotop এর মতো সরঞ্জামগুলি ব্যবহার করব। আপনাদের সবার জন্য অনেক অনেক ধন্যবাদ।
usef_ksa

0

ফ্লিপ যেমন বলেছে, দেখে মনে হচ্ছে সমস্যাটি মাইএসকিএল যা করছে তা প্রায় রয়েছে।

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

কয়েক মিলিয়ন সারি আপডেট করে এমন কোয়েরিগুলি চালানোর সময় আমি কেবল সিপিইউ / ডিস্কের ব্যবহারটি দেখতে পাই।

উচ্চ লোড গড় আই / ও এর প্রত্যক্ষ পরিণতি।

আপনার মাইএসকিএল লগিংটি ক্র্যাঙ্ক করুন এটিতে কোনও খারাপ কোড আছে কিনা তা দেখতে / সূচকগুলি পরিবর্তন করতে সহায়তা করবে। আপনার সারণী বিশ্লেষণ সাহায্য করতে পারে (তবে সম্ভবত খুব বেশি নয়)।

সি

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