কিভাবে একটি ডাটাবেস OOM ক্র্যাশ থেকে মুক্তি পায়

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

একটি ডাটাবেস ব্যবহারকারীর দৃষ্টিকোণ থেকে, তারা কীভাবে খারাপ মেমরি ব্যবস্থাপনায় ভোগে? এটি আমাদের ব্যবহারকারীদের বিরক্ত করার জন্য ব্যবহৃত জিনিসগুলির একটি তালিকা:

• OOM ত্রুটির কারণে ব্যাকএন্ড প্রক্রিয়া ক্র্যাশ হয়ে যায়। আমাদের সম্প্রদায়ের একজন সদস্যকে উদ্ধৃত করতে: হাই, অ্যাপাচি ডরিস, আপনার স্মৃতিশক্তি কম থাকলে কিছু কাজকে ধীর করা বা ব্যর্থ করা ঠিক আছে, কিন্তু ডাউনটাইম নিক্ষেপ করা ঠিক নয়।

  
  

• ব্যাকএন্ড প্রক্রিয়াগুলি অত্যধিক মেমরির স্থান খরচ করে, কিন্তু একটি প্রশ্নের জন্য মেমরির ব্যবহারকে দোষারোপ করার বা সীমিত করার জন্য সঠিক কাজটি খুঁজে বের করার কোন উপায় নেই।

  
  

• প্রতিটি প্রশ্নের জন্য একটি সঠিক মেমরি আকার সেট করা কঠিন, তাই প্রচুর মেমরি স্পেস থাকা সত্ত্বেও একটি ক্যোয়ারী বাতিল হওয়ার সম্ভাবনা রয়েছে।

  
  

• উচ্চ-সঙ্গতিমূলক প্রশ্নগুলি অসমগতভাবে ধীর, এবং মেমরি হটস্পটগুলি সনাক্ত করা কঠিন।

  
  

• হ্যাশটেবল তৈরির সময় মধ্যবর্তী ডেটা ডিস্কে ফ্লাশ করা যায় না, তাই দুটি বড় টেবিলের মধ্যে কোয়েরিগুলি প্রায়ই OOM-এর কারণে ব্যর্থ হয়।

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

মেমরি বরাদ্দ

অ্যাপাচি ডরিসে, মেমরি বরাদ্দের জন্য আমাদের একটি একমাত্র ইন্টারফেস রয়েছে: বরাদ্দকারী । এটি মেমরির ব্যবহারকে দক্ষ এবং নিয়ন্ত্রণে রাখার জন্য উপযুক্ত মনে করে সামঞ্জস্য করবে।

এছাড়াও, মেমট্র্যাকারগুলি বরাদ্দকৃত বা রিলিজ করা মেমরির আকার ট্র্যাক করার জন্য রয়েছে এবং তিনটি ভিন্ন ডেটা স্ট্রাকচার অপারেটর এক্সিকিউশনে বৃহৎ মেমরি বরাদ্দের জন্য দায়ী (আমরা অবিলম্বে তাদের কাছে পৌঁছাব)।

মেমরিতে ডেটা স্ট্রাকচার

যেহেতু বিভিন্ন প্রশ্নের এক্সিকিউশনে বিভিন্ন মেমরি হটস্পট প্যাটার্ন থাকে, তাই Apache Doris তিনটি ভিন্ন ইন-মেমরি ডেটা স্ট্রাকচার প্রদান করে: Arena , HashTable , এবং PODArray । তারা সব বরাদ্দকারীর রাজত্বের অধীনে।

1. এরিনা

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

খণ্ডগুলি প্রধানত শাফেলের সময় সিরিয়ালাইজড বা ডিসিরিয়ালাইজড ডেটা বা হ্যাশটেবলে সিরিয়ালাইজড কীগুলি সংরক্ষণ করতে ব্যবহৃত হয়।

একটি খণ্ডের প্রাথমিক আকার হল 4096 বাইট। বর্তমান খণ্ডটি অনুরোধ করা মেমরির চেয়ে ছোট হলে তালিকায় একটি নতুন খণ্ড যোগ করা হবে।

