PostgreSQL অভ্যন্তরীণ পরিসংখ্যানে গভীরভাবে ডুব দিন। আলেক্সি লেসভস্কি

অ্যালেক্সি লেসোভস্কির 2015 রিপোর্টের প্রতিলিপি "পোস্টগ্রেএসকিউএল অভ্যন্তরীণ পরিসংখ্যানে গভীরভাবে ডুব"

প্রতিবেদনের লেখক থেকে দাবিত্যাগ: আমি লক্ষ্য করি যে এই প্রতিবেদনটি নভেম্বর 2015 তারিখের - 4 বছরেরও বেশি সময় কেটে গেছে এবং অনেক সময় পেরিয়ে গেছে। প্রতিবেদনে আলোচিত সংস্করণ 9.4 আর সমর্থিত নয়। বিগত 4 বছরে, 5টি নতুন রিলিজ প্রকাশিত হয়েছে যার মধ্যে পরিসংখ্যান সম্পর্কিত অনেকগুলি উদ্ভাবন, উন্নতি এবং পরিবর্তনগুলি উপস্থিত হয়েছে এবং কিছু উপাদান পুরানো এবং প্রাসঙ্গিক নয়৷ আমি পর্যালোচনা করার সাথে সাথে, আমি এই স্থানগুলি চিহ্নিত করার চেষ্টা করেছি যাতে পাঠক আপনাকে বিভ্রান্ত করতে না পারে। আমি এই জায়গাগুলি পুনঃলিখন করিনি, সেগুলির অনেকগুলি রয়েছে এবং ফলস্বরূপ, একটি সম্পূর্ণ ভিন্ন প্রতিবেদন চালু হবে।

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

শুভ অপরাহ্ন আমার নাম আলেক্সি। যেমন ইলিয়া বলেছেন, আমি PostgreSQL পরিসংখ্যান সম্পর্কে কথা বলব।

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

আমি আপনাকে বলব কিভাবে কার্যকরভাবে পরিসংখ্যান ব্যবহার করে আপনার বিভিন্ন সমস্যা সমাধান করতে হয় বা থাকতে পারে।

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

এবং কোন টুল রিভিউ থাকবে না, আমি একটি পণ্যের সাথে অন্য পণ্যের তুলনা করব না। কোন বিজ্ঞাপন থাকবে না। বাদ দেই।

আমি আপনাকে দেখাতে চাই যে পরিসংখ্যান ব্যবহার করা দরকারী। এটা জরুরি. নির্ভয়ে ব্যবহার করুন। আমাদের যা দরকার তা হল সাধারণ এসকিউএল এবং এসকিউএল-এর প্রাথমিক জ্ঞান।

এবং আমরা সমস্যা সমাধানের জন্য কোন পরিসংখ্যান নির্বাচন করতে হবে সে সম্পর্কে কথা বলব।

যদি আমরা PostgreSQL দেখি এবং প্রক্রিয়াগুলি দেখার জন্য অপারেটিং সিস্টেমে একটি কমান্ড চালাই, আমরা একটি "ব্ল্যাক বক্স" দেখতে পাব। আমরা এমন কিছু প্রক্রিয়া দেখব যা কিছু করে, এবং নাম দিয়ে আমরা মোটামুটিভাবে কল্পনা করতে পারি যে তারা সেখানে কী করছে, তারা কী করছে। কিন্তু, আসলে, এটি একটি কালো বক্স, আমরা ভিতরে তাকাতে পারি না।

আমরা CPU লোড দেখতে পারি top, আমরা কিছু সিস্টেম ইউটিলিটি দ্বারা মেমরি ব্যবহার দেখতে পারি, কিন্তু আমরা PostgreSQL এর ভিতরে দেখতে সক্ষম হব না। এর জন্য আমাদের অন্যান্য সরঞ্জামের প্রয়োজন।

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

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

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

পরিসংখ্যানের সমস্যা কি?

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

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

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

পরিসংখ্যান আমাদের বেশ কিছু জিনিস বলে। তাদের ক্যাটাগরিতে ভাগ করা যায়।

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

পরিসংখ্যানের উত্সগুলি নিম্নরূপ উপস্থাপন করা হয়েছে:

• শেয়ার্ড মেমরিতে (শেয়ারড বাফার) স্ট্যাটিক ডেটা রাখার জন্য একটি সেগমেন্ট রয়েছে, এমন কাউন্টারগুলিও রয়েছে যেগুলি ক্রমাগত বৃদ্ধি পায় যখন নির্দিষ্ট ঘটনা ঘটে, বা ডাটাবেসের ক্রিয়াকলাপে কিছু মুহূর্ত দেখা দেয়।
• এই সমস্ত কাউন্টার ব্যবহারকারীর জন্য উপলব্ধ নয় এবং এমনকি প্রশাসকের কাছেও উপলব্ধ নয়। এগুলো নিম্নস্তরের জিনিস। সেগুলি অ্যাক্সেস করার জন্য, PostgreSQL SQL ফাংশন আকারে একটি ইন্টারফেস প্রদান করে। আমরা এই ফাংশনগুলি ব্যবহার করে কিছু নির্বাচন করতে পারি এবং কিছু ধরণের মেট্রিক (বা মেট্রিক্সের সেট) পেতে পারি।
• যাইহোক, এই ফাংশনগুলি ব্যবহার করা সর্বদা সুবিধাজনক নয়, তাই ফাংশনগুলি ভিউগুলির ভিত্তি (VIEWs)। এগুলি হল ভার্চুয়াল টেবিল যা একটি নির্দিষ্ট সাবসিস্টেমের পরিসংখ্যান প্রদান করে বা ডাটাবেসের কিছু ইভেন্টের সেটে।
• এই বিল্ট-ইন ভিউ (VIEWs) হল পরিসংখ্যান নিয়ে কাজ করার জন্য প্রধান ইউজার ইন্টারফেস। এগুলি কোনও অতিরিক্ত সেটিংস ছাড়াই ডিফল্টরূপে উপলব্ধ, আপনি অবিলম্বে সেগুলি ব্যবহার করতে, দেখতে, সেখান থেকে তথ্য নিতে পারেন৷ এবং অবদান আছে. অবদান সরকারী. আপনি postgresql-contrib প্যাকেজটি ইনস্টল করতে পারেন (উদাহরণস্বরূপ, postgresql94-contrib), কনফিগারেশনে প্রয়োজনীয় মডিউল লোড করতে পারেন, এর জন্য পরামিতি নির্দিষ্ট করতে পারেন, PostgreSQL পুনরায় চালু করতে পারেন এবং আপনি এটি ব্যবহার করতে পারেন। (বিঃদ্রঃ. বিতরণের উপর নির্ভর করে, অবদানের সাম্প্রতিক সংস্করণগুলিতে প্যাকেজটি প্রধান প্যাকেজের অংশ).
• এবং অনানুষ্ঠানিক অবদান আছে. তারা স্ট্যান্ডার্ড PostgreSQL বিতরণের সাথে সরবরাহ করা হয় না। সেগুলি অবশ্যই একটি লাইব্রেরি হিসাবে সংকলিত বা ইনস্টল করা উচিত। এই অনানুষ্ঠানিক অবদানের বিকাশকারী কী নিয়ে এসেছে তার উপর নির্ভর করে বিকল্পগুলি খুব আলাদা হতে পারে।

এই স্লাইডটি সেই সমস্ত ভিউ (VIEWs) এবং PostgreSQL 9.4-এ উপলব্ধ কিছু ফাংশন দেখায়। আমরা দেখতে পাচ্ছি, তাদের অনেক আছে. এবং আপনি যদি প্রথমবার এটি অনুভব করেন তবে বিভ্রান্ত হওয়া বেশ সহজ।

তবে আমরা যদি আগের ছবিটা তুলি Как тратится время на PostgreSQL এবং এই তালিকার সাথে সামঞ্জস্যপূর্ণ, আমরা এই ছবিটি পাই। প্রতিটি দৃশ্য (VIEWs), অথবা প্রতিটি ফাংশন, আমরা PostgreSQL চলমান থাকলে উপযুক্ত পরিসংখ্যান পেতে এক বা অন্য উদ্দেশ্যে ব্যবহার করতে পারি। এবং আমরা ইতিমধ্যে সাবসিস্টেমের অপারেশন সম্পর্কে কিছু তথ্য পেতে পারি।

প্রথম জিনিস আমরা তাকান হবে pg_stat_database. আমরা দেখতে পাচ্ছি, এটি একটি প্রতিনিধিত্ব. এতে অনেক তথ্য রয়েছে। সবচেয়ে বৈচিত্রময় তথ্য. এবং এটি ডাটাবেসে আমরা কী চলছে তার খুব দরকারী জ্ঞান দেয়।

আমরা সেখান থেকে কি নিতে পারি? সহজ জিনিস দিয়ে শুরু করা যাক।

select
sum(blks_hit)*100/sum(blks_hit+blks_read) as hit_ratio
from pg_stat_database;

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

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

select
datname,
(xact_commit*100)/(xact_commit+xact_rollback) as c_ratio,
deadlocks, conflicts,
temp_file, pg_size_pretty(temp_bytes) as temp_size
from pg_stat_database;

এই উপস্থাপনা থেকে আর কি নেওয়া যেতে পারে? আপনি ডাটাবেসে ঘটছে অসঙ্গতি দেখতে পারেন. এখানে কি দেখানো হয়? কমিট, রোলব্যাক, অস্থায়ী ফাইল তৈরি, তাদের আকার, অচলাবস্থা এবং দ্বন্দ্ব রয়েছে।

আমরা এই অনুরোধ ব্যবহার করতে পারেন. এই SQL বেশ সহজ. এবং আমরা নিজেদের জন্য এই তথ্য দেখতে পারেন.

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

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

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

