কয়টি প্রসঙ্গের স্যুইচগুলি "স্বাভাবিক" (সিপিইউ কোরগুলির ফাংশন হিসাবে (বা অন্য))?


34

হাই লিনাক্স / ইউনিক্স ওভারলর্ডস,

লিনাক্স সার্ভারে কয়টি কনটেক্সট সুইচ (প্রতি প্রসেসর কোর) নরমাল রয়েছে সে সম্পর্কে আপনার কারও কি থাম্বের নিয়ম রয়েছে ?

আমার কলেজটি এখানে এনেছে এবং সে 8-কোর x86_64মেশিনে 16 কে দেখছে ।

গত কয়েকদিন ধরে সরফেস থেকে কিছু পরিসংখ্যান এখানে ...

ALT পাঠ্য

প্রক্রিয়া তৈরির পরিসংখ্যানগুলি দেখতে, এখানে একই গ্রাফের লোগারিথমিক ভিউ দেওয়া হয়েছে ...

Alt টেক্সট http://src.autonomy.net.au/imagebin/7481f7e52bead4effc90248fc23c72fe- চিত্র_11.png

এবং 8 টি কোর মৃত্যুর বিরক্ত হয় ...

Alt পাঠ্য http://src.autonomy.net.au/imagebin/0e94326652e977fd74edcd840f94200f- চিত্র চিত্র_২০.png

সিএস বনাম আইওয়েট (x10000 স্কেল)

Alt পাঠ্য http://src.autonomy.net.au/imagebin/a52a2a8a120394849c0da4045933e306- চিত্র চিত্র_13.png

কেউ যদি জিজ্ঞাসা করেন তবে আরও অকেজো তথ্য ..

  • সার্ভার যে স্টোরেজে কাজ করে তা হ'ল এফসির মাধ্যমে 0.5TB SAN
  • এখানে 8 গিগাবাইট র‌্যাম রয়েছে, বেশিরভাগ ক্যাশে - কোনও অদলবদল হয় না।

1
কোন বিশেষ পিরিয়ডে?
dmckee

কাজের চাপ সম্পর্কে আপনি আরও নির্দিষ্ট হতে পারেন?
dmo

1
আপনি কীভাবে এই গ্রাফটি তৈরি করলেন? সত্যিই দুর্দান্ত লাগছে!
আন্তোইন বেনকামুন

হাই Antoine: - গ্রাফ sarface (থেকে তৈরি করা হয় projects.autonomy.net.au/sarface )
অহশ্বেরশের

গ্রাফের লিঙ্কগুলি এখন পর্যন্ত মারা গেছে। @ Xerxes আপনি কি কোথাও থেকে সেখানে যেতে পারেন?
törzsmókus

উত্তর:


25

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

সিস্টেম কল

সিস্টেম কলগুলি তাদের নিজস্ব প্রকৃতির দ্বারা প্রসঙ্গের স্যুইচগুলির কারণ হয়। যখন কোনও প্রক্রিয়া কোনও সিস্টেম কল করে, এটি মূলত কার্নেলটিকে সময় এবং মেমরির বর্তমান পয়েন্টটি গ্রহণ করার জন্য বলে যে প্রক্রিয়াটি করার সুযোগ পাচ্ছে না, এবং সম্পন্ন হওয়ার পরে একই জায়গায় ফিরে আসবে।

আমরা যখন লিনাক্স থেকে লেখার (2) সিস্কেল এর সংজ্ঞাটি দেখি তখন এটি খুব স্পষ্ট হয়:

NAME এর
       লিখুন - একটি ফাইল বর্ণনাকারী লিখুন

সংক্ষিপ্তসার
       # অন্তর্ভুক্ত 

       ssize_t Writ (int fd, const void * buf, আকার_t গণনা);

বর্ণনা
       লিখুন () ফাইলটিতে বাফার পয়েন্ট বুফ থেকে বাইটস গণনা করতে লিখুন
       ফাইল বিবরণী এফডি দ্বারা উল্লেখ করা হয়। [..]

