কেন লিনাক্সে ক্যাচ ফেলে?


84

আমাদের সার্ভারগুলিতে আমাদের মধ্যরাতে ক্যাচ ফেলে দেওয়ার অভ্যাস রয়েছে।

sync; echo 3 > /proc/sys/vm/drop_caches

আমি কোডটি চালানোর সময় মনে হয় প্রচুর র‍্যাম মুক্ত হয়ে যায়, তবে আমার কি সত্যিই তা করা দরকার। ফ্রি র‌্যাম কি অপচয় নয়?


62
যে ব্যক্তি এটি প্রবেশ করিয়েছে সেই ব্যক্তিকে সন্ধান করুন এবং কেন এটি করেছেন তা তাকে জিজ্ঞাসা করুন। আপনি যেমন সঠিকভাবে অনুমান করেছেন, এর কোনও সুস্পষ্ট ভাল কারণ নেই।
মাইকেল হ্যাম্পটন

10
কার্নেলটি ডিবাগ করা হচ্ছে। এটা সম্বন্ধে. এটি আসলে কোনও র‌্যাম মুক্ত করে না; নাম অনুসারে এটি ক্যাশে ফেলে দেয় এবং ফলস্বরূপ হ্রাস পায়।
মাইকেল হ্যাম্পটন

28
@ আইকোড তারপরে আপনার সার্ভারের সাথে সমস্যাটি সৃষ্টি হওয়ার কারণটি এড়াতে চেষ্টা করার চেয়ে সমস্যাটি খুঁজে বের করা উচিত। যদি আমার গাড়িটি প্রতিবার আমি তীক্ষ্ণ ডান ঘুরিয়ে থামায়, ডানদিকে ঘুরিয়ে দেওয়া এড়ানো একটি লম্পট ফিক্স।
ডেভিড শোয়ার্জ

7
সম্পর্কিত thedailywtf.com/Articles/Modern-Memory-Management.aspx দৃ argu ়ভাবে তর্ক করা এটি একটি খারাপ ধারণা।
ড্রোনিক্স

7
সম্পর্কিত, এবং "সমস্যা" এর একটি দরকারী বিবরণ: linuxatemyram.com
বিল ওয়েইস

উত্তর:


86

আপনি 100% সঠিক। এটা না র্যাম মুক্ত করা একটি ভাল অনুশীলন। এটি সম্ভবত কার্গো কাল্ট সিস্টেম প্রশাসনের একটি উদাহরণ।


9
কার্গো কাল্ট সিস্টেম প্রশাসনের উল্লেখ করার জন্য +1। যে সিসাদমিন সেই শব্দটি জানেন না এবং এর অর্থ কী তা তাকে বহিষ্কার করা উচিত।
টনি

8
@ টনি: আমরা তখন
সিসাদমিন

2
বেশিরভাগ মানবতার মতো, আমি প্রচুর অনুমোদনের সাথে সংক্ষিপ্ত ব্রাশের প্রতিবেদনগুলি পছন্দ করি, তবে একটি উদ্ধৃতি বা যুক্তি আমার সুপেরেগোর +1 উপার্জন করতে পারে।
অ্যারন হল

2
আপনার আপত্তি না থাকলে কার্গো-কাল্ট প্রশাসন, পাশাপাশি উপরেরগুলিও ব্যাখ্যা করুন। হতে পারে কোনও ফলো-অন এডিটে? আমি এখনও আমার +1 ধরে রাখছি ...: পি
অ্যারন হল

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

62

হ্যাঁ, ক্যাশে ক্লিয়ারিং র‌্যামকে মুক্ত করবে, তবে এটি কার্নেলটিকে ক্যাশে না করে ডিস্কে ফাইলগুলি সন্ধান করবে যার ফলে কার্য সম্পাদন সমস্যা হতে পারে।

সাধারণত যখন উপলব্ধ র‍্যামটি হ্রাস পায় তখন কার্নেলটি ক্যাশে সাফ করে দেয়। এটি প্রায়শই পিডিএফলুশ ব্যবহার করে ডিস্কে নির্লিপ্ত কন্টেন্ট লিখে থাকে।


20
এটি কেন খারাপ ধারণা তা বোঝানোর জন্য +1 ।
ওগ্রে গীতসংহিতা

