اعلی کارکردگی اور مقامی تقسیم: TimescaleDB سپورٹ کے ساتھ Zabbix

زبکس ایک مانیٹرنگ سسٹم ہے۔ کسی بھی دوسرے نظام کی طرح، اسے تمام مانیٹرنگ سسٹم کے تین اہم مسائل کا سامنا ہے: ڈیٹا اکٹھا کرنا اور اس پر کارروائی کرنا، تاریخ کو ذخیرہ کرنا، اور اسے صاف کرنا۔

ڈیٹا حاصل کرنے، پروسیسنگ اور ریکارڈ کرنے کے مراحل میں وقت لگتا ہے۔ زیادہ نہیں، لیکن ایک بڑے سسٹم کے لیے اس کے نتیجے میں بڑی تاخیر ہو سکتی ہے۔ اسٹوریج کا مسئلہ ڈیٹا تک رسائی کا مسئلہ ہے۔ وہ رپورٹس، چیک اور ٹرگرز کے لیے استعمال ہوتے ہیں۔ ڈیٹا تک رسائی میں تاخیر کارکردگی کو بھی متاثر کرتی ہے۔ جب ڈیٹا بیس بڑھتے ہیں تو غیر متعلقہ ڈیٹا کو حذف کرنا پڑتا ہے۔ ہٹانا ایک مشکل آپریشن ہے جو کچھ وسائل بھی کھاتا ہے۔

زبکس میں جمع کرنے اور ذخیرہ کرنے کے دوران تاخیر کے مسائل کیشنگ کے ذریعے حل کیے جاتے ہیں: کئی قسم کے کیشز، ڈیٹا بیس میں کیشنگ۔ تیسرے مسئلے کو حل کرنے کے لیے، کیشنگ مناسب نہیں ہے، اس لیے Zabbix نے TimescaleDB استعمال کیا۔ وہ آپ کو اس کے بارے میں بتائے گا۔ آندرے گوشچن - ٹیکنیکل سپورٹ انجینئر زیبکس ایس آئی اے. اینڈری 6 سال سے زیادہ عرصے سے زبکس کو سپورٹ کر رہے ہیں اور کارکردگی کا براہ راست تجربہ رکھتے ہیں۔

TimescaleDB کیسے کام کرتا ہے، یہ باقاعدہ PostgreSQL کے مقابلے میں کیا کارکردگی دے سکتا ہے؟ Zabbix TimescaleDB ڈیٹا بیس کے لیے کیا کردار ادا کرتا ہے؟ شروع سے کیسے شروع کیا جائے اور PostgreSQL سے کیسے منتقل کیا جائے اور کون سی کنفیگریشن بہتر کارکردگی رکھتی ہے؟ کٹ کے تحت یہ سب کے بارے میں.

پیداواری چیلنجز

ہر نگرانی کے نظام کو کارکردگی کے مخصوص چیلنجوں کا سامنا ہے۔ میں ان میں سے تین کے بارے میں بات کروں گا: ڈیٹا اکٹھا کرنا اور پروسیسنگ، اسٹوریج، اور ہسٹری کلیئرنگ۔

تیز رفتار ڈیٹا اکٹھا کرنا اور پروسیسنگ۔ ایک اچھے مانیٹرنگ سسٹم کو فوری طور پر تمام ڈیٹا حاصل کرنا چاہیے اور اسے محرک اظہار کے مطابق - اس کے معیار کے مطابق پروسیس کرنا چاہیے۔ پروسیسنگ کے بعد، سسٹم کو اس ڈیٹا کو فوری طور پر ڈیٹا بیس میں بعد میں استعمال کے لیے محفوظ کرنا چاہیے۔

تاریخ کا ذخیرہ۔ ایک اچھے مانیٹرنگ سسٹم کو تاریخ کو ڈیٹا بیس میں محفوظ کرنا چاہیے اور میٹرکس تک آسان رسائی فراہم کرنی چاہیے۔ رپورٹس، گرافس، ٹرگرز، تھریشولڈز، اور کیلکولیٹڈ الرٹ ڈیٹا آئٹمز میں تاریخ استعمال کرنے کی ضرورت ہے۔