ফেরত মূল্য
       সাফল্যে, লিখিত বাইট সংখ্যা ফিরে আসে (শূন্য নির্দেশ করে)
       কিছুই লেখা হয়নি)। ত্রুটিতে, -1 ফিরিয়ে দেওয়া হয়েছে, এবং এর্নো সেট করা আছে
       উপযুক্তভাবে।
       [..]

এটি মূলত কার্নেলটিকে প্রক্রিয়াটি থেকে অপারেশন গ্রহণ করতে, countবাইটগুলিতে সরে যেতে , বর্তমান প্রক্রিয়াটির *bufবর্ণনাকারী ফাইল করার জন্য নির্দেশিত মেমরি ঠিকানা থেকে শুরু করে fdপ্রক্রিয়াটিতে ফিরে ফিরে আসে এবং এটি কীভাবে চলে যায় তা তাকে বলে।

এটি দেখানোর একটি দুর্দান্ত উদাহরণ হ'ল ভালভ উত্স ভিত্তিক গেমস, hlds এর ডেডিকেটেড গেম সার্ভার । http://nopaste.narf.at/f1b22dbc9 গেম সার্ভারের কোনও একক দৃষ্টিকোণ দ্বারা সম্পন্ন এক সেকেন্ডের মূল্যবান সিস্টেমে দেখায় যার কোনও খেলোয়াড় নেই। এই প্রসেসটি ব্যয়বহুল হওয়ার জন্য আপনাকে কেবল একটি অনুভূতি দেওয়ার জন্য একটি Xeon X3220 (2.4Ghz) এ প্রায় 3% সিপিইউ সময় নেয়।

একাধিক-কার্য

কনটেক্সট স্যুইচিংয়ের আরেকটি উত্স হতে পারে এমন প্রক্রিয়াগুলি যা সিস্কলগুলি না করে, তবে অন্য প্রক্রিয়াগুলির জন্য জায়গা তৈরি করার জন্য একটি প্রদত্ত সিপিইউ বন্ধ করে দেওয়া দরকার।

এটি কল্পনা করার একটি দুর্দান্ত উপায় হ'ল সিপুবার্ন । সিপবার্ন নিজে নিজে কোনও স্কাইককল করে না, এটি কেবল নিজের মেমরির উপরে পুনরাবৃত্তি করে, সুতরাং এটি কোনও প্রসঙ্গে স্যুইচিংয়ের কারণ হবে না।

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

আরও পড়া

linfo.org প্রসঙ্গের স্যুইচ এবং সিস্টেম কলগুলি কী তা নিয়ে একটি দুর্দান্ত লিখনআপ রয়েছে । উইকিপিডিয়ায় জেনেরিক তথ্য এবং সিস্টেম কলগুলিতে একটি দুর্দান্ত লিঙ্ক সংগ্রহ রয়েছে।


1
এটি দরকারী হয়েছে - আপনি আমাকে একটি দুর্দান্ত ধারণা দিয়েছেন! =)
জেরক্সেস

1
আপনার বক্তব্য System calls cause context switches by their very own natureভুল মনে হচ্ছে। সিস্টেম কলগুলি মোড স্যুইচ হিসাবে কারণ হিসাবে linfo.org/context_switch.html
নিকোলাস ল্যাব্রোট

6

আমার মাঝারিভাবে লোড হওয়া ওয়েবসার্ভার প্রায় 100-150 এ বসে যায় এবং বেশিরভাগ সময় কয়েক হাজারে পিক নিয়ে সেকেন্ডে স্যুইচ করে।

উচ্চ প্রসঙ্গের স্যুইচ রেটগুলি নিজেরাই কোনও সমস্যা নয়, তবে তারা আরও তাত্পর্যপূর্ণ সমস্যার দিকে নির্দেশ করতে পারে।

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

বিকল্প হিসাবে আপনি যদি এক্স চালাচ্ছেন তবে কনসোল মোডে নেমে চেষ্টা করুন।

আবার সম্পাদনা করুন: প্রতি সেকেন্ডে 16k সেকেন্ডে, প্রতিটি সিপিইউ প্রতি মিলিসেকেন্ডে দুটি সুইচ গড়ে তোলে - এটি সাধারণ টাইমলাইসের অর্ধেক থেকে sixth ষ্ঠ। তিনি কি প্রচুর আইও বাউন্ড থ্রেড চালাবেন?