35

এর মতো ক্যাশে ফেলে দেওয়ার কারণটি ডিস্কের পারফরম্যান্সের জন্য, এবং এটিই কেবল বিদ্যমান।

আই / ও-ইনটেনসিভ বেঞ্চমার্কটি চালানোর সময় আপনি নিশ্চিত হতে চান যে আপনি যে বিভিন্ন সেটিংস চেষ্টা করেছেন সেগুলি আসলে ডিস্ক আই / ও করছে, সুতরাং লিনাক্স আপনাকে পুরো পুনরায় বুট করার পরিবর্তে ক্যাশে ফেলে দেওয়ার অনুমতি দেয়।

ডকুমেন্টেশন থেকে উদ্ধৃতি :

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

এই ফাইলটির ব্যবহার কার্যকারিতা সমস্যার কারণ হতে পারে। যেহেতু এটি ক্যাশেড অবজেক্টগুলি ত্যাগ করে, তাই বাদ পড়া বস্তুগুলি পুনরায় তৈরি করতে উল্লেখযোগ্য পরিমাণে I / O এবং CPU লাগতে পারে, বিশেষত যদি তারা অতিরিক্ত ব্যবহারের মধ্যে থাকে under এ কারণে, কোনও পরীক্ষার বাইরে বা ডিবাগিং পরিবেশের ব্যবহার করার পরামর্শ দেওয়া হয় না।


অবশ্যই, আপনি যা করার চেষ্টা করছেন তার উপর নির্ভর করে, একটি সম্পূর্ণ পুনরায় বুট করার ফলে ডিস্কের ক্যাশে যথেষ্ট পরিমাণে সাফ নাও হতে পারে।
একটি সিভিএন

1
"যখন মেমরির প্রয়োজন হয় তখন এই বিষয়গুলি স্বয়ংক্রিয়ভাবে কার্নেল দ্বারা পুনরুদ্ধার করা হয়" ডিজাইনের লক্ষ্য তবে এটি সর্বদা প্রকৃত আচরণ হতে পারে না।
ড্যান প্রিটস

@ ড্যানপ্রিটগুলি আপনাকে কী এমনটা মনে করে যে তা এমন নয়?
জো

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

26

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

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

আমার পরিবেশে, লিনাক্স প্রায়শই ভুল অনুমান করে এবং বেশিরভাগ ইউরোপ স্টক এক্সচেঞ্জের শুরুতে (স্থানীয় সময় প্রায় 0900) সার্ভারগুলি এমন কাজ করা শুরু করবে যা তারা কেবলমাত্র একবার করে করে যা মেমরির অদলবদল করা দরকার যা পূর্বে অদলবদল হয়ে গেছে কারণ লগফাইल्स, সংকোচন, সেগুলি অনুলিপি করা ইত্যাদিতে ক্যাশে ভরাট করা ছিল যেখানে জিনিসগুলিকে সরিয়ে নিতে হয়েছিল।

তবে ক্যাশেগুলি ফেলে দেওয়া কি এই সমস্যার সমাধান? অবশ্যই না। এখানে সমাধান কী হবে তা লিনাক্সকে যা জানা নেই তা জানানো: এই ফাইলগুলি সম্ভবত আর ব্যবহার করা হবে না। এটি লিখিত অ্যাপ্লিকেশন দ্বারা যেমন posix_fadvise()একটি সিএমডি লাইন সরঞ্জাম ব্যবহার করে বা ব্যবহার vmtouchকরতে পারে (যা জিনিসগুলি পাশাপাশি ক্যাশে ফাইলগুলিতে সন্ধান করতেও ব্যবহৃত হতে পারে)।

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

আপনার জায়গায় যা হওয়া উচিত তা হ'ল এমন একটি সিস্টেম যা আপনার মেমোরি ব্যবহারের নিদর্শনগুলি পর্যবেক্ষণ করে (উদাহরণস্বরূপ যদি কিছু বদলানো হয়) এবং তারপরে সেই অনুযায়ী বিশ্লেষণ করুন এবং সে অনুযায়ী কাজ করুন। সমাধানটি হতে পারে vtouch ব্যবহার করে দিনের শেষে কিছু বড় ফাইল উচ্ছেদ করা; এটি আরও র‌্যাম যুক্ত করাও হতে পারে কারণ সার্ভারের দৈনিক পিকের ব্যবহার কেবল এটিই।