বর্তমান খণ্ডটি 128M-এর চেয়ে ছোট হলে, নতুন খণ্ডটি তার আকার দ্বিগুণ করবে; যদি এটি 128M-এর থেকে বড় হয়, নতুন খণ্ডটি প্রয়োজনের চেয়ে 128M বড় হবে৷

পুরানো ছোট খণ্ড নতুন অনুরোধের জন্য বরাদ্দ করা হবে না. বরাদ্দকৃত অংশ এবং বরাদ্দ না করা অংশগুলির মধ্যে বিভাজন রেখা চিহ্নিত করার জন্য একটি কার্সার রয়েছে।

2. হ্যাশ টেবিল

HashTables হ্যাশ যোগদান, সমষ্টি, সেট অপারেশন, এবং উইন্ডো ফাংশন জন্য প্রযোজ্য. PartitionedHashTable কাঠামো 16টির বেশি সাব-হ্যাশটেবল সমর্থন করে না। এটি হ্যাশটেবলের সমান্তরাল একত্রীকরণকেও সমর্থন করে এবং প্রতিটি সাব-হ্যাশ জয়েন স্বাধীনভাবে স্কেল করা যেতে পারে।

এগুলি সামগ্রিক মেমরি ব্যবহার এবং স্কেলিং দ্বারা সৃষ্ট বিলম্ব কমাতে পারে।

যদি বর্তমান হ্যাশটেবলটি 8M-এর থেকে ছোট হয়, তাহলে এটি 4 এর একটি ফ্যাক্টর দ্বারা মাপানো হবে;

যদি এটি 8M এর চেয়ে বড় হয় তবে এটি 2 এর একটি গুণিতক দ্বারা মাপানো হবে;

যদি এটি 2G-এর চেয়ে ছোট হয়, এটি 50% পূর্ণ হলে তা মাপানো হবে;

এবং যদি এটি 2G-এর থেকে বড় হয়, এটি 75% পূর্ণ হলে এটি মাপ করা হবে।

নতুন তৈরি করা হ্যাশটেবলগুলি কতটা ডেটা থাকবে তার উপর ভিত্তি করে প্রাক-স্কেল করা হবে। আমরা বিভিন্ন পরিস্থিতিতে বিভিন্ন ধরণের হ্যাশটেবল সরবরাহ করি। উদাহরণস্বরূপ, সমষ্টির জন্য, আপনি PHmap প্রয়োগ করতে পারেন।

3. PODArray

PODArray, নাম অনুসারে, POD-এর একটি গতিশীল অ্যারে। এটি এবং std::vector মধ্যে পার্থক্য হল যে PODArray উপাদানগুলি শুরু করে না। এটি মেমরি সারিবদ্ধকরণ এবং std::vector এর কিছু ইন্টারফেস সমর্থন করে।

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

মেমরি ইন্টারফেস

একমাত্র ইন্টারফেস হিসাবে যেটি Arena, PODArray, এবং HashTable সমন্বয় করে, অ্যালোকেটর 64M এর চেয়ে বড় অনুরোধের জন্য মেমরি ম্যাপিং (MMAP) বরাদ্দ কার্যকর করে।

4K-এর চেয়ে ছোটদের সরাসরি সিস্টেম থেকে malloc/free এর মাধ্যমে বরাদ্দ করা হবে; এবং এর মধ্যে থাকা একটি সাধারণ-উদ্দেশ্য ক্যাশিং ChunkAllocator দ্বারা ত্বরান্বিত হবে, যা আমাদের বেঞ্চমার্কিং ফলাফল অনুসারে 10% কর্মক্ষমতা বৃদ্ধি নিয়ে আসে।

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

আমরা তাদের উভয়ের অভিজ্ঞতার পরে TCMalloc এর উপর Jemalloc বেছে নিয়েছি। আমরা আমাদের উচ্চ-সঙ্গতি পরীক্ষায় TCMalloc চেষ্টা করেছি এবং লক্ষ্য করেছি যে সেন্ট্রালফ্রিলিস্টে স্পিন লক মোট ক্যোয়ারী সময়ের 40% সময় নেয়।

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

