سنتز به عنوان یکی از روش های بهبود عملکرد PostgreSQL

مقدمه فلسفی

همانطور که می دانید، تنها دو روش برای حل مشکلات وجود دارد:

1. روش تحلیل یا روش کسر یا از عام به خاص.
2. روش سنتز یا روش استقراء یا از خاص به عام.

برای حل مشکل "بهبود عملکرد پایگاه داده"، ممکن است به این شکل باشد.

تحلیل - ما مسئله را به بخش های جداگانه تجزیه و تحلیل می کنیم و با حل آنها سعی می کنیم عملکرد پایگاه داده را به عنوان یک کل بهبود دهیم.

در عمل، تجزیه و تحلیل چیزی شبیه به این است:

• یک مشکل رخ می دهد (حادثه عملکرد)
• جمع آوری اطلاعات آماری در مورد وضعیت پایگاه داده
• به دنبال تنگناها هستند
• ما مشکلات را از تنگناها حل می کنیم

تنگناهای پایگاه داده - زیرساخت (CPU، حافظه، دیسک‌ها، شبکه، سیستم عامل)، تنظیمات (postgresql.conf)، پرسش‌ها:

شالوده: امکان نفوذ و تغییر برای یک مهندس تقریباً صفر است.

تنظیمات پایگاه داده: احتمال تغییرات کمی بیشتر از مورد قبلی است، اما به عنوان یک قاعده هنوز بسیار دشوار است، به خصوص در ابرها.

درخواست ها به پایگاه داده: تنها جا برای مانور.

سنتز - ما عملکرد بخش‌های جداگانه را بهبود می‌بخشیم، انتظار داریم که عملکرد پایگاه داده در نتیجه بهبود یابد.

مقدمه غزلی یا چرا همه اینها ضروری است

اگر عملکرد پایگاه داده نظارت نشود، فرآیند حل و فصل حوادث عملکرد چیست:

مشتری - "همه چیز با ما بد است، خیلی طول می کشد، یک کار خوب برای ما انجام دهید"
مهندس - "این چقدر بد است؟"
مشتری - "الان همینطور است (یک ساعت پیش، دیروز، آخرین باری که بود)، آرام آرام"
مهندس - "کی خوب بود؟"
مشتری - "یک هفته (دو هفته) پیش بد نبود. "(خوش شانس است)
مشتری - "یادم نیست چه زمانی خوب بود، اما اکنون بد است" (پاسخ منظم)

نتیجه یک تصویر کلاسیک است:

چه کسی سرزنش می کند و چه کاری باید انجام دهد؟

پاسخ بخش اول سوال ساده ترین است - مهندس DBA همیشه مقصر است.

پاسخ بخش دوم نیز چندان دشوار نیست - شما باید یک سیستم نظارت بر عملکرد پایگاه داده را پیاده سازی کنید.

اولین سوال مطرح می شود - چه چیزی را نظارت کنیم؟

مسیر 1. ما همه چیز را نظارت خواهیم کرد

بار CPU، تعداد عملیات خواندن/نوشتن دیسک، اندازه حافظه اختصاص داده شده، و یک مگاتون دیگر از شمارنده های مختلف که هر سیستم نظارتی کم و بیش فعال می تواند ارائه دهد.

نتیجه مجموعه ای از نمودارها، جداول خلاصه و اعلان های ایمیل مداوم و مهندس 100٪ مشغول حل یک سری بلیط های یکسان است، با این حال، به عنوان یک قاعده، با عبارت استاندارد - "مشکل موقت. اقدامی لازم نیست." اما همه مشغول هستند و همیشه چیزی برای نشان دادن به مشتری وجود دارد - کار در نوسان کامل است.

راه 2. فقط موارد مورد نیاز را نظارت کنید و آنچه لازم نیست نیازی به نظارت ندارد

شما می توانید، کمی متفاوت، فقط نهادها و رویدادها را نظارت کنید:

• کدام مهندس DBA می تواند بر آن تأثیر بگذارد
• زمانی که یک رویداد رخ می دهد یا یک موجودیت تغییر می کند، الگوریتمی از اقدامات وجود دارد.

بر اساس این فرض و یادآوری "مقدمه فلسفی"برای جلوگیری از تکرار منظم"مقدمه غزلی یا چرا همه اینها ضروری استتوصیه می‌شود برای بهینه‌سازی و تجزیه و تحلیل، عملکرد پرس‌و‌جوهای فردی نظارت شود، که در نهایت باید به بهبود عملکرد کل پایگاه داده منجر شود.

اما به منظور بهبود یک پرس و جو سنگین که بر عملکرد کلی پایگاه داده تأثیر می گذارد، ابتدا باید آن را پیدا کنید.

بنابراین، دو سؤال مرتبط با هم مطرح می شود:

• که درخواست سخت تلقی می شود
• نحوه جستجوی پرس و جوهای دشوار

بدیهی است که پرس و جوی سنگین، پرس و جوی است که از منابع سیستم عامل زیادی برای به دست آوردن نتیجه استفاده می کند.

بیایید به سؤال دوم برویم - چگونه جستجو و سپس پرس و جوهای سنگین را نظارت کنیم؟

PostgreSQL چه قابلیت های نظارت بر پرس و جو دارد؟

