উচ্চ কর্মক্ষমতা এবং নেটিভ পার্টিশনিং: TimescaleDB সমর্থন সহ Zabbix

Zabbix একটি মনিটরিং সিস্টেম। অন্যান্য সিস্টেমের মতো, এটি সমস্ত পর্যবেক্ষণ সিস্টেমের তিনটি প্রধান সমস্যার সম্মুখীন হয়: ডেটা সংগ্রহ এবং প্রক্রিয়াকরণ, ইতিহাস সংরক্ষণ করা এবং এটি পরিষ্কার করা।

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

Zabbix-এ সংগ্রহ এবং স্টোরেজ বিলম্বের সমস্যাগুলি ক্যাশিংয়ের মাধ্যমে সমাধান করা হয়: বিভিন্ন ধরণের ক্যাশে, ডাটাবেসে ক্যাশিং। তৃতীয় সমস্যা সমাধানের জন্য, ক্যাশিং উপযুক্ত নয়, তাই Zabbix-এ TimescaleDB ব্যবহার করা হয়েছিল। এটা সম্পর্কে জানাবেন আন্দ্রে গুশচিন - প্রযুক্তিগত সহায়তা প্রকৌশলী জ্যাবিক্স এসআইএ. আন্দ্রে 6 বছরেরও বেশি সময় ধরে জ্যাবিক্সকে সমর্থন করছে এবং সরাসরি পারফরম্যান্সের সাথে জড়িত।

TimescaleDB কিভাবে কাজ করে, নিয়মিত PostgreSQL এর তুলনায় এটি কী পারফরম্যান্স দিতে পারে? টাইমস্কেলডিবিতে Zabbix কি ভূমিকা পালন করে? কিভাবে স্ক্র্যাচ থেকে শুরু করবেন এবং কিভাবে PostgreSQL থেকে স্থানান্তর করবেন এবং কোন কনফিগারেশন কর্মক্ষমতা ভাল? এই সব কাটা অধীনে.

কর্মক্ষমতা চ্যালেঞ্জ

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

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

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

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

পুরানো ডেটা পরিষ্কার করা একটি কাঁটাযুক্ত সমস্যা যা ডাটাবেসের কার্যকারিতার উপর একটি বড় প্রভাব ফেলে।

Zabbix-এ ক্যাশিং

Zabbix-এ, প্রথম এবং দ্বিতীয় কলগুলি ক্যাশিং ব্যবহার করে সমাধান করা হয়। RAM ডেটা সংগ্রহ এবং প্রক্রিয়া করতে ব্যবহৃত হয়। স্টোরেজের জন্য - ট্রিগার, গ্রাফ এবং গণনা করা আইটেমের ইতিহাস। DB এর দিকে, মৌলিক নির্বাচনের জন্য কিছু ক্যাশিং আছে, যেমন গ্রাফ।

Zabbix সার্ভারের পাশে ক্যাশিং হল:

• কনফিগারেশন ক্যাশে;
• ValueCache;
• হিস্ট্রি ক্যাশে;
• TrendsCache.

আরো বিস্তারিত তাদের বিবেচনা।

কনফিগারেশন ক্যাশে

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

এই সমস্ত কনফিগারেশন ক্যাশে সংরক্ষণ করা হয় যাতে ডাটাবেসে অপ্রয়োজনীয় প্রশ্ন তৈরি না হয়। সার্ভার শুরু হওয়ার পরে, আমরা এই ক্যাশে আপডেট করি, তৈরি করি এবং পর্যায়ক্রমে কনফিগারেশন আপডেট করি।

তথ্য সংগ্রহ

স্কিমটি বেশ বড়, তবে এর মধ্যে মূল জিনিসটি সংগ্রাহক. এগুলি বিভিন্ন "পোলার" - সমাবেশ প্রক্রিয়া। তারা বিভিন্ন ধরণের সমাবেশের জন্য দায়ী: তারা SNMP, IPMI এর মাধ্যমে ডেটা সংগ্রহ করে এবং এটি সমস্ত প্রিপ্রসেসিং-এ স্থানান্তর করে।

বাছাইকারীদের কমলা রঙে চক্কর দেওয়া হয়।

