PostgreSQL মনিটরিং বেসিক। আলেক্সি লেসভস্কি

আমি আপনাকে ডেটা এগ্রেট "পোস্টগ্রেএসকিউএল মনিটরিংয়ের মৌলিক বিষয়গুলি" থেকে অ্যালেক্সি লেসভস্কির প্রতিবেদনের প্রতিলিপি পড়ার পরামর্শ দিচ্ছি।

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

আমার নাম আলেক্সি লেসোভস্কি, আমি ডেটা এগ্রেট কোম্পানির প্রতিনিধিত্ব করি।

নিজের সম্পর্কে কয়েকটি শব্দ। আমি একটি সিস্টেম প্রশাসক হিসাবে অনেক আগে শুরু.

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

এবং আমার কর্মজীবন জুড়ে, আমি সর্বদা পরিসংখ্যান, পর্যবেক্ষণ এবং টেলিমেট্রির বিষয়ে আগ্রহী। এবং যখন আমি একজন সিস্টেম অ্যাডমিনিস্ট্রেটর ছিলাম, আমি জ্যাবিক্সের সাথে খুব ঘনিষ্ঠভাবে কাজ করেছি। এবং আমি স্ক্রিপ্টের একটি ছোট সেট লিখলাম zabbix-এক্সটেনশন. তিনি তার সময়ে বেশ জনপ্রিয় ছিলেন। এবং সেখানে কেবলমাত্র লিনাক্স নয়, বিভিন্ন উপাদানগুলিও খুব আলাদা গুরুত্বপূর্ণ জিনিসগুলি পর্যবেক্ষণ করা সম্ভব হয়েছিল।

এখন আমি PostgreSQL এ কাজ করছি। আমি ইতিমধ্যেই আরেকটি জিনিস লিখছি যা আপনাকে PostgreSQL পরিসংখ্যানের সাথে কাজ করতে দেয়। এটা কে বলে pg কেন্দ্র (হাবরে নিবন্ধ - স্নায়ু এবং উত্তেজনা ছাড়াই পোস্ট-গ্রেস পরিসংখ্যান).

একটি সামান্য পরিচায়ক নোট. আমাদের গ্রাহকদের, আমাদের ক্লায়েন্টদের কি পরিস্থিতিতে আছে? ডাটাবেসের সাথে সম্পর্কিত কিছু দুর্ঘটনা আছে। এবং যখন ডাটাবেসটি ইতিমধ্যে পুনরুদ্ধার করা হয়েছে, তখন বিভাগের প্রধান বা বিকাশের প্রধান এসে বলেন: "বন্ধুরা, আমাদের ডাটাবেসটি নিরীক্ষণ করা দরকার, কারণ খারাপ কিছু ঘটেছে এবং ভবিষ্যতে এটি যাতে না ঘটে তা প্রতিরোধ করতে হবে।" এবং এখানে একটি মনিটরিং সিস্টেম বেছে নেওয়ার বা বিদ্যমান মনিটরিং সিস্টেমকে অভিযোজিত করার আকর্ষণীয় প্রক্রিয়া শুরু হয় যাতে আপনি আপনার ডাটাবেস - PostgreSQL, MySQL বা অন্য কিছু নিরীক্ষণ করতে পারেন। এবং সহকর্মীরা পরামর্শ দিতে শুরু করে: “আমি শুনেছি যে এরকম এবং এমন একটি ডাটাবেস রয়েছে। আসুন এটি ব্যবহার করি।" সহকর্মীরা একে অপরের সাথে তর্ক শুরু করে। এবং শেষ পর্যন্ত দেখা যাচ্ছে যে আমরা কিছু ধরণের ডাটাবেস নির্বাচন করি, তবে PostgreSQL মনিটরিং এটিতে খুব খারাপভাবে উপস্থাপন করা হয়েছে এবং আমাদের সর্বদা কিছু যোগ করতে হবে। GitHub থেকে কিছু সংগ্রহস্থল নিন, সেগুলি ক্লোন করুন, স্ক্রিপ্টগুলি মানিয়ে নিন এবং কোনওভাবে কাস্টমাইজ করুন৷ এবং শেষ পর্যন্ত এটি কিছু ধরণের ম্যানুয়াল কাজ হচ্ছে।

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

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

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