تاریخ کو صاف کرنا۔ کبھی کبھی ایسا دن آتا ہے جب آپ کو میٹرکس کو ذخیرہ کرنے کی ضرورت نہیں ہوتی ہے۔ آپ کو اس ڈیٹا کی ضرورت کیوں ہے جو 5 سال پہلے، ایک یا دو مہینے پہلے جمع کیا گیا تھا: کچھ نوڈس کو حذف کر دیا گیا ہے، کچھ میزبانوں یا میٹرکس کی اب ضرورت نہیں ہے کیونکہ وہ پرانے ہو چکے ہیں اور اب جمع نہیں ہوتے۔ ایک اچھے مانیٹرنگ سسٹم کو تاریخی ڈیٹا کو ذخیرہ کرنا چاہیے اور اسے وقتاً فوقتاً حذف کرنا چاہیے تاکہ ڈیٹا بیس میں اضافہ نہ ہو۔

باسی ڈیٹا کو صاف کرنا ایک اہم مسئلہ ہے جو ڈیٹا بیس کی کارکردگی کو بہت زیادہ متاثر کرتا ہے۔

Zabbix میں کیشنگ

Zabbix میں، پہلی اور دوسری کالز کو کیشنگ کے ذریعے حل کیا جاتا ہے۔ RAM کو ڈیٹا اکٹھا کرنے اور اس پر کارروائی کرنے کے لیے استعمال کیا جاتا ہے۔ سٹوریج کے لیے - ٹرگرز، گرافس اور حسابی ڈیٹا عناصر میں تاریخ۔ ڈیٹا بیس کی طرف بنیادی انتخاب کے لیے کچھ کیشنگ ہے، مثال کے طور پر، گراف۔

Zabbix سرور کی طرف کیشنگ خود یہ ہے:

• کنفیگریشن کیچ؛
• ویلیو کیچ؛
• ہسٹری کیچ؛
• TrendsCache.

مزید تفصیل میں ان پر غور کریں.

کنفیگریشن کیچ

یہ وہ اہم کیش ہے جہاں ہم میٹرکس، میزبان، ڈیٹا آئٹمز، ٹرگرز - وہ سب کچھ جو ہمیں پری پروسیسنگ اور ڈیٹا اکٹھا کرنے کے لیے درکار ہوتا ہے۔

یہ سب کنفیگریشن کیچ میں محفوظ ہے تاکہ ڈیٹا بیس میں غیر ضروری سوالات پیدا نہ ہوں۔ سرور شروع ہونے کے بعد، ہم اس کیش کو اپ ڈیٹ کرتے ہیں، ترتیب دیتے ہیں اور وقتاً فوقتاً اپ ڈیٹ کرتے ہیں۔

ڈیٹا اکٹھا کرنا

خاکہ کافی بڑا ہے، لیکن اس میں اہم چیز ہے۔ جمع کرنے والے. یہ مختلف "پولرز" ہیں - اسمبلی کے عمل۔ وہ مختلف قسم کی اسمبلی کے لیے ذمہ دار ہیں: وہ SNMP، IPMI کے ذریعے ڈیٹا اکٹھا کرتے ہیں، اور اس سب کو پری پروسیسنگ میں منتقل کرتے ہیں۔

جمع کرنے والوں کا خاکہ نارنجی میں دیا گیا ہے۔

Zabbix نے جمع کرنے والی اشیاء کا حساب لگایا ہے جو چیک کو جمع کرنے کے لیے درکار ہیں۔ اگر ہمارے پاس وہ ہیں، تو ہم ان کے لیے ڈیٹا براہ راست ValueCache سے حاصل کرتے ہیں۔

پری پروسیسنگ ہسٹری کیچ

تمام جمع کنندگان ملازمتیں حاصل کرنے کے لیے 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 اور ڈیٹا بیس کے ذریعے درخواستیں بھیج سکتا ہے، اور ڈیٹا حاصل کرنے کے لیے ایک خاص مقابلہ پیدا کرتا ہے۔ لہٰذا، نتائج کی تیز رفتار ترسیل اور جانچ کے مطابق ڈیٹا بیس کی بہتر اور بہتر ٹیوننگ کی ضرورت ہے۔

نوکرانی

زیبکس میں کارکردگی کا تیسرا چیلنج ہاؤس کیپر کا استعمال کرتے ہوئے ہسٹری کلیئرنگ ہے۔ یہ تمام ترتیبات کی پیروی کرتا ہے - اعداد و شمار کے عناصر بتاتے ہیں کہ دنوں میں تبدیلیوں (رجحانات) کی حرکیات کو کتنی دیر تک ذخیرہ کرنا ہے۔

ہم پرواز پر TrendsCache کا حساب لگاتے ہیں۔ جب ڈیٹا آتا ہے، ہم اسے ایک گھنٹے کے لیے جمع کرتے ہیں اور رجحان کی تبدیلیوں کی حرکیات کے لیے اسے جدولوں میں ریکارڈ کرتے ہیں۔