Zabbix কম্পিউটেড অ্যাগ্রিগেশন আইটেম আছে যেগুলো চেকের জন্য প্রয়োজন। আমাদের কাছে সেগুলি থাকলে, আমরা সরাসরি ValueCache থেকে তাদের জন্য ডেটা নিয়ে থাকি।

প্রি-প্রসেসিং HistoryCache

সমস্ত সংগ্রাহক কাজ পেতে ConfigurationCache ব্যবহার করে। তারপরে তারা সেগুলিকে প্রিপ্রসেসিং-এ প্রেরণ করে।

প্রিপ্রসেসিং প্রিপ্রসেসিং ধাপগুলি পেতে কনফিগারেশন ক্যাশে ব্যবহার করে। এটি বিভিন্ন উপায়ে এই ডেটা প্রক্রিয়া করে।

প্রি-প্রসেসিং-এর মাধ্যমে ডেটা প্রক্রিয়া করার পর, আমরা এটিকে প্রসেস করার জন্য HistoryCache-এ সংরক্ষণ করি। এটি ডেটা সংগ্রহ সম্পূর্ণ করে এবং আমরা Zabbix-এর মূল প্রক্রিয়ায় চলে যাই- ইতিহাস সিঙ্কার, যেহেতু এটি একটি মনোলিথিক স্থাপত্য।

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

ValueCache, ইতিহাস এবং প্রবণতা ক্যাশে

ইতিহাস সিঙ্কার হল প্রধান প্রক্রিয়া যা প্রতিটি ডেটা উপাদান অর্থাৎ প্রতিটি মানকে পরমাণুভাবে প্রক্রিয়া করে।

হিস্ট্রি সিঙ্কার হিস্ট্রি ক্যাশে থেকে মান নেয় এবং গণনার জন্য ট্রিগারের জন্য কনফিগারেশন চেক করে। যদি তারা হয় - হিসাব করে।

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

হিস্ট্রি সিঙ্কার ডাটাবেসে সমস্ত ডেটা লিখে, এবং এটি ডিস্কে লেখে। প্রক্রিয়াকরণ প্রক্রিয়া এখানে শেষ হয়.

ডিবি ক্যাশিং

আপনি যখন গ্রাফ বা ইভেন্ট রিপোর্ট দেখতে চান তখন ডিবি পাশে বিভিন্ন ক্যাশে রয়েছে:

• Innodb_buffer_pool MySQL পাশে;
• shared_buffers PostgreSQL পাশে;
• effective_cache_size ওরাকল পাশে;
• shared_pool DB2 পাশে।

অন্যান্য অনেক ক্যাশে আছে, কিন্তু এই সব ডাটাবেসের জন্য প্রধান বেশী. তারা আপনাকে RAM এ ডেটা রাখার অনুমতি দেয় যা প্রায়শই প্রশ্নের জন্য প্রয়োজন হয়। এ জন্য তাদের নিজস্ব প্রযুক্তি রয়েছে।

ডাটাবেস কর্মক্ষমতা সমালোচনামূলক

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

দৃশ্যায়নের জন্য - গ্রাফানা. এটি আমাদের ব্যবহারকারীদের মধ্যে একটি জনপ্রিয় সমাধান। তিনি সরাসরি Zabbix API এবং ডাটাবেসের মাধ্যমে অনুরোধ পাঠাতে পারেন এবং ডেটা প্রাপ্তির জন্য একটি নির্দিষ্ট সঙ্গতি তৈরি করেন। অতএব, ফলাফল এবং পরীক্ষার দ্রুত বিতরণের জন্য একটি সূক্ষ্ম এবং উন্নত ডাটাবেস টিউনিং প্রয়োজন।

বাড়ির সরকার

Zabbix-এ তৃতীয় পারফরম্যান্স চ্যালেঞ্জ হল হাউসকিপারের সাথে ইতিহাস পরিষ্কার করা। এটি সমস্ত সেটিংসকে সম্মান করে - ডেটা উপাদানগুলি নির্দেশ করে যে দিনের মধ্যে পরিবর্তনের গতিশীলতা (প্রবণতা) কতক্ষণ সংরক্ষণ করতে হবে।

TrendsCache আমরা ফ্লাইতে গণনা করি। যখন ডেটা আসে, আমরা এটি এক ঘন্টার মধ্যে একত্রিত করি এবং প্রবণতা পরিবর্তনের গতিশীলতার জন্য টেবিলে রাখি।

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

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

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

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