প্রথমেই জেনে নেওয়া যাক মনিটরিং কি। মনিটরিং একটি খুব গুরুত্বপূর্ণ জিনিস আছে. এটা সবাই বোঝে। কিন্তু একই সময়ে, পর্যবেক্ষণ একটি ব্যবসায়িক পণ্যের সাথে সম্পর্কিত নয় এবং সরাসরি কোম্পানির মুনাফাকে প্রভাবিত করে না, তাই একটি অবশিষ্ট ভিত্তিতে পর্যবেক্ষণের জন্য সবসময় সময় বরাদ্দ করা হয়। যদি আমাদের সময় থাকে, তাহলে আমরা মনিটরিং করি; যদি আমাদের কাছে সময় না থাকে, তাহলে ঠিক আছে, আমরা এটিকে ব্যাকলগে রাখব এবং একদিন আমরা এই কাজগুলিতে ফিরে যাব।

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

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

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

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

আপনি এই সংখ্যাগুলি আপনার প্রিয় মনিটরিং সিস্টেমে যোগ করতে পারেন, গ্রাফ আঁকতে পারেন, ফাংশন যোগ করতে পারেন এবং দীর্ঘমেয়াদে বিশ্লেষণ পেতে পারেন।

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

আর আমরা যদি ডাটাবেস মনিটরিং এর কথা বলি, তাহলে কি মনিটর করার দরকার আছে? প্রথমত, আমাদের প্রাপ্যতা নিরীক্ষণ করতে হবে, কারণ ডাটাবেস এমন একটি পরিষেবা যা ক্লায়েন্টদের ডেটা অ্যাক্সেস প্রদান করে এবং আমাদের প্রাপ্যতা নিরীক্ষণ করতে হবে এবং এর কিছু গুণগত এবং পরিমাণগত বৈশিষ্ট্যও প্রদান করতে হবে।

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

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

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

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

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

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

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

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

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

এই ড্যাশবোর্ডে আপনার কি যোগ করা উচিত? আপনি প্রতিক্রিয়া সময় হিসাবে যেমন একটি বৈশিষ্ট্য সঙ্গে শুরু করতে পারেন. PostgreSQL এর pg_stat_statements ভিউ আছে। এটি ডিফল্টরূপে নিষ্ক্রিয় থাকে, তবে এটি একটি গুরুত্বপূর্ণ সিস্টেম ভিউ যা সর্বদা সক্রিয় এবং ব্যবহার করা উচিত। এটি ডাটাবেসে কার্যকর করা সমস্ত চলমান প্রশ্নগুলির তথ্য সঞ্চয় করে।

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

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

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

লেনদেনের সংখ্যা অনুমান করার জন্য, আমরা আবার pg_stat_database ভিউ উল্লেখ করতে পারি। আমরা কমিটের সংখ্যা এবং রোলব্যাকের সংখ্যা যোগ করতে পারি এবং প্রতি সেকেন্ডে লেনদেনের সংখ্যা পেতে পারি।

সবাই কি বোঝে যে একাধিক অনুরোধ একটি লেনদেনে ফিট হতে পারে? তাই TPS এবং QPS কিছুটা আলাদা।

প্রতি সেকেন্ডে অনুরোধের সংখ্যা pg_stat_statements থেকে পাওয়া যেতে পারে এবং কেবলমাত্র সমস্ত সম্পূর্ণ অনুরোধের যোগফল গণনা করুন। এটা স্পষ্ট যে আমরা বর্তমান মানটিকে আগেরটির সাথে তুলনা করি, এটি বিয়োগ করি, ডেল্টা পাই এবং পরিমাণ পাই।

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

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

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

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

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