অন্যান্য পরিস্থিতিতে সূক্ষ্ম-টিউনিং করার পরে, এটি TCMalloc এর মতো একই কার্যকারিতা প্রদান করেছে কিন্তু কম মেমরি গ্রহণ করেছে।

মেমরি পুনঃব্যবহার

Apache Doris এর এক্সিকিউশন লেয়ারে মেমরির পুনঃব্যবহার ব্যাপকভাবে সম্পাদিত হয়। উদাহরণস্বরূপ, একটি ক্যোয়ারী কার্যকর করার সময় ডেটা ব্লকগুলি পুনরায় ব্যবহার করা হবে। শাফেলের সময়, প্রেরকের প্রান্তে দুটি ব্লক থাকবে এবং তারা পর্যায়ক্রমে কাজ করবে, একটি ডেটা গ্রহণ করবে এবং অন্যটি RPC পরিবহনে।

একটি ট্যাবলেট পড়ার সময়, ডরিস প্রিডিকেট কলামটি পুনরায় ব্যবহার করবে, সাইক্লিক রিডিং প্রয়োগ করবে, ফিল্টার করবে, ফিল্টার করা ডেটা উপরের ব্লকে কপি করবে এবং তারপরে পরিষ্কার করবে।

একটি এগ্রিগেট কী টেবিলে ডেটা ইনজেস্ট করার সময়, একবার মেমটেবল যেটি ডেটা ক্যাশে করে একটি নির্দিষ্ট আকারে পৌঁছায়, এটি প্রাক-একত্রিত হবে এবং তারপরে আরও ডেটা লেখা হবে।

মেমরি পুনঃব্যবহার ডাটা স্ক্যানিং-এও কার্যকর করা হয়। স্ক্যানিং শুরু হওয়ার আগে, স্ক্যানিং টাস্কের জন্য অনেকগুলি ফ্রি ব্লক (স্ক্যানার এবং থ্রেডের সংখ্যার উপর নির্ভর করে) বরাদ্দ করা হবে।

প্রতিটি স্ক্যানার শিডিউলিংয়ের সময়, বিনামূল্যের ব্লকগুলির মধ্যে একটি ডেটা পড়ার জন্য স্টোরেজ স্তরে পাঠানো হবে।

ডেটা পড়ার পরে, পরবর্তী গণনাতে উপরের অপারেটরদের ব্যবহারের জন্য ব্লকটিকে প্রযোজকের সারিতে রাখা হবে। একবার একটি উপরের অপারেটর ব্লক থেকে গণনা ডেটা অনুলিপি করলে, ব্লকটি পরবর্তী স্ক্যানার সময়সূচীর জন্য বিনামূল্যে ব্লকগুলিতে ফিরে যাবে।

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

মেমরি ট্র্যাকিং

Apache Doris মেমরি হটস্পট বিশ্লেষণ করার সময় মেমরির বরাদ্দ এবং রিলিজ অনুসরণ করার জন্য MemTrackers ব্যবহার করে। মেমট্র্যাকাররা প্রতিটি ডেটা ক্যোয়ারী, ডেটা ইনজেশন, ডেটা কমপ্যাকশন টাস্ক এবং প্রতিটি গ্লোবাল অবজেক্টের মেমরি সাইজ যেমন ক্যাশে এবং ট্যাবলেট মেটা রেকর্ড রাখে।

এটি ম্যানুয়াল কাউন্টিং এবং মেমহুক অটো-ট্র্যাকিং উভয়কেই সমর্থন করে। ব্যবহারকারীরা একটি ওয়েব পৃষ্ঠায় ডরিস ব্যাকএন্ডে রিয়েল-টাইম মেমরি ব্যবহার দেখতে পারেন।

মেমট্র্যাকারের গঠন

Apache Doris 1.2.0-এর আগে MemTracker সিস্টেমটি একটি শ্রেণিবদ্ধ ট্রি কাঠামোতে ছিল, যার মধ্যে process_mem_tracker, query_pool_mem_tracker, query_mem_tracker, instance_mem_tracker, ExecNode_mem_tracker, এবং আরও অনেক কিছু ছিল।