ہاؤس کیپر معمول کے "سلیکٹس" کا استعمال کرتے ہوئے ڈیٹا بیس سے معلومات کو شروع اور حذف کرتا ہے۔ یہ ہمیشہ موثر نہیں ہوتا، جیسا کہ اندرونی عمل کی کارکردگی کے گراف سے دیکھا جا سکتا ہے۔

سرخ گراف سے پتہ چلتا ہے کہ ہسٹری سنسر مسلسل مصروف ہے۔ اوپر والا نارنجی گراف ہاؤس کیپر ہے، جو مسلسل چل رہا ہے۔ وہ ڈیٹا بیس کے ان تمام قطاروں کو حذف کرنے کا انتظار کرتا ہے جن کی اس نے وضاحت کی ہے۔

آپ کو ہاؤس کیپر کو کب غیر فعال کرنا چاہیے؟ مثال کے طور پر، ایک "آئٹم آئی ڈی" ہے اور آپ کو ایک مخصوص وقت کے اندر آخری 5 ہزار قطاروں کو حذف کرنے کی ضرورت ہے۔ یقینا، یہ انڈیکس کے ذریعہ ہوتا ہے۔ لیکن عام طور پر ڈیٹاسیٹ بہت بڑا ہوتا ہے، اور ڈیٹا بیس اب بھی ڈسک سے پڑھتا ہے اور اسے کیشے میں رکھتا ہے۔ ڈیٹا بیس کے لیے یہ ہمیشہ ایک بہت مہنگا آپریشن ہوتا ہے اور ڈیٹا بیس کے سائز پر منحصر ہوتا ہے، یہ کارکردگی کے مسائل کا باعث بن سکتا ہے۔

گھریلو ملازم کو غیر فعال کرنا آسان ہے۔ ویب انٹرفیس میں ہاؤس کیپر کے لیے "ایڈمنسٹریشن جنرل" میں ایک ترتیب ہے۔ ہم داخلی رجحان کی تاریخ کے لیے اندرونی ہاؤس کیپنگ کو غیر فعال کر دیتے ہیں اور یہ اب اس کا انتظام نہیں کرتا ہے۔

ہاؤس کیپر کو آف کر دیا گیا، گراف برابر ہو گئے - اس معاملے میں کیا مسائل ہو سکتے ہیں اور کارکردگی کے تیسرے چیلنج کو حل کرنے میں کیا مدد کر سکتا ہے؟

تقسیم کرنا - تقسیم کرنا یا تقسیم کرنا

عام طور پر، تقسیم کاری کو ہر متعلقہ ڈیٹا بیس پر مختلف طریقے سے ترتیب دیا جاتا ہے جسے میں نے درج کیا ہے۔ ہر ایک کی اپنی ٹیکنالوجی ہے، لیکن وہ عام طور پر ایک جیسے ہیں۔ ایک نیا پارٹیشن بنانا اکثر بعض مسائل کا باعث بنتا ہے۔

عام طور پر، پارٹیشنز کو "سیٹ اپ" کے لحاظ سے ترتیب دیا جاتا ہے - ڈیٹا کی مقدار جو ایک دن میں بنتی ہے۔ ایک اصول کے طور پر، تقسیم ایک دن میں جاری کی جاتی ہے، یہ کم از کم ہے۔ نئے بیچ کے رجحانات کے لیے - 1 مہینہ۔

اگر "سیٹ اپ" بہت بڑا ہے تو اقدار تبدیل ہو سکتی ہیں۔ اگر ایک چھوٹا "سیٹ اپ" 5 nvps (نئی اقدار فی سیکنڈ) تک ہے، ایک درمیانہ 000 سے 5 تک ہے، پھر ایک بڑا 000 nvps سے اوپر ہے۔ یہ بڑی اور بہت بڑی تنصیبات ہیں جن کے لیے ڈیٹا بیس کی محتاط ترتیب کی ضرورت ہوتی ہے۔

بہت بڑی تنصیبات پر، ایک دن کی مدت زیادہ سے زیادہ نہیں ہو سکتی۔ میں نے روزانہ 40 GB یا اس سے زیادہ کے MySQL پارٹیشنز دیکھے ہیں۔ یہ ڈیٹا کی ایک بہت بڑی مقدار ہے جو مسائل پیدا کر سکتی ہے اور اسے کم کرنے کی ضرورت ہے۔

