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

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

چرا به قابلیت مشاهده نیاز داریم؟

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

یکی از چیزهایی که ما با آن شروع می کنیم، ثبت پرس و جوها است. ما می‌خواهیم جزئیات دستور SQL، معیارهای مربوط به زمان اجرا و حافظه مصرف‌شده و آمار جداول مورد استفاده را ثبت کنیم. متأسفانه، بسیاری از تنظیمات پیش‌فرض در سیستم‌های پایگاه داده ما منجر به گم شدن اطلاعاتی می‌شوند که برای اشکال‌زدایی بسیار مهم هستند. یکی از این بخش ها جزئیات پرس و جوهایی است که کند هستند و محتمل ترین دلایل این مسائل هستند.

گزارش آهسته پرس و جو چیست؟

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

طرح اجرا توضیح می دهد که موتور پایگاه داده هنگام اجرای پرس و جو چه کاری انجام می دهد. این می‌تواند شامل عملیات‌های زیادی مانند پیوستن به بسیاری از جداول، استفاده از فهرست‌ها، مرتب‌سازی داده‌ها یا ذخیره موقت آن در دیسک باشد. چنین طرحی تمام جزئیات را ارائه می دهد، با این حال، این طرح ها ممکن است فضای زیادی را اشغال کنند. بنابراین، ما آنها را برای هر پرس و جو ذخیره نمی کنیم، زیرا احتمالاً اکثر پرس و جوها سریع هستند و نیازی به بررسی ندارند.

گزارش کند پرس و جو مکانیزمی برای ثبت جزئیات پرس و جوهایی است که اجرای آنها بیش از حد طولانی است. این به بررسی کمک می کند زیرا ما جزئیات را در لحظه ای که پرس و جو اجرا می شود ضبط می کنیم. گزارش کند پرس و جو می تواند برای شناسایی تنگناهای عملکرد و بهینه سازی پرس و جوهای کند برای بهبود عملکرد کلی پایگاه داده PostgreSQL شما مفید باشد.

خواندن توصیه می شود: 8 استراتژی اثبات شده برای بهبود عملکرد پایگاه داده

چگونه Log Query Slow را پیکربندی کنیم؟

برای فعال کردن ثبت درخواست کند در PostgreSQL، باید چند پارامتر را تنظیم کنیم. بیایید آنها را یکی یکی ببینیم.

ابتدا باید ورود به سیستم را با:

log_statement = 'all'

این به PostgreSQL دستور می دهد تا تمام عبارات صحیح نحوی را ثبت کند. گزینه های دیگر هستند none (هیچ چیز را وارد نکنید)، ddl (فقط پرس و جوهای زبان تعریف داده را وارد کنید، به عنوان مثال، پرس و جوهایی که طرحواره را تغییر می دهند)، mod (پرس و جوهای DDL و پرس و جوهایی که داده ها را تغییر می دهند، اما مواردی مانند این را ندارند VACUUM).

همچنین شایان ذکر است که log_statement چیزهای نادرست نحوی را ثبت نخواهد کرد. ما باید استفاده کنیم log_min_error_statement برای انجام آن. همچنین، log_statement ممکن است اطلاعات محرمانه را ثبت کند.

پارامتر دیگری طول مدت تمام عبارات تکمیل شده را ثبت می کند:

log_duration = on

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

log_min_duration_statement = 100ms

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

پس از انجام این تغییرات، شما باید PostgreSQL را مجددا راه اندازی کنید برای اعمال پیکربندی

پارامترهای اضافی وجود دارد که می توانید پیکربندی کنید. برای مثال:

log_destination = 'csvlog'

باعث ورود به یک فایل CSV می شود. ممکن است بخواهید با استفاده از فرمت های مختلف فایل وارد شوید.

log_filename = 'postgresql.log.%Y-%m-%d-%H'

نام فایل log را پیکربندی می کند. این کار پردازش گزارش‌ها را به صورت خودکار آسان‌تر می‌کند.

log_rotation_age = 60