দুটি প্রতিবেশী স্তরের মেমট্র্যাকাররা পিতামাতা-সন্তানের সম্পর্কের। তাই, একটি শিশু মেমট্র্যাকারে গণনার যেকোন ভুলগুলি সর্বত্র জমে উঠবে এবং এর ফলে অবিশ্বাস্যতার বৃহত্তর স্কেল হবে।

Apache Doris 1.2.0 এবং পরবর্তীতে, আমরা MemTrackers এর গঠনকে অনেক সহজ করে দিয়েছি। MemTrackers শুধুমাত্র তাদের ভূমিকার উপর ভিত্তি করে দুটি প্রকারে বিভক্ত: MemTracker Limiter এবং অন্যান্য।

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

MemTracker Limiter এবং অন্যান্য MemTrackers-এর মধ্যে পিতামাতা-সন্তানের সম্পর্ক শুধুমাত্র স্ন্যাপশট প্রিন্টিং-এ প্রকাশ পায়। আপনি একটি প্রতীকী লিঙ্ক হিসাবে এই ধরনের একটি সম্পর্ক চিন্তা করতে পারেন. এগুলি একই সময়ে খাওয়া হয় না এবং একজনের জীবনচক্র অন্যটির জীবনচক্রকে প্রভাবিত করে না।

এটি ডেভেলপারদের বুঝতে এবং ব্যবহার করা অনেক সহজ করে তোলে।

MemTrackers (MemTracker Limiter এবং অন্যান্য সহ) মানচিত্রের একটি গ্রুপে রাখা হয়। তারা ব্যবহারকারীদের সামগ্রিক মেমট্র্যাকার টাইপ স্ন্যাপশট, ক্যোয়ারী/লোড/কম্প্যাকশন টাস্ক স্ন্যাপশট প্রিন্ট করার অনুমতি দেয় এবং সবচেয়ে বেশি মেমরি ব্যবহার বা সবচেয়ে বেশি মেমরি ব্যবহার করে ক্যোয়ারী/লোড খুঁজে বের করতে দেয়।

মেমট্র্যাকার কিভাবে কাজ করে

একটি নির্দিষ্ট এক্সিকিউশনের মেমরি ব্যবহার গণনা করার জন্য, বর্তমান থ্রেডের থ্রেড লোকালের একটি স্ট্যাকের সাথে একটি মেমট্র্যাকার যোগ করা হয়। Jemalloc বা TCMalloc-এ malloc/free/realloc পুনরায় লোড করার মাধ্যমে, MemHook বরাদ্দ বা রিলিজ করা মেমরির প্রকৃত আকার পায় এবং বর্তমান থ্রেডের থ্রেড লোকাল-এ রেকর্ড করে।

যখন একটি সম্পাদন করা হয়, প্রাসঙ্গিক MemTracker স্ট্যাক থেকে সরানো হবে। স্ট্যাকের নীচে মেমট্র্যাকার রয়েছে যা পুরো ক্যোয়ারী/লোড এক্সিকিউশন প্রক্রিয়া চলাকালীন মেমরি ব্যবহার রেকর্ড করে।

এখন, আমাকে একটি সরলীকৃত ক্যোয়ারী এক্সিকিউশন প্রক্রিয়া দিয়ে ব্যাখ্যা করা যাক।

• একটি ডরিস ব্যাকএন্ড নোড শুরু হওয়ার পরে, সমস্ত থ্রেডের মেমরি ব্যবহার প্রক্রিয়া মেমট্র্যাকারে রেকর্ড করা হবে।

  
  

• যখন একটি ক্যোয়ারী জমা দেওয়া হয়, একটি ক্যোয়ারী মেমট্র্যাকার থ্রেড লোকাল স্টোরেজ (TLS) স্ট্যাকে ফ্র্যাগমেন্ট এক্সিকিউশন থ্রেডে যোগ করা হবে।

  
  