গৃহকর্ত্রীকে অক্ষম করা হয়েছে, গ্রাফিক্স সমতল করা হয়েছে - এই ক্ষেত্রে কী সমস্যা হতে পারে এবং তৃতীয় কর্মক্ষমতা চ্যালেঞ্জ সমাধানে কী সাহায্য করতে পারে?

বিভাজন - বিভাজন বা বিভাজন

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

পার্টিশনগুলি সাধারণত "সেটআপ" - একদিনে তৈরি করা ডেটার পরিমাণের উপর নির্ভর করে কনফিগার করা হয়। একটি নিয়ম হিসাবে, পার্টিশন এক দিনে সেট আপ করা হয়, এটি সর্বনিম্ন। নতুন পার্টিশন ট্রেন্ডের জন্য — ১ মাস।

একটি খুব বড় "সেটআপ" এর ক্ষেত্রে মান পরিবর্তন হতে পারে। যদি একটি ছোট "সেটআপ" 5 এনভিপিএস (প্রতি সেকেন্ডে নতুন মান) হয়, একটি গড় 000 থেকে 5 পর্যন্ত হয়, তবে একটি বড়টি 000 এনভিপিএস-এর উপরে। এগুলি বড় এবং খুব বড় ইনস্টলেশন যার জন্য ডাটাবেসের নিজেই যত্নশীল কনফিগারেশন প্রয়োজন।

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

পার্টিশন কি দেয়?

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

দ্রুত অপসারণ - DELETE. একটি ফাইল/সাবটেবল নির্বাচন করা হয়েছে, মোছার জন্য সারি নির্বাচন নয়।

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

প্রায়শই অনেক ডেটাবেসও গতি বাড়ায় INSERT - সন্তানের টেবিলে সন্নিবেশ করান।

টাইমস্কেলডিবি

v 4.2-এর জন্য আমরা TimescaleDB-তে আমাদের মনোযোগ নিবদ্ধ করেছি। এটি একটি নেটিভ ইন্টারফেস সহ একটি PostgreSQL এক্সটেনশন। এক্সটেনশনটি রিলেশনাল ডাটাবেসের সুবিধা না হারিয়ে টাইম সিরিজ ডেটার সাথে দক্ষতার সাথে কাজ করে। TimescaleDB এছাড়াও স্বয়ংক্রিয়ভাবে পার্টিশন.

TimescaleDB একটি ধারণা আছে হাইপারটেবল (হাইপারটেবল) যা আপনি তৈরি করেন। এর মধ্যে রয়েছে খণ্ড - পার্টিশন। খণ্ডগুলি একটি হাইপারটেবলের স্বয়ংক্রিয়ভাবে পরিচালিত টুকরা যা অন্য খণ্ডকে প্রভাবিত করে না। প্রতিটি খণ্ডের নিজস্ব সময়সীমা রয়েছে।

TimescaleDB বনাম PostgreSQL

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

200 মিলিয়ন সারির পরে, PostgreSQL সাধারণত অনেক কম হতে শুরু করে এবং 0-এ কর্মক্ষমতা হারায়। TimescaleDB আপনাকে যেকোন পরিমাণ ডেটা সহ দক্ষতার সাথে "সন্নিবেশ" করতে দেয়।

বিন্যাস

TimescaleDB ইনস্টল করা যেকোনো প্যাকেজের জন্য যথেষ্ট সহজ। ভিতরে ডকুমেন্টেশন সবকিছু বিস্তারিত - এটি অফিসিয়াল PostgreSQL প্যাকেজগুলির উপর নির্ভর করে। TimescaleDB হাত দ্বারা তৈরি এবং কম্পাইল করা যেতে পারে।

Zabbix ডাটাবেসের জন্য, আমরা কেবল এক্সটেনশনটি সক্রিয় করি:

echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix

আপনি সক্রিয় করুন extension এবং Zabbix ডাটাবেসের জন্য এটি তৈরি করুন। শেষ ধাপ হল একটি হাইপারটেবিল তৈরি করা।

টাইমস্কেলডিবি-তে ইতিহাসের টেবিল স্থানান্তর করা হচ্ছে

এই জন্য একটি বিশেষ ফাংশন আছে. create_hypertable:

SELECT create_hypertable(‘history’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_log’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_text’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_str’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
UPDATE config SET db_extension=’timescaledb’, hk_history_global=1, hk_trends_global=1

ফাংশন তিনটি পরামিতি আছে. প্রথম - ডাটাবেসে টেবিলযার জন্য আপনি একটি হাইপারটেবিল তৈরি করতে চান। দ্বিতীয় - ক্ষেত্র, যা অনুযায়ী এটি তৈরি করা প্রয়োজন chunk_time_interval — ব্যবহার করা পার্টিশন খণ্ডের ব্যবধান। আমার ক্ষেত্রে, ব্যবধান একদিন - 86।

তৃতীয় প্যারামিটার হল migrate_data. যদি সেট করা হয় true, তারপর সমস্ত বর্তমান ডেটা পূর্ব-তৈরি খণ্ডগুলিতে স্থানান্তরিত হয়। আমি নিজে ব্যবহার করেছি migrate_data. আমার প্রায় 1TB ছিল যা এক ঘন্টার বেশি সময় নেয়। এমনকি কিছু ক্ষেত্রে, পরীক্ষা করার সময়, আমি অক্ষরের প্রকারের ঐতিহাসিক ডেটা মুছে দিয়েছি, যা স্টোরেজের জন্য ঐচ্ছিক, যাতে সেগুলি স্থানান্তর না হয়।

শেষ ধাপ- UPDATE: এ db_extension রাখা timescaledbযাতে ডাটাবেস বুঝতে পারে যে এই এক্সটেনশন আছে। Zabbix এটি সক্রিয় করে এবং সঠিকভাবে ডাটাবেসে সিনট্যাক্স এবং প্রশ্নগুলি ব্যবহার করে - সেই বৈশিষ্ট্যগুলি যা TimescaleDB-এর জন্য প্রয়োজনীয়।

হার্ডওয়্যার কনফিগারেশন

আমি দুটি সার্ভার ব্যবহার করেছি। প্রথম - ভিএমওয়্যার মেশিন. এটি যথেষ্ট ছোট: 20 Intel® Xeon® CPU E5-2630 v 4 @ 2.20GHz, 16 GB RAM এবং একটি 200 GB SSD ড্রাইভ৷

আমি Debian OS 10.8-10.8.pgdg1+90 এবং xfs ফাইল সিস্টেমের সাথে PostgreSQL 1 ইনস্টল করেছি। আমি এই নির্দিষ্ট ডাটাবেসটি ব্যবহার করার জন্য সর্বনিম্নভাবে সবকিছু কনফিগার করেছি, Zabbix নিজে যা ব্যবহার করবে তা বিয়োগ করে।

একই মেশিনে একটি Zabbix সার্ভার ছিল, PostgreSQL এবং লোড এজেন্ট. আমার 50 জন সক্রিয় এজেন্ট ছিল যারা ব্যবহার করেছিল LoadableModuleখুব দ্রুত বিভিন্ন ফলাফল তৈরি করতে: সংখ্যা, স্ট্রিং। আমি অনেক ডাটা দিয়ে ডাটাবেস পূরণ করেছি।

প্রাথমিকভাবে, কনফিগারেশন রয়েছে 5 আইটেম হোস্ট প্রতি ডেটা। এটিকে বাস্তব ইনস্টলেশনের মতো দেখাতে প্রায় প্রতিটি উপাদানে একটি ট্রিগার থাকে। কিছু ক্ষেত্রে একাধিক ট্রিগার ছিল। একটি নেটওয়ার্ক নোড ছিল 3-000 ট্রিগার.

আইটেম আপডেট ব্যবধান - 4-7 সেকেন্ড. আমি শুধুমাত্র 50টি এজেন্ট ব্যবহার করে নয়, আরও যোগ করে লোড নিজেই নিয়ন্ত্রণ করেছি। এছাড়াও, ডেটা উপাদানগুলির সাহায্যে, আমি গতিশীলভাবে লোড নিয়ন্ত্রণ করেছি এবং আপডেটের ব্যবধানটি 4 সেকেন্ডে কমিয়েছি।

পোস্টগ্রেএসকিউএল। 35 এনভিপিএস

এই হার্ডওয়্যারে আমার প্রথম রান ছিল বিশুদ্ধ PostgreSQL - প্রতি সেকেন্ডে 35 হাজার মান। আপনি দেখতে পাচ্ছেন, ডেটা সন্নিবেশ করতে এক সেকেন্ডের ভগ্নাংশ সময় লাগে - সবকিছু ঠিকঠাক এবং দ্রুত। একমাত্র জিনিস হল যে 200 GB SSD ড্রাইভ দ্রুত পূরণ করে।

এটি একটি স্ট্যান্ডার্ড Zabbix সার্ভার কর্মক্ষমতা ড্যাশবোর্ড।

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

চতুর্থ গ্রাফটি HistoryCache এর ব্যবহার দেখায়। এটি ডাটাবেসে ঢোকানোর আগে এক ধরনের বাফার। সবুজ পঞ্চম গ্রাফটি ValueCache এর ব্যবহার দেখায়, অর্থাৎ প্রতি সেকেন্ডে কয়েক হাজার মান ট্রিগারের জন্য কতটি ValueCache হিট করে।

পোস্টগ্রেএসকিউএল। 50 এনভিপিএস

তারপরে আমি একই হার্ডওয়্যারে প্রতি সেকেন্ডে লোড বাড়িয়ে 50 হাজার মান করেছি।

হাউসকিপার থেকে লোড করার সময়, 10 হাজার মান সন্নিবেশ করাতে 2-3 সেকেন্ড সময় লেগেছিল।

গৃহকর্ত্রী ইতিমধ্যে পথ পেতে শুরু করেছে.

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

পোস্টগ্রেএসকিউএল। 80 এনভিপিএস

তারপর আমি প্রতি সেকেন্ডে 80 হাজার মান লোড বাড়িয়েছি। এটি প্রায় 400 হাজার ডেটা উপাদান এবং 280 হাজার ট্রিগার।

ত্রিশটি হিস্ট্রি সিঙ্কারের লোডিং ইনসার্ট ইতিমধ্যেই বেশ বেশি৷

আমি বিভিন্ন পরামিতিও বাড়িয়েছি: ইতিহাস সিঙ্কার, ক্যাশে।

আমার হার্ডওয়্যারে, ইতিহাস সিঙ্কারের লোডিং সর্বাধিক বেড়েছে। HistoryCache দ্রুত ডেটা দিয়ে পূর্ণ হয় - বাফার প্রক্রিয়াকরণের জন্য ডেটা জমা করেছে৷

এই সমস্ত সময়, আমি প্রসেসর, র‌্যাম এবং অন্যান্য সিস্টেম প্যারামিটারগুলি কীভাবে ব্যবহার করা হয়েছিল তা দেখেছি এবং আবিষ্কার করেছি যে ডিস্কের ব্যবহার সর্বাধিক।

আমি ব্যবহার করেছি সর্বোচ্চ ডিস্ক ক্ষমতা এই হার্ডওয়্যারে এবং এই ভার্চুয়াল মেশিনে। এই ধরনের তীব্রতার সাথে, PostgreSQL বেশ সক্রিয়ভাবে ডেটা ডাম্প করতে শুরু করে এবং ডিস্কের আর লেখার এবং পড়ার সময় ছিল না।

দ্বিতীয় সার্ভার

আমি অন্য একটি সার্ভার নিয়েছি যেখানে ইতিমধ্যে 48টি প্রসেসর এবং 128 গিগাবাইট র‍্যাম রয়েছে। আমি এটি টিউন করেছি - 60টি ইতিহাস সিঙ্কার সেট করেছি এবং গ্রহণযোগ্য কর্মক্ষমতা অর্জন করেছি।

আসলে, এটি ইতিমধ্যে একটি কর্মক্ষমতা সীমা যেখানে কিছু করা প্রয়োজন।

timescaledb. 80 এনভিপিএস

আমার প্রধান কাজ হল একটি Zabbix লোডের বিরুদ্ধে TimescaleDB এর ক্ষমতা পরীক্ষা করা। প্রতি সেকেন্ডে 80 হাজার মান অনেক, মেট্রিক্স সংগ্রহের ফ্রিকোয়েন্সি (অবশ্যই ইয়ানডেক্স বাদে) এবং একটি মোটামুটি বড় "সেটআপ"।

প্রতিটি গ্রাফে একটি ডিপ রয়েছে - এটি শুধুমাত্র একটি ডেটা স্থানান্তর। Zabbix সার্ভারে ব্যর্থতার পরে, ইতিহাস সিঙ্কারের লোডিং প্রোফাইল অনেক পরিবর্তিত হয়েছে - এটি তিনবার পড়ে গেছে।

TimescaleDB আপনাকে প্রায় 3 গুণ দ্রুত ডেটা সন্নিবেশ করতে এবং কম HistoryCache ব্যবহার করতে দেয়।

তদনুসারে, আপনি একটি সময়মত তথ্য পাবেন।

timescaledb. 120 এনভিপিএস

তারপরে আমি ডেটা উপাদানের সংখ্যা বাড়িয়ে 500 হাজার করেছি। প্রধান কাজটি ছিল TimescaleDB-এর ক্ষমতা পরীক্ষা করা - আমি প্রতি সেকেন্ডে 125 হাজার মানের একটি গণনাকৃত মান পেয়েছি।

এটি একটি কার্যকরী "সেটআপ" যা কাজ করতে দীর্ঘ সময় নিতে পারে। কিন্তু যেহেতু আমার ডিস্ক মাত্র 1,5 টিবি, তাই আমি কয়েক দিনের মধ্যে এটি পূরণ করেছি।

সবচেয়ে গুরুত্বপূর্ণ, নতুন TimescaleDB পার্টিশন একই সময়ে তৈরি করা হচ্ছে।

পারফরম্যান্সের জন্য, এটি সম্পূর্ণরূপে লক্ষণীয় নয়। যখন MySQL-এ পার্টিশন তৈরি করা হয়, উদাহরণস্বরূপ, জিনিসগুলি আলাদা। এটি সাধারণত রাতে ঘটে, কারণ এটি সাধারণ সন্নিবেশ, টেবিল ম্যানিপুলেশন ব্লক করে এবং পরিষেবার অবনতি ঘটাতে পারে। এটি TimescaleDB এর ক্ষেত্রে নয়।

উদাহরণস্বরূপ, আমি সম্প্রদায়ের সেট থেকে একটি গ্রাফ দেখাব। ছবিতে, TimescaleDB সক্রিয় করা হয়েছে, যার কারণে প্রসেসরে io.weight ব্যবহারের লোড কমে গেছে। অভ্যন্তরীণ প্রক্রিয়াগুলির উপাদানগুলির ব্যবহারও হ্রাস পেয়েছে। তাছাড়া, এটি সাধারণ প্যানকেক ডিস্কের একটি সাধারণ ভার্চুয়াল মেশিন, এবং একটি SSD নয়।

তথ্যও

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

TimescaleDB সেট আপ করা সহজ, কর্মক্ষমতা বৃদ্ধি করে, Zabbix এবং এর সাথে ভাল কাজ করে PostgreSQL এর উপর সুবিধা আছে.

আপনি যদি PostgreSQL ব্যবহার করেন এবং এটি পরিবর্তন করার পরিকল্পনা না করেন, তাহলে আমি সুপারিশ করি Zabbix এর সাথে টাইমস্কেলডিবি এক্সটেনশনের সাথে PostgreSQL ব্যবহার করুন. এই সমাধান মাঝারি "সেটআপ" পর্যন্ত কার্যকরভাবে কাজ করে।

আমরা বলি "হাই পারফরম্যান্স" - মানে হাইলোড++. আপনি যে প্রযুক্তি এবং অনুশীলনগুলি লক্ষ লক্ষ ব্যবহারকারীদের পরিষেবা দেওয়ার অনুমতি দেয় সেগুলি জানতে বেশি সময় লাগবে না৷ তালিকা রিপোর্ট 7 এবং 8 নভেম্বরের জন্য, আমরা ইতিমধ্যেই অঙ্কন করেছি, কিন্তু সাক্ষাৎ আরো সুপারিশ করা যেতে পারে।

আমাদের সদস্যতা ылку и টেলিগ্রাম, যাতে আমরা আসন্ন সম্মেলনের বৈশিষ্ট্যগুলি প্রকাশ করি এবং কীভাবে এটি থেকে সর্বাধিক লাভ করা যায় তা খুঁজে বের করি৷

উত্স: www.habr.com