অস্থায়ী ফাইল (temp_files)ও খারাপ। যখন একটি ব্যবহারকারীর অনুরোধে অপারেশনাল, অস্থায়ী ডেটা মিটমাট করার জন্য যথেষ্ট মেমরি থাকে না, তখন এটি ডিস্কে একটি ফাইল তৈরি করে। এবং মেমরির একটি অস্থায়ী বাফারে যে সমস্ত ক্রিয়াকলাপগুলি সে সম্পাদন করতে পারে সেগুলি ইতিমধ্যে ডিস্কে সঞ্চালিত হতে শুরু করে। এটা ধীরগতির. এটি কোয়েরি সম্পাদনের সময় বাড়ায়। এবং যে ক্লায়েন্ট PostgreSQL এ একটি অনুরোধ পাঠিয়েছে সে একটু পরে একটি প্রতিক্রিয়া পাবে। এই সমস্ত ক্রিয়াকলাপগুলি মেমরিতে সঞ্চালিত হলে, Postgres অনেক দ্রুত প্রতিক্রিয়া জানাবে এবং ক্লায়েন্ট কম অপেক্ষা করবে।

pg_stat_bgwriter - এই ভিউ দুটি PostgreSQL ব্যাকগ্রাউন্ড সাবসিস্টেমের অপারেশন বর্ণনা করে: checkpointer и background writer.

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

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

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

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

এবং চেকপয়েন্ট সামঞ্জস্য করার জন্য তিনটি পরামিতি রয়েছে:

• сheckpoint_segments.

• сheckpoint_timeout.

• сheckpoint_competion_target.

তারা আপনাকে নিয়ন্ত্রণ পয়েন্টগুলির ক্রিয়াকলাপ নিয়ন্ত্রণ করতে দেয়। কিন্তু আমি তাদের উপর বাস করব না. তাদের প্রভাব একটি পৃথক বিষয়।

সতর্কতা: প্রতিবেদনে বিবেচনা করা সংস্করণ 9.4 আর প্রাসঙ্গিক নয়। PostgreSQL এর আধুনিক সংস্করণে, প্যারামিটার checkpoint_segments পরামিতি দ্বারা প্রতিস্থাপিত min_wal_size и max_wal_size.

পরবর্তী সাবসিস্টেম হল পটভূমি লেখক − background writer. সে কি করছে? এটি একটি অবিরাম লুপে ক্রমাগত সঞ্চালিত হয়। শেয়ার্ড বাফারে পৃষ্ঠাগুলি স্ক্যান করে এবং ডিস্কে পাওয়া নোংরা পৃষ্ঠাগুলিকে ফ্লাশ করে৷ এইভাবে, এটি চেকপয়েন্টারকে চেকপয়েন্টিংয়ের সময় কম কাজ করতে সহায়তা করে।

তার আর কি দরকার? এটি ভাগ করা বাফারগুলিতে পরিষ্কার পৃষ্ঠাগুলির প্রয়োজনের জন্য সরবরাহ করে যদি সেগুলি হঠাৎ করে (বড় পরিমাণে এবং অবিলম্বে) ডেটা মিটমাট করার জন্য প্রয়োজন হয়। ধরুন একটি পরিস্থিতির উদ্ভব হয়েছে যখন অনুরোধের জন্য পরিষ্কার পৃষ্ঠাগুলির প্রয়োজন এবং সেগুলি ইতিমধ্যেই ভাগ করা বাফারে রয়েছে৷ পোস্টগ্রেস backend সে শুধু সেগুলো নেয় এবং ব্যবহার করে, তাকে নিজেকে কিছু পরিষ্কার করতে হবে না। কিন্তু হঠাৎ করে এমন কোনো পৃষ্ঠা না থাকলে, ব্যাকএন্ড বিরতি দেয় এবং পৃষ্ঠাগুলিকে ডিস্কে ফ্লাশ করতে এবং তাদের নিজস্ব প্রয়োজনে সেগুলি নিয়ে যাওয়ার জন্য অনুসন্ধান শুরু করে - যা বর্তমানে কার্যকর করা অনুরোধের সময়কে নেতিবাচকভাবে প্রভাবিত করে। আপনি যদি দেখতে পান যে আপনার একটি প্যারামিটার আছে maxwritten_clean বড়, এর মানে হল যে ব্যাকগ্রাউন্ড লেখক তার কাজ করছেন না এবং আপনাকে প্যারামিটার বাড়াতে হবে bgwriter_lru_maxpagesযাতে তিনি এক চক্রে আরও কাজ করতে পারেন, আরও পৃষ্ঠা পরিষ্কার করতে পারেন।

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

সতর্কতা: _নিম্নলিখিত পাঠ্যটি প্রতিলিপির সাথে সম্পর্কিত পরিসংখ্যানগত দৃষ্টিভঙ্গি বর্ণনা করে। পোস্টগ্রেস 10-এ বেশিরভাগ ভিউ এবং ফাংশনের নাম পরিবর্তন করা হয়েছে। নাম পরিবর্তনের সারমর্ম ছিল প্রতিস্থাপন করা। xlog উপর wal и location উপর lsn ফাংশন/ভিউ নাম, ইত্যাদিতে বিশেষ উদাহরণ, ফাংশন pg_xlog_location_diff() নামকরণ করা হয়েছিল pg_wal_lsn_diff()._

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

