মঙ্গোডিবি খুব বেশি স্মৃতি ব্যবহার করছে

Question

আমরা এখন বেশ কয়েক সপ্তাহ ধরে মঙ্গোডিবি ব্যবহার করছি, আমরা যে সামগ্রিক প্রবণতাটি দেখেছি তা হ'ল মঙ্গোদব অনেক বেশি মেমরি ব্যবহার করছে (এর ডেটাসেট + সূচকগুলির পুরো আকারের চেয়ে অনেক বেশি)।

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

নীচে হটোপ এবং শো ডিবিএস কমান্ডের ফলাফল রয়েছে ।

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

ওওএম অন্যান্য গুরুত্বপূর্ণ প্রক্রিয়াগুলি যেমন পোস্টগ্রিজ, রেডিস ইত্যাদি হত্যা শুরু করে (যেমন দেখা যায় যে এই সমস্যাটি কাটিয়ে উঠতে আমরা র‌্যামটি 183 গিগাবাইটে বাড়িয়েছি যা এখন কাজ করে তবে বেশ ব্যয়বহুল m মঙ্গো ~ 87 গিগাবাইট র‌্যাম ব্যবহার করে, পুরো ডেটাসেটের আকারের প্রায় 4X)

সুতরাং,

1. এই কি অনেক বেশি মেমরির ব্যবহার সত্যই প্রত্যাশিত এবং স্বাভাবিক? (ডকুমেন্টেশন অনুসারে, ওয়্যার্ডটাইগার তার ক্যাশের জন্য র্যামের সর্বাধিক ~ 60% ব্যবহার করে, তবে ডেটাসেটের আকার বিবেচনা করে, 86 গিগাবাইট র‌্যাম নিতে সক্ষম হওয়ার মতো পর্যাপ্ত ডেটা আছে কি?)
2. এমনকি যদি মেমোরির ব্যবহার আশা করা হয়, তবে আরও প্রক্রিয়া আরও মেমরির জন্য অনুরোধ শুরু করার ক্ষেত্রে কেন মঙ্গো তার বরাদ্দ মেমরিটি ছেড়ে দেবে না? আমরা র‌্যাম বাড়ানোর আগে এবং এটি সিস্টেমটিকে সম্পূর্ণরূপে অস্থিতিশীল করে তোলার আগে অন্যান্য বিভিন্ন চলমান প্রক্রিয়াগুলি নিয়মিত লিনাক্স ওম দ্বারা নিহত হয়।

ধন্যবাদ!

Comments

হয়তো ওয়্যার্ডটাইগার এর ইন্টার্নালগুলিতে কিছু উপস্থাপনা যেমন মোংডব.বি.প্রেসেন্টেশনস_..এর কিছু আলোকপাত করতে পারে। আমি প্রত্যাশা করি যে 50% শারীরিক র‍্যামের ডিফল্ট ব্যবহার কেবল ডেডিকেটেড মঙ্গোডিবি হোস্টের জন্য কী প্রয়োজন তা কেবলমাত্র একটি অনুমান এবং এটির পরিবর্তনের জন্য অনেকেরই প্রয়োজন। এফডাব্লুআইডাব্লু, আমি বিশ্বাস করি না ক্যাশেসাইজবি সেট করা মঙ্গোকে "সীমাবদ্ধ" করছে - বিকল্পটি সেখানে রয়েছে যাতে আপনার মোতায়েনের উপর নিয়ন্ত্রণ থাকে। ক্যাশের জন্য মেমো মোঙ্গো কত "প্রয়োজনীয়" তা নির্ধারণের জন্য আপনাকে প্রত্যাশিত সার্ভার লোডের অধীনে সার্ভারের ক্যাশে পরিসংখ্যানগুলি পর্যবেক্ষণ করতে হবে।

Answer 1

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

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

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

• ওয়্যার্ডটাইগার ডিস্ক স্টোরেজকে সংকুচিত করে, তবে মেমরির ডেটা সঙ্কুচিত হয়।