আবার গ্রাফ পোস্ট সম্পাদনা করুন: অবশ্যই আইও আবদ্ধ মনে হচ্ছে। প্রসঙ্গের সুইচগুলি বেশি হলে সিস্টেমটি কি তার বেশিরভাগ সময় এসআইএসে ব্যয় করে?

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

সম্পাদনা: হুমম্ম। ডেডটাইমের সময় বনি ++ বা ডিবেঞ্চ দিয়ে আপনার সান অ্যাক্সেসে কিছু বেঞ্চমার্ক পাওয়ার কোনও সুযোগ? তাদের যদি একই রকম ফলাফল হয় তবে তা দেখতে আগ্রহী হব।

সম্পাদনা: উইকএন্ডে এই সম্পর্কে চিন্তাভাবনা করা এবং আমি যখন অনুরূপ ব্যবহার প্যাটারগুলি দেখেছি যখন বনি "একবারে একটি বাইট লিখুন" পাস করছেন। এটি প্রচুর পরিমাণে স্যুইচিং চলছে তা ব্যাখ্যা করতে পারে, কারণ প্রতিটি লেখার জন্য পৃথক সিস্টাল প্রয়োজন।


আমি এখনও নিশ্চিত নই যে উচ্চ প্রসঙ্গ-স্যুইচ রেট কোনও সমস্যা নয়, আমি 100-150 নয়, 4K থেকে 16K এর মতো উচ্চের কথা বলছি।
জেরক্সেস

আমাদের সার্ভারগুলির কোনওরই কোনও এক্স চালায় না wait IO অপেক্ষার সমস্যা এবং এটির সাথে সম্পর্কযুক্ত CS এর সাথে আমি আপনার সাথে একমত। যদিও এইচবিএ কার্ডটি সন্দেহভাজন নয় যদিও আমরা একই কার্ডটি অন্য শতাধিক সার্ভারগুলিতে ব্যবহার করি ... উপসংহারটি হ'ল আমি সান দলগুলিকে ক্রেপি ইভা সানকে দোষ দিচ্ছি যে তারা সর্বদা চেষ্টা করে এবং রক্ষা করে। নোট করুন যে একটি উচ্চ আইও-ওয়েট সর্বদা সজাগ হওয়ার কারণ নয় , যদি কোনও মেশিনে সর্বাধিক প্রক্রিয়াগুলি আইও-আবদ্ধ থাকে তবে এটি আশা করা যায় যে নিষ্ক্রিয় স্পিনগুলি করার জন্য সার্ভারের থেকে ভাল আর কিছুই থাকবে না।
জেরেক্সেস

দ্বিতীয় সত্ত্বেও - চতুর্থ গ্রাফ সংযুক্ত করে দেখায় যে এটি আমার মতো প্রথমটির চেয়ে খুব কাছাকাছি নয়। কোনওভাবেই ঠিক গ্রহন নয়। আমি এখনও সানকে দোষ দিই। =)
জেরেক্সেস

1

আমি সিস্টেমের রাজ্যের সিপিইউ দখল হার সম্পর্কে উদ্বেগের দিকে বেশি ঝুঁকছি। যদি এটি 10% বা তারও বেশি কাছাকাছি হয়, তার অর্থ আপনার ওএস প্রসঙ্গের সুইচগুলি করতে খুব বেশি সময় ব্যয় করছে A তবে কিছু প্রক্রিয়া অন্য মেশিনে সরিয়ে নেওয়া বেশ ধীর হলেও , এটি করার উপযুক্ত ser


1

এই জাতীয় জিনিসগুলির জন্য আপনাকে আপনার সার্ভারগুলির জন্য পারফরম্যান্সের বেসলাইনগুলি চেষ্টা করা উচিত। এইভাবে, আপনি অতীতে রেকর্ড করা জিনিসগুলির সাথে হঠাৎ করে আপনার লক্ষ্য করা জিনিসগুলির তুলনা করতে পারেন।

