حل مشکلات فضای ذخیره سازی در AWS RDS Postgres

Summarize this content to 400 words in Persian Lang
به عنوان یک مهندس devops، حفظ عملکرد بهینه پایگاه داده بسیار مهم است. اخیراً با یک مشکل دائمی در مورد Postgres RDS خود مواجه شدیم: فضای ذخیره سازی رایگان به سرعت در حال کاهش بود و یافتن علت اصلی کار ساده ای نبود. این پست به تشریح روند بررسی، مسیرهایی که کاوش کردیم، و اینکه چگونه در نهایت مشکل را حل کردیم، توضیح می‌دهد.

1. فایل های موقت

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

SELECT datname, temp_files AS “Temporary files”, temp_bytes AS “Size of temporary files”
FROM pg_stat_database;

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

با این حال، در مورد ما، این در اوایل رد شد زیرا پیکربندی ما از یک تصویر بهینه سازی شده برای ذخیره سازی استفاده می کند. فایل‌های موقت در ذخیره‌سازی EBS DB نوشته نمی‌شوند، بلکه در حافظه محلی نوشته می‌شوند، بنابراین به مشکل فضای ذخیره‌سازی پایگاه داده کمکی نمی‌کنند.

2. تاپل های مرده

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

SELECT relname, n_dead_tup
FROM pg_stat_all_tables
ORDER BY n_dead_tup DESC
LIMIT 10;

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

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

3. فایل های یتیم

ما همچنین فایل‌های یتیم را بررسی کردیم، که اگر فایل‌ها در فهرست پایگاه داده باقی بمانند بدون اینکه اشیاء مربوطه به آنها اشاره کنند، ممکن است رخ دهد. اگر ذخیره‌سازی نمونه تمام شود یا موتور در طول عملیات‌هایی مانند ALTER TABLE، VACUUM FULL یا CLUSTER خراب شود، ممکن است این وضعیت رخ دهد. برای بررسی فایل های یتیم، اندازه پایگاه داده اشغال شده توسط فایل ها را با اندازه واقعی بازیابی شده با جمع اشیاء مقایسه کردیم:

— Size of the database occupied by files
SELECT pg_size_pretty(pg_database_size(‘DATABASE_NAME’));

— Size of database retrieved by summing the objects (real size)
SELECT pg_size_pretty(SUM(pg_relation_size(oid)))
FROM pg_class;

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

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

4. شکاف های تکرار

شکاف های تکرار یکی دیگر از دلایل متداول نفخ ذخیره سازی به دلیل انباشته شدن WAL (Write Ahead Logs) در صورت عدم مصرف صحیح است. با این حال، پس از بررسی، تأیید کردیم که از Replication استفاده نمی‌شود، و هیچ شکاف تکراری در نمونه ما فعال نیست.

5. Log Files

پیشرفت زمانی حاصل شد که ما فایل‌های گزارش را بررسی کردیم. ما متوجه شدیم که فایل های گزارش ما فضای زیادی را مصرف می کنند:

اندازه‌های گزارش در سه روز گذشته شامل فایل‌های 20، 18، 10 و 8 گیگابایتی بود.

پیکربندی گزارش‌گیری ما روی جستارهایی تنظیم شده بود که حداقل 1 ثانیه اجرا می‌شدند، از جمله پارامترهای bind آنها. این منجر به ورودی‌های ثبت بسیار بزرگ شد، به‌ویژه زمانی که پرس‌و‌جوهای پیچیده با پارامترهای گسترده به طور مکرر اجرا می‌شدند.

راه حل

برای حل مشکل ذخیره سازی، تنظیمات زیر را انجام دادیم:

افزایش حداقل زمان اجرا برای ورود به سیستم (log_min_duration_statement): حداقل زمان اجرا برای ثبت درخواست‌ها را از 1 ثانیه به 5 ثانیه تغییر دادیم. این امر تعداد پرس و جوهای ثبت شده را به میزان قابل توجهی کاهش داد و بر پرس و جوهای طولانی مدت و بالقوه تأثیرگذارتر تمرکز کرد.
سیاست حفظ گزارش تنظیم شده (rds.log_retention_period): مدت زمان نگهداری فایل های گزارش را از 3 روز پیش فرض به تنها 1 روز کاهش دادیم. این تغییر بلافاصله به آزادسازی فضای ذخیره سازی با کاهش حجم داده های گزارش حفظ شده کمک کرد.

همچنین قابل ذکر است log_parameter_max_length پارامتری که می تواند پارامتر bind ثبت شده را محدود کند.

این تغییرات منجر به کاهش قابل توجهی در اندازه فایل های گزارش شده و در نتیجه فضای ذخیره سازی را آزاد کرده و از مصرف سریع بیشتر جلوگیری می کند.

نتیجه گیری

هنگامی که با مشکلات فضای ذخیره سازی در PostgreSQL RDS مواجه می شوید، بررسی سیستماتیک تمام منابع ممکن مصرف ذخیره سازی بسیار مهم است. در مورد ما، گزارش‌ها به‌طور غیرمنتظره‌ای بزرگ بودند، اما یک تنظیم استراتژیک برای پارامترهای گزارش و خط‌مشی‌های نگهداری به ما کمک کرد فضای ذخیره‌سازی ارزشمند را بازیابی کنیم.

SELECT datname, temp_files AS "Temporary files", temp_bytes AS "Size of temporary files" 
FROM pg_stat_database;

SELECT relname, n_dead_tup 
FROM pg_stat_all_tables 
ORDER BY n_dead_tup DESC 
LIMIT 10;

-- Size of the database occupied by files
SELECT pg_size_pretty(pg_database_size('DATABASE_NAME'));

-- Size of database retrieved by summing the objects (real size)
SELECT pg_size_pretty(SUM(pg_relation_size(oid))) 
FROM pg_class;