• ডিফল্টরূপে ওয়্যার্ডটাইগার প্রতিটি প্রতিশ্রুতি সম্পর্কিত ডেটা ফাইঙ্ক করে না , তাই লগ ফাইলগুলি র‍্যামেও থাকে যা মেমরির উপরে নিয়ে যায়। এটি আরও উল্লেখ করা হয়েছে যে I / O কে দক্ষতার সাথে ব্যবহার করার জন্য, ওয়্যার্ডটাইগারগুলি আই / ও রিকুয়েস্টেসগুলি (ক্যাশে মিস করে) একসাথে করেছে, এতে কিছুটা র‌্যামও নেওয়া হয়েছে বলে মনে হচ্ছে (আসলে নোংরা পৃষ্ঠাগুলি (পরিবর্তন করা / আপডেট হওয়া পৃষ্ঠাগুলি) আপডেটের একটি তালিকা রয়েছে তাদের উপর একটি সমকালীন স্কিপলিস্টে সঞ্চিত )।

• ওয়্যার্ডটাইগার রেকর্ডের একাধিক সংস্করণকে তার ক্যাশে রাখে (মাল্টি ভার্সন কনকুরન્સી নিয়ন্ত্রণ, পড়া অপারেশনগুলি তাদের অপারেশনের আগে শেষ প্রতিশ্রুতিবদ্ধ সংস্করণে অ্যাক্সেস করে)।

• ওয়্যার্ডটাইগার ডেটাগুলির চেকসামগুলি ক্যাশে রাখে।

• মোংগোডিবি নিজেই খোলা সংযোগগুলি, সমষ্টিগুলি, সার্ভারসাইড কোড এবং ইত্যাদির জন্য মেমরি গ্রহণ করে ।

এই তথ্যগুলি বিবেচনা করে, নির্ভর করা show dbs;প্রযুক্তিগতভাবে সঠিক ছিল না, কারণ এটি কেবল ডেটাসেটের সংকুচিত আকার দেখায়।

সম্পূর্ণ ডেটাসেটের আকার পেতে নিম্নলিখিত কমান্ডগুলি ব্যবহার করা যেতে পারে।

db.getSiblingDB('data_server').stats()
# OR
db.stats()

এই ফলাফলগুলি নিম্নলিখিত:

{
    "db" : "data_server",
    "collections" : 11,
    "objects" : 266565289,
    "avgObjSize" : 224.8413545621088,
    "dataSize" : 59934900658, # 60GBs
    "storageSize" : 22959984640,
    "numExtents" : 0,
    "indexes" : 41,
    "indexSize" : 7757348864, # 7.7GBs
    "ok" : 1
}

সুতরাং দেখে মনে হচ্ছে যে আসল ডেটাসেটের আকার + এর সূচিগুলি সেই মেমরিটির প্রায় 68 জিবি নিচ্ছে।

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

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

Comments

আমরা একই সমস্যা আছে। মোংগোডিবি র‌্যাম খাইতে থাকে। অনুরূপ অনুপাত। oom_score_adj সমাধানটি আপনি যে পরিচালনা করতে পারেন তার মধ্যে সেরা জিনিস ছিল ?

— হার্টেটার

@ হার্টেটার ওয়েল আমরা ওয়্যারডিটিজারের ক্যাচি সাইজ হ্রাস করেছি, আমাদের সূচীগুলি এবং সূচীকরণ নীতি পরিচালনার জন্য আরও প্রচেষ্টা করেছি এবং শেষ পর্যন্ত, আমাদের যত্ন নেওয়া জিনিসগুলির জন্য ওম_স্কোর_এডজে হ্রাস পেয়েছে, এটি আমি অনুমান করি যাইহোক যাই করা যায়।

— স্পাইসেল

Answer 2

আমি মনে করি না মঙ্গোডিবিতে আপনার এখানে সমস্যা আছে, যেমনটি জেস্টেল আপনাকে বলেছিল যে ওয়্যারটেড টাইগার সহ মঙ্গোডিবি 50% উপলব্ধ মেমরি ব্যবহার করবে তাই আপনি যদি আপনার সার্ভারের র‌্যাম বাড়িয়ে নেন তবে এটি আরও মেমরি গ্রহণ করবে।