যদি আমরা দেখি যে সমস্ত মান সমান, তবে এটি আদর্শ এবং প্রতিরূপটি মাস্টারের চেয়ে পিছিয়ে নেই।

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

сколько записано xlog в байтах
$ select
pg_xlog_location_diff(pg_current_xlog_location(),'0/00000000');
лаг репликации в байтах
$ select
client_addr,
pg_xlog_location_diff(pg_current_xlog_location(), replay_location)
from pg_stat_replication;
лаг репликации в секундах
$ select
extract(epoch from now() - pg_last_xact_replay_timestamp());

এসব বিষয় ভিন্ন হলে একধরনের ল্যাগ থাকে। ল্যাগ হল মাস্টারের প্রতিরূপের ল্যাগ, অর্থাৎ ডেটা সার্ভারের মধ্যে আলাদা।

বিলম্বের তিনটি কারণ রয়েছে:

• এটি ডিস্ক সাবসিস্টেম যা ফাইল সিঙ্ক লেখাগুলি পরিচালনা করতে পারে না।
• এগুলি সম্ভাব্য নেটওয়ার্ক ত্রুটি, বা নেটওয়ার্ক ওভারলোড, যখন ডেটার প্রতিরূপ পৌঁছানোর সময় থাকে না এবং এটি পুনরুত্পাদন করতে পারে না।
• এবং প্রসেসর। প্রসেসর একটি খুব বিরল ক্ষেত্রে. এবং আমি এটি দুই বা তিনবার দেখেছি, তবে এটিও ঘটতে পারে।

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

দ্রষ্টব্য: pg_xlog_location-এর পরিবর্তেdiff() ফাংশন, আপনি বিয়োগ অপারেটর ব্যবহার করতে পারেন এবং একটি অবস্থান থেকে অন্য অবস্থান বিয়োগ করতে পারেন। আরামপ্রদ.

একটি ব্যবধান সঙ্গে, যা সেকেন্ডে, একটি মুহূর্ত আছে. মাস্টারের উপর কোন কার্যকলাপ না থাকলে, লেনদেনটি প্রায় 15 মিনিট আগে ছিল এবং কোন কার্যকলাপ নেই, এবং যদি আমরা প্রতিলিপিতে এই ল্যাগটি দেখি, আমরা 15 মিনিটের ব্যবধান দেখতে পাব। এটি মনে রাখার মতো। এবং যখন আপনি এই ব্যবধান দেখেছেন তখন এটি একটি স্তম্ভিত হতে পারে।

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

select
relname,
pg_size_pretty(pg_relation_size(relname::regclass)) as size,
seq_scan, seq_tup_read,
seq_scan / seq_tup_read as seq_tup_avg
from pg_stat_user_tables
where seq_tup_read > 0 order by 3,4 desc limit 5;

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

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

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

select
relname,
pg_size_pretty(pg_total_relation_size(relname::regclass)) as
full_size,
pg_size_pretty(pg_relation_size(relname::regclass)) as
table_size,
pg_size_pretty(pg_total_relation_size(relname::regclass) -
pg_relation_size(relname::regclass)) as index_size
from pg_stat_user_tables
order by pg_total_relation_size(relname::regclass) desc limit 10;

এই টেবিলটি ব্যবহার করে এবং অতিরিক্ত ফাংশন ব্যবহার করে টেবিলের আকারগুলিও পাওয়া যেতে পারে pg_total_relation_size(), pg_relation_size().

সাধারণভাবে, মেটাকমান্ড আছে dt и di, যা আপনি PSQL এ ব্যবহার করতে পারেন এবং টেবিল এবং সূচকের আকারও দেখতে পারেন।

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

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

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

select
s.relname,
pg_size_pretty(pg_relation_size(relid)),
coalesce(n_tup_ins,0) + 2 * coalesce(n_tup_upd,0) -
coalesce(n_tup_hot_upd,0) + coalesce(n_tup_del,0) AS total_writes,
(coalesce(n_tup_hot_upd,0)::float * 100 / (case when n_tup_upd > 0
then n_tup_upd else 1 end)::float)::numeric(10,2) AS hot_rate,
(select v[1] FROM regexp_matches(reloptions::text,E'fillfactor=(\d+)') as
r(v) limit 1) AS fillfactor
from pg_stat_all_tables s
join pg_class c ON c.oid=relid
order by total_writes desc limit 50;

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

এবং যখন আপনি আছে n_tup_hot_upd বড়, এটা খুব ভালো। এর মানে হল হাল্কা আপডেটগুলি প্রাধান্য পায় এবং এটি সম্পদের পরিপ্রেক্ষিতে আমাদের জন্য সস্তা এবং সবকিছু ঠিক আছে।

