লিনাক্স মেমরি বিভাজন


20

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

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


আমি কেবল দ্রুত কমান্ডলাইন সমাধানগুলি দেখছি না, কোনও সাধারণ প্রোগ্রাম / তত্ত্বটিও করবে। অতএব, আমি সার্ভারফল্টে জিজ্ঞাসা করি নি।
রঘু

1
আমি এখানে একটি বিষয় বুঝতে পারি না। আমি যতদূর বুঝতে পারি মেমরি বিভাজন অবশ্যই মেমরির ঘাটতির কারণ হতে পারে এবং ফলস্বরূপ মেমরির বরাদ্দের ত্রুটির জন্য। তবে আপনি কর্মক্ষমতা হ্রাস সম্পর্কে জিজ্ঞাসা করছেন। আপনার প্রচুর স্মৃতি ডিস্কে বদলে যাওয়ার কারণে এটি? এবং যদি তাই vmstatহয় তাহলে মাঠে কি দিতে so?

@ এসকিউএলএসপি - আরও সুনির্দিষ্ট হওয়ার জন্য আমার উত্তর সম্পাদনা করেছে।
টিম পোস্ট

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

@ টিম - যেমন আমি পরামর্শ দিয়েছি এটি কেবলমাত্র বাশ / ক্লিপ কমান্ড নয় যেটি আমি জানতে চেয়েছিলাম, আমার বেঞ্চমার্কিং পদ্ধতিতে (ফলাফলগুলি বিশ্লেষণ করার জন্য, এটি চালানোর জন্য নয়) আমাকে সহায়তা করার জন্য আমার তথ্যের প্রয়োজন ছিল।
রঘু

উত্তর:


12

আমি ট্যাগের জবাব দিচ্ছি । আমার উত্তরটি কেবল লিনাক্সের ক্ষেত্রে নির্দিষ্ট ।

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

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

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

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

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

আরও স্মৃতি যুক্ত করুন, বা দাবিদার malloc()গ্রাহকরা বিভক্ত করুন :) এটি কেবল খণ্ডন নয় যা আপনার দিকে নজর দেওয়া দরকার।

vmstatআসলে কোথায় সংরক্ষণ করা হচ্ছে তার একটি ওভারভিউ পাওয়ার চেষ্টা করুন ।


উত্তরের জন্য ধন্যবাদ. আমি মাইএসকিএল - ইন্নাডব বাফার পুল - এর জন্য কতটা ভাল ভাড়া (সিসবেঞ্চ ব্যবহার করে) ব্যবহার করছে তা দেখতে বিশাল পৃষ্ঠাগুলি (আকার = 2048 কেবি) ব্যবহার করছিলাম। প্রথমদিকে যখন প্রক্রিয়াটি আপটাইম (এবং এমনকি সিস্টেম আপটাইম) কম ছিল, এটি খুব ভাল ফলাফল দিচ্ছিল। যাইহোক, এর পারফরম্যান্স বেশ কয়েকটি রান ওভারকে হ্রাস করতে শুরু করে। আপনার উল্লিখিত পৃষ্ঠাটি সম্পর্কে, আমি অবশ্যই একটি উচ্চ ভিএম ক্রিয়াকলাপ লক্ষ্য করেছি, তবে আমি অনুমান করেছি যে এটি সম্ভবত বেঞ্চমার্ক এবং ইন্নাডব লগ ফ্লাশিংয়ের কারণে হয়েছে (ভিএম ক্রিয়াকলাপটি বিশাল পৃষ্ঠাগুলির চেয়ে বেশি)। আমি vm.sppppiness 1 এ সেটও করেছি আমি কোনও কঠোর পরিবর্তন লক্ষ্য করতে পারিনি।
রঘু

সূক্ষ্ম ম্যানুয়াল অনুসারে , "মেমরির চাপের মধ্যে বিশাল পৃষ্ঠাগুলি মুছতে পারে না।" আমি মনে করি এটি ডাব্লু / আর / টি স্ট্যান্ডার্ড মেমরির একটি ভাল উত্তর তবে হুইটপেজের জন্য নয়।
ড্যান প্রিটস

5

শাঁস

বর্তমান বিভাজন সূচকের ব্যবহার পেতে:

sudo cat /sys/kernel/debug/extfrag/extfrag_index

কার্নেল মেমরি ডিফল্ট করতে এক্সিকিউট করার চেষ্টা করুন:

sysctl vm.compact_memory=1  

এছাড়াও আপনি স্বচ্ছ বিশাল পৃষ্ঠাগুলি (ওরফে টিএইচপি) এবং / অথবা অদলবদল (বা হ্রাস swappiness) অক্ষম করার চেষ্টা করছেন ।

ইউজার-স্পেস

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