আমার সার্ভারে সমস্ত অ্যাপ্লিকেশন নোহাপে চলছে। সম্ভবত nohup.out ক্যাশে এবং মেমরি খাওয়া হচ্ছে?
আইভোকড

@ আইকোড: এটি একটি কারণ হতে পারে, nohup.out কত বড় তা পরীক্ষা করে দেখুন। এটির কতটুকু ক্যাশে রয়েছে তা নির্ধারণ করতে vmtouch ব্যবহার করুন।
প্লাজমাএইচ

cat /dev/null > path/nohup.outNohup.out দ্রুত বাড়ছে বলে আমার 15 মিনিটের মধ্যে ক্রোন জব রয়েছে । সম্ভবত লিনাক্স nohup.out ক্যাশে করছে এমনকি আমি এটি পরিষ্কার করে দিচ্ছি
আইভোকড

5
@ আইকোড যদি আপনার কাছ থেকে আউটপুট প্রয়োজন না হয় তবে এটিতে nohupপুনরায় নির্দেশনা দেওয়া উচিত /dev/null। দেখে মনে হচ্ছে আপনার সিস্টেমে কিছুটা সময় কিছু অনভিজ্ঞ সিসাদমিন কাজ করছে। এর আউটপুটটি কীভাবে ডাইরেক্ট করবেন তার জন্য স্ট্যাকওভারফ্লো.com/ সেকশনস 10408816/… দেখুনnohup/dev/null
ডেভিড উইলকিন্স

যদিও nohup.out 15 মিনিটের ব্যবধানে সাফ হয়ে গেছে, যদি কোনও কারণে অ্যাপস প্রক্রিয়াটি মারা যায় তবে nohup.out অন্য স্ক্রিপ্ট থেকে স্বয়ংক্রিয়ভাবে ব্যাকআপ হয়ে যাবে। আমি ভিএমটিচ চেষ্টা করেছি। এটি সত্যই একটি খুব ভাল সরঞ্জাম
আইভোকড

16

ভার্চুয়াল মেশিনগুলির গোছা শুরু করার সময় ড্রপ ক্যাশে দরকারী হতে দেখেছি। বা অন্য যে কোনও কিছু বৃহত পৃষ্ঠাগুলি ব্যবহার করে যেমন কিছু ডাটাবেস সার্ভার।

লিনাক্সের বড় পৃষ্ঠাগুলিতে একটি পৃষ্ঠায় রাখার জন্য 2MB সংঘবদ্ধ দৈহিক র‌্যাম খুঁজে পেতে প্রায়শই র‌্যামকে ডিফ্র্যাগ করতে হয়। সমস্ত ফাইল ক্যাশে মুক্ত করা এই প্রক্রিয়াটিকে খুব সহজ করে তোলে।

তবে আমি অন্যান্য উত্তরগুলির সাথে বেশিরভাগের সাথে একমত যে প্রতি রাতে ফাইলের ক্যাশে ফেলে দেওয়ার কোনও ভাল কারণ নেই।


1
আমি দ্বিতীয় অর্ডার কুসংস্কার দেখানো জন্য upvated হ'ল ক্যাশে প্রতিক্রিয়া।
নোয়া স্পুরিয়ার

1
এছাড়াও, হাই-মেমোরি নোডগুলিতে এইচপিসি অ্যাপ্লিকেশনগুলিতে (1 টিবি) কয়েকটি বড় ফাইল পড়ার ফলে প্রচুর পরিমাণে মেমরি ক্যাশে হয়ে যায়। যেহেতু অনেক এইচপিসি অ্যাপ্লিকেশন শত শত জিবি ম্যালোক সঞ্চালন করে, মাইগ্রেশন প্রক্রিয়াগুলি সিস্টেমের ক্যাশেড মেমরি "সীমানা" এ পৌঁছানোর পরে NUMA নোডের বিচ্ছিন্নভাবে ক্ষুদ্র মেমরির ক্ষুদ্র অংশগুলিকে স্থানান্তরিত করতে পারে কারণ সিস্টেম কয়েক ঘন্টার জন্য স্টল করতে পারে। সবচেয়ে খারাপ, ইউজারল্যান্ডে আপনি সমস্ত ক্ষুদ্র 2MB ব্লক বরাদ্দকরণের জন্য সিস্টেমটিকে ক্রেটগুলি মুক্ত করার জন্য কিছুই করতে পারবেন না যা এটি একবারে মুক্তি দিতে পারে, বিশাল পৃষ্ঠার ডিফ্র্যাগ এবং অ্যাপ্লিকেশনগুলিকে সাধারণত চালিত হতে দেয়।
ব্যবহারকারী1649948