• একবার একটি স্ক্যাননোড নির্ধারিত হয়ে গেলে, একটি স্ক্যাননোড মেমট্র্যাকার থ্রেড লোকাল স্টোরেজ (টিএলএস) স্ট্যাকে ফ্র্যাগমেন্ট এক্সিকিউশন থ্রেডে যোগ করা হবে। তারপর, এই থ্রেডে বরাদ্দ করা বা প্রকাশিত যেকোন মেমরি ক্যোয়ারী মেমট্র্যাকার এবং স্ক্যাননোড মেমট্র্যাকার উভয়ের মধ্যে রেকর্ড করা হবে।

  
  

• একটি স্ক্যানার নির্ধারিত হওয়ার পরে, স্ক্যানার থ্রেডের TLS স্ট্যাকে একটি ক্যোয়ারী মেমট্র্যাকার এবং একটি স্ক্যানার মেমট্র্যাকার যোগ করা হবে।

  
  

• স্ক্যানিং সম্পন্ন হলে, স্ক্যানার থ্রেড TLS স্ট্যাকের সমস্ত মেমট্র্যাকার সরানো হবে। স্ক্যাননোড শিডিউলিং সম্পন্ন হলে, স্ক্যাননোড মেমট্র্যাকারকে ফ্র্যাগমেন্ট এক্সিকিউশন থ্রেড থেকে সরিয়ে দেওয়া হবে। তারপর, একইভাবে, যখন একটি অ্যাগ্রিগেশন নোড নির্ধারিত হয়, তখন একটি AggregationNode MemTracker ফ্র্যাগমেন্ট এক্সিকিউশন থ্রেড TLS স্ট্যাকের সাথে যোগ করা হবে এবং শিডিউল করা হয়ে গেলে সরিয়ে দেওয়া হবে।

  
  

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

মেমট্র্যাকার কীভাবে ব্যবহার করবেন

ডরিস ব্যাকএন্ড ওয়েব পেজ রিয়েল-টাইম মেমরির ব্যবহার প্রদর্শন করে, যা বিভিন্ন প্রকারে বিভক্ত: ক্যোয়ারী/লোড/কম্প্যাকশন/গ্লোবাল। বর্তমান মেমরি খরচ এবং সর্বোচ্চ খরচ দেখানো হয়.

গ্লোবাল প্রকারের মধ্যে রয়েছে ক্যাশে এবং ট্যাবলেটমেটার মেমট্র্যাকার।

ক্যোয়ারী প্রকার থেকে, আপনি বর্তমান কোয়েরির বর্তমান মেমরি খরচ এবং সর্বোচ্চ খরচ এবং এতে জড়িত অপারেটরগুলি দেখতে পারেন (আপনি লেবেল থেকে তারা কীভাবে সম্পর্কিত তা বলতে পারেন)। ঐতিহাসিক প্রশ্নের মেমরি পরিসংখ্যানের জন্য, আপনি Doris FE অডিট লগ বা BE INFO লগগুলি পরীক্ষা করতে পারেন৷

মেমরি সীমা

ডরিস ব্যাকএন্ডে ব্যাপকভাবে বাস্তবায়িত মেমরি ট্র্যাকিংয়ের সাথে, আমরা OOM, ব্যাকএন্ড ডাউনটাইমের কারণ এবং বৃহৎ-স্কেল ক্যোয়ারী ব্যর্থতা দূর করার এক ধাপ কাছাকাছি। পরবর্তী ধাপ হল মেমরির ব্যবহার নিয়ন্ত্রণে রাখার জন্য প্রশ্ন এবং প্রক্রিয়ার মেমরি সীমা অপ্টিমাইজ করা।

প্রশ্নের মেমরি সীমা

ব্যবহারকারী প্রতিটি প্রশ্নের একটি মেমরি সীমা রাখতে পারেন. যদি এক্সিকিউশনের সময় সেই সীমা অতিক্রম করা হয়, প্রশ্নটি বাতিল করা হবে। কিন্তু সংস্করণ 1.2 থেকে, আমরা মেমরি ওভারকমিটের অনুমতি দিয়েছি, যা একটি আরও নমনীয় মেমরি সীমা নিয়ন্ত্রণ।

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