আপনি আপনার প্রোগ্রামটি এটির সাথে পুনরায় সংবিধানের মাধ্যমে বা কেবল আপনার প্রোগ্রামটি চালিয়ে কাস্টম ম্যালোকে স্যুইচ করতে পারেন LD_PRELOAD: LD_PRELOAD=${JEMALLOC_PATH}/lib/libjemalloc.so.1 app ( টিএইচপি এবং মেমরি মেমোরি বরাদ্দকারীদের মধ্যে মিথস্ক্রিয়া থেকে সাবধান থাকুন )

যদিও, মেমরি বিভাজনের সাথে কিছুটা সম্পর্কযুক্ত নয় (তবে মেমোরি সংযোগ / মাইগ্রেশনের সাথে সংযুক্ত), আপনি সম্ভবত আপনার পরিষেবাটির একাধিক ইনস্ট্যান্স চালাতে চান, প্রতিটি NUMA নোডের জন্য একটি এবং সেগুলি ব্যবহার করে আবদ্ধ করতে চান numactl


1
আপনি কেন ভাবেন যে অদলবদল অক্ষম করা সাহায্য করতে পারে? আমার কাছে মনে হয় অদলবদল অক্ষম করা আরও বেশি আঘাত করবে।
ক্যাস্পারড

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

2
পর্যাপ্ত পরিমাণে অদলবদল করা কর্মক্ষমতা উন্নত করবে। আপনার যদি অপর্যাপ্ত অদলবদলের জায়গা থাকে তবে পারফরম্যান্সের সমস্যাগুলি হ'ল অদলবদ সক্ষম করার যথেষ্ট কারণ।
ক্যাস্পারড

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

2
"কেবল যদি তারা মনে করে যে তারা উপকারী" - এটি অতিরিক্ত হিউরিস্টিক যুক্ত করে এবং সিস্টেমটিকে কম অনুমানযোগ্য করে তোলে। এছাড়াও পৃষ্ঠার প্রতিস্থাপন অ্যালগরিদমগুলি (অদলবদল এবং বেনামে ব্যবহৃত mmap) বিভিন্ন কার্নেলগুলিতে (যেমন লিনাক্স বনাম ফ্রিবিএসডি বনাম), বা একই OS এর বিভিন্ন সংস্করণে (2.6.32 বনাম 3.2 বনাম 3.10) আলাদাভাবে প্রয়োগ করা হয় .. "এটি পরিবর্তিত পৃষ্ঠাগুলির অনুমতি দেয় [। ..] শারীরিক মেমরি থেকে [...] থেকে বেরিয়ে আসা - যা মেমরির ফাঁসগুলি গোপন করবে। "কেসগুলি পরিচালনা করুন যেখানে ব্যবহারের চেয়ে অনেক বেশি মেমোরি সংরক্ষিত রয়েছে" - ধীর ব্যবস্থা ডাউন সিস্টেমের চেয়ে অনেক খারাপ, সুতরাং "বুদ্ধিমান" প্রশ্নবিদ্ধ।
SaveTheRbtz

4

বিশাল পৃষ্ঠা ব্যবহারের ফলে লিনাক্সে অতিরিক্ত মেমরি বিভাজন ঘটানো উচিত নয়; বিশাল পৃষ্ঠাগুলির জন্য লিনাক্স সমর্থনটি কেবল শেয়ার্ড মেমোরির জন্য (shmget বা mmap এর মাধ্যমে) হয় এবং যে কোনও বিশাল পৃষ্ঠাগুলি অবশ্যই বিশেষভাবে অনুরোধ করা উচিত এবং সিস্টেম অ্যাডমিন দ্বারা পূর্বনির্ধারণ করতে হবে। স্মৃতিশক্তি একবার হয়ে গেলে সেগুলি সেখানে পিন করা থাকে এবং অদলবদল হয় না। মেমরি বিভাজনের মুখে বিশাল পৃষ্ঠাগুলিতে অদলবদল করার চ্যালেঞ্জ হ'ল তারা কেন মেমোরিতে পিন থাকে (যখন 2MB বিশাল পৃষ্ঠা বরাদ্দ করা হয় তখন কার্নেলটি অবশ্যই 512 সংক্ষিপ্ত ফ্রি 4KB পৃষ্ঠাগুলি সন্ধান করতে হবে যা সম্ভবত উপস্থিত নেই)।

বিশাল পৃষ্ঠাগুলিতে লিনাক্স ডকুমেন্টেশন: http://lwn.net/Articles/375098/