+1 বড় পৃষ্ঠাগুলি ( sysctl -w vm.nr_hugepages=...) তৈরি করার কমান্ডটি এমনকি কাজ করতে অস্বীকার করে যতক্ষণ না আমি প্রথমে ক্যাশে (আর্চ লিনাক্স) না ফেলে।
আলেকসান্দ্র ডাবিনস্কি

8

সম্ভবত এটি সমস্যাটি সন্ধান করার দক্ষতা বা অভিজ্ঞতা সম্পন্ন কেউ না থাকলে সিস্টেমকে স্থিতিশীল করার উপায় হিসাবে এটি চালু করা সম্ভব হয়।

রিসোর্স মুক্ত করা হচ্ছে

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

স্মৃতি খেয়ে কী চলছে?

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

শেষের সারি

এটি কেবল যে প্রয়োজনীয় তা অনুমান করবেন না। এটি কেন আছে তা সন্ধানে তৎপর হন, অন্যেরা এটির ভুল বলে প্রস্তাব দিলে এটি নিষ্ক্রিয় করার সাহস পান এবং সিস্টেমটি পর্যবেক্ষণ করুন - আসল সমস্যাটি কী তা শিখুন এবং এটিকে সংশোধন করুন।


4

লিনাক্স / এম k৮ কে আসলে একটি কার্নেল বাগ রয়েছে যার ফলে kswapd পাগল হয়ে যায় এবং ১০০% সিপিইউ খায় (৫০% যদি সিপিই-বাউন্ড কিছু কাজ থাকে, যেমন ডেবিয়ান বাইনারি প্যাকেজ অটোবিল্ডার - ভলগো বিল্ডড - ইতিমধ্যে চলছে) যা করতে পারে (বেশিরভাগ ক্ষেত্রেই) সময়ের; সর্বদা নয়) প্রতি কয়েক ঘন্টা পরে এই বিশেষ কমান্ডটি চালিয়ে প্রশমন করা উচিত।

বলা হচ্ছে… আপনার সার্ভারটি সম্ভবত এম 68 ক (আটারি, অ্যামিগা, ক্লাসিক ম্যাকিনটোস, ভিএমই, কিউ 40 / কিউ 60, সান 3) সিস্টেম নয় ;-)

এই ক্ষেত্রে, যে ব্যক্তি লাইনগুলিতে রেখেছে তারা কিছু সন্দেহজনক বা সর্বোত্তম, পুরানো পরামর্শ অনুসরণ করেছে বা র্যাম কীভাবে ভুল ব্যবহার করা উচিত সে সম্পর্কে ধারণা পেয়েছে (আধুনিক চিন্তাভাবনা আসলে "ফ্রি র‌্যাম র‌্যাম নষ্ট হয়" এবং ক্যাশে দেওয়ার পরামর্শ দেয়) , বা "আবিষ্কার" করেছে যে এই "সংশোধন" [sic!] অন্য কোথাও (এবং সঠিক সমাধান অনুসন্ধানে খুব অলস ছিল)।


"একটি কর্নেল বাগ যার ফলে কেসপ্যাড পাগল হয়ে যায়" - এটি কোন বাগ?
বেন

@ এই থ্রেডটি দেখুন (এই বার্তাটি এবং বেশ কয়েকটি ফলোআপ, যার মধ্যে একটি অনুমান রয়েছে যেখানে এটি আসতে পারে)
মীরাবিলোস

1
আমি একই ধরণের সমস্যাটি অনুভব করছি (যদিও এটি x86_64) এবং এই মুহুর্তে একমাত্র সমাধান হ'ল
ফার্নান্দো

2
@ ফারানান্দো আমারও এম 68 কে বক্সে একটি "ড্রপ ক্যাশে" ক্রোনজব রয়েছে mi
মীরাবিলোস