PostgreSQL এর আরেকটি বৈশিষ্ট্য হল PostgreSQL দীর্ঘ লেনদেনের ক্ষেত্রে খুবই কষ্টদায়ক। বিশেষ করে এমন লেনদেন থেকে যা দীর্ঘ সময় ধরে ঝুলে থাকে এবং কিছুই করে না। এটি তথাকথিত স্ট্যাট অলস-ইন-লেনদেন। এই ধরনের লেনদেন তালা ধরে রাখে এবং শূন্যতাকে কাজ করা থেকে বাধা দেয়। এবং ফলস্বরূপ, টেবিলগুলি ফুলে যায় এবং আকারে বৃদ্ধি পায়। এবং এই টেবিলগুলির সাথে কাজ করে এমন প্রশ্নগুলি ধীরে ধীরে কাজ করতে শুরু করে, কারণ আপনাকে মেমরি থেকে ডিস্ক এবং পিছনের সারিগুলির সমস্ত পুরানো সংস্করণগুলিকে বেলচাতে হবে৷ অতএব, সময়, দীর্ঘতম লেনদেনের সময়কাল, দীর্ঘতম ভ্যাকুয়াম অনুরোধগুলিও নিরীক্ষণ করা দরকার। এবং যদি আমরা এমন কিছু প্রক্রিয়া দেখতে পাই যেগুলি অনেক দীর্ঘ সময় ধরে চলছে, ইতিমধ্যে একটি OLTP লোডের জন্য 10-20-30 মিনিটের বেশি, তাহলে আমাদের সেগুলির প্রতি মনোযোগ দিতে হবে এবং জোরপূর্বক সেগুলি বন্ধ করতে হবে, বা অ্যাপ্লিকেশনটিকে অপ্টিমাইজ করতে হবে যাতে তারা বলা হয় না এবং এত দীর্ঘ স্তব্ধ না. একটি বিশ্লেষণাত্মক কাজের চাপের জন্য, 10-20-30 মিনিট স্বাভাবিক; আরও দীর্ঘ সময় রয়েছে।

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

সংযুক্ত ক্লায়েন্টদের সম্পর্কে তথ্য গুরুত্বপূর্ণ কারণ, একটি PostgreSQL দৃষ্টিকোণ থেকে, ক্লায়েন্টরা আলাদা। ভালো ক্লায়েন্ট আছে আবার খারাপ ক্লায়েন্ট আছে।

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

এমন পরিস্থিতিতে আছে যখন ক্লায়েন্ট সংযোগ করেছে, এটি সংযোগ ধরে রাখে, কিন্তু কিছুই করে না। এটি নিষ্ক্রিয় অবস্থায় রয়েছে।

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

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

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

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

যদি আমরা দীর্ঘ লেনদেন দেখতে পাই, আমাদের সেগুলি ইতিমধ্যেই সম্পূর্ণ করা উচিত। একটি OLTP লোডের জন্য, দীর্ঘ লেনদেনগুলি ইতিমধ্যে 1-2-3 মিনিটের বেশি. একটি OLAP কাজের চাপের জন্য, দীর্ঘ লেনদেন স্বাভাবিক, কিন্তু যদি সেগুলি সম্পূর্ণ হতে দুই ঘণ্টার বেশি সময় নেয়, তাহলে এটিও একটি চিহ্ন যে আমাদের কোথাও একটা তির্যক আছে৷

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

আমাদের কাজের চাপ মূল্যায়ন করার জন্য এবং কোন টেবিলগুলি আমাদের জন্য "সবচেয়ে গরম" তা মোটামুটিভাবে বোঝার জন্য এটি প্রয়োজনীয়। উদাহরণস্বরূপ, এটি এমন পরিস্থিতিতে প্রয়োজন যেখানে আমরা কিছু দ্রুত SSD স্টোরেজের উপর "হট" টেবিল রাখতে চাই। উদাহরণস্বরূপ, কিছু সংরক্ষণাগার টেবিল যা আমরা দীর্ঘদিন ধরে ব্যবহার করিনি সেগুলিকে কিছু ধরণের "ঠান্ডা" সংরক্ষণাগারে, SATA ড্রাইভে স্থানান্তরিত করা যেতে পারে এবং সেগুলিকে সেখানে থাকতে দিন, সেগুলি প্রয়োজন অনুসারে অ্যাক্সেস করা হবে।

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

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

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

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

এবং আমরা এটি পর্যবেক্ষণে দেখতে পারি। এবং ইতিমধ্যে এই প্রশ্নটি দেখুন, এটির জন্য একটি ব্যাখ্যা চালান, পরিসংখ্যান সংগ্রহ করুন, একটি নতুন অতিরিক্ত সূচক তৈরি করুন। এবং ইতিমধ্যে এই সমস্যা সাড়া. সেজন্য এটা গুরুত্বপূর্ণ।