এটি কেন ডিবি + ইনডেক্সের আকারের চেয়ে বেশি, মনে রাখবেন যে ওয়্যার্ডটাইগার ডিস্কে ডাটাবেসটি সংকুচিত করে এবং নথির পরিবর্তনগুলি রেকর্ড করতে স্ন্যাপশট লগগুলিও ব্যবহার করে। সুতরাং ওয়্যার্ডটাইগারটির আসল আকার হ'ল ডিবিএস * সংক্ষেপণ_স্নাপ শর্ট লগগুলি ব্যবহার করে আকার। সুতরাং সঠিক প্রত্যাশিত আকারটি জানা প্রায় অসম্ভব।

মনের মধ্যে এছাড়াও রাখুন সরঞ্জাম চাই যে top, ps, htopমেমরি সত্যিই অ্যাপ্লিকেশন দ্বারা ব্যবহার করা প্রদর্শন না, বিস্তারিত জানার জন্য এই SOW প্রশ্নের refere: https://stackoverflow.com/questions/131303/how-to-measure-actual-memory -usage অফ আন-অ্যাপ্লিকেশন-বা প্রক্রিয়ার

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

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

Answer 3

ডক্স

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

মেমরি ব্যবহারের ওভারভিউ

কমান্ড db.serverStatus()( ডক্স ) মেমরির ব্যবহারের একটি ওভারভিউ সরবরাহ করতে পারে, বিশেষত:

> db.serverStatus().mem
{ "bits" : 64, "resident" : 27, "virtual" : 397, "supported" : true }

> db.serverStatus().tcmalloc
... not easy to read! ...

> db.serverStatus().tcmalloc.tcmalloc.formattedString
------------------------------------------------
MALLOC:        3416192 (    3.3 MiB) Bytes in use by application
MALLOC: +      4788224 (    4.6 MiB) Bytes in page heap freelist
MALLOC: +       366816 (    0.3 MiB) Bytes in central cache freelist
...
... a bunch of stats in an easier to read format ...

আপনার সূচকগুলি কত বড়?

db.stats() সমস্ত সূচকের মোট আকার দেখাতে পারে, তবে আমরা ব্যবহার করে একটি একক সংগ্রহের জন্য বিশদ তথ্যও পেতে পারি db.myCollection.stats()

উদাহরণস্বরূপ, এই আদেশটি প্রতিটি সংগ্রহের জন্য সূচির আকারগুলির তুলনা করবে :

> db.getCollectionNames().map(name => ({totalIndexSize: db.getCollection(name).stats().totalIndexSize, name: name})).sort((a, b) => a.totalIndexSize - b.totalIndexSize).forEach(printjson)
...
{ "totalIndexSize" : 696320, "name" : "smallCollection" }
{ "totalIndexSize" : 135536640, "name" : "bigCollection" }
{ "totalIndexSize" : 382681088, "name" : "hugeCollection" }
{ "totalIndexSize" : 511901696, "name" : "massiveCollection" }

এর বৃহত্তর সংগ্রহের বিশদটি এখন আমরা দেখতে পাচ্ছি, এর সূচকগুলির মধ্যে কোনটি সবচেয়ে ব্যয়বহুল তা দেখতে:

> db.massiveCollection.stats().indexSizes
{
        "_id_" : 230862848,
        "groupId_1_userId_1" : 49971200,
        "createTime_1" : 180301824,
        "orderId_1" : 278528,
        "userId_1" : 50155520
}

এটি কোথায় সঞ্চয় সম্ভব হতে পারে সে সম্পর্কে আমাদের আরও ভাল ধারণা দিতে পারে।

(এক্ষেত্রে আমাদের একটি সূচক ছিল createTimeযা তার চেয়েও বিশাল ছিল - ডকুমেন্টে একটি করে প্রবেশ - এবং আমরা সিদ্ধান্ত নিয়েছি যে এটি ছাড়া আমরা বাঁচতে পারি))

Comments

সূচকের কী বড় মেমরির ব্যয় হয়?

— ম্যাথিয়াস লাইককেগার্ড লরেঞ্জেন 13

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

— জোয়েটউইল