تقسیم کیا دیتی ہے؟

تقسیم کی میزیں. اکثر یہ ڈسک پر الگ الگ فائلیں ہوتی ہیں۔ استفسار کا منصوبہ ایک پارٹیشن کو زیادہ بہتر طریقے سے منتخب کرتا ہے۔ عام طور پر تقسیم کاری رینج کے لحاظ سے استعمال ہوتی ہے - یہ 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 ڈیٹا بیس کے لیے بنائیں۔ آخری مرحلہ ایک ہائپر ٹیبل بنانا ہے۔

ہسٹری ٹیبلز کو TimescaleDB پر منتقل کرنا

اس کے لیے ایک خاص فنکشن ہے۔ 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. مجھے تقریباً 1 ٹی بی تھا، جس میں ایک گھنٹہ سے زیادہ وقت لگا۔ یہاں تک کہ کچھ معاملات میں، جانچ کے دوران، میں نے کریکٹر کی قسموں کے تاریخی ڈیٹا کو حذف کر دیا جو سٹوریج کے لیے درکار نہیں تھے، تاکہ انہیں منتقل نہ کیا جا سکے۔

آخری قدم - UPDATE: پر db_extension ڈال timescaledbتاکہ ڈیٹابیس سمجھے کہ یہ ایکسٹینشن موجود ہے۔ Zabbix اسے چالو کرتا ہے اور صحیح طریقے سے ڈیٹا بیس میں نحو اور سوالات کا استعمال کرتا ہے - وہ خصوصیات جو TimescaleDB کے لیے ضروری ہیں۔

ہارڈ ویئر کی ترتیب

میں نے دو سرورز کا استعمال کیا۔ پہلا - وی ایم ویئر مشین. یہ کافی چھوٹا ہے: 20 Intel® Xeon® CPU E5-2630 v 4 @ 2.20GHz پروسیسرز، 16 GB RAM اور 200 GB SSD۔

میں نے اس پر Debian 10.8-10.8.pgdg1+90 OS اور xfs فائل سسٹم کے ساتھ PostgreSQL 1 انسٹال کیا۔ میں نے اس مخصوص ڈیٹا بیس کو استعمال کرنے کے لیے ہر چیز کو کم سے کم ترتیب دیا، مائنس کیا جو Zabbix خود استعمال کرے گا۔

اسی مشین پر ایک Zabbix سرور، PostgreSQL اور تھا۔ لوڈ ایجنٹس. میرے پاس 50 فعال ایجنٹ تھے جو استعمال کر رہے تھے۔ LoadableModuleبہت تیزی سے مختلف نتائج پیدا کرنے کے لیے: نمبرز، سٹرنگز۔ میں نے ڈیٹا بیس کو بہت سارے ڈیٹا سے بھر دیا۔

ابتدائی طور پر ترتیب پر مشتمل ہے 5 عناصر ڈیٹا فی میزبان۔ تقریباً ہر عنصر میں ایک محرک ہوتا ہے تاکہ اسے حقیقی تنصیبات سے ملتا جلتا بنایا جا سکے۔ کچھ معاملات میں ایک سے زیادہ محرک تھے۔ ایک نیٹ ورک نوڈ کے لئے وہاں تھے 3-000 محرکات.

ڈیٹا آئٹم اپ ڈیٹ کا وقفہ - 4-7 سیکنڈ. میں نے نہ صرف 50 ایجنٹوں کا استعمال کر کے بلکہ مزید اضافہ کر کے خود بوجھ کو کنٹرول کیا۔ اس کے علاوہ، ڈیٹا عناصر کا استعمال کرتے ہوئے، میں نے متحرک طور پر لوڈ کو ایڈجسٹ کیا اور اپ ڈیٹ کا وقفہ 4 سیکنڈ تک کم کیا۔

پوسٹگری ایس کیو ایل۔ 35 این وی پی ایس

اس ہارڈ ویئر پر میری پہلی دوڑ خالص PostgreSQL پر تھی - 35 ہزار ویلیوز فی سیکنڈ۔ جیسا کہ آپ دیکھ سکتے ہیں، ڈیٹا داخل کرنے میں ایک سیکنڈ کا حصہ لگتا ہے - سب کچھ اچھا اور تیز ہے۔ صرف یہ ہے کہ 200 GB SSD ڈسک تیزی سے بھر جاتی ہے۔

یہ ایک معیاری Zabbix سرور پرفارمنس ڈیش بورڈ ہے۔