পর্যবেক্ষণের আরেকটি উদাহরণ। আমি মনে করি অনেকেই তাকে চিনতে পেরেছেন কারণ তিনি খুব জনপ্রিয়। যারা তাদের প্রকল্পে এটি ব্যবহার করে প্রমিথিউস? কে প্রমিথিউসের সাথে এই পণ্যটি ব্যবহার করে? আসল বিষয়টি হ'ল এই পর্যবেক্ষণের স্ট্যান্ডার্ড সংগ্রহস্থলে PostgreSQL এর সাথে কাজ করার জন্য একটি ড্যাশবোর্ড রয়েছে - postgres_exporter প্রমিথিউস। কিন্তু একটি খারাপ বিবরণ আছে.

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

কিভাবে এই টেবিলে পরিসংখ্যান পেতে? এই উদ্দেশ্যে, PostgreSQL এর একটি নির্দিষ্ট পরিবার রয়েছে। এবং প্রধান দৃশ্য হল pg_stat_user_tables. User_tables - এর অর্থ ব্যবহারকারীর পক্ষ থেকে তৈরি করা টেবিল। বিপরীতে, এমন সিস্টেম ভিউ রয়েছে যা PostgreSQL নিজেই ব্যবহার করে। এবং একটি সংক্ষিপ্ত সারণী Alltables, যা সিস্টেম এবং ব্যবহারকারী উভয়ই অন্তর্ভুক্ত করে। আপনি তাদের যে কোনটি থেকে শুরু করতে পারেন যা আপনার সবচেয়ে ভালো লাগে।

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

এই তথ্যের উপর ভিত্তি করে, আমরা তথাকথিত TopN টেবিল তৈরি করতে পারি। যেমন, Top-5, Top-10. এবং আপনি সেই গরম টেবিলগুলিকে ট্র্যাক করতে পারেন যা অন্যদের চেয়ে বেশি পুনর্ব্যবহৃত হয়। উদাহরণস্বরূপ, সন্নিবেশের জন্য 5টি "গরম" টেবিল। এবং এই TopN টেবিলগুলি ব্যবহার করে আমরা আমাদের কাজের চাপকে মূল্যায়ন করি এবং যেকোনো রিলিজ, আপডেট এবং স্থাপনার পরে কাজের চাপের বিস্ফোরণ মূল্যায়ন করতে পারি।

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

এবং এখন আপনার জন্য একটি ছোট প্রশ্ন. আপনি যখন আপনার ডাটাবেস সার্ভারে লোড লক্ষ্য করেন তখন কী প্রশ্ন আসে? আপনার পরবর্তী প্রশ্ন কি?

কিন্তু প্রকৃতপক্ষে প্রশ্ন ওঠে নিম্নরূপ। কি অনুরোধ লোড কারণ? যে, লোড দ্বারা সৃষ্ট প্রক্রিয়াগুলি তাকান আকর্ষণীয় নয়। এটা পরিষ্কার যে হোস্টের যদি ডাটাবেস থাকে, তাহলে ডাটাবেস সেখানে চলছে এবং এটা পরিষ্কার যে শুধুমাত্র ডাটাবেসগুলোই সেখানে নিষ্পত্তি করা হবে। আমরা যদি Top খুলি, তাহলে আমরা PostgreSQL-এর প্রসেসের একটি তালিকা দেখতে পাব যা কিছু করছে। তারা কী করছে তা শীর্ষ থেকে পরিষ্কার হবে না।

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

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

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

আপনি দীর্ঘতম ক্যোয়ারীগুলি নিরীক্ষণ করতে পারেন, অর্থাৎ, সেই প্রশ্নগুলি যেগুলি সম্পূর্ণ হতে দীর্ঘতম সময় নেয়৷ তারা প্রসেসর চালায়, তারা I/O গ্রাস করে। এছাড়াও আমরা এটিকে মোট_সময়, গড়_সময়, blk_write_time এবং blk_read_time ব্যবহার করে মূল্যায়ন করতে পারি।

আমরা সম্পদ ব্যবহারের পরিপ্রেক্ষিতে সবচেয়ে ভারী অনুরোধগুলিকে মূল্যায়ন এবং নিরীক্ষণ করতে পারি, যেগুলি ডিস্ক থেকে পড়ে, যেগুলি মেমরির সাথে কাজ করে, বা বিপরীতভাবে, কিছু ধরণের লেখার লোড তৈরি করে৷

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

