কিভাবে HBase থেকে 3 গুণ পর্যন্ত এবং HDFS থেকে 5 গুণ পর্যন্ত পড়ার গতি বাড়ানো যায়

বড় ডেটা নিয়ে কাজ করার সময় উচ্চ কর্মক্ষমতা অন্যতম প্রধান প্রয়োজনীয়তা। Sberbank-এর ডেটা লোডিং বিভাগে, আমরা আমাদের Hadoop-ভিত্তিক ডেটা ক্লাউডে প্রায় সমস্ত লেনদেন পাম্প করি এবং তাই তথ্যের সত্যিই বড় প্রবাহের সাথে মোকাবিলা করি। স্বাভাবিকভাবেই, আমরা সর্বদা কর্মক্ষমতা উন্নত করার উপায় খুঁজছি, এবং এখন আমরা আপনাকে বলতে চাই কিভাবে আমরা RegionServer HBase এবং HDFS ক্লায়েন্ট প্যাচ করতে পেরেছি, যার কারণে আমরা পড়ার ক্রিয়াকলাপের গতি উল্লেখযোগ্যভাবে বৃদ্ধি করতে সক্ষম হয়েছি।


যাইহোক, উন্নতির সারমর্মে যাওয়ার আগে, বিধিনিষেধগুলি সম্পর্কে কথা বলা মূল্যবান যা, নীতিগতভাবে, আপনি যদি HDD তে বসে থাকেন তবে এড়ানো যাবে না।

কেন HDD এবং দ্রুত র্যান্ডম অ্যাক্সেস রিডগুলি বেমানান৷
যেমন আপনি জানেন, HBase এবং অন্যান্য অনেক ডেটাবেস, কয়েক দশ কিলোবাইটের আকারের ব্লকে ডেটা সঞ্চয় করে। ডিফল্টরূপে এটি প্রায় 64 KB। এখন কল্পনা করা যাক যে আমাদের শুধুমাত্র 100 বাইট পেতে হবে এবং আমরা HBase কে একটি নির্দিষ্ট কী ব্যবহার করে এই ডেটা দিতে বলি। যেহেতু HFiles-এ ব্লকের আকার 64 KB, অনুরোধটি প্রয়োজনের চেয়ে 640 গুণ বড় (এক মিনিট!) হবে৷

পরবর্তী, যেহেতু অনুরোধটি HDFS এবং এর মেটাডেটা ক্যাশিং প্রক্রিয়ার মাধ্যমে যাবে শর্ট সার্কিট ক্যাশে (যা ফাইলগুলিতে সরাসরি অ্যাক্সেসের অনুমতি দেয়), এটি ডিস্ক থেকে ইতিমধ্যে 1 এমবি পড়ার দিকে নিয়ে যায়। যাইহোক, এটি পরামিতি দিয়ে সামঞ্জস্য করা যেতে পারে dfs.client.read.shortcircuit.buffer.size এবং অনেক ক্ষেত্রে এই মানটি কমাতে বোঝায়, উদাহরণস্বরূপ 126 KB.

ধরা যাক আমরা এটি করি, কিন্তু উপরন্তু, যখন আমরা জাভা এপিআই-এর মাধ্যমে ডেটা পড়া শুরু করি, যেমন FileChannel.read এর মতো ফাংশন এবং অপারেটিং সিস্টেমকে নির্দিষ্ট পরিমাণ ডেটা পড়তে বলি, এটি "শুধু ক্ষেত্রে" 2 গুণ বেশি পড়ে। , অর্থাৎ আমাদের ক্ষেত্রে 256 KB. এর কারণ হল এই আচরণ প্রতিরোধ করার জন্য FADV_RANDOM পতাকা সেট করার সহজ উপায় জাভা নেই।

ফলস্বরূপ, আমাদের 100 বাইট পেতে, হুডের নীচে 2600 গুণ বেশি পড়া হয়। মনে হবে যে সমাধানটি সুস্পষ্ট, আসুন ব্লকের আকারকে এক কিলোবাইটে কমিয়ে দেই, উল্লিখিত পতাকা সেট করি এবং দুর্দান্ত জ্ঞানার্জন ত্বরণ লাভ করি। কিন্তু মুশকিল হল ব্লকের আকার 2 গুণ কমিয়ে, আমরা প্রতি ইউনিটে পড়ার বাইটের সংখ্যাও 2 গুণ কমিয়ে দিই।

FADV_RANDOM পতাকা সেট করে কিছু লাভ পাওয়া যেতে পারে, তবে শুধুমাত্র উচ্চ মাল্টি-থ্রেডিং এবং 128 KB ব্লকের আকারের সাথে, তবে এটি সর্বাধিক কয়েক শতাংশের বেশি:

100টি ফাইলে পরীক্ষা করা হয়েছিল, প্রতিটি 1 জিবি আকারের এবং 10টি HDD-তে অবস্থিত।

আসুন আমরা এই গতিতে নীতিগতভাবে কী গণনা করতে পারি তা গণনা করি:
ধরা যাক আমরা 10 এমবি/সেকেন্ড গতিতে 280টি ডিস্ক থেকে পড়ি, যেমন 3 মিলিয়ন বার 100 বাইট। কিন্তু আমরা মনে রাখি যে, আমাদের যে ডেটার প্রয়োজন তা পড়ার চেয়ে 2600 গুণ কম। এইভাবে, আমরা 3 মিলিয়নকে 2600 দ্বারা ভাগ করি এবং পাই প্রতি সেকেন্ডে 1100 রেকর্ড।

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

তাহলে কিভাবে ডাটাবেস অনেক বেশি গতি অর্জন করে? এই প্রশ্নের উত্তর দিতে, আসুন নীচের ছবিতে কী ঘটছে তা দেখুন:

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

এইভাবে, আমরা কেবলমাত্র OS ক্যাশে থাকা বা তুলনাযোগ্য অ্যাক্সেস গতির SSD/NVMe স্টোরেজ ডিভাইসে থাকা ডেটাগুলিতে অ্যাক্সেস ত্বরান্বিত করার সাথে মোকাবিলা করব।

আমাদের ক্ষেত্রে, আমরা 4টি সার্ভারের একটি বেঞ্চে পরীক্ষা পরিচালনা করব, যার প্রত্যেকটি নিম্নরূপ চার্জ করা হয়:

CPU: Xeon E5-2680 v4 @ 2.40GHz 64 থ্রেড।
মেমরি: 730 জিবি।
জাভা সংস্করণ: 1.8.0_111