در مقایسه با اوراکل، امکانات کمی وجود دارد، اما هنوز هم می توان کاری انجام داد.

PG_STAT_STATEMENTS

برای جستجو و نظارت بر پرس و جوهای سنگین در PostgreSQL، پسوند استاندارد pg_stat_statements در نظر گرفته شده است.

پس از نصب افزونه، نمایی به همین نام در پایگاه داده هدف ظاهر می شود که باید برای اهداف نظارتی استفاده شود.

ستون های pg_stat_statements را برای ساختن یک سیستم نظارتی هدف قرار دهید:

• پرس و جو کد هش داخلی از درخت تجزیه اپراتور محاسبه شده است
• max_time حداکثر زمان صرف شده برای بیانیه، بر حسب میلی ثانیه

با جمع آوری و استفاده از آمار روی این دو ستون می توانید یک سیستم نظارتی بسازید.

نحوه استفاده از pg_stat_statements برای نظارت بر عملکرد PostgreSQL

برای نظارت بر عملکرد پرس و جو استفاده کنید:
در سمت پایگاه داده هدف - نمای pg_stat_statements
از طرف سرور و پایگاه‌های داده نظارتی - مجموعه‌ای از اسکریپت‌های bash و جداول سرویس.

مرحله 1 - جمع آوری داده های آماری

در میزبان مانیتورینگ cron، اسکریپتی به طور منظم راه اندازی می شود که محتویات نمای pg_stat_statements را از پایگاه داده هدف به جدول pg_stat_history در پایگاه داده نظارت کپی می کند.

این یک تاریخچه از اجرای پرس و جوهای فردی ایجاد می کند که می تواند برای تولید گزارش های عملکرد و پیکربندی معیارها استفاده شود.

مرحله 2 - تنظیم معیارهای عملکرد

بر اساس داده‌های جمع‌آوری‌شده، کوئری‌هایی را انتخاب می‌کنیم که اجرای آنها برای مشتری (برنامه) حیاتی/مهم‌تر است. در توافق با مشتری، مقادیر معیارهای عملکرد را با استفاده از فیلدهای queryid و max_time تنظیم می کنیم.

نتیجه - شروع نظارت بر عملکرد

1. اسکریپت نظارت، هنگام اجرا، معیارهای عملکرد پیکربندی شده را با مقایسه مقدار max_time متریک با مقدار نمای pg_stat_statements در پایگاه داده هدف بررسی می کند.
2. اگر مقدار در پایگاه داده هدف از مقدار متریک بیشتر شود، یک هشدار ایجاد می شود (یک حادثه در سیستم بلیط)

گزینه اضافی 1

تاریخچه طرح پرس و جو

برای حل بعدی رویدادهای عملکرد، داشتن سابقه تغییر برنامه های اجرای پرس و جو بسیار خوب است.

جدول سرویس log_query برای ذخیره تاریخ استفاده می شود. جدول هنگام تجزیه و تحلیل فایل گزارش بارگذاری شده PostgreSQL پر می شود. از آنجایی که فایل log، برخلاف نمای pg_stat_statements، حاوی متن کامل با مقادیر پارامترهای اجرا و متن عادی نیست، می‌توان نه تنها زمان و مدت درخواست‌ها را ثبت کرد، بلکه برنامه‌های اجرایی را نیز در زمان جاری ذخیره کرد. زمان.

گزینه اضافی 2

فرآیند بهبود مستمر عملکرد

نظارت بر پرس و جوهای منفرد به طور کلی برای حل مشکل بهبود مستمر عملکرد پایگاه داده به عنوان یک کل در نظر گرفته نشده است، زیرا مشکلات عملکرد را فقط برای پرس و جوهای فردی کنترل و حل می کند. با این حال، می توانید روش را گسترش دهید و پرس و جوهای نظارتی را برای همه پایگاه های داده پیکربندی کنید.

برای انجام این کار، باید معیارهای عملکرد اضافی را وارد کنید:

• برای روزهای آخر
• برای دوره پایه

اسکریپت پرس و جوها را از نمای pg_stat_statements در پایگاه داده هدف انتخاب می کند و مقدار max_time را با میانگین مقدار max_time مقایسه می کند، در حالت اول برای روزهای آخر یا برای دوره زمانی انتخاب شده (پایه)، در حالت دوم.

بنابراین، در صورت کاهش عملکرد برای هر درخواست، یک هشدار به صورت خودکار و بدون تجزیه و تحلیل دستی گزارش ها ایجاد می شود.

سنتز چه ربطی به آن دارد؟

در رویکرد توصیف شده، همانطور که روش سنتز نشان می دهد، با بهبود بخش های جداگانه سیستم، سیستم را به عنوان یک کل بهبود می دهیم.

• پرس و جو توسط پایگاه داده - چکیده اجرا شده است
• درخواست اصلاح شده - آنتی تز
• تغییر وضعیت سیستم - سنتز

توسعه سیستم

• برنامه های افزودنی آمار جمع آوری شده با افزودن تاریخچه برای نمای سیستم pg_stat_activity
• گسترش آمار جمع‌آوری‌شده با افزودن تاریخچه برای آمار جداول فردی شرکت‌کننده در پرس‌و‌جوها
• ادغام با سیستم مانیتورینگ ابری AWS
• و با این حال، شما می توانید به چیزی برسید ...

منبع: www.habr.com