এটি বলেছিল, আমার কাছে সার্ভারগুলি চলছে (খুব বেশি ব্যস্ত ওরাকল সার্ভার নয়, মূলত), যা প্রায় 4 কে শৃঙ্গের সাথে প্রায় 2k স্থির থাকে। আমার সার্ভারগুলির জন্য, এটি স্বাভাবিক, অন্য ব্যক্তির সার্ভারগুলির জন্য যা উপায় খুব কম বা খুব বেশি হতে পারে।

আপনার ডেটাতে আপনি কতদূর ফিরে যেতে পারবেন?

আপনি আমাদের কী ধরণের সিপিইউ তথ্য দিতে পারেন?


আমি অবশ্যই একটি বেসলাইন রাখার সাথে একমত হই এবং আমাদের কাছে নাগিওসের ডেটা দীর্ঘ সময় ধরে ফিরে আসে - এই সার্ভারে সমস্যা হ'ল এটি নতুন রক্ত ​​- কেবল অল্প সময়ের জন্যই ছিল। তদ্ব্যতীত, এটি চলমান এন্টারপ্রাইজ (পড়ুন: ক্রেপ) সফ্টওয়্যার - টিমসাইট - কেবল অপরিজ্ঞাত-পরিবর্তনশীল তালিকায় যুক্ত করতে। আমি এখনও সর (ব্যক্তিগত পছন্দ) পছন্দ করি তাই আমি ডিফল্ট (২-সপ্তাহ) এর চেয়ে বেশি রাখার জন্য এটি কনফিগার করব, এবং এটি কীভাবে হয় তা দেখুন।
জেরেক্সেস

Rrdtool (যা দেখতে আপনার গ্রাফগুলি দেখে মনে হচ্ছে) এর সাথে স্যার ব্যবহার করা আপনার ডেটা (বা এটির অন্তত বিমূর্ত) দীর্ঘ সময়ের জন্য রাখার একটি সহজ উপায় হতে পারে।
wzzrd

0

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


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

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

দুঃখিত, আপনি ওএস বিকাশের দৃষ্টিকোণ থেকে প্রসঙ্গের সুইচগুলি হ্রাস করার কথা বলছেন? এ জাতীয় বিকাশের সাথে কিছুই করার নেই, সিএস হ্রাস করার জন্য একটি সিস্টেম ডিজাইনের সুবিধা সম্পর্কে আমার কোনও মতামত নেই :) আপনি যদি কোনও সার্ভারে প্রসঙ্গের স্যুইচগুলি হ্রাস করার কথা বলছেন তবে বিষয়টি প্রসঙ্গের সুইচগুলি হ্রাস করে অন্য জায়গাগুলিতে বিলম্বিতা প্রবর্তন করে। EG মেশিনে প্রক্রিয়াগুলির সংখ্যা হ্রাস করার অর্থ আপনাকে এই প্রক্রিয়াগুলি অন্য একটি মেশিনে স্থানান্তরিত করতে হবে, যার অর্থ একটি নেটওয়ার্কের মধ্যে যোগাযোগ ঘটে, যা অনেক ধীর হয়!
অ্যালেক্স জে

আমি বিশ্বাস করি আপনার প্রসঙ্গের সুইচগুলির সংজ্ঞাটি ত্রুটিযুক্ত; কোনও সিস্টেম কল সঞ্চালিত হয়ে গেলে সেগুলি ঘটে, এমনকি যদি এটি একই থ্রেডে ফিরে আসে। অ্যাপ্লিকেশনগুলি বিভিন্ন কৌশল করে এর বিরুদ্ধে অপ্টিমাইজ করে। উদাহরণস্বরূপ, অ্যাপাচি সিস্টেমের সময় প্রায়শই পাওয়া প্রয়োজন; সেই উদ্দেশ্যে একটি থ্রেড লোকালটাইমকে বারবার কল করে এবং ফলাফলটি ভাগ করে নেওয়া মেমরিতে সঞ্চয় করে। অন্যান্য থ্রেডগুলিকে কেবল র‌্যাম থেকে পড়তে হবে এবং এটি করার সময় কোনও প্রক্রিয়া স্যুইচ লাগবে না।
নিক্সার
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.