ALTER TABLE table_name SET (fillfactor = 70);

কিভাবে ভলিউম বাড়ানো যায় hot updateov? আমরা ব্যবহার করতে পারি fillfactor. INSERTs ব্যবহার করে একটি টেবিলে একটি পৃষ্ঠা পূরণ করার সময় এটি সংরক্ষিত খালি স্থানের আকার নির্ধারণ করে। সন্নিবেশগুলি যখন টেবিলে যায়, তারা সম্পূর্ণরূপে পৃষ্ঠাটি পূরণ করে, এতে খালি স্থান ছেড়ে যায় না। তারপর একটি নতুন পৃষ্ঠা হাইলাইট করা হয়। ডেটা আবার পূরণ করা হয়। এবং এটি ডিফল্ট আচরণ, ফিলফ্যাক্টর = 100%।

আমরা ফিলফ্যাক্টর 70% সেট করতে পারি। অর্থাৎ, সন্নিবেশ সহ, একটি নতুন পৃষ্ঠা বরাদ্দ করা হয়েছিল, তবে পৃষ্ঠার মাত্র 70% পূর্ণ হয়েছিল। এবং আমরা 30% রিজার্ভ বাকি আছে. যখন আপনাকে একটি আপডেট করতে হবে, এটি সম্ভবত একই পৃষ্ঠায় ঘটবে এবং সারির নতুন সংস্করণ একই পৃষ্ঠায় ফিট হবে৷ এবং hot_update করা হবে। এটি টেবিলে লেখা সহজ করে তোলে।

select c.relname,
current_setting('autovacuum_vacuum_threshold') as av_base_thresh,
current_setting('autovacuum_vacuum_scale_factor') as av_scale_factor,
(current_setting('autovacuum_vacuum_threshold')::int +
(current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples))
as av_thresh,
s.n_dead_tup
from pg_stat_user_tables s join pg_class c ON s.relname = c.relname
where s.n_dead_tup > (current_setting('autovacuum_vacuum_threshold')::int
+ (current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples));

অটোভ্যাকুয়াম সারি। Autovacuum এমন একটি সাবসিস্টেম যার জন্য PostgreSQL-এ খুব কম পরিসংখ্যান রয়েছে। আমরা শুধুমাত্র pg_stat_activity-এর টেবিলে দেখতে পারি যে এই মুহূর্তে আমাদের কতগুলি ভ্যাকুয়াম আছে। যাইহোক, এটি চলার সময় সারিতে কতগুলি টেবিল রয়েছে তা বোঝা খুব কঠিন।

দ্রষ্টব্য: _ Postgres 10 এর পর থেকে, ভ্যাকুয়াম ভ্যাকুয়াম ট্র্যাক করার পরিস্থিতি অনেক উন্নত হয়েছে - pg_stat_progress ভিউ দেখা দিয়েছেভ্যাকুয়াম, যা অটোভ্যাকুয়াম পর্যবেক্ষণের বিষয়টিকে ব্যাপকভাবে সরল করে।

আমরা এই সরলীকৃত প্রশ্নটি ব্যবহার করতে পারি। এবং আমরা দেখতে পারি কখন ভ্যাকুয়াম তৈরি করা উচিত। কিন্তু, কিভাবে এবং কখন ভ্যাকুয়াম শুরু করা উচিত? আমি আগে কথা বলেছি এই স্ট্রিংগুলির পুরানো সংস্করণ। আপডেট হয়েছে, সারির নতুন সংস্করণ ঢোকানো হয়েছে। স্ট্রিংটির একটি অপ্রচলিত সংস্করণ উপস্থিত হয়েছে৷ টেবিল pg_stat_user_tables যেমন একটি পরামিতি আছে n_dead_tup. এটি "মৃত" সারির সংখ্যা দেখায়। এবং যত তাড়াতাড়ি মৃত সারিগুলির সংখ্যা একটি নির্দিষ্ট থ্রেশহোল্ডের চেয়ে বেশি হয়ে গেছে, একটি অটোভ্যাকুয়াম টেবিলে আসবে।

এবং কিভাবে এই থ্রেশহোল্ড গণনা করা হয়? এটি টেবিলের মোট সারির সংখ্যার একটি খুব নির্দিষ্ট শতাংশ। একটি প্যারামিটার আছে autovacuum_vacuum_scale_factor. এটি শতাংশ নির্ধারণ করে। ধরা যাক 10% + 50 লাইনের একটি অতিরিক্ত বেস থ্রেশহোল্ড আছে। এবং কি হয়? যখন আমাদের টেবিলের সমস্ত সারির "10% + 50" এর চেয়ে বেশি মৃত সারি থাকে, আমরা টেবিলটিকে অটোভ্যাকুয়ামে রাখি।