এবং আপনি অস্থায়ী ফাইল বা অস্থায়ী টেবিল ব্যবহার করে এমন প্রশ্নগুলিও নিরীক্ষণ করতে পারেন।

এবং আমরা এখনও পটভূমি প্রক্রিয়া আছে. পটভূমি প্রক্রিয়াগুলি প্রাথমিকভাবে চেকপয়েন্ট বা তাদের চেকপয়েন্টও বলা হয়, এগুলি হল অটোভ্যাকুয়াম এবং প্রতিলিপি।

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

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

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

তদনুসারে, নির্দিষ্ট ক্ষেত্রগুলি ব্যবহার করে pg_stat_bgwriter এর মাধ্যমে আমরা ঘটতে থাকা চেকপয়েন্টের সংখ্যা নিরীক্ষণ করতে পারি। এবং যদি আমাদের একটি নির্দিষ্ট সময়ের মধ্যে অনেকগুলি চেকপয়েন্ট থাকে (10-15-20 মিনিটে, আধা ঘন্টার মধ্যে), উদাহরণস্বরূপ, 3-4-5, তবে এটি ইতিমধ্যে একটি সমস্যা হতে পারে। এবং আপনাকে ইতিমধ্যে ডাটাবেস দেখতে হবে, কনফিগারেশনটি দেখতে হবে, কীসের কারণে এত চেকপয়েন্ট রয়েছে। হয়তো কোন ধরনের বড় রেকর্ডিং চলছে। আমরা ইতিমধ্যে কাজের চাপ মূল্যায়ন করতে পারি, কারণ আমরা ইতিমধ্যে কাজের চাপ গ্রাফ যোগ করেছি। আমরা ইতিমধ্যেই চেকপয়েন্ট প্যারামিটারগুলিকে পরিবর্তন করতে পারি এবং নিশ্চিত করতে পারি যে তারা ক্যোয়ারী কার্যক্ষমতাকে ব্যাপকভাবে প্রভাবিত করে না।

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

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

এবং, অবশ্যই, ভ্যাকুয়ামের সময়কাল। যদি আমাদের দীর্ঘস্থায়ী ভ্যাকুয়াম থাকে যা খুব দীর্ঘ সময়ের জন্য চলে, তবে এর অর্থ হ'ল আমাদের আবার ভ্যাকুয়াম কনফিগারেশনে মনোযোগ দিতে হবে এবং সম্ভবত এর সেটিংস পুনর্বিবেচনা করতে হবে। কারণ ভ্যাকুয়াম দীর্ঘ সময় ধরে (3-4 ঘন্টা) টেবিলে কাজ করার সময় একটি পরিস্থিতি তৈরি হতে পারে, তবে ভ্যাকুয়ামটি কাজ করার সময়, প্রচুর পরিমাণে মৃত সারি আবার টেবিলে জমা হতে পারে। এবং শূন্যতা সম্পন্ন হওয়ার সাথে সাথে তাকে আবার এই টেবিলটি ভ্যাকুয়াম করতে হবে। এবং আমরা একটি পরিস্থিতিতে আসা - একটি অন্তহীন শূন্যতা. এবং এই ক্ষেত্রে, ভ্যাকুয়াম তার কাজের সাথে মানিয়ে নিতে পারে না, এবং টেবিলগুলি ধীরে ধীরে আকারে ফুলতে শুরু করে, যদিও এতে দরকারী ডেটার পরিমাণ একই থাকে। অতএব, দীর্ঘ ভ্যাকুয়ামের সময়, আমরা সর্বদা কনফিগারেশনটি দেখি এবং এটি অপ্টিমাইজ করার চেষ্টা করি, তবে একই সাথে যাতে ক্লায়েন্টের অনুরোধগুলির কার্যকারিতা ক্ষতিগ্রস্ত না হয়।

আজকাল কার্যত কোন PostgreSQL ইনস্টলেশন নেই যার স্ট্রিমিং প্রতিলিপি নেই। প্রতিলিপি হল একটি মাস্টার থেকে একটি প্রতিলিপিতে ডেটা সরানোর প্রক্রিয়া।