এবং এখানে মূল বিষয় হল টেবিলের ডেটার পরিমাণ যা পড়তে হবে। আসল বিষয়টি হল যে আপনি যদি HBase ক্যাশে সম্পূর্ণরূপে স্থাপন করা একটি টেবিল থেকে ডেটা পড়েন, তাহলে এটি অপারেটিং সিস্টেমের বাফ/ক্যাশে থেকেও পড়তে আসবে না। কারণ HBase ডিফল্টভাবে 40% মেমরি ব্লকক্যাচে নামক কাঠামোতে বরাদ্দ করে। মূলত এটি একটি ConcurrentHashMap, যেখানে কী হল ফাইলের নাম + ব্লকের অফসেট, এবং মান হল এই অফসেটে প্রকৃত ডেটা।

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

উদাহরণস্বরূপ, আমাদের ক্ষেত্রে, এক আরএস-এ ব্লকক্যাশের ভলিউম প্রায় 12 জিবি। আমরা একটি নোডে দুটি আরএস অবতরণ করেছি, অর্থাৎ 96 জিবি সমস্ত নোডে ব্লকক্যাশের জন্য বরাদ্দ করা হয়েছে। এবং অনেকগুণ বেশি ডেটা রয়েছে, উদাহরণস্বরূপ, এটি 4টি টেবিল হতে দিন, প্রতিটি 130টি অঞ্চল, যেখানে ফাইলগুলি 800 এমবি আকারের, FAST_DIFF দ্বারা সংকুচিত, অর্থাৎ মোট 410 গিগাবাইট (এটি বিশুদ্ধ ডেটা, যেমন প্রতিলিপি ফ্যাক্টর বিবেচনা না করে)।

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

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

1. ক্যাশে ব্লক 1 রাখুন
2. ক্যাশে থেকে ব্লক 1 সরান
3. ক্যাশে ব্লক 2 রাখুন
4. ক্যাশে থেকে ব্লক 2 সরান
5. ক্যাশে ব্লক 3 রাখুন

5টি কাজ সম্পন্ন! যাইহোক, এই পরিস্থিতিকে স্বাভাবিক বলা যাবে না; আসলে, আমরা HBase কে একগুচ্ছ সম্পূর্ণ অকেজো কাজ করতে বাধ্য করছি। এটি ক্রমাগত OS ক্যাশে থেকে ডেটা পড়ে, এটি ব্লকক্যাশে রাখে, শুধুমাত্র এটিকে প্রায় অবিলম্বে ফেলে দেওয়ার জন্য কারণ ডেটার একটি নতুন অংশ এসেছে৷ পোস্টের শুরুতে অ্যানিমেশনটি সমস্যার সারমর্ম দেখায় - আবর্জনা সংগ্রাহক স্কেল বন্ধ হয়ে যাচ্ছে, বায়ুমণ্ডল উত্তপ্ত হচ্ছে, দূরবর্তী এবং গরম সুইডেনের ছোট্ট গ্রেটা বিচলিত হচ্ছে। এবং আমরা আইটি লোকেরা যখন বাচ্চারা দু: খিত হয় তখন এটি সত্যিই পছন্দ করি না, তাই আমরা এটি সম্পর্কে কী করতে পারি তা নিয়ে ভাবতে শুরু করি।