پہلا نیلا گراف فی سیکنڈ کی قدروں کی تعداد ہے۔ دائیں طرف دوسرا گراف تعمیراتی عمل کی لوڈنگ ہے۔ تیسرا اندرونی تعمیراتی عمل کو لوڈ کر رہا ہے: ہسٹری سنسر اور ہاؤس کیپر، جو یہاں کافی عرصے سے چل رہا ہے۔

چوتھا گراف ہسٹری کیچ کا استعمال دکھاتا ہے۔ ڈیٹا بیس میں داخل کرنے سے پہلے یہ ایک قسم کا بفر ہے۔ سبز پانچواں گراف ValueCache کے استعمال کو ظاہر کرتا ہے، یعنی کتنے ValueCache ٹرگرز کے لیے ہٹ ہوتے ہیں - یہ کئی ہزار ویلیوز فی سیکنڈ ہے۔

پوسٹگری ایس کیو ایل۔ 50 این وی پی ایس

پھر میں نے اسی ہارڈ ویئر پر بوجھ کو 50 ہزار ویلیو فی سیکنڈ تک بڑھا دیا۔

ہاؤس کیپر سے لوڈ کرتے وقت، 10 ہزار ویلیو ڈالنے میں 2-3 سیکنڈ لگے۔

گھریلو ملازم پہلے ہی کام میں مداخلت کرنے لگا ہے۔

تیسرا گراف ظاہر کرتا ہے کہ، عام طور پر، ٹریپرز اور ہسٹری سنچرز پر بوجھ اب بھی 60% ہے۔ چوتھے گراف میں، ہسٹری کیچ پہلے ہی ہاؤس کیپر آپریشن کے دوران کافی فعال طور پر بھرنا شروع کر رہا ہے۔ یہ 20% بھرا ہوا ہے، جو تقریباً 0,5 GB ہے۔

پوسٹگری ایس کیو ایل۔ 80 این وی پی ایس

پھر میں نے بوجھ کو 80 ہزار ویلیو فی سیکنڈ تک بڑھا دیا۔ یہ تقریباً 400 ہزار ڈیٹا عناصر اور 280 ہزار محرکات ہیں۔

تیس ہسٹری سنچرز کی لوڈنگ لاگت پہلے ہی کافی زیادہ ہے۔

میں نے مختلف پیرامیٹرز میں بھی اضافہ کیا: ہسٹری سنسر، کیچز۔

میرے ہارڈ ویئر پر، ہسٹری سنسر کی لوڈنگ زیادہ سے زیادہ ہو گئی۔ ہسٹری کیچ تیزی سے ڈیٹا سے بھر گیا - پروسیسنگ کے لیے ڈیٹا بفر میں جمع ہو گیا تھا۔

اس سارے عرصے میں میں نے مشاہدہ کیا کہ پروسیسر، ریم اور سسٹم کے دیگر پیرامیٹرز کو کس طرح استعمال کیا گیا، اور پتہ چلا کہ ڈسک کا استعمال زیادہ سے زیادہ تھا۔

میں نے استعمال حاصل کر لیا ہے۔ زیادہ سے زیادہ ڈسک کی صلاحیتیں اس ہارڈ ویئر پر اور اس ورچوئل مشین پر۔ اتنی شدت کے ساتھ، PostgreSQL نے ڈیٹا کو کافی فعال طور پر فلش کرنا شروع کر دیا، اور ڈسک کے پاس لکھنے اور پڑھنے کا وقت نہیں رہا۔

دوسرا سرور

میں نے ایک اور سرور لیا، جس میں پہلے سے ہی 48 پروسیسر اور 128 جی بی ریم تھی۔ میں نے اسے ٹیون کیا - اسے 60 ہسٹری سنسر پر سیٹ کیا، اور قابل قبول کارکردگی حاصل کی۔

درحقیقت، یہ پہلے سے ہی پیداواری صلاحیت کی حد ہے جہاں کچھ کرنے کی ضرورت ہے۔

ٹائم اسکیل ڈی بی۔ 80 این وی پی ایس

میرا بنیادی کام Zabbix لوڈ کے خلاف TimescaleDB کی صلاحیتوں کی جانچ کرنا ہے۔ فی سیکنڈ 80 ہزار اقدار بہت زیادہ ہیں، میٹرکس جمع کرنے کی فریکوئنسی (یندیکس کے علاوہ، یقینا) اور کافی بڑا "سیٹ اپ"۔