PostgreSQL-এ প্রতিলিপি একটি লেনদেন লগের মাধ্যমে করা হয়। উইজার্ড একটি লেনদেন লগ তৈরি করে। লেনদেন লগ নেটওয়ার্ক সংযোগের মাধ্যমে প্রতিরূপের সাথে ভ্রমণ করে এবং তারপরে এটি প্রতিলিপিতে পুনরুত্পাদন করা হয়। ইহা সহজ.

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

কিন্তু তা সত্ত্বেও, প্রতিলিপিকরণ ল্যাগ মূল্যায়ন করার জন্য, আপনাকে লেনদেনে লগের অবস্থান জানতে হবে। এবং এই লেনদেন লগ অবস্থানগুলি ঠিক pg_stat_replication ভিউতে রয়েছে৷ তুলনামূলকভাবে বলতে গেলে, আমরা pg_xlog_location_diff() ফাংশন ব্যবহার করে লেনদেন লগে দুটি পয়েন্ট নিতে পারি। তাদের মধ্যে ডেল্টা গণনা করুন এবং বাইটে প্রতিলিপি ল্যাগ পান। এটা খুব সুবিধাজনক এবং সহজ.

সংস্করণ 10-এ, এই ফাংশনটির নাম পরিবর্তন করে pg_wal_lsn_diff() করা হয়েছিল। সাধারণভাবে, সমস্ত ফাংশন, ভিউ এবং ইউটিলিটিগুলিতে যেখানে "xlog" শব্দটি উপস্থিত হয়েছিল, এটি "ওয়াল" মান দিয়ে প্রতিস্থাপিত হয়েছিল। এটি দৃশ্য এবং ফাংশন উভয় ক্ষেত্রেই প্রযোজ্য। এটি এমন একটি উদ্ভাবন।

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

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

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

তাছাড়া, এই পরিসংখ্যানগুলি /proc ফাইল সিস্টেম থেকেও পাওয়া যেতে পারে, যেমনটি রিসাইক্লিং প্রসেসরের জন্য করা হয়। আমি জানি না কেন এই তথ্য মনিটরিং যোগ করা হয় না. কিন্তু তবুও, আপনার পর্যবেক্ষণে এটি থাকা গুরুত্বপূর্ণ।

একই নেটওয়ার্ক ইন্টারফেস প্রযোজ্য. প্যাকেটে, বাইটে নেটওয়ার্ক থ্রুপুট সম্পর্কে তথ্য রয়েছে, কিন্তু তবুও লেটেন্সি সম্পর্কে কোনও তথ্য নেই এবং ব্যবহার সম্পর্কে কোনও তথ্য নেই, যদিও এটিও দরকারী তথ্য।

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

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

এবং কয়েকটি মূল পয়েন্ট:

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

আপনি যদি এই বিষয়ে আগ্রহী হন, তাহলে আপনি এই লিঙ্কগুলি অনুসরণ করতে পারেন।
http://bit.do/stats_collector - এটি পরিসংখ্যান সংগ্রাহকের অফিসিয়াল ডকুমেন্টেশন। সমস্ত পরিসংখ্যানগত দৃষ্টিভঙ্গির বিবরণ এবং সমস্ত ক্ষেত্রের একটি বিবরণ রয়েছে৷ আপনি তাদের পড়তে, বুঝতে এবং বিশ্লেষণ করতে পারেন। এবং তাদের উপর ভিত্তি করে, আপনার গ্রাফ তৈরি করুন এবং আপনার পর্যবেক্ষণে যোগ করুন।

উদাহরণ অনুরোধ:
http://bit.do/dataegret_sql
http://bit.do/lesovsky_sql

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

প্রশ্ন