আপনি যদি ক্যাশে সমস্ত ব্লক না রাখেন, তবে তাদের শুধুমাত্র একটি নির্দিষ্ট শতাংশ রাখেন, যাতে ক্যাশে উপচে না যায়? BlockCache-এ ডেটা রাখার জন্য ফাংশনের শুরুতে কোডের মাত্র কয়েকটি লাইন যোগ করে শুরু করা যাক:

  public void cacheBlock(BlockCacheKey cacheKey, Cacheable buf, boolean inMemory) {
    if (cacheDataBlockPercent != 100 && buf.getBlockType().isData()) {
      if (cacheKey.getOffset() % 100 >= cacheDataBlockPercent) {
        return;
      }
    }
...

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

উদাহরণস্বরূপ, cacheDataBlockPercent = 20 সেট করুন এবং দেখুন কি হয়:

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

একই সময়ে, CPU ব্যবহার বৃদ্ধি পায়, কিন্তু উৎপাদনশীলতার তুলনায় অনেক কম:

এটিও লক্ষণীয় যে ব্লকক্যাশে সংরক্ষিত ব্লকগুলি আলাদা। বেশিরভাগ, প্রায় 95%, ডেটা নিজেই। আর বাকিটা মেটাডেটা, যেমন ব্লুম ফিল্টার বা LEAF_INDEX এবং প্রভৃতি. এই ডেটা যথেষ্ট নয়, তবে এটি খুব দরকারী, কারণ সরাসরি ডেটা অ্যাক্সেস করার আগে, এখানে আরও অনুসন্ধান করা প্রয়োজন কিনা এবং যদি তাই হয়, আগ্রহের ব্লকটি ঠিক কোথায় অবস্থিত তা বোঝার জন্য HBase মেটাতে ফিরে যায়।

অতএব, কোডে আমরা একটি চেক শর্ত দেখতে পাই buf.getBlockType().isData() এবং এই মেটাকে ধন্যবাদ, আমরা এটিকে যেকোনো ক্ষেত্রেই ক্যাশে রেখে দেব।

এখন এর লোড বৃদ্ধি করা যাক এবং একযোগে বৈশিষ্ট্যটিকে কিছুটা শক্ত করা যাক। প্রথম পরীক্ষায় আমরা কাটঅফ শতাংশ = 20 করেছি এবং ব্লকক্যাশে সামান্য কম ব্যবহার করা হয়েছিল। এখন আসুন এটিকে 23% এ সেট করি এবং প্রতি 100 মিনিটে 5টি থ্রেড যোগ করি কোন বিন্দুতে স্যাচুরেশন ঘটে তা দেখতে:

এখানে আমরা দেখতে পাই যে আসল সংস্করণটি প্রায় সাথে সাথেই প্রতি সেকেন্ডে প্রায় 100 হাজার অনুরোধে সিলিংয়ে আঘাত করে। যেখানে প্যাচ 300 হাজার পর্যন্ত একটি ত্বরণ দেয়। একই সময়ে, এটা স্পষ্ট যে আরও ত্বরণ আর এত "মুক্ত" নয়; CPU ব্যবহারও বাড়ছে।

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

এটি নিয়ন্ত্রণ করার জন্য তিনটি বিকল্প যুক্ত করা হয়েছে:

hbase.lru.cache.heavy.eviction.count.limit আমরা অপ্টিমাইজেশান ব্যবহার শুরু করার আগে ক্যাশে থেকে ডেটা উচ্ছেদ করার প্রক্রিয়াটি কতবার চালানো উচিত তা সেট করে (অর্থাৎ ব্লকগুলি এড়িয়ে যাওয়া)। ডিফল্টরূপে এটি MAX_INT = 2147483647 এর সমান এবং প্রকৃতপক্ষে এর মানে হল যে বৈশিষ্ট্যটি কখনই এই মানটির সাথে কাজ করা শুরু করবে না৷ কারণ উচ্ছেদ প্রক্রিয়া প্রতি 5 - 10 সেকেন্ডে শুরু হয় (এটি লোডের উপর নির্ভর করে) এবং 2147483647 * 10 / 60 / 60 / 24 / 365 = 680 বছর। যাইহোক, আমরা এই প্যারামিটারটি 0 এ সেট করতে পারি এবং লঞ্চের পরপরই বৈশিষ্ট্যটিকে কাজ করতে পারি।

যাইহোক, এই প্যারামিটারে একটি পেলোডও রয়েছে। যদি আমাদের লোড এমন হয় যে স্বল্প-মেয়াদী পাঠ (দিনে বলুন) এবং দীর্ঘ-মেয়াদী পাঠগুলি (রাতে) ক্রমাগত ছেদ করা হয়, তবে আমরা নিশ্চিত করতে পারি যে দীর্ঘ পঠন ক্রিয়াকলাপগুলি চলমান থাকলেই বৈশিষ্ট্যটি চালু করা হয়েছে।

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

hbase.lru.cache.heavy.eviction.mb.size.limit — 10 সেকেন্ডের মধ্যে আমরা কত মেগাবাইট ক্যাশে রাখতে চাই (এবং অবশ্যই, উচ্ছেদ) সেট করে। বৈশিষ্ট্য এই মান পৌঁছানোর এবং এটি বজায় রাখার চেষ্টা করবে। মূল বিষয়টি হল: যদি আমরা ক্যাশে গিগাবাইটগুলিকে ঢেলে দেই, তাহলে আমাদের গিগাবাইটগুলিকে উচ্ছেদ করতে হবে এবং এটি, যেমনটি আমরা উপরে দেখেছি, খুব ব্যয়বহুল। যাইহোক, আপনি এটিকে খুব ছোট সেট করার চেষ্টা করবেন না, কারণ এর ফলে ব্লক স্কিপ মোড অকালে প্রস্থান হবে। শক্তিশালী সার্ভারের জন্য (প্রায় 20-40 শারীরিক কোর), এটি প্রায় 300-400 MB সেট করা সর্বোত্তম। মধ্যবিত্তের জন্য (~10 কোর) 200-300 MB। দুর্বল সিস্টেমের জন্য (2-5 কোর) 50-100 MB স্বাভাবিক হতে পারে (এগুলিতে পরীক্ষা করা হয়নি)।

চলুন দেখি এটি কিভাবে কাজ করে: ধরা যাক আমরা hbase.lru.cache.heavy.eviction.mb.size.limit = 500 সেট করেছি, কিছু লোড (পড়া) আছে এবং তারপর প্রতি ~10 সেকেন্ডে আমরা গণনা করি কত বাইট ছিল সূত্র ব্যবহার করে উচ্ছেদ করা হয়েছে:

ওভারহেড = ফ্রিড বাইট সমষ্টি (এমবি) * 100 / সীমা (এমবি) - 100;

যদি প্রকৃতপক্ষে 2000 MB উচ্ছেদ করা হয়, তাহলে ওভারহেড এর সমান:

2000 * 100 / 500 - 100 = 300%

অ্যালগরিদমগুলি কয়েক দশ শতাংশের বেশি বজায় রাখার চেষ্টা করে না, তাই বৈশিষ্ট্যটি ক্যাশে করা ব্লকের শতাংশ হ্রাস করবে, যার ফলে একটি স্বয়ংক্রিয়-টিউনিং প্রক্রিয়া প্রয়োগ করা হবে।

যাইহোক, যদি লোড কমে যায়, ধরা যাক শুধুমাত্র 200 MB উচ্ছেদ করা হয়েছে এবং ওভারহেড নেতিবাচক হয়ে গেছে (তথাকথিত ওভারশুটিং):

200 * 100 / 500 - 100 = -60%

বিপরীতে, ওভারহেড ইতিবাচক না হওয়া পর্যন্ত বৈশিষ্ট্যটি ক্যাশে ব্লকের শতাংশ বৃদ্ধি করবে।

এটি বাস্তব ডেটাতে কীভাবে দেখায় তার একটি উদাহরণ নীচে দেওয়া হল৷ 0% পৌঁছানোর চেষ্টা করার দরকার নেই, এটি অসম্ভব। এটি খুব ভাল যখন এটি প্রায় 30 - 100% হয়, এটি স্বল্প-মেয়াদী বৃদ্ধির সময় অপ্টিমাইজেশন মোড থেকে অকাল প্রস্থান এড়াতে সহায়তা করে।

hbase.lru.cache.heavy.eviction.overhead.coefficient - আমরা কত দ্রুত ফলাফল পেতে চাই তা সেট করে। যদি আমরা নিশ্চিতভাবে জানি যে আমাদের পাঠগুলি বেশিরভাগই দীর্ঘ এবং অপেক্ষা করতে চাই না, আমরা এই অনুপাতটি বাড়াতে পারি এবং দ্রুত উচ্চ কার্যক্ষমতা পেতে পারি।

উদাহরণস্বরূপ, আমরা এই সহগ = 0.01 সেট করি। এর মানে হল যে ওভারহেড (উপরে দেখুন) ফলাফলের দ্বারা এই সংখ্যা দ্বারা গুণিত হবে এবং ক্যাশে ব্লকের শতাংশ হ্রাস পাবে। ধরা যাক ওভারহেড = 300% এবং সহগ = 0.01, তাহলে ক্যাশে ব্লকের শতাংশ 3% কমে যাবে।

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

বাস্তবায়ন কোড

        LruBlockCache cache = this.cache.get();
        if (cache == null) {
          break;
        }
        freedSumMb += cache.evict()/1024/1024;
        /*
        * Sometimes we are reading more data than can fit into BlockCache
        * and it is the cause a high rate of evictions.
        * This in turn leads to heavy Garbage Collector works.
        * So a lot of blocks put into BlockCache but never read,
        * but spending a lot of CPU resources.
        * Here we will analyze how many bytes were freed and decide
        * decide whether the time has come to reduce amount of caching blocks.
        * It help avoid put too many blocks into BlockCache
        * when evict() works very active and save CPU for other jobs.
        * More delails: https://issues.apache.org/jira/browse/HBASE-23887
        */

        // First of all we have to control how much time
        // has passed since previuos evict() was launched
        // This is should be almost the same time (+/- 10s)
        // because we get comparable volumes of freed bytes each time.
        // 10s because this is default period to run evict() (see above this.wait)
        long stopTime = System.currentTimeMillis();
        if ((stopTime - startTime) > 1000 * 10 - 1) {
          // Here we have to calc what situation we have got.
          // We have the limit "hbase.lru.cache.heavy.eviction.bytes.size.limit"
          // and can calculte overhead on it.
          // We will use this information to decide,
          // how to change percent of caching blocks.
          freedDataOverheadPercent =
            (int) (freedSumMb * 100 / cache.heavyEvictionMbSizeLimit) - 100;
          if (freedSumMb > cache.heavyEvictionMbSizeLimit) {
            // Now we are in the situation when we are above the limit
            // But maybe we are going to ignore it because it will end quite soon
            heavyEvictionCount++;
            if (heavyEvictionCount > cache.heavyEvictionCountLimit) {
              // It is going for a long time and we have to reduce of caching
              // blocks now. So we calculate here how many blocks we want to skip.
              // It depends on:
             // 1. Overhead - if overhead is big we could more aggressive
              // reducing amount of caching blocks.
              // 2. How fast we want to get the result. If we know that our
              // heavy reading for a long time, we don't want to wait and can
              // increase the coefficient and get good performance quite soon.
              // But if we don't sure we can do it slowly and it could prevent
              // premature exit from this mode. So, when the coefficient is
              // higher we can get better performance when heavy reading is stable.
              // But when reading is changing we can adjust to it and set
              // the coefficient to lower value.
              int change =
                (int) (freedDataOverheadPercent * cache.heavyEvictionOverheadCoefficient);
              // But practice shows that 15% of reducing is quite enough.
              // We are not greedy (it could lead to premature exit).
              change = Math.min(15, change);
              change = Math.max(0, change); // I think it will never happen but check for sure
              // So this is the key point, here we are reducing % of caching blocks
              cache.cacheDataBlockPercent -= change;
              // If we go down too deep we have to stop here, 1% any way should be.
              cache.cacheDataBlockPercent = Math.max(1, cache.cacheDataBlockPercent);
            }
          } else {
            // Well, we have got overshooting.
            // Mayby it is just short-term fluctuation and we can stay in this mode.
            // It help avoid permature exit during short-term fluctuation.
            // If overshooting less than 90%, we will try to increase the percent of
            // caching blocks and hope it is enough.
            if (freedSumMb >= cache.heavyEvictionMbSizeLimit * 0.1) {
              // Simple logic: more overshooting - more caching blocks (backpressure)
              int change = (int) (-freedDataOverheadPercent * 0.1 + 1);
              cache.cacheDataBlockPercent += change;
              // But it can't be more then 100%, so check it.
              cache.cacheDataBlockPercent = Math.min(100, cache.cacheDataBlockPercent);
            } else {
              // Looks like heavy reading is over.
              // Just exit form this mode.
              heavyEvictionCount = 0;
              cache.cacheDataBlockPercent = 100;
            }
          }
          LOG.info("BlockCache evicted (MB): {}, overhead (%): {}, " +
            "heavy eviction counter: {}, " +
            "current caching DataBlock (%): {}",
            freedSumMb, freedDataOverheadPercent,
            heavyEvictionCount, cache.cacheDataBlockPercent);

          freedSumMb = 0;
          startTime = stopTime;
       }

এর এখন একটি বাস্তব উদাহরণ ব্যবহার করে এই সব তাকান. আমাদের নিম্নলিখিত পরীক্ষার স্ক্রিপ্ট আছে:

1. আসুন স্ক্যান করা শুরু করি (25 থ্রেড, ব্যাচ = 100)
2. 5 মিনিট পরে, মাল্টি-গেট যোগ করুন (25 থ্রেড, ব্যাচ = 100)
3. 5 মিনিট পরে, মাল্টি-গেটস বন্ধ করুন (শুধুমাত্র আবার স্ক্যান করা বাকি আছে)

আমরা দুটি রান করি, প্রথম hbase.lru.cache.heavy.eviction.count.limit = 10000 (যা আসলে বৈশিষ্ট্যটি নিষ্ক্রিয় করে), এবং তারপর সীমা = 0 সেট করে (এটি সক্ষম করে)।

নীচের লগগুলিতে আমরা দেখি কিভাবে বৈশিষ্ট্যটি চালু করা হয়েছে এবং ওভারশুটিং 14-71% এ পুনরায় সেট করা হয়েছে। সময়ে সময়ে লোড হ্রাস পায়, যা ব্যাকপ্রেশার চালু করে এবং HBase আবার আরও ব্লক ক্যাশে করে।

অঞ্চল সার্ভার লগ করুন
উচ্ছেদ করা (এমবি): 0, অনুপাত 0.0, ওভারহেড (%): -100, ভারী উচ্ছেদ কাউন্টার: 0, বর্তমান ক্যাশিং ডেটাব্লক (%): 100
উচ্ছেদ করা (এমবি): 0, অনুপাত 0.0, ওভারহেড (%): -100, ভারী উচ্ছেদ কাউন্টার: 0, বর্তমান ক্যাশিং ডেটাব্লক (%): 100
উচ্ছেদ করা (এমবি): 2170, অনুপাত 1.09, ওভারহেড (%): 985, ভারী উচ্ছেদ কাউন্টার: 1, বর্তমান ক্যাশিং ডেটাব্লক (%): 91 < শুরু
উচ্ছেদ করা (এমবি): 3763, অনুপাত 1.08, ওভারহেড (%): 1781, ভারী উচ্ছেদ কাউন্টার: 2, বর্তমান ক্যাশিং ডেটাব্লক (%): 76
উচ্ছেদ করা (এমবি): 3306, অনুপাত 1.07, ওভারহেড (%): 1553, ভারী উচ্ছেদ কাউন্টার: 3, বর্তমান ক্যাশিং ডেটাব্লক (%): 61
উচ্ছেদ করা (এমবি): 2508, অনুপাত 1.06, ওভারহেড (%): 1154, ভারী উচ্ছেদ কাউন্টার: 4, বর্তমান ক্যাশিং ডেটাব্লক (%): 50
উচ্ছেদ করা (এমবি): 1824, অনুপাত 1.04, ওভারহেড (%): 812, ভারী উচ্ছেদ কাউন্টার: 5, বর্তমান ক্যাশিং ডেটাব্লক (%): 42
উচ্ছেদ করা (এমবি): 1482, অনুপাত 1.03, ওভারহেড (%): 641, ভারী উচ্ছেদ কাউন্টার: 6, বর্তমান ক্যাশিং ডেটাব্লক (%): 36
উচ্ছেদ করা (এমবি): 1140, অনুপাত 1.01, ওভারহেড (%): 470, ভারী উচ্ছেদ কাউন্টার: 7, বর্তমান ক্যাশিং ডেটাব্লক (%): 32
উচ্ছেদ করা (এমবি): 913, অনুপাত 1.0, ওভারহেড (%): 356, ভারী উচ্ছেদ কাউন্টার: 8, বর্তমান ক্যাশিং ডেটাব্লক (%): 29
উচ্ছেদ করা (এমবি): 912, অনুপাত 0.89, ওভারহেড (%): 356, ভারী উচ্ছেদ কাউন্টার: 9, বর্তমান ক্যাশিং ডেটাব্লক (%): 26
উচ্ছেদ করা (এমবি): 684, অনুপাত 0.76, ওভারহেড (%): 242, ভারী উচ্ছেদ কাউন্টার: 10, বর্তমান ক্যাশিং ডেটাব্লক (%): 24
উচ্ছেদ করা (এমবি): 684, অনুপাত 0.61, ওভারহেড (%): 242, ভারী উচ্ছেদ কাউন্টার: 11, বর্তমান ক্যাশিং ডেটাব্লক (%): 22
উচ্ছেদ করা (এমবি): 456, অনুপাত 0.51, ওভারহেড (%): 128, ভারী উচ্ছেদ কাউন্টার: 12, বর্তমান ক্যাশিং ডেটাব্লক (%): 21
উচ্ছেদ করা (এমবি): 456, অনুপাত 0.42, ওভারহেড (%): 128, ভারী উচ্ছেদ কাউন্টার: 13, বর্তমান ক্যাশিং ডেটাব্লক (%): 20
উচ্ছেদ করা (এমবি): 456, অনুপাত 0.33, ওভারহেড (%): 128, ভারী উচ্ছেদ কাউন্টার: 14, বর্তমান ক্যাশিং ডেটাব্লক (%): 19
উচ্ছেদ করা (এমবি): 342, অনুপাত 0.33, ওভারহেড (%): 71, ভারী উচ্ছেদ কাউন্টার: 15, বর্তমান ক্যাশিং ডেটাব্লক (%): 19
উচ্ছেদ করা (এমবি): 342, অনুপাত 0.32, ওভারহেড (%): 71, ভারী উচ্ছেদ কাউন্টার: 16, বর্তমান ক্যাশিং ডেটাব্লক (%): 19
উচ্ছেদ করা (এমবি): 342, অনুপাত 0.31, ওভারহেড (%): 71, ভারী উচ্ছেদ কাউন্টার: 17, বর্তমান ক্যাশিং ডেটাব্লক (%): 19
উচ্ছেদ করা (এমবি): 228, অনুপাত 0.3, ওভারহেড (%): 14, ভারী উচ্ছেদ কাউন্টার: 18, বর্তমান ক্যাশিং ডেটাব্লক (%): 19
উচ্ছেদ করা (এমবি): 228, অনুপাত 0.29, ওভারহেড (%): 14, ভারী উচ্ছেদ কাউন্টার: 19, বর্তমান ক্যাশিং ডেটাব্লক (%): 19
উচ্ছেদ করা (এমবি): 228, অনুপাত 0.27, ওভারহেড (%): 14, ভারী উচ্ছেদ কাউন্টার: 20, বর্তমান ক্যাশিং ডেটাব্লক (%): 19
উচ্ছেদ করা (এমবি): 228, অনুপাত 0.25, ওভারহেড (%): 14, ভারী উচ্ছেদ কাউন্টার: 21, বর্তমান ক্যাশিং ডেটাব্লক (%): 19
উচ্ছেদ করা (এমবি): 228, অনুপাত 0.24, ওভারহেড (%): 14, ভারী উচ্ছেদ কাউন্টার: 22, বর্তমান ক্যাশিং ডেটাব্লক (%): 19
উচ্ছেদ করা (এমবি): 228, অনুপাত 0.22, ওভারহেড (%): 14, ভারী উচ্ছেদ কাউন্টার: 23, বর্তমান ক্যাশিং ডেটাব্লক (%): 19
উচ্ছেদ করা (এমবি): 228, অনুপাত 0.21, ওভারহেড (%): 14, ভারী উচ্ছেদ কাউন্টার: 24, বর্তমান ক্যাশিং ডেটাব্লক (%): 19
উচ্ছেদ করা (এমবি): 228, অনুপাত 0.2, ওভারহেড (%): 14, ভারী উচ্ছেদ কাউন্টার: 25, বর্তমান ক্যাশিং ডেটাব্লক (%): 19
উচ্ছেদ করা (এমবি): 228, অনুপাত 0.17, ওভারহেড (%): 14, ভারী উচ্ছেদ কাউন্টার: 26, বর্তমান ক্যাশিং ডেটাব্লক (%): 19
উচ্ছেদ করা (এমবি): 456, অনুপাত 0.17, ওভারহেড (%): 128, ভারী উচ্ছেদ কাউন্টার: 27, বর্তমান ক্যাশিং ডেটাব্লক (%): 18 < যোগ করা হয়েছে (কিন্তু টেবিল একই)
উচ্ছেদ করা (এমবি): 456, অনুপাত 0.15, ওভারহেড (%): 128, ভারী উচ্ছেদ কাউন্টার: 28, বর্তমান ক্যাশিং ডেটাব্লক (%): 17
উচ্ছেদ করা (এমবি): 342, অনুপাত 0.13, ওভারহেড (%): 71, ভারী উচ্ছেদ কাউন্টার: 29, বর্তমান ক্যাশিং ডেটাব্লক (%): 17
উচ্ছেদ করা (এমবি): 342, অনুপাত 0.11, ওভারহেড (%): 71, ভারী উচ্ছেদ কাউন্টার: 30, বর্তমান ক্যাশিং ডেটাব্লক (%): 17
উচ্ছেদ করা (এমবি): 342, অনুপাত 0.09, ওভারহেড (%): 71, ভারী উচ্ছেদ কাউন্টার: 31, বর্তমান ক্যাশিং ডেটাব্লক (%): 17
উচ্ছেদ করা (এমবি): 228, অনুপাত 0.08, ওভারহেড (%): 14, ভারী উচ্ছেদ কাউন্টার: 32, বর্তমান ক্যাশিং ডেটাব্লক (%): 17
উচ্ছেদ করা (এমবি): 228, অনুপাত 0.07, ওভারহেড (%): 14, ভারী উচ্ছেদ কাউন্টার: 33, বর্তমান ক্যাশিং ডেটাব্লক (%): 17
উচ্ছেদ করা (এমবি): 228, অনুপাত 0.06, ওভারহেড (%): 14, ভারী উচ্ছেদ কাউন্টার: 34, বর্তমান ক্যাশিং ডেটাব্লক (%): 17
উচ্ছেদ করা (এমবি): 228, অনুপাত 0.05, ওভারহেড (%): 14, ভারী উচ্ছেদ কাউন্টার: 35, বর্তমান ক্যাশিং ডেটাব্লক (%): 17
উচ্ছেদ করা (এমবি): 228, অনুপাত 0.05, ওভারহেড (%): 14, ভারী উচ্ছেদ কাউন্টার: 36, বর্তমান ক্যাশিং ডেটাব্লক (%): 17
উচ্ছেদ করা (এমবি): 228, অনুপাত 0.04, ওভারহেড (%): 14, ভারী উচ্ছেদ কাউন্টার: 37, বর্তমান ক্যাশিং ডেটাব্লক (%): 17
উচ্ছেদ করা (এমবি): 109, অনুপাত 0.04, ওভারহেড (%): -46, ভারী উচ্ছেদ কাউন্টার: 37, বর্তমান ক্যাশিং ডেটাব্লক (%): 22 < পিছনের চাপ
উচ্ছেদ করা (এমবি): 798, অনুপাত 0.24, ওভারহেড (%): 299, ভারী উচ্ছেদ কাউন্টার: 38, বর্তমান ক্যাশিং ডেটাব্লক (%): 20
উচ্ছেদ করা (এমবি): 798, অনুপাত 0.29, ওভারহেড (%): 299, ভারী উচ্ছেদ কাউন্টার: 39, বর্তমান ক্যাশিং ডেটাব্লক (%): 18
উচ্ছেদ করা (এমবি): 570, অনুপাত 0.27, ওভারহেড (%): 185, ভারী উচ্ছেদ কাউন্টার: 40, বর্তমান ক্যাশিং ডেটাব্লক (%): 17
উচ্ছেদ করা (এমবি): 456, অনুপাত 0.22, ওভারহেড (%): 128, ভারী উচ্ছেদ কাউন্টার: 41, বর্তমান ক্যাশিং ডেটাব্লক (%): 16
উচ্ছেদ করা (এমবি): 342, অনুপাত 0.16, ওভারহেড (%): 71, ভারী উচ্ছেদ কাউন্টার: 42, বর্তমান ক্যাশিং ডেটাব্লক (%): 16
উচ্ছেদ করা (এমবি): 342, অনুপাত 0.11, ওভারহেড (%): 71, ভারী উচ্ছেদ কাউন্টার: 43, বর্তমান ক্যাশিং ডেটাব্লক (%): 16
উচ্ছেদ করা (এমবি): 228, অনুপাত 0.09, ওভারহেড (%): 14, ভারী উচ্ছেদ কাউন্টার: 44, বর্তমান ক্যাশিং ডেটাব্লক (%): 16
উচ্ছেদ করা (এমবি): 228, অনুপাত 0.07, ওভারহেড (%): 14, ভারী উচ্ছেদ কাউন্টার: 45, বর্তমান ক্যাশিং ডেটাব্লক (%): 16
উচ্ছেদ করা (এমবি): 228, অনুপাত 0.05, ওভারহেড (%): 14, ভারী উচ্ছেদ কাউন্টার: 46, বর্তমান ক্যাশিং ডেটাব্লক (%): 16
উচ্ছেদ করা (এমবি): 222, অনুপাত 0.04, ওভারহেড (%): 11, ভারী উচ্ছেদ কাউন্টার: 47, বর্তমান ক্যাশিং ডেটাব্লক (%): 16
উচ্ছেদ করা (এমবি): 104, অনুপাত 0.03, ওভারহেড (%): -48, ভারী উচ্ছেদ কাউন্টার: 47, বর্তমান ক্যাশিং ডেটাব্লক (%): 21 < বাধা পায়
উচ্ছেদ করা (এমবি): 684, অনুপাত 0.2, ওভারহেড (%): 242, ভারী উচ্ছেদ কাউন্টার: 48, বর্তমান ক্যাশিং ডেটাব্লক (%): 19
উচ্ছেদ করা (এমবি): 570, অনুপাত 0.23, ওভারহেড (%): 185, ভারী উচ্ছেদ কাউন্টার: 49, বর্তমান ক্যাশিং ডেটাব্লক (%): 18
উচ্ছেদ করা (এমবি): 342, অনুপাত 0.22, ওভারহেড (%): 71, ভারী উচ্ছেদ কাউন্টার: 50, বর্তমান ক্যাশিং ডেটাব্লক (%): 18
উচ্ছেদ করা (এমবি): 228, অনুপাত 0.21, ওভারহেড (%): 14, ভারী উচ্ছেদ কাউন্টার: 51, বর্তমান ক্যাশিং ডেটাব্লক (%): 18
উচ্ছেদ করা (এমবি): 228, অনুপাত 0.2, ওভারহেড (%): 14, ভারী উচ্ছেদ কাউন্টার: 52, বর্তমান ক্যাশিং ডেটাব্লক (%): 18
উচ্ছেদ করা (এমবি): 228, অনুপাত 0.18, ওভারহেড (%): 14, ভারী উচ্ছেদ কাউন্টার: 53, বর্তমান ক্যাশিং ডেটাব্লক (%): 18
উচ্ছেদ করা (এমবি): 228, অনুপাত 0.16, ওভারহেড (%): 14, ভারী উচ্ছেদ কাউন্টার: 54, বর্তমান ক্যাশিং ডেটাব্লক (%): 18
উচ্ছেদ করা (এমবি): 228, অনুপাত 0.14, ওভারহেড (%): 14, ভারী উচ্ছেদ কাউন্টার: 55, বর্তমান ক্যাশিং ডেটাব্লক (%): 18
উচ্ছেদ করা (এমবি): 112, অনুপাত 0.14, ওভারহেড (%): -44, ভারী উচ্ছেদ কাউন্টার: 55, বর্তমান ক্যাশিং ডেটাব্লক (%): 23 < পিছনের চাপ
উচ্ছেদ করা (এমবি): 456, অনুপাত 0.26, ওভারহেড (%): 128, ভারী উচ্ছেদ কাউন্টার: 56, বর্তমান ক্যাশিং ডেটাব্লক (%): 22
উচ্ছেদ করা (এমবি): 342, অনুপাত 0.31, ওভারহেড (%): 71, ভারী উচ্ছেদ কাউন্টার: 57, বর্তমান ক্যাশিং ডেটাব্লক (%): 22
উচ্ছেদ করা (এমবি): 342, অনুপাত 0.33, ওভারহেড (%): 71, ভারী উচ্ছেদ কাউন্টার: 58, বর্তমান ক্যাশিং ডেটাব্লক (%): 22
উচ্ছেদ করা (এমবি): 342, অনুপাত 0.33, ওভারহেড (%): 71, ভারী উচ্ছেদ কাউন্টার: 59, বর্তমান ক্যাশিং ডেটাব্লক (%): 22
উচ্ছেদ করা (এমবি): 342, অনুপাত 0.33, ওভারহেড (%): 71, ভারী উচ্ছেদ কাউন্টার: 60, বর্তমান ক্যাশিং ডেটাব্লক (%): 22
উচ্ছেদ করা (এমবি): 342, অনুপাত 0.33, ওভারহেড (%): 71, ভারী উচ্ছেদ কাউন্টার: 61, বর্তমান ক্যাশিং ডেটাব্লক (%): 22
উচ্ছেদ করা (এমবি): 342, অনুপাত 0.33, ওভারহেড (%): 71, ভারী উচ্ছেদ কাউন্টার: 62, বর্তমান ক্যাশিং ডেটাব্লক (%): 22
উচ্ছেদ করা (এমবি): 342, অনুপাত 0.33, ওভারহেড (%): 71, ভারী উচ্ছেদ কাউন্টার: 63, বর্তমান ক্যাশিং ডেটাব্লক (%): 22
উচ্ছেদ করা (এমবি): 342, অনুপাত 0.32, ওভারহেড (%): 71, ভারী উচ্ছেদ কাউন্টার: 64, বর্তমান ক্যাশিং ডেটাব্লক (%): 22
উচ্ছেদ করা (এমবি): 342, অনুপাত 0.33, ওভারহেড (%): 71, ভারী উচ্ছেদ কাউন্টার: 65, বর্তমান ক্যাশিং ডেটাব্লক (%): 22
উচ্ছেদ করা (এমবি): 342, অনুপাত 0.33, ওভারহেড (%): 71, ভারী উচ্ছেদ কাউন্টার: 66, বর্তমান ক্যাশিং ডেটাব্লক (%): 22
উচ্ছেদ করা (এমবি): 342, অনুপাত 0.32, ওভারহেড (%): 71, ভারী উচ্ছেদ কাউন্টার: 67, বর্তমান ক্যাশিং ডেটাব্লক (%): 22
উচ্ছেদ করা (এমবি): 342, অনুপাত 0.33, ওভারহেড (%): 71, ভারী উচ্ছেদ কাউন্টার: 68, বর্তমান ক্যাশিং ডেটাব্লক (%): 22
উচ্ছেদ করা (এমবি): 342, অনুপাত 0.32, ওভারহেড (%): 71, ভারী উচ্ছেদ কাউন্টার: 69, বর্তমান ক্যাশিং ডেটাব্লক (%): 22
উচ্ছেদ করা (এমবি): 342, অনুপাত 0.32, ওভারহেড (%): 71, ভারী উচ্ছেদ কাউন্টার: 70, বর্তমান ক্যাশিং ডেটাব্লক (%): 22
উচ্ছেদ করা (এমবি): 342, অনুপাত 0.33, ওভারহেড (%): 71, ভারী উচ্ছেদ কাউন্টার: 71, বর্তমান ক্যাশিং ডেটাব্লক (%): 22
উচ্ছেদ করা (এমবি): 342, অনুপাত 0.33, ওভারহেড (%): 71, ভারী উচ্ছেদ কাউন্টার: 72, বর্তমান ক্যাশিং ডেটাব্লক (%): 22
উচ্ছেদ করা (এমবি): 342, অনুপাত 0.33, ওভারহেড (%): 71, ভারী উচ্ছেদ কাউন্টার: 73, বর্তমান ক্যাশিং ডেটাব্লক (%): 22
উচ্ছেদ করা (এমবি): 342, অনুপাত 0.33, ওভারহেড (%): 71, ভারী উচ্ছেদ কাউন্টার: 74, বর্তমান ক্যাশিং ডেটাব্লক (%): 22
উচ্ছেদ করা (এমবি): 342, অনুপাত 0.33, ওভারহেড (%): 71, ভারী উচ্ছেদ কাউন্টার: 75, বর্তমান ক্যাশিং ডেটাব্লক (%): 22
উচ্ছেদ করা (এমবি): 342, অনুপাত 0.33, ওভারহেড (%): 71, ভারী উচ্ছেদ কাউন্টার: 76, বর্তমান ক্যাশিং ডেটাব্লক (%): 22
উচ্ছেদ করা (এমবি): 21, অনুপাত 0.33, ওভারহেড (%): -90, ভারী উচ্ছেদ কাউন্টার: 76, বর্তমান ক্যাশিং ডেটাব্লক (%): 32
উচ্ছেদ করা (এমবি): 0, অনুপাত 0.0, ওভারহেড (%): -100, ভারী উচ্ছেদ কাউন্টার: 0, বর্তমান ক্যাশিং ডেটাব্লক (%): 100
উচ্ছেদ করা (এমবি): 0, অনুপাত 0.0, ওভারহেড (%): -100, ভারী উচ্ছেদ কাউন্টার: 0, বর্তমান ক্যাশিং ডেটাব্লক (%): 100

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

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

পুল রিকোয়েস্টে সম্পূর্ণ কোড পাওয়া যাবে HBASE 23887 গিথুবে।

যাইহোক, প্রতি সেকেন্ডে 300 হাজার রিড এই অবস্থার অধীনে এই হার্ডওয়্যারে অর্জন করা যায় না। আসল বিষয়টি হল যে যখন আপনাকে HDFS-এর মাধ্যমে ডেটা অ্যাক্সেস করার প্রয়োজন হয়, তখন ShortCircuitCache (এর পরে SSC হিসাবে উল্লেখ করা হয়) পদ্ধতি ব্যবহার করা হয়, যা আপনাকে নেটওয়ার্ক ইন্টারঅ্যাকশন এড়িয়ে সরাসরি ডেটা অ্যাক্সেস করতে দেয়।

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

এটি উপলব্ধি করার পরে, আমরা বুঝতে পেরেছি যে স্বাধীন এসএসসিগুলির একটি বিন্যাস তৈরি করে সমস্যাটি সমাধান করা যেতে পারে:

private final ShortCircuitCache[] shortCircuitCache;
...
shortCircuitCache = new ShortCircuitCache[this.clientShortCircuitNum];
for (int i = 0; i < this.clientShortCircuitNum; i++)
  this.shortCircuitCache[i] = new ShortCircuitCache(…);

এবং তারপর শেষ অফসেট ডিজিটেও ছেদগুলি বাদ দিয়ে তাদের সাথে কাজ করুন:

public ShortCircuitCache getShortCircuitCache(long idx) {
    return shortCircuitCache[(int) (idx % clientShortCircuitNum)];
}

এখন আপনি পরীক্ষা শুরু করতে পারেন। এটি করার জন্য, আমরা একটি সাধারণ মাল্টি-থ্রেডেড অ্যাপ্লিকেশন সহ HDFS থেকে ফাইলগুলি পড়ব। পরামিতি সেট করুন:

conf.set("dfs.client.read.shortcircuit", "true");
conf.set("dfs.client.read.shortcircuit.buffer.size", "65536"); // по дефолту = 1 МБ и это сильно замедляет чтение, поэтому лучше привести в соответствие к реальным нуждам
conf.set("dfs.client.short.circuit.num", num); // от 1 до 10

এবং শুধু ফাইলগুলি পড়ুন:

FSDataInputStream in = fileSystem.open(path);
for (int i = 0; i < count; i++) {
    position += 65536;
    if (position > 900000000)
        position = 0L;
    int res = in.read(position, byteBuffer, 0, 65536);
}

এই কোডটি পৃথক থ্রেডে কার্যকর করা হয়েছে এবং আমরা একসাথে পড়া ফাইলের সংখ্যা (10 থেকে 200 - অনুভূমিক অক্ষ পর্যন্ত) এবং ক্যাশে সংখ্যা (1 থেকে 10 - গ্রাফিক্স পর্যন্ত) বৃদ্ধি করব। উল্লম্ব অক্ষটি ত্বরণ দেখায় যা শুধুমাত্র একটি ক্যাশে থাকা অবস্থায় SSC বৃদ্ধির ফলে ঘটে।

গ্রাফটি কীভাবে পড়তে হয়: একটি ক্যাশে সহ 100 KB ব্লকে 64 হাজার রিডের জন্য কার্যকর করার সময় 78 সেকেন্ড প্রয়োজন। যেখানে 5 ক্যাশে এটি 16 সেকেন্ড সময় নেয়। সেগুলো. ~5 বার একটি ত্বরণ আছে। গ্রাফ থেকে দেখা যায়, অল্প সংখ্যক সমান্তরাল পাঠের জন্য প্রভাবটি খুব বেশি লক্ষণীয় নয়; এটি একটি লক্ষণীয় ভূমিকা পালন করতে শুরু করে যখন 50 টির বেশি থ্রেড রিড হয়। এটিও লক্ষণীয় যে 6 থেকে এসএসসি-র সংখ্যা বৃদ্ধি এবং উপরে একটি উল্লেখযোগ্যভাবে ছোট কর্মক্ষমতা বৃদ্ধি দেয়।

দ্রষ্টব্য 1: যেহেতু পরীক্ষার ফলাফলগুলি বেশ অস্থির (নীচে দেখুন), 3 রান করা হয়েছিল এবং ফলস্বরূপ মানগুলি গড় করা হয়েছিল।

দ্রষ্টব্য 2: এলোমেলো অ্যাক্সেস কনফিগার করার পারফরম্যান্স লাভ একই, যদিও অ্যাক্সেস নিজেই কিছুটা ধীর।

যাইহোক, এটি স্পষ্ট করা প্রয়োজন যে, HBase-এর ক্ষেত্রে ভিন্ন, এই ত্বরণ সবসময় বিনামূল্যে হয় না। এখানে আমরা তালা ঝুলিয়ে রাখার পরিবর্তে CPU-এর আরও কাজ করার ক্ষমতাকে "আনলক" করি।

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

উদাহরণস্বরূপ, আসুন SSC = 3 সেটিংটি ঘনিষ্ঠভাবে দেখি। পরিসরে কার্যক্ষমতা বৃদ্ধি প্রায় 3.3 গুণ। নীচে তিনটি পৃথক রানের ফলাফল রয়েছে।

যখন CPU খরচ প্রায় 2.8 গুণ বৃদ্ধি পায়। পার্থক্যটি খুব বড় নয়, তবে ছোট্ট গ্রেটা ইতিমধ্যেই খুশি এবং স্কুলে যাওয়ার এবং পাঠ নেওয়ার সময় থাকতে পারে।

সুতরাং, HDFS (উদাহরণস্বরূপ স্পার্ক, ইত্যাদি) তে বাল্ক অ্যাক্সেস ব্যবহার করে এমন যেকোনো টুলের জন্য এটি একটি ইতিবাচক প্রভাব ফেলবে, তবে শর্ত থাকে যে অ্যাপ্লিকেশন কোডটি লাইটওয়েট (অর্থাৎ প্লাগটি HDFS ক্লায়েন্টের দিকে) এবং বিনামূল্যে CPU পাওয়ার আছে। . পরীক্ষা করার জন্য, HBase থেকে পড়ার জন্য BlockCache অপ্টিমাইজেশান এবং SSC টিউনিংয়ের সম্মিলিত ব্যবহার কী প্রভাব ফেলবে তা পরীক্ষা করা যাক।

এটি দেখা যায় যে এই ধরনের পরিস্থিতিতে প্রভাবটি পরিমার্জিত পরীক্ষার মতো দুর্দান্ত নয় (কোনও প্রক্রিয়াকরণ ছাড়াই পড়া), তবে এখানে অতিরিক্ত 80K চেপে নেওয়া বেশ সম্ভব। একসাথে, উভয় অপ্টিমাইজেশান 4x পর্যন্ত গতি প্রদান করে।

এই অপ্টিমাইজেশনের জন্য একটি পিআরও তৈরি করা হয়েছিল [HDFS-15202], যা মার্জ করা হয়েছে এবং এই কার্যকারিতা ভবিষ্যতে রিলিজে উপলব্ধ হবে।

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

এটি করার জন্য, আমরা দুটি হোস্ট (মোট 800 থ্রেড) থেকে স্ট্যান্ডার্ড YCSB লোড টেস্টিং ইউটিলিটির উদাহরণ চালু করেছি। সার্ভারের দিকে - 4টি হোস্টে RegionServer এবং Cassandra-এর 4টি উদাহরণ (যেখানে ক্লায়েন্টরা চলছে, তাদের প্রভাব এড়াতে নয়)৷ রিডিং আকারের টেবিল থেকে এসেছে:

HBase – HDFS-এ 300 GB (100 GB বিশুদ্ধ ডেটা)

ক্যাসান্ড্রা - 250 জিবি (প্রতিলিপি ফ্যাক্টর = 3)

সেগুলো. ভলিউম প্রায় একই ছিল (HBase এ একটু বেশি)।

HBase পরামিতি:

dfs.client.short.circuit.num = 5 (HDFS ক্লায়েন্ট অপ্টিমাইজেশান)

hbase.lru.cache.heavy.eviction.count.limit = 30 - এর মানে হল প্যাচটি 30টি উচ্ছেদের পরে কাজ শুরু করবে (~5 মিনিট)

hbase.lru.cache.heavy.eviction.mb.size.limit = 300 - ক্যাশিং এবং উচ্ছেদের লক্ষ্য পরিমাণ

YCSB লগ পার্স করা হয়েছে এবং এক্সেল গ্রাফে কম্পাইল করা হয়েছে:

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

আমরা আশা করি যে এই তথ্যটি উত্পাদনশীলতার জন্য উত্তেজনাপূর্ণ সংগ্রামের সময় কারও পক্ষে কার্যকর হতে পারে।

উত্স: www.habr.com