3

একটি কারণ হতে পারে যে সাইটটি কোনও ধরণের মনিটরিং চলছে, এটি নিখরচায় র‌্যামের পরিমাণ পরীক্ষা করে এবং প্রশাসকদের কাছে একটি সতর্কতা প্রেরণ করে যখন ফ্রি রাম একটি নির্দিষ্ট শতাংশের নিচে নেমে যায়। যদি নিরীক্ষণ সরঞ্জামটি নিখরচায় রাম গণনায় ক্যাশে অন্তর্ভুক্ত না করার জন্য যথেষ্ট মূক হয় তবে এটি মিথ্যা সতর্কতা প্রেরণ করতে পারে; নিয়মিতভাবে ক্যাশে খালি করা এই সতর্কতাগুলিকে দমন করতে পারে যখন "সত্যিকারের" রাম কম হয়ে যায় তখনও সরঞ্জামটি লক্ষ্য করার সুযোগ দেয়।

অবশ্যই, এই ধরণের পরিস্থিতিতে প্রকৃত সমাধান হ'ল নিখরচায় র‌্যাম গণনায় ক্যাশে অন্তর্ভুক্ত করার জন্য পর্যবেক্ষণের সরঞ্জামটি সংশোধন করা; ক্যাশে পরিষ্কার করা কেবলমাত্র এক ব্যয়সাধ্য কাজ এবং একটি খারাপ দিকও কারণ ডিস্কগুলিতে অ্যাক্সেস করার পরে ক্যাশে দ্রুত পুনরায় পূরণ হবে ill

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


3

আমি একটি রাত্রে ক্রোন কাজের ক্ষেত্রে এটি করার একটি যুক্তিযুক্ত কারণ সম্পর্কে ভাবতে পারি।

একটি বড় সিস্টেমে, এটি পর্যায়ক্রমে ক্যাশেগুলি ফেলে দেওয়ার জন্য দরকারী হতে পারে যাতে আপনি মেমরির খণ্ডগুলি সরিয়ে ফেলতে পারেন।

ছোট পৃষ্ঠাগুলিকে বিশাল পৃষ্ঠাগুলিতে একত্রিত করতে কার্নেলের স্বচ্ছ বিশাল পৃষ্ঠাগুলি পর্যায়ক্রমিক মেমরির সুইপ করে। অধঃপতিত অবস্থার অধীনে এটির ফলে সিস্টেমটি এক বা দুই মিনিটের বিরতিতে ঘটতে পারে (এর সাথে আমার অভিজ্ঞতাটি RHEL6 এ ছিল; আশা করি এটি উন্নত হয়েছে)। ক্যাচগুলি ফেলে দেওয়ার ফলে বিশাল পৃষ্ঠার সুইপারের সাথে কাজ করার কিছু জায়গা থাকতে পারে।

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


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

আমি জানি না কোনও গুগল সফ্টওয়্যার আসলে এটি করে কিনা।


1
আপনি কি এই জন্য কোন উত্স আছে? এটি এমন কিছুর মতো শোনায় যে এটি যদি কোনও সমস্যা থাকে তবে কার্নেলের মধ্যে স্থির করা উচিত।
স্পষ্টত

3
স্বচ্ছ হিটপেজ সহ বিরাম নিয়ে আমার ব্যক্তিগত অভিজ্ঞতা রয়েছে have RHEL6, ডেল আর 810, 4 সিপিইউ, 64 জিবি র‌্যাম। স্বচ্ছ বিশালপৃষ্ঠাগুলি অক্ষম করা (এটি করার জন্য একটি / প্রো ফাইল রয়েছে) অবিলম্বে বিরতি স্থির করে। আমি সেই সময়ে ক্যাশে ড্রপ কৌশলটি চেষ্টা করি নি; পরিবর্তে আমি আমাদের জাভা অ্যাপ্লিকেশনগুলিকে অপ-স্বচ্ছ হিটপেজগুলি ব্যবহার করার জন্য পুনরায় কনফিগার করেছি এবং স্বচ্ছ হিটপ্যাজগুলি অক্ষম রেখেছি। আইআইআরসি, আমরা পরিস্থিতিটি যথেষ্ট উপলব্ধি করে বুঝতে পারি যে আমরা কেবল ক্ষতিগ্রস্থ মানুষই নই, এবং রেড হ্যাট বিষয়টি সম্পর্কে জানত।
ড্যান প্রিটস