select c.relname,
current_setting('autovacuum_vacuum_threshold') as av_base_thresh,
current_setting('autovacuum_vacuum_scale_factor') as av_scale_factor,
(current_setting('autovacuum_vacuum_threshold')::int +
(current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples))
as av_thresh,
s.n_dead_tup
from pg_stat_user_tables s join pg_class c ON s.relname = c.relname
where s.n_dead_tup > (current_setting('autovacuum_vacuum_threshold')::int
+ (current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples));

যাইহোক, একটি পয়েন্ট আছে. প্যারামিটারের জন্য মৌলিক থ্রেশহোল্ড av_base_thresh и av_scale_factor স্বতন্ত্রভাবে বরাদ্দ করা যেতে পারে। এবং, সেই অনুযায়ী, থ্রেশহোল্ড বিশ্বব্যাপী হবে না, তবে টেবিলের জন্য স্বতন্ত্র। অতএব, গণনা করতে, সেখানে আপনাকে কৌশল এবং কৌশলগুলি ব্যবহার করতে হবে। এবং যদি আপনি আগ্রহী হন, আপনি Avito থেকে আমাদের সহকর্মীদের অভিজ্ঞতা দেখতে পারেন (স্লাইডের লিঙ্কটি অবৈধ এবং পাঠ্যে আপডেট করা হয়েছে)।

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

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

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

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

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

দুটি লিঙ্ক:

https://github.com/dataegret/pg-utils/blob/master/sql/low_used_indexes.sql

http://www.databasesoup.com/2014/05/new-finding-unused-indexes-query.html

অব্যবহৃত সূচীগুলি কীভাবে সন্ধান করা যায় তার জন্য এগুলি আরও উন্নত প্রশ্নের উদাহরণ।

দ্বিতীয় লিঙ্কটি একটি বরং আকর্ষণীয় প্রশ্ন। এর মধ্যে একটি খুব তুচ্ছ যুক্তি আছে। আমি পর্যালোচনার জন্য এটি সুপারিশ.

আর কি সূচী দ্বারা সংক্ষিপ্ত করা উচিত?

• অব্যবহৃত সূচক খারাপ.

• তারা জায়গা নেয়।

• আপডেট অপারেশন ধীর.

• ভ্যাকুয়ামের জন্য অতিরিক্ত কাজ।

যদি আমরা অব্যবহৃত সূচীগুলি সরিয়ে ফেলি, তবে আমরা কেবল ডাটাবেসটিকে আরও ভাল করব।

পরের দৃশ্য হল pg_stat_activity. এটি ইউটিলিটির একটি অ্যানালগ ps, শুধুমাত্র PostgreSQL এ। যদি ps'ওহম আপনি অপারেটিং সিস্টেমের প্রক্রিয়াগুলি দেখেন, তাহলে pg_stat_activity আপনাকে PostgreSQL এর ভিতরে কার্যকলাপ দেখাবে।

আমরা সেখান থেকে কি নিতে পারি?

select
count(*)*100/(select current_setting('max_connections')::int)
from pg_stat_activity;

আমরা ডাটাবেসে ঘটছে যে সামগ্রিক কার্যকলাপ দেখতে পারেন. আমরা একটি নতুন স্থাপনা করতে পারেন. সেখানে সবকিছু বিস্ফোরিত হয়েছে, নতুন সংযোগ গ্রহণ করা হচ্ছে না, অ্যাপ্লিকেশনে ত্রুটিগুলি ঢেলে দেওয়া হচ্ছে।

select
client_addr, usename, datname, count(*)
from pg_stat_activity group by 1,2,3 order by 4 desc;

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

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

select
client_addr, usename, datname,
clock_timestamp() - xact_start as xact_age,
clock_timestamp() - query_start as query_age,
query
from pg_stat_activity order by xact_start, query_start;

অনুগ্রহ করে মনে রাখবেন: এই ধরনের অনুরোধের সাথে, আমরা দীর্ঘ অনুরোধ এবং লেনদেন সংজ্ঞায়িত করতে পারি। আমরা ফাংশন ব্যবহার করি clock_timestamp() কাজের সময় নির্ধারণ করতে। দীর্ঘ অনুরোধ যা আমরা পেয়েছি, আমরা সেগুলি মনে রাখতে পারি, তাদের কার্যকর করতে পারি explain, পরিকল্পনা দেখুন এবং একরকম অপ্টিমাইজ করুন। আমরা বর্তমান দীর্ঘ অনুরোধের শুটিং এবং বাস.