Apache Doris 2.0 এ থাকাকালীন, আমরা প্রশ্নের জন্য ব্যতিক্রম নিরাপত্তা উপলব্ধি করেছি। তার মানে যেকোনও অপর্যাপ্ত মেমরি বরাদ্দের ফলে ক্যোয়ারীটি অবিলম্বে বাতিল হয়ে যাবে, যা পরবর্তী ধাপে "বাতিল" স্থিতি পরীক্ষা করার ঝামেলা বাঁচায়।

প্রক্রিয়ার উপর মেমরি সীমা

নিয়মিতভাবে, ডরিস ব্যাকএন্ড সিস্টেম থেকে প্রসেসের শারীরিক মেমরি এবং বর্তমানে উপলব্ধ মেমরি আকার পুনরুদ্ধার করে। ইতিমধ্যে, এটি সমস্ত ক্যোয়ারী/লোড/কম্প্যাকশন কাজের মেমট্র্যাকার স্ন্যাপশট সংগ্রহ করে।

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

যদি ব্যবহৃত প্রক্রিয়া মেমরিটি SoftMemLimit (মোট সিস্টেম মেমরির 81%, ডিফল্টরূপে) বেশি হয়, বা উপলব্ধ সিস্টেম মেমরি সতর্কতা জলের চিহ্নের (3.2GB-এর কম) নীচে নেমে যায়, মাইনর GC ট্রিগার করা হবে।

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

যদি নতুন রিলিজ করা মেমরি প্রক্রিয়া মেমরির 10% কভার না করে, মেমরি ওভারকমিট সক্ষম করে, ডরিস 10% টার্গেট পূরণ না হওয়া পর্যন্ত বা সমস্ত প্রশ্ন বাতিল না হওয়া পর্যন্ত সবচেয়ে বড় "ওভারকমিটার" কোয়েরিগুলি বাতিল করা শুরু করবে৷

তারপর, ডরিস সিস্টেম মেমরি চেকিং ব্যবধান এবং GC ব্যবধান ছোট করবে। আরও মেমরি উপলব্ধ হওয়ার পরে প্রশ্নগুলি চালিয়ে যাওয়া হবে।

যদি ব্যবহৃত প্রক্রিয়া মেমরি মেমলিমিটের (মোট সিস্টেম মেমরির 90%, ডিফল্টভাবে), বা উপলব্ধ সিস্টেম মেমরি লো ওয়াটার মার্ক (1.6GB-এর কম) এর নিচে নেমে যায়, তাহলে সম্পূর্ণ GC ট্রিগার করা হবে।

এই সময়ে, ডেটা ইনজেশনের কাজগুলি বন্ধ করা হবে, এবং সমস্ত ডেটা পৃষ্ঠা ক্যাশে এবং বেশিরভাগ অন্যান্য ক্যাশে প্রকাশ করা হবে৷

যদি, এই সমস্ত পদক্ষেপের পরে, নতুন প্রকাশিত মেমরিটি প্রসেস মেমরির 20% কভার না করে, ডরিস সমস্ত মেমট্র্যাকারগুলিকে খতিয়ে দেখবে এবং সবচেয়ে বেশি মেমরি-গ্রাহক প্রশ্ন এবং ইনজেশনের কাজগুলি খুঁজে বের করবে এবং সেগুলিকে একে একে বাতিল করবে৷

20% লক্ষ্যমাত্রা পূরণ হওয়ার পরেই সিস্টেম মেমরি চেকিং ব্যবধান এবং GC ব্যবধান বাড়ানো হবে এবং প্রশ্ন এবং ইনজেশন কাজগুলি চালিয়ে যাওয়া হবে। (একটি আবর্জনা সংগ্রহের ক্রিয়াকলাপ সাধারণত শত শত μs থেকে কয়েক ডজন ms পর্যন্ত লাগে।)

প্রভাব এবং ফলাফল

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

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

পরবর্তী পর্যায়ে, আমরা মেমরি ওভারকমিটমেন্টে প্রশ্নের সমাপ্তি নিশ্চিত করার পরিকল্পনা করছি, যার অর্থ মেমরির ঘাটতির কারণে কম প্রশ্ন বাতিল করতে হবে।

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

আপনি যদি আমাদের ডেভেলপারদের সাথে দেখা করতে চান তবে এখানেই আপনি আমাদের খুঁজে পাবেন ।