হ্যালো ড্যান, আমি আমার সার্ভারে একই আচরণ স্থির করছি। আমি প্রচুর পরিমাণে ডেটা নিয়ে কাজ করি এবং একই পাইথন প্রোগ্রামের 10+ গণনা (প্রথম গণনার সময়ের x2-3) এর পরে কঠোর কর্মক্ষমতা দেখা দেয় fall আমি যদি একবার দেখে নিই, মেমোরি ক্যাশের আকার বিশাল, 100 + জিবি। এবং যদি আমি এই মেমরি ক্যাশেটি ফ্লাশ করি এবং আমার প্রোগ্রামটি আবার চালিত করি তবে আমি আমার প্রাথমিক গণনার সময়টি ফিরে পেয়েছি। এই ঘটনাটি ভাগ করে নেওয়ার জন্য আপনার কাছে কোনও নথি বা তথ্য আছে? ধন্যবাদ.
এক্সেল বোরজা

1
access.redhat.com/solutions/46111 এটি বর্ণনা করে। আপনার ক্ষেত্রে সমস্যাটি কিনা তা দেখতে আপনি স্বচ্ছ হিটপেজগুলি অক্ষম করতে পারেন।
ড্যান প্রিটস

2

কেবল আমার দুটি সেন্ট যুক্ত করতে: সিস্টেমটি খুব ভাল করেই জানে যে এই মেমরি পৃষ্ঠাগুলি ক্যাশে, এবং যখন কোনও অ্যাপ্লিকেশন মেমরির জন্য জিজ্ঞাসা করবে তখন প্রয়োজনের পরিমাণ হ্রাস পাবে।

একটি প্রাসঙ্গিক সেটিংস হ'ল /proc/sys/vm/swappinessযা নতুন মেমরি বরাদ্দের সময় কার্নেলকে মেমরি ক্যাশগুলি ছাড়তে পছন্দ করতে বা "নিষ্ক্রিয়" বরাদ্দ হওয়া মেমরি পৃষ্ঠাগুলি অদলবদল করতে বলে।


1

প্রশ্নটি ২০১৪ সালের, তবে কিছু লুকানো সেন্টো 6..৮ ব্যাকেন্ডে সমস্যাটি আজ অবধি বিদ্যমান, এটি এখনও কারও পক্ষে কার্যকর হতে পারে।

https://github.com/zfsonlinux/zfs/issues/1548 zfs সহ একটি সমস্যা বর্ণনা করে। মুছে ফেলা ফাইলগুলির জন্য ডিস্কের স্থান মুক্ত করা হয়নি কারণ zfs এর উপরে যদি এনএফএস ব্যবহার করা হয় তবে ফাইলের ইনোডগুলি কার্নেলের ইনোড ক্যাশে থেকে বাদ না দেওয়া হয়।

বাগ থ্রেড থেকে উদ্ধৃত করার জন্য, বেহেলডর্ফ, জানুয়ারী 6 2015 লিখেছেন:

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

অর্থাত রাতের প্রতিধ্বনি 3> / proc / sys / vm / ড্রপ_ক্যাচগুলি যদি আপনি আপনার zfs পুনর্গঠনের জন্য ডাউনটাইম না চান তবে সেই বাগের পক্ষে সহজতম সমাধান fix

সুতরাং সম্ভবত কার্গো কাল্ট পরিচালনা করা নয়, তবে কিছু ভাল ডিবাগিংয়ের কারণ ছিল।


0

এটি NUMA (অ ইউনিফর্ম মেমরি অ্যাক্সেস) সিস্টেমে বুঝতে পারে, যেখানে সাধারণত প্রতিটি সিপিইউ (সকেট) স্বচ্ছভাবে সমস্ত মেমরি অ্যাক্সেস করতে পারে তবে সমান্তরাল এইচপিসি অ্যাপ্লিকেশনগুলির সাথে মিল রেখে অন্যান্য সকেটের মেমরির তুলনায় এর নিজস্ব মেমরি দ্রুত অ্যাক্সেস করা যায়।