select * from pg_stat_activity where state in
('idle in transaction', 'idle in transaction (aborted)';

খারাপ লেনদেন লেনদেনে নিষ্ক্রিয় এবং লেনদেনে নিষ্ক্রিয় (অবসৃত) লেনদেন।

এর মানে কী? লেনদেনের একাধিক রাজ্য রয়েছে। এবং এই রাজ্যগুলির একটি যে কোন সময় নিতে পারে. রাষ্ট্র সংজ্ঞায়িত করার জন্য একটি ক্ষেত্র আছে state এই দৃশ্যে এবং আমরা এটি রাষ্ট্র নির্ধারণ করতে ব্যবহার করি।

select * from pg_stat_activity where state in
('idle in transaction', 'idle in transaction (aborted)';

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

আপনি যদি দেখেন যে আপনার ডাটাবেসে তাদের মধ্যে 5-10-20 টির বেশি আছে, তাহলে আপনাকে চিন্তিত হতে হবে এবং তাদের সাথে কিছু করা শুরু করতে হবে।

এখানে আমরা গণনার সময়ের জন্যও ব্যবহার করি clock_timestamp(). আমরা লেনদেন অঙ্কুর, আমরা অ্যাপ্লিকেশন অপ্টিমাইজ.

আমি উপরে বলেছি, লক হল যখন দুই বা ততোধিক লেনদেন এক বা একদল সংস্থানের জন্য প্রতিযোগিতা করে। এ জন্য আমাদের একটি ক্ষেত্র রয়েছে waiting বুলিয়ান মান সহ true বা false.

সত্য - এর মানে হল যে প্রক্রিয়াটি অপেক্ষা করছে, কিছু করা দরকার। যখন একটি প্রক্রিয়া অপেক্ষা করছে, তখন যে ক্লায়েন্টটি প্রক্রিয়া শুরু করেছে সেও অপেক্ষা করছে। ব্রাউজারে ক্লায়েন্ট বসে থাকে এবং অপেক্ষা করে।

সতর্কতা: _ Postgres 9.6 থেকে শুরু, ক্ষেত্র waiting সরানো হয়েছে এবং আরও দুটি তথ্যপূর্ণ ক্ষেত্র দ্বারা প্রতিস্থাপিত হয়েছে wait_event_type и wait_event._

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

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

https://github.com/lesovsky/uber-scripts/blob/master/postgresql/sql/c4_06_show_locked_queries.sql

https://github.com/lesovsky/uber-scripts/blob/master/postgresql/sql/show_locked_queries_95.sql

https://github.com/lesovsky/uber-scripts/blob/master/postgresql/sql/show_locked_queries_96.sql

http://big-elephants.com/2013-09/exploring-query-locks-in-postgres/

এবং এখানে দুটি প্রশ্ন রয়েছে যা আপনাকে লকগুলি ট্র্যাক করতে দেয়৷ আমরা ভিউ ব্যবহার করি pg_locks, যা আপনাকে ভারী লক ট্র্যাক করতে দেয়।

এবং প্রথম লিঙ্কটি নিজেই অনুরোধের পাঠ্য। এটা বেশ লম্বা.

এবং দ্বিতীয় লিঙ্কটি লকগুলির উপর একটি নিবন্ধ। এটা পড়া দরকারী, এটা খুব আকর্ষণীয়.

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

এইভাবে আমরা খুঁজে বের করতে পারি কে কাকে তালাবদ্ধ করেছে, কে কাকে ধরে রেখেছে এবং আমরা এটি আরও মোকাবেলা করতে পারি।

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

Cреднее время запроса в милисекундах
$ select (sum(total_time) / sum(calls))::numeric(6,3)
from pg_stat_statements;

Самые активно пишущие (в shared_buffers) запросы
$ select query, shared_blks_dirtied
from pg_stat_statements
where shared_blks_dirtied > 0 order by 2 desc;

আমরা সেখান থেকে কি নিতে পারি? যদি আমরা সাধারণ জিনিস সম্পর্কে কথা বলি, আমরা গড় ক্যোয়ারী কার্যকর করার সময় নিতে পারি। সময় বাড়ছে, যার মানে পোস্টগ্রেএসকিউএল ধীরে ধীরে সাড়া দিচ্ছে এবং কিছু করা দরকার।

আমরা ডাটাবেসে সবচেয়ে সক্রিয় লেখার লেনদেন দেখতে পারি যা ভাগ করা বাফারগুলিতে ডেটা পরিবর্তন করে। কে সেখানে ডেটা আপডেট করে বা মুছে দেয় তা দেখুন।

এবং আমরা শুধু এই অনুরোধের জন্য বিভিন্ন পরিসংখ্যান দেখতে পারেন.

https://github.com/dataegret/pg-utils/blob/master/sql/global_reports/query_stat_total.sql

আমরা pg_stat_statements রিপোর্ট তৈরি করতে ব্যবহৃত হয়। আমরা দিনে একবার পরিসংখ্যান রিসেট করি। আসুন এটা জমা করা যাক. পরের বার পরিসংখ্যান রিসেট করার আগে, আমরা একটি প্রতিবেদন তৈরি করি। এখানে রিপোর্টের একটি লিঙ্ক আছে. আপনি এটা দেখতে পারেন.

আমরা কি করছি? আমরা সমস্ত প্রশ্নের জন্য সামগ্রিক পরিসংখ্যান গণনা করি। তারপর, প্রতিটি প্রশ্নের জন্য, আমরা এই সামগ্রিক পরিসংখ্যানে এর ব্যক্তিগত অবদান গণনা করি।

এবং আমরা কি দেখতে পারি? আমরা অন্য সমস্ত অনুরোধের পটভূমির বিপরীতে একটি নির্দিষ্ট ধরণের সমস্ত অনুরোধের মোট সম্পাদনের সময় দেখতে পারি। আমরা সামগ্রিক চিত্রের সাথে সম্পর্কিত CPU এবং I/O ব্যবহার দেখতে পারি। এবং ইতিমধ্যে এই অনুরোধগুলি অপ্টিমাইজ করতে. আমরা এই প্রতিবেদনের উপর ভিত্তি করে শীর্ষ অনুসন্ধানগুলি তৈরি করছি এবং ইতিমধ্যে কী অপ্টিমাইজ করতে হবে সে সম্পর্কে চিন্তা করার জন্য খাবার পাচ্ছি৷

আমরা পর্দার পিছনে কি আছে? এখনও কিছু জমা আছে যা আমি বিবেচনা করিনি, কারণ সময় সীমিত।

আছে pgstattuple এছাড়াও স্ট্যান্ডার্ড অবদান প্যাকেজ থেকে একটি অতিরিক্ত মডিউল। এটি আপনাকে মূল্যায়ন করতে দেয় bloat টেবিল, তথাকথিত. টেবিল বিভক্তকরণ। এবং যদি ফ্র্যাগমেন্টেশন বড় হয় তবে আপনাকে এটি অপসারণ করতে হবে, বিভিন্ন সরঞ্জাম ব্যবহার করতে হবে। এবং ফাংশন pgstattuple একটি দীর্ঘ সময়ের জন্য কাজ করে। এবং আরো টেবিল, এটি দীর্ঘ কাজ করবে.

পরবর্তী অবদান হল pg_buffercache. এটি আপনাকে ভাগ করা বাফারগুলি পরিদর্শন করতে দেয়: কতটা নিবিড়ভাবে এবং কোন টেবিলের বাফার পৃষ্ঠাগুলি ব্যবহার করা হয়৷ এবং এটি আপনাকে ভাগ করা বাফারগুলি দেখতে এবং সেখানে কী ঘটছে তা মূল্যায়ন করার অনুমতি দেয়।

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

পরবর্তী মডিউল হল pg_stat_kcache. এটি সিস্টেম কলও ব্যবহার করে getrusage(). এবং অনুরোধটি কার্যকর করার আগে এবং পরে এটি কার্যকর করে। এবং প্রাপ্ত পরিসংখ্যানে, এটি আমাদের অনুমান করতে দেয় যে আমাদের অনুরোধটি ডিস্ক I/O-তে কতটা ব্যয় করেছে, অর্থাৎ, ফাইল সিস্টেমের সাথে কাজ করে এবং প্রসেসরের ব্যবহার দেখে। যাইহোক, মডিউলটি তরুণ (খে-খে) এবং এটির কাজের জন্য প্রয়োজন PostgreSQL 9.4 এবং pg_stat_statements, যা আমি আগে উল্লেখ করেছি।

• পরিসংখ্যান ব্যবহার করার ক্ষমতা দরকারী। আপনার তৃতীয় পক্ষের সফ্টওয়্যারের প্রয়োজন নেই। আপনি দেখতে পারেন, দেখতে পারেন, কিছু করতে পারেন, পারফর্ম করতে পারেন।

• পরিসংখ্যান ব্যবহার করা সহজ, এটি সাধারণ SQL। আপনি একটি অনুরোধ সংগ্রহ করেছেন, এটি সংকলন করেছেন, এটি পাঠিয়েছেন, এটি দেখেছেন।

• পরিসংখ্যান প্রশ্নের উত্তর দিতে সাহায্য করে। আপনার যদি প্রশ্ন থাকে, আপনি পরিসংখ্যানে যান - দেখুন, উপসংহার আঁকুন, ফলাফল বিশ্লেষণ করুন।

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

রেফারেন্স

নিবন্ধে পাওয়া বৈধ লিঙ্ক, যার উপর ভিত্তি করে, প্রতিবেদনে ছিল.

লেখক আরো লিখুন
https://dataegret.com/news-blog (ইঞ্জি.)

পরিসংখ্যান সংগ্রাহক
https://www.postgresql.org/docs/current/monitoring-stats.html

সিস্টেম অ্যাডমিনিস্ট্রেশন ফাংশন
https://www.postgresql.org/docs/current/functions-admin.html

মডিউল অবদান
https://www.postgresql.org/docs/current/pgstatstatements.html
https://www.postgresql.org/docs/current/pgstattuple.html
https://www.postgresql.org/docs/current/pgbuffercache.html
https://github.com/klando/pgfincore
https://github.com/dalibo/pg_stat_kcache

এসকিউএল ইউটিলিটি এবং এসকিউএল কোড উদাহরণ
https://github.com/dataegret/pg-utils

আপনার মনোযোগের জন্য আপনাকে ধন্যবাদ!

উত্স: www.habr.com