সেখানে এক পরিস্থিতিতে যেখানে মেমরি ফ্র্যাগমেন্টেশন বিশাল পৃষ্ঠা বরাদ্দ ধীর হতে পারে (কিন্তু যেখানে বিশাল পৃষ্ঠাগুলি কারণ মেমরির ফ্র্যাগমেন্টেশন), এবং যে যদি আপনার সিস্টেমে যদি একটি অ্যাপ্লিকেশন দ্বারা অনুরোধ বিশাল পৃষ্ঠাগুলির পুকুর হত্তয়া কনফিগার করা হয়েছে। যদি / proc / sys / vm / nr_overcommit_hugepages / proc / sys / vm / nr_hugepages এর চেয়ে বড় হয়, এটি হতে পারে।


প্রকৃতপক্ষে - এবং এটি সাধারণত পারফরম্যান্সে সহায়তা করবে কারণ এটি টিএলবি মিস করতে বাধা দেবে (ব্যাখ্যা করার জন্য লিঙ্কিত নিবন্ধটি দেখুন)।
ড্যান প্রিটস

0

নেই /proc/buddyinfoযা খুবই দরকারী। পাইথন স্ক্রিপ্টের মতো এটি একটি দুর্দান্ত আউটপুট ফর্ম্যাট সহ আরও কার্যকর useful

https://gist.github.com/labeneator/9574294

বিশাল পৃষ্ঠাগুলির জন্য আপনি 2097152 (2MiB) আকার বা বড় কিছু ফ্রি টুকরো চান। স্বচ্ছ বিশাল পৃষ্ঠাগুলির জন্য কার্নেলের কাছে কিছু জিজ্ঞাসা করা হলে এটি স্বয়ংক্রিয়ভাবে সংক্রামিত হবে, তবে আপনি কতগুলি পেতে পারেন তা দেখতে চাইলে রুট রান হিসাবে:

echo 1 | sudo tee /proc/sys/vm/compact_memory

এছাড়াও হ্যাঁ, বিশাল পৃষ্ঠাগুলি খণ্ডিতকরণের জন্য বড় সমস্যা সৃষ্টি করে। হয় আপনি কোনও বিশাল পৃষ্ঠা পেতে পারেন না, বা তাদের উপস্থিতি কার্নেলকে কিছু পাওয়ার জন্য প্রচুর অতিরিক্ত সময় ব্যয় করে।

আমার একটি সমাধান রয়েছে যা আমার পক্ষে কাজ করে। আমি এটি বেশ কয়েকটি সার্ভার এবং আমার ল্যাপটপে ব্যবহার করি। এটি ভার্চুয়াল মেশিনগুলির জন্য দুর্দান্ত কাজ করে।

kernelcore=4Gআপনার লিনাক্স কার্নেল কমান্ড লাইনে বিকল্প যুক্ত করুন । আমার সার্ভারে আমি 8 জি ব্যবহার করি। সংখ্যাটি সম্পর্কে সতর্ক থাকুন, কারণ এটি আপনার কার্নেলটিকে সেই মেমরির বাইরে কিছু বরাদ্দ করতে বাধা দেবে। যে সমস্ত সার্ভারগুলিতে প্রচুর সকেট বাফার প্রয়োজন হয় বা সেই স্ট্রিম ডিস্ক কয়েকশো ড্রাইভে লেখেন তারা এভাবে সীমাবদ্ধ থাকতে পছন্দ করবেন না। স্ল্যাব বা ডিএমএর জন্য "পিন করা" থাকা যে কোনও মেমরি বরাদ্দ এই বিভাগে।

আপনার অন্যান্য সমস্ত স্মৃতি তখন "চলমান" হয়ে যায় যার অর্থ বিশাল পৃষ্ঠা বরাদ্দের জন্য এটি সুন্দর অংশগুলিতে সংযুক্ত করা যায়। এখন স্বচ্ছ বিশাল পৃষ্ঠাগুলি সত্যই তা বন্ধ করতে পারে এবং যেমনটি ধারণা করা হচ্ছে তেমন কাজ করতে পারে। যখনই কার্নেলের আরও 2M পৃষ্ঠাগুলির প্রয়োজন হয় তখন এটি 4K পৃষ্ঠাগুলি অন্য কোথাও পুনরায় তৈরি করতে পারে।

এবং, আমি পুরোপুরি নিশ্চিত নই যে এটি শূন্য-অনুলিপি সরাসরি আইওয়ের সাথে কীভাবে যোগাযোগ করে। "অস্থাবর অঞ্চল" মেমোরিটি পিন করার কথা নয়, তবে সরাসরি আইও অনুরোধটি ডিএমএর জন্য ঠিক তাই করবে। এটি কপি করতে পারে। এটি যেভাবেই চলমান জোনে পিন করতে পারে। উভয় ক্ষেত্রে এটি সম্ভবত আপনি যা চেয়েছিলেন ঠিক তা নয়।

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