প্রশ্ন: আপনি বলেছিলেন যে আপনি ব্র্যান্ডের বিজ্ঞাপন দেবেন না, তবে আমি এখনও কৌতূহলী - আপনি আপনার প্রকল্পগুলিতে কী ধরণের ড্যাশবোর্ড ব্যবহার করেন?
উত্তর: এটি পরিবর্তিত হয়। এটি ঘটে যে আমরা একজন গ্রাহকের কাছে আসি এবং তার ইতিমধ্যে তার নিজস্ব পর্যবেক্ষণ রয়েছে। এবং আমরা গ্রাহককে তাদের পর্যবেক্ষণে কী যুক্ত করা দরকার সে সম্পর্কে পরামর্শ দিই। সবচেয়ে খারাপ অবস্থা জাবিক্সের। কারণ এতে TopN গ্রাফ তৈরি করার ক্ষমতা নেই। আমরা নিজেরাই ব্যবহার করি ওকমিটার, কারণ আমরা এই লোকদের সাথে পর্যবেক্ষণে পরামর্শ করছিলাম। তারা আমাদের প্রযুক্তিগত বৈশিষ্ট্যের উপর ভিত্তি করে PostgreSQL নিরীক্ষণ করেছে। আমি আমার নিজের পোষা-প্রকল্প লিখছি, যা প্রমিথিউসের মাধ্যমে ডেটা সংগ্রহ করে এবং এটিকে রেন্ডার করে গ্রাফানা. আমার কাজ হল প্রমিথিউসে আমার নিজস্ব রপ্তানিকারক তৈরি করা এবং তারপর গ্রাফনায় সবকিছু রেন্ডার করা।

প্রশ্ন: AWR রিপোর্ট বা... সমষ্টির কোনো অ্যানালগ আছে? আপনি এই মত কিছু সম্পর্কে জানেন?
উত্তর: হ্যাঁ, আমি জানি AWR কী, এটি একটি দুর্দান্ত জিনিস। এই মুহুর্তে বিভিন্ন ধরণের সাইকেল রয়েছে যা প্রায় নিম্নলিখিত মডেলটি বাস্তবায়ন করে। কিছু সময়ের ব্যবধানে, কিছু বেসলাইন একই PostgreSQL বা আলাদা স্টোরেজে লেখা হয়। আপনি ইন্টারনেটে তাদের গুগল করতে পারেন, তারা সেখানে আছে। পোস্টগ্রেএসকিউএল থ্রেডে sql.ru ফোরামে এই ধরনের একটি ডেভেলপার বসে আছে। আপনি তাকে সেখানে ধরতে পারেন। হ্যাঁ, এই ধরনের জিনিস আছে, তারা ব্যবহার করা যেতে পারে. প্লাস তার মধ্যে pg কেন্দ্র আমি এমন একটি জিনিসও লিখছি যা আপনাকে একই জিনিস করতে দেয়।

PS1 আপনি যদি postgres_exporter ব্যবহার করেন, তাহলে আপনি কোন ড্যাশবোর্ড ব্যবহার করছেন? তাদের মধ্যে বেশ কিছু আছে। সেগুলি ইতিমধ্যেই সেকেলে। হয়তো সম্প্রদায় একটি আপডেট টেমপ্লেট তৈরি করবে?

PS2 সরানো হয়েছে pganalize কারণ এটি একটি মালিকানাধীন SaaS অফার যা কর্মক্ষমতা নিরীক্ষণ এবং স্বয়ংক্রিয় টিউনিং পরামর্শের উপর ফোকাস করে।

শুধুমাত্র নিবন্ধিত ব্যবহারকারীরা জরিপে অংশগ্রহণ করতে পারবেন। সাইন ইন করুনকরুন।

কোন স্ব-হোস্টেড postgresql মনিটরিং (ড্যাশবোর্ড সহ) আপনি সেরা বিবেচনা করেন?

• 30,0%আলেক্সি লেসোভস্কি বা zabbix 4.4 বা libzbxpgsql + zabbix libzbxpgsql + zabbix3 থেকে Zabbix + সংযোজন

• 0,0%https://github.com/lesovsky/pgcenter0

• 0,0%https://github.com/pg-monz/pg_monz0

• 20,0%https://github.com/cybertec-postgresql/pgwatch22

• 20,0%https://github.com/postgrespro/mamonsu2

• 0,0%https://www.percona.com/doc/percona-monitoring-and-management/conf-postgres.html0

• 10,0%pganalyze হল একটি মালিকানাধীন SaaS - আমি এটি মুছে ফেলতে পারি না

• 10,0%https://github.com/powa-team/powa1

• 0,0%https://github.com/darold/pgbadger0

• 0,0%https://github.com/darold/pgcluu0

• 0,0%https://github.com/zalando/PGObserver0

• 10,0%https://github.com/spotify/postgresql-metrics1

10 জন ব্যবহারকারী ভোট দিয়েছেন। 26 জন ব্যবহারকারী বিরত ছিলেন।

উত্স: www.habr.com