অনেকগুলি সমান্তরাল অ্যাপ্লিকেশনগুলি একক প্রক্রিয়া থেকে ফাইল I / O করতে থাকে, ফলে ডিস্ক ক্যাশে বরাদ্দকৃত একক NUMA নোডে মেমরির একটি বড় অংশকে প্রস্থান করার সময় ছেড়ে যায়, অন্যদিকে অন্যান্য NUMA নোডে মেমরিটি বেশিরভাগই বিনামূল্যে থাকতে পারে। এই পরিস্থিতিতে, যেহেতু আমি জানি লিনাক্স কার্নেলের পুনরায় দাবি প্রক্রিয়াটি এখনও NUMA- সচেতন নয়, ক্যাশকে বরাদ্দ করা মেমরির NUMA নোডে চলমান প্রক্রিয়াগুলি অন্য NUMA নোডে মেমরি বরাদ্দ করতে বাধ্য হয়, যতক্ষণ না অন্য নোডে নিখরচায় র‌্যাম থাকে ততক্ষণ পারফরম্যান্সটি হারাতে পারে।

তবে, এইচপিসি সিস্টেমে ক্রোন দিয়ে নির্দিষ্ট সময়ে নয়, নতুন ব্যবহারকারীর কাজ শুরু করার আগে ক্যাশে পরিষ্কার করা বুদ্ধিমানের কাজ হবে।

অ সমান্তরাল অ্যাপ্লিকেশনগুলির জন্য এই সমস্যা দেখা দেওয়ার সম্ভাবনা কম।


0

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

তবে বাস্তবতা এতটা সহজ নয়। কর্মক্ষেত্র হয়:

  1. ড্রপ ক্যাশে পর্যায়ক্রমে কার্যকর করুন
  2. প্রয়োজনে ড্রপ ক্যাশে চালিত করুন (ক্রিয়াকলাপের অদলবদল করার জন্য vmstat 1 ব্যবহার করে নিরীক্ষণ করুন)
  3. লিনাক্সকে ডিডি বা পাইথন-ফ্যাডভিসের মতো ইউটিলিটি ব্যবহার করে ক্যাশে থেকে কিছু ফাইল (অ্যাপাচি লগ ফাইলের মতো) সরিয়ে ফেলার পরামর্শ দিন। Https://unix.stackexchange.com/questions/36907/DP-a-specific-file-from-the-linux-filesystem-cache দেখুন

উদাহরণস্বরূপ ডিডি রান:

dd if=/var/log/apache2/access_log.1 iflag=nocache count=0

পাইথন-ফ্যাডভিস উদাহরণ:

pyadvise -d /var/log/apache2/access_log.1


-5

আমার কাছে একটি ডেস্কটপ মেশিন রয়েছে যা পিএইই কার্নেলটিতে 16 গিগাবাইট র‌্যাম চালায়। এক ঘন্টা বা দু' ঘন্টা পরে ডিস্কের পারফরম্যান্স নাটকীয়ভাবে হ্রাস পায় যতক্ষণ না আমি ক্যাচগুলি ফেলে রাখি যাতে আমি কেবল ক্রোনটিতে রাখি। আমি জানি না যে এটি PAE কার্নেল বা মেশিন প্রচুর পরিমাণে থাকলে ক্যাশে বাস্তবায়ন এত ধীরে ধীরে সমস্যা আছে কিনা।


9
এটি "কার্গো কাল্ট" সিস্টেম প্রশাসনের একটি প্রধান উদাহরণ: সমস্যাটি সনাক্তকরণ এবং সমাধান করার পরিবর্তে আপনি কেবল এটি মুখোশ করছেন।
মাইকেল হ্যাম্পটন

2
কখনও কখনও সমীচীন সমাধানটি সঠিক হয়। এটি কেবল আসল সমস্যা সমাধান করা বন্ধ করে দিচ্ছে, বা এটি পরিস্থিতিতে যেমন প্রয়োজন তত সমাধান হতে পারে। এটি খারাপ অভ্যাস হলেও এটি এখনও "কার্গো কাল্ট" নয়। এখানে একটি প্রদর্শিত কারণ এবং প্রভাব রয়েছে: ড্রপ ক্যাশে এবং ডিস্কের কার্যকারিতা উন্নতি করে।
ড্যান প্রিটস

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