ہر گراف میں ایک ڈپ ہے - یہ بالکل ڈیٹا کی منتقلی ہے۔ زبکس سرور میں ناکامی کے بعد، ہسٹری سنسر کا لوڈنگ پروفائل بہت بدل گیا - یہ تین بار گر گیا۔

TimescaleDB آپ کو تقریباً 3 گنا تیزی سے ڈیٹا داخل کرنے اور کم HistoryCache استعمال کرنے کی اجازت دیتا ہے۔

اس کے مطابق، آپ کو بروقت ڈیٹا موصول ہوگا۔

ٹائم اسکیل ڈی بی۔ 120 این وی پی ایس

پھر میں نے ڈیٹا عناصر کی تعداد بڑھا کر 500 ہزار کر دی۔ اہم کام TimescaleDB کی صلاحیتوں کو جانچنا تھا - مجھے 125 ہزار ویلیو فی سیکنڈ کی حسابی قدر موصول ہوئی۔

یہ ایک کام کرنے والا "سیٹ اپ" ہے جو طویل عرصے تک کام کر سکتا ہے۔ لیکن چونکہ میری ڈسک صرف 1,5 TB تھی، میں نے اسے چند دنوں میں بھر دیا۔

سب سے اہم بات یہ ہے کہ اسی وقت نئے TimescaleDB پارٹیشنز بنائے گئے تھے۔

یہ کارکردگی کے لیے مکمل طور پر ناقابل توجہ ہے۔ جب MySQL میں پارٹیشنز بنائے جاتے ہیں، مثال کے طور پر، سب کچھ مختلف ہوتا ہے۔ یہ عام طور پر رات کے وقت ہوتا ہے کیونکہ یہ عام اندراج کو روکتا ہے، میزوں کے ساتھ کام کرتا ہے اور سروس میں کمی پیدا کر سکتا ہے۔ TimescaleDB کے ساتھ ایسا نہیں ہے۔

مثال کے طور پر، میں کمیونٹی میں بہت سے لوگوں کا ایک گراف دکھاؤں گا۔ تصویر میں، TimescaleDB فعال ہے، جس کی بدولت پروسیسر پر io.weight استعمال کرنے کا بوجھ کم ہو گیا ہے۔ اندرونی عمل کے عناصر کے استعمال میں بھی کمی آئی۔ مزید یہ کہ یہ عام پینکیک ڈسک پر ایک عام ورچوئل مشین ہے، SSD نہیں۔

نتائج

TimescaleDB چھوٹے "سیٹ اپ" کے لیے ایک اچھا حل ہے، جو ڈسک کی کارکردگی کو متاثر کرتا ہے۔ یہ آپ کو اس وقت تک اچھی طرح سے کام جاری رکھنے کی اجازت دے گا جب تک کہ ڈیٹا بیس کو جلد سے جلد ہارڈ ویئر میں منتقل نہ کر دیا جائے۔

TimescaleDB ترتیب دینا آسان ہے، کارکردگی میں اضافہ دیتا ہے، Zabbix اور کے ساتھ اچھی طرح کام کرتا ہے۔ PostgreSQL پر فوائد ہیں۔.

اگر آپ PostgreSQL استعمال کرتے ہیں اور اسے تبدیل کرنے کا ارادہ نہیں رکھتے تو میں تجویز کرتا ہوں۔ Zabbix کے ساتھ مل کر TimescaleDB ایکسٹینشن کے ساتھ PostgreSQL استعمال کریں۔. یہ حل ایک درمیانے "سیٹ اپ" تک مؤثر طریقے سے کام کرتا ہے۔

جب ہم کہتے ہیں "اعلی کارکردگی" تو ہمارا مطلب ہے۔ ہائی لوڈ++. آپ کو ان ٹیکنالوجیز اور طریقوں کے بارے میں جاننے کے لیے زیادہ انتظار نہیں کرنا پڑے گا جو خدمات کو لاکھوں صارفین کی خدمت کے قابل بناتی ہیں۔ فہرست رپورٹس 7 اور 8 نومبر کے لیے ہم پہلے ہی مرتب کر چکے ہیں، لیکن یہاں ملاقاتیں مزید تجویز کیا جا سکتا ہے.

ہمارے سبسکرائب کریں۔ ылку и تار، جس میں ہم آنے والی کانفرنس کی خصوصیات کو ظاہر کرتے ہیں، اور اس سے زیادہ سے زیادہ فائدہ اٹھانے کا طریقہ معلوم کرتے ہیں۔

ماخذ: www.habr.com