باعث ایجاد یک فایل لاگ جدید در هر شصت دقیقه می شود.

compute_query_id = 'on'

محاسبات درون هسته ای شناسه پرس و جو را فعال می کند. ما می توانیم از این شناسه برای یافتن پرس و جوهای یکسان به بهترین شکل استفاده کنیم. این کار با PostgreSQL 13 شروع می شود.

هنگامی که کوئری ها را ثبت می کنیم، باید برنامه های اجرایی آنها را دریافت کنیم. برای آن می توانیم از pg_store_plans استفاده کنیم.

pg_store_plans.plan_format = 'json'

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

pg_store_plans.max_plan_length = 1048576

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

ما همچنین می توانیم آنچه را که دقیقاً ثبت شده است پیکربندی کنیم:

pg_store_plans.log_buffers = true
pg_store_plans.log_analyze = true
pg_store_plans.log_buffers = true
pg_store_plans.log_timing = true

این باید جزئیات کافی از آنچه اتفاق افتاده را به شما بدهد.

در مورد پایگاه های داده زودگذر؟

اگر پایگاه داده شما برای مدت طولانی زنده باشد، پیکربندی PostgreSQL ساده است. این معمولاً زمانی اتفاق می‌افتد که پایگاه داده خود را در فضای ابری (یا به طور کلی به عنوان یک پایگاه داده میزبانی شده) میزبانی می‌کنید، یا اگر آن را در یک ظرف Docker اجرا می‌کنید که به عنوان یک سرویس در حال اجرا است.

با این حال، اگر PostgreSQL را فقط برای یک دوره بسیار کوتاه اجرا می کنید، به عنوان مثال در طول تست های خودکار خود، ممکن است هیچ راه فنی برای پیکربندی مجدد آن نداشته باشید. این ممکن است در مورد Testcontainers صدق کند. به طور معمول، ممکن است برخی از کدهای اولیه را درست قبل از مجموعه آزمایشی واقعی خود اجرا کنید تا وابستگی هایی مانند شبیه سازهای ذخیره سازی یا سرورهای پایگاه داده را راه اندازی کنید. Testcontainers از اجرای آنها به عنوان کانتینرهای Docker مراقبت می کند. با این حال، هیچ راه ساده ای برای راه اندازی مجدد کانتینر وجود ندارد. در برخی از زبان‌ها، ممکن است یک API واقعی داشته باشید که به خوبی از عهده این کار بر می‌آید.

یک استراتژی پایگاه داده زودگذر اجازه می دهد تا داده های با توان عملیاتی بالا و اغلب در حال تغییر را از پایگاه داده اصلی جدا کند تا کارایی را افزایش دهد و خطرات عملیاتی را کاهش دهد. این رویکرد به مسائلی مانند هزینه های پرس و جو و فشار سیستم می پردازد، با DB زودگذر که داده های یکبار مصرف را در خود نگه می دارد، در نتیجه ثبات و عملکرد سیستم را تضمین می کند.

اگر PostgreSQL خود را برای آزمایش ها به عنوان یک سرویس در GitHub Actions میزبانی کنید، ممکن است مشکلات مشابهی رخ دهد. شما نمی توانید به راحتی کانتینرها را کنترل کنید و پس از اعمال تغییرات پیکربندی، آنها را مجددا راه اندازی کنید.

راه حل این است که از یک تصویر Docker سفارشی استفاده کنید. فقط تصویر خود را با فایل پیکربندی که ثبت درخواست کند را فعال می کند آماده کنید. سپس می توانید فقط یک بار کانتینر را اجرا کنید و پیکربندی مطابق انتظار خواهد بود.

خلاصه

گزارش آهسته پرس و جو قابلیتی است که به شما امکان می دهد پرس و جوهایی را ثبت کنید که اجرای آنها بیش از یک آستانه مشخص شده طول می کشد. این می تواند به طور قابل توجهی بررسی پرس و جوهای کند را آسان کند زیرا تمام جزئیات مهم پرس و جوها از قبل در دسترس هستند.