معاملات بدون هدف و برنامه ریزی

بانکهای اطلاعاتی PostgreSQL نیاز به نگهداری دوره ای دارند که به عنوان جاروبرقی شناخته می شوند. برای بسیاری از تاسیسات ، کافی است که اجازه دهید جاروبرقی توسط Daemon Autovacuum انجام شود ، که در بخش 25. 1. 6 شرح داده شده است. برای به دست آوردن بهترین نتایج برای وضعیت خود ، ممکن است لازم باشد پارامترهای autovacuuming را که در آنجا شرح داده شده است تنظیم کنید. برخی از مدیران پایگاه داده می خواهند فعالیت های Daemon را با دستورات خلاء دستی که به صورت دستی انجام می شود ، تکمیل یا جایگزین کنند ، که به طور معمول مطابق برنامه توسط CRON یا SCRIPTS Task Scheduler اجرا می شوند. برای تنظیم صحیح خلاء دستی ، درک موضوعات مورد بحث در چند بخش بعدی ضروری است. مدیرانی که به Autovacuuming تکیه می کنند ممکن است هنوز هم بخواهند این ماده را کم کنند تا به آنها در درک و تنظیم اتوآکومیت کمک کند.

25. 1. 1. اصول اولیه

دستور خلاء PostgreSQL باید به دلایل مختلف هر جدول را بطور منظم پردازش کند:

1. برای بازیابی یا استفاده مجدد از فضای دیسک اشغال شده توسط ردیف های به روز شده یا حذف شده.
2. برای به روزرسانی آمار داده های مورد استفاده توسط برنامه ریز پرس و جو PostgreSQL.
3. برای به روزرسانی نقشه دید ، که اسکن های فقط شاخص را سرعت می بخشد.
4. برای محافظت در برابر از دست دادن داده های بسیار قدیمی به دلیل بسته بندی شناسه معامله یا بسته بندی شناسه چند منظوره.

هر یک از این دلایل نشان می دهد که عملیات خلاء با فرکانس و دامنه مختلف را نشان می دهد ، همانطور که در زیر بخش های زیر توضیح داده شده است.

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

خلاء مقدار قابل توجهی از ترافیک I/O ایجاد می کند که می تواند برای سایر جلسات فعال عملکرد ضعیفی ایجاد کند. پارامترهای پیکربندی وجود دارد که می توانند برای کاهش تأثیر عملکرد خلاء پس زمینه تنظیم شوند - به بخش 20. 4. 4 مراجعه کنید.

25. 1. 2. بازیابی فضای دیسک

در PostgreSQL ، یک به روزرسانی یا حذف یک ردیف بلافاصله نسخه قدیمی ردیف را حذف نمی کند. این رویکرد برای به دست آوردن مزایای کنترل همزمانی چندگانه ضروری است (MVCC ، به فصل 13 مراجعه کنید): نسخه ردیف نباید حذف شود در حالی که هنوز هم برای سایر معاملات قابل مشاهده است. اما سرانجام ، یک نسخه ردیف منسوخ یا حذف شده دیگر مورد توجه هیچ معامله ای نیست. فضایی که اشغال می کند باید برای استفاده مجدد توسط ردیف های جدید پس گرفته شود تا از رشد بی حد و حصر نیازهای فضای دیسک جلوگیری شود. این کار با اجرای خلاء انجام می شود.

شکل استاندارد خلاء نسخه های Dead Row را در جداول و شاخص ها حذف می کند و فضای موجود برای استفاده مجدد در آینده را نشان می دهد. با این حال ، این فضای را به سیستم عامل بر نمی گرداند ، مگر در مورد ویژه ای که یک یا چند صفحه در انتهای یک جدول کاملاً آزاد می شود و می توان یک قفل جدول اختصاصی را به راحتی بدست آورد. در مقابل ، خلاء با نوشتن یک نسخه کامل از پرونده جدول بدون فضای مرده ، جداول را به طور فعال جمع می کند. این اندازه جدول را به حداقل می رساند ، اما می تواند مدت زمان زیادی طول بکشد. همچنین برای کپی جدید جدول ، به فضای دیسک اضافی نیاز دارد ، تا زمانی که عملیات کامل شود.

هدف معمول جاروبرقی معمول انجام خلاء استاندارد است که اغلب به اندازه کافی برای جلوگیری از نیاز به خلاء به اندازه کافی است. Daemon Autovacuum سعی در این روش دارد و در واقع هرگز خلاء کامل نخواهد بود. در این رویکرد ، ایده این نیست که جداول را در حداقل اندازه خود نگه دارید ، بلکه برای حفظ استفاده از حالت پایدار از فضای دیسک: هر جدول فضای معادل حداقل اندازه خود را اشغال می کند به علاوه هرچند فضای زیادی بین خلاء استفاده می شود. اگرچه می توان از خلاء پر برای کوچک کردن یک جدول به حداقل اندازه آن و بازگشت فضای دیسک به سیستم عامل استفاده کرد ، اگر جدول در آینده دوباره رشد کند ، نکته زیادی در این مورد وجود ندارد. بنابراین ، اجرای خلاء استاندارد نسبتاً وحشتناک یک رویکرد بهتر از عملکرد خلاء نادر برای حفظ جداول به روز شده است.

برخی از مدیران ترجیح می دهند خود را جاروبرقی کنند ، به عنوان مثال تمام کارها را در شب انجام می دهند که بار کم است. مشکل انجام جاروبرقی طبق یک برنامه ثابت این است که اگر یک جدول در فعالیت به روزرسانی سنبله غیر منتظره داشته باشد ، ممکن است تا جایی که خلاء کامل برای بازپس گیری فضا ضروری است ، نفخ شود. با استفاده از Daemon AutoVacuum این مشکل را کاهش می دهد ، زیرا Daemon در پاسخ به فعالیت به روزرسانی ، به صورت پویا جارو می کند. غیرفعال کردن Daemon به طور کامل غیر منطقی است ، مگر اینکه حجم کار بسیار قابل پیش بینی داشته باشید. یکی از سازش های احتمالی این است که پارامترهای Daemon را تنظیم کنید تا فقط به فعالیت بروزرسانی غیرمعمول واکنش نشان دهد ، بنابراین چیزها را از دست نمی دهد ، در حالی که انتظار می رود خلاء برنامه ریزی شده بخش عمده ای از کار را هنگام بار معمولی انجام دهد.

برای کسانی که از Autovacuum استفاده نمی کنند ، یک روش معمولی برای برنامه ریزی خلاء در پایگاه داده یک بار در روز در طی یک دوره کم مصرف ، که با جاروبرقی مکرر جداول به شدت به روز شده در صورت لزوم تکمیل می شود.(برخی از نصب ها با نرخ بروزرسانی بسیار بالا ، شلوغ ترین میزهای خود را هر چند وقت یک بار در هر چند دقیقه خلاء می کنند.) اگر چندین پایگاه داده در یک خوشه دارید ، فراموش نکنید که هر یک را خلاء کنید. برنامه vacuumdb ممکن است مفید باشد.

نکته

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

نکته

اگر یک جدول دارید که کل محتویات آن به صورت دوره ای حذف شده است ، به جای استفاده از Delete و به دنبال آن خلاء ، این کار را با Truncate انجام دهید. کوتاه کردن کل محتوای جدول را بلافاصله حذف می کند ، بدون اینکه نیاز به خلاء یا خلاء بعدی داشته باشید تا فضای دیسک دیسک فعلی را پس بگیریم. نقطه ضعف این است که معانی سختگیرانه MVCC نقض می شود.

25. 1. 3. به روزرسانی آمار برنامه ریز

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

Daemon AutoVacuum در صورت فعال بودن ، هر زمان که محتوای یک جدول به اندازه کافی تغییر کرده باشد ، به طور خودکار دستورات را تجزیه و تحلیل می کند. با این حال ، مدیران ممکن است ترجیح دهند به عملیات تجزیه و تحلیل دستی متکی باشند ، به ویژه اگر مشخص شود که فعالیت به روزرسانی در یک جدول بر آمار ستون های "جالب" تأثیر نمی گذارد. برنامه های Daemon به عنوان تابعی از تعداد ردیف های درج شده یا به روز شده ، کاملاً مورد تجزیه و تحلیل قرار می گیرند. هیچ آگاهی در مورد اینکه آیا این منجر به تغییرات آماری معنی دار خواهد شد ، ندارد.

Tuples در پارتیشن ها تغییر کرده و کودکان وراثت باعث تجزیه و تحلیل در جدول والدین نمی شوند. اگر جدول والدین خالی باشد یا به ندرت تغییر یابد ، ممکن است هرگز توسط Autovacuum پردازش نشود ، و آمار مربوط به درخت وراثت به طور کلی جمع آوری نمی شود. برای به روز نگه داشتن آمار ، می توان تجزیه و تحلیل را در جدول والدین انجام داد.

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

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

نکته

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

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

نکته

Daemon Autovacuum دستورات تجزیه و تحلیل برای جداول خارجی را صادر نمی کند ، زیرا هیچ وسیله ای برای تعیین چند بار ممکن است مفید باشد. اگر پرس و جوهای شما برای برنامه ریزی مناسب به آمار مربوط به جداول خارجی نیاز دارند ، ایده خوبی است که دستورات مورد نظر دستی را روی آن جداول در یک برنامه مناسب اجرا کنید.

نکته

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

25. 1. 4. به روزرسانی نقشه دید

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

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

25. 1. 5. جلوگیری از خرابی در شناسه معاملات معامله

معانی معاملات MVCC PostgreSQL به این بستگی دارد که بتوانید شماره شناسه معامله (XID) را مقایسه کنید: یک نسخه ردیف با درج XID بیشتر از XID معامله فعلی "در آینده" است و نباید برای معامله فعلی قابل مشاهده باشد. اما از آنجا که شناسه معاملات دارای اندازه محدود (32 بیت) خوشه ای است که برای مدت طولانی (بیش از 4 میلیارد معاملات) اجرا می شود (بیش از 4 میلیارد معاملات) برای بسته بندی شناسه معاملات دچار می شود: پیشخوان XID به صفر می رسد و همه معاملات ناگهانی که در آن وجود داردبه نظر می رسد گذشته در آینده است - این بدان معنی است که خروجی آنها نامرئی می شود. به طور خلاصه ، از دست دادن داده های فاجعه بار.(در واقع داده ها هنوز وجود دارد ، اما اگر نتوانید به آن برسید ، این راحتی سرد است.) برای جلوگیری از این امر ، لازم است هر جدول را در هر پایگاه داده حداقل یک بار در هر دو میلیارد معاملات خلاء کنید.

دلیل این که جاروبرقی دوره ای مشکل را حل می کند این است که خلاء ردیف ها را به عنوان یخ زده نشان می دهد ، نشان می دهد که آنها توسط معامله ای که در گذشته به اندازه کافی مرتکب شده است درج شده است که اثرات معامله درج می تواند برای همه معاملات فعلی و آینده قابل مشاهده باشدبشرXID های طبیعی با استفاده از حسابی Modulo-2 32 مقایسه می شوند. این بدان معناست که برای هر XID معمولی ، دو میلیارد XID وجود دارد که "بزرگتر" و دو میلیارد "جدیدتر" هستند. راه دیگر برای گفتن این است که فضای معمولی XID به صورت دایره ای و بدون نقطه پایانی است. بنابراین ، هنگامی که یک نسخه ردیف با یک XID معمولی خاص ایجاد شده است ، به نظر می رسد نسخه ردیف برای دو میلیارد معاملات بعدی "در گذشته" باشد ، مهم نیست که ما در مورد کدام XID معمولی صحبت می کنیم. اگر نسخه ردیف پس از بیش از دو میلیارد معاملات هنوز وجود داشته باشد ، ناگهان در آینده به نظر می رسد. برای جلوگیری از این امر ، PostgreSQL یک XID خاص ، FrozentransactionId را ذخیره می کند ، که از قوانین مقایسه XID عادی پیروی نمی کند و همیشه از هر XID معمولی قدیمی تر به حساب می آید. نسخه های ردیف منجمد طوری رفتار می شوند که گویی XID درج Frozentransactionid است ، به طوری که به نظر می رسد در گذشته "در گذشته" به کلیه معاملات عادی بدون در نظر گرفتن مسائل بسته بندی شده ، و بنابراین چنین نسخه های ردیف تا زمان حذف ، مهم نیست که چه مدت طول بکشد. است.

توجه داشته باشید

در نسخه های PostgreSQL قبل از 9. 4 ، انجماد با جایگزینی درج یک ردیف XID با FrozentransactionId ، که در ستون سیستم XMIN ردیف قابل مشاهده بود ، انجام شد. نسخه های جدیدتر فقط یک پرچم پرچم را تنظیم می کنند و XMIN اصلی ردیف را برای استفاده پزشکی قانونی احتمالی حفظ می کنند. با این حال ، ردیف هایی با XMIN برابر با FrozentransactionId (2) هنوز هم ممکن است در پایگاه داده های pg_upgrade 'd از نسخه های قبل از 9. 4 یافت شود.

همچنین ، کاتالوگ سیستم ممکن است حاوی ردیف هایی با XMIN برابر با bootstraptransactionid (1) باشد ، نشان می دهد که آنها در مرحله اول initDB درج شده اند. مانند FrozentransactionId ، این XID خاص به عنوان قدیمی تر از هر XID معمولی درمان می شود.

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

خلاء از نقشه دید برای تعیین اینکه صفحات یک جدول باید اسکن شود ، استفاده می کند. به طور معمول ، این صفحات را رد می کند که هیچ نسخه Dead Row ندارند حتی اگر این صفحات هنوز هم می توانند نسخه های ردیف با مقادیر XID قدیمی داشته باشند. بنابراین ، خلاء طبیعی همیشه هر نسخه ردیف قدیمی را در جدول یخ نمی زند. هنگامی که این اتفاق بیفتد ، خلاء در نهایت نیاز به انجام خلاء تهاجمی خواهد داشت ، که باعث می شود تمام مقادیر XID و MXID واجد شرایط واجد شرایط ، از جمله آنهایی که از صفحات قابل مشاهده اما کل یخ زده نیستند ، یخ بزند. در عمل بیشتر جداول نیاز به خلاء تهاجمی دوره ای دارند. در صورتی که خلاء این کار را انجام می دهد: در صورتی که تعداد معاملات که از آخرین اسکن گذشت ، بیشتر از vacuum_freeze_age منهای خلاء_FREEZE_MIN_AGE بیشتر است. تنظیم VACUUM_FREEZE_TABLE_AGE به 0 Vacuum را مجبور کنید تا همیشه از استراتژی تهاجمی خود استفاده کنید.

حداکثر زمانی که یک جدول می تواند از بین برود ، دو میلیارد معاملات منهای مقدار Vacuum_Freeze_Min_age در زمان آخرین خلاء تهاجمی است. اگر قرار باشد بیش از این بدون استفاده شود ، از دست دادن داده ها می تواند نتیجه بگیرد. برای اطمینان از این که این اتفاق نمی افتد ، Autovacuum در هر جدول که ممکن است حاوی ردیف های غیرقانونی با XID های قدیمی تر از سن مشخص شده توسط پارامتر پیکربندی AutoVacuum_Freeze_Max_age باشد ، فراخوانی می شود.(این اتفاق حتی اگر AutoVacuum غیرفعال باشد اتفاق می افتد.)

این بدان معنی است که اگر یک جدول در غیر این صورت خالی نشود ، AutoVacuum تقریباً یک بار در هر AUTOVACUUM_FREEZE_MAX_AGE MINUS MINUS VACUUM_FREEZE_MIN_AGE انجام می شود. برای جداول که به طور مرتب برای اهداف احیای فضا خالی می شوند ، این از اهمیت کمی برخوردار است. با این حال ، برای جداول استاتیک (از جمله جداول که درج دریافت می کنند ، اما به روزرسانی یا حذف نمی شوند) ، نیازی به خلاء برای احیای فضا نیست ، بنابراین می توان سعی در به حداکثر رساندن فاصله بین اتوآکرهای اجباری در جداول استاتیک بسیار بزرگ داشت. بدیهی است که می توان این کار را با افزایش autovacuum_freeze_max_age یا کاهش خلاء_freeze_min_age انجام داد.

حداکثر مؤثر برای vacuum_freeze_table_age 0. 95 * autovacuum_freeze_max_age ؛تنظیم بالاتر از آن به حداکثر می رسد. مقداری بالاتر از AutoVacuum_freeze_max_age معنی ندارد زیرا یک اتوواک ضد بسته بندی در آن نقطه به هر حال تحریک می شود و ضرب 0. 95 قبل از این اتفاق می افتد که یک اتاق تنفسی را برای اجرای خلاء دستی ایجاد کند. به عنوان یک قانون شست ، vacuum_freeze_table_age باید بر روی مقداری تا حدودی زیر autovacuum_freeze_max_age تنظیم شود ، و شکاف کافی به وجود می آورد به گونه ای که یک خلاء منظم یا یک اتوآکوم به طور منظم که توسط حذف طبیعی و فعالیت به روزرسانی ایجاد می شود ، در آن پنجره اجرا می شود. تنظیم بیش از حد آن می تواند منجر به اتوواکوهای ضد پیچ و تاب شود ، حتی اگر این جدول اخیراً برای بازپس گیری فضا تخلیه شده باشد ، در حالی که مقادیر پایین تر منجر به جاروبرقی مکرر تهاجمی می شوند.

تنها نقطه ضعف افزایش autovacuum_freeze_max_age (و vacuum_freeze_table_age همراه با آن) این است که زیر مجموعه های PG_XACT و PG_COMMIT_TS خوشه پایگاه داده فضای بیشتری را به خود اختصاص می دهند ، زیرا باید وضعیت تعهد را ذخیره کند و (اگر Track_Commit_TimeSt) TimeMamp Tramentams را فعال کند. AutoVacuum_freeze_max_age افق. وضعیت تعهد از دو بیت در هر معامله استفاده می کند ، بنابراین اگر autovacuum_freeze_max_age روی حداکثر مقدار مجاز آن دو میلیارد تنظیم شود ، انتظار می رود که pg_xact به حدود نیمی از گیگابایت و pg_commit_ts تا حدود 20 گیگابایت رشد کند. اگر این در مقایسه با اندازه کل پایگاه داده شما بی اهمیت است ، تنظیم autovacuum_freeze_max_age به حداکثر مقدار مجاز آن توصیه می شود. در غیر این صورت ، بسته به آنچه می خواهید برای ذخیره سازی PG_XACT و PG_COMMIT_TS اجازه دهید ، آن را تنظیم کنید..

یکی از ضررهای کاهش خلاء_freeze_min_age این است که ممکن است باعث خلاء کار بی فایده شود: یخ زدن یک ردیف در صورت اصلاح ردیف به زودی پس از آن ، اتلاف وقت است (باعث می شود XID جدید به دست بیاید). بنابراین تنظیمات باید به اندازه کافی بزرگ باشد که ردیف ها یخ زده نشوند تا زمانی که بعید به نظر برسند دیگر تغییر کنند.

برای ردیابی سن قدیمی ترین XID های ناخوشایند در یک پایگاه داده ، خلاء آمار XID را در جداول سیستم PG_CLASS و PG_DATABASE ذخیره می کند. به طور خاص ، ستون Relfrozenxid از یک ردیف PG_Class یک جدول حاوی قدیمی ترین XID باقیمانده در پایان جدیدترین خلاء است که با موفقیت Relfrozenxid (معمولاً جدیدترین خلاء تهاجمی). به طور مشابه ، ستون datfrozenxid از یک ردیف pg_database یک پایگاه داده یک محدوده پایین تر در XID های غیرروزن است که در آن پایگاه داده ظاهر می شود-این فقط حداقل مقادیر Relfrozenxid در هر جدول در پایگاه داده است. یک روش مناسب برای بررسی این اطلاعات ، اجرای نمایش داده شدگان مانند:

انتخاب C. Oid :: RegClass به عنوان Table_Name ، بزرگترین (سن (c. relfrozenxid) ، سن (T. Relfrozenxid)) به عنوان سن از PG_Class C سمت چپ به pg_class t در c. reltoastrelid = t. oid که در آن c. relkind in ('r '،' m ') ؛Datname ، Age (datfrozenxid) را از pg_database انتخاب کنید.

ستون سنی تعداد معاملات را از XID قطع به XID معامله فعلی اندازه گیری می کند.

نکته

هنگامی که پارامتر Verbose فرمان خلاء مشخص شده است ، خلاء آمار مختلفی را در مورد جدول چاپ می کند. این شامل اطلاعاتی در مورد چگونگی پیشرفت Relfrozenxid و RelminMxid است. هنگامی که Autovacuum Logging (کنترل شده توسط log_autovacuum_min_duration) در مورد یک عمل خلاء که توسط AutoVacuum انجام شده است ، در ورود به سیستم سرور نیز ظاهر می شود.

خلاء به طور معمول فقط صفحاتی را که از آخرین خلاء اصلاح شده اند ، اسکن می کند ، اما Relfrozenxid تنها در صورتی قابل پیشروی است که هر صفحه از جدول که ممکن است حاوی XID های بی فایده باشد اسکن می شود. این اتفاق می افتد که Relfrozenxid بیش از معاملات Vacuum_Freeze_Table_age قدیمی باشد ، هنگامی که از گزینه یخ خلاء استفاده می شود ، یا وقتی همه صفحات که قبلاً تمام یخ زده نیستند ، برای حذف نسخه های ردیف مرده نیاز به خلاء دارند. هنگامی که خلاء هر صفحه ای را که در حال حاضر کاملاً یخ زده نیست ، اسکن می کند ، باید سن (Relfrozenxid) را فقط کمی بیشتر از تنظیمات Vacuum_Freeze_Min_age که مورد استفاده قرار گرفته است ، تعیین کند (بیشتر با تعداد معاملات از زمان شروع خلاء شروع شده است)بشرخلاء Relfrozenxid را به قدیمی ترین XID که در جدول باقی مانده است ، قرار می دهد ، بنابراین ممکن است که مقدار نهایی بسیار جدیدتر از آنچه که مورد نیاز است ، باشد. اگر تا زمانی که AutoVacuum_freeze_max_age به دست نیامده ، به زودی روی میز صادر نمی شود ، به زودی یک اتوآکوم به داخل جدول مجبور می شود.

اگر به دلایلی AutoVacuum نتواند XID های قدیمی را از یک جدول پاک کند ، سیستم شروع به انتشار پیام های هشدار دهنده مانند این می کند وقتی قدیمی ترین XID های پایگاه داده به چهل میلیون معاملات از نقطه بسته بندی می رسند:

هشدار: پایگاه داده "MYDB" باید در 39985967 معاملات مورد توجه قرار گیرد: برای جلوگیری از خاموش شدن پایگاه داده ، یک خلاء گسترده پایگاه داده را در آن بانک اطلاعاتی اجرا کنید.

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

خطا: پایگاه داده برای جلوگیری از از دست دادن داده های بسته بندی در پایگاه داده "MyDB" ، دستوراتی را قبول نمی کند: Postmaster و خلاء آن پایگاه داده را در حالت تک کاربر متوقف کنید.

حاشیه ایمنی سه میلیون نفری حرکت وجود دارد تا با اجرای دستی دستورات خلاء مورد نیاز ، مدیر بدون از دست دادن داده بهبود یابد. با این حال ، از آنجا که سیستم پس از ورود به حالت خاموش کردن ایمنی ، دستورات را اجرا نمی کند ، تنها راه انجام این کار متوقف کردن سرور و شروع سرور در حالت تک کاربر برای اجرای خلاء است. حالت خاموش کردن در حالت تک کاربر اجرا نمی شود. برای جزئیات بیشتر در مورد استفاده از حالت تک کاربر ، به صفحه مرجع Postgres مراجعه کنید.

25. 1. 5. 1. چند تازگی و بسته بندی

از شناسه های چند منظوره برای پشتیبانی از قفل ردیف توسط چندین معاملات استفاده می شود. از آنجا که فقط فضای محدودی در یک هدر Tuple برای ذخیره اطلاعات قفل وجود دارد ، این اطلاعات به عنوان "شناسه معامله چندگانه" یا شناسه چند منظوره برای کوتاه مدت رمزگذاری می شود ، هر زمان که بیش از یک معامله به طور همزمان وجود داشته باشد که یک ردیف را قفل کند. اطلاعاتی که در مورد شناسه های معامله در هر شناسه چند منظوره خاص گنجانده شده است ، به طور جداگانه در زیر مجموعه PG_Multixact ذخیره می شود ، و فقط شناسه multixact در قسمت XMAX در عنوان Tuple ظاهر می شود. مانند شناسه های معامله ، شناسه های چند منظوره به عنوان یک پیشخوان 32 بیتی و ذخیره سازی مربوطه اجرا می شوند ، که همه آنها نیاز به مدیریت دقیق پیری ، پاکسازی ذخیره سازی و دست زدن به بسته بندی دارند. یک منطقه ذخیره سازی جداگانه وجود دارد که لیست اعضا را در هر چند تیزهوشی نگه می دارد ، که از یک پیشخوان 32 بیتی نیز استفاده می کند و همچنین باید مدیریت شود.

هرگاه VACUUM قسمتی از جدول را اسکن می کند، هر شناسه چندگانه ای را که با آن مواجه می شود و قدیمی تر از vacuum_multixact_freeze_min_age است، با مقدار متفاوتی جایگزین می کند، که می تواند مقدار صفر، شناسه تراکنش منفرد یا شناسه چندگانه جدیدتر باشد. برای هر جدول، pg_class. relminmxid قدیمی ترین شناسه چند دقیق ممکن را که هنوز در هر یک از این جدول ظاهر می شود ذخیره می کند. اگر این مقدار قدیمی تر از vacuum_multixact_freeze_table_age باشد، یک خلاء تهاجمی ایجاد می شود. همانطور که در بخش قبل بحث شد، خلاء تهاجمی به این معنی است که فقط آن دسته از صفحاتی که کاملا منجمد شناخته شده اند رد می شوند. mxid_age() را می توان در pg_class استفاده کرد. relminmxid برای پیدا کردن سن خود.

VACUUM های تهاجمی، صرف نظر از علت ایجاد آنها، تضمین می شود که می توانند relminmxid جدول را پیش ببرند. در نهایت، از آنجایی که همه جداول در همه پایگاه های داده اسکن می شوند و قدیمی ترین مقادیر multixact آن ها پیشرفته است، ذخیره سازی روی دیسک برای Multixactهای قدیمی تر می تواند حذف شود.

به عنوان یک وسیله ایمنی، یک اسکن خلاء تهاجمی برای هر جدولی که سن چند دقیق آن بیشتر از autovacuum_multixact_freeze_max_age باشد، رخ خواهد داد. همچنین، اگر فضای ذخیره سازی اشغال شده توسط اعضای multixact بیش از 2 گیگابایت باشد، اسکن های خلاء تهاجمی اغلب برای همه میزها انجام می شود، از آن هایی که قدیمی ترین سن چندگانه را دارند. هر دوی این نوع اسکن های تهاجمی حتی اگر اتوواکیوم اسمی غیرفعال باشد، اتفاق می افتد.

25. 1. 6. دیمون اتوواکیوم

PostgreSQL دارای یک ویژگی اختیاری اما بسیار توصیه شده به نام autovacuum است که هدف آن خودکارسازی اجرای دستورات VACUUM و ANALYZE است. وقتی فعال باشد، خلاء خودکار جداولی را بررسی می کند که تعداد زیادی تاپل درج شده، به روز شده یا حذف شده داشته باشند. این چک ها از تسهیلات جمع آوری آمار استفاده می کنند. بنابراین، autovacuum نمی تواند استفاده شود مگر اینکه track_counts روی true تنظیم شود. در پیکربندی پیش فرض، جاروبرقی خودکار فعال است و پارامترهای پیکربندی مربوطه به طور مناسب تنظیم می شوند.

"Daemon Autovacuum" در واقع از چندین فرآیند تشکیل شده است. یک فرآیند Daemon مداوم به نام پرتاب AutoVacuum وجود دارد که وظیفه شروع فرآیندهای کارگر AutoVacuum را برای همه پایگاه های داده است. پرتابگر کار را در طول زمان توزیع می کند و سعی می کند یک کارگر را در هر پایگاه داده در هر ثانیه AutoVacuum_naptime شروع کند.(بنابراین ، اگر نصب دارای پایگاه داده N باشد ، یک کارگر جدید در هر ثانیه autovacuum_naptime / n راه اندازی می شود.) حداکثر فرآیندهای کارگر autovacuum_max_workers مجاز به اجرای همزمان است. اگر بیش از پایگاه داده های AutoVacuum_Max_workers وجود داشته باشد ، پردازش می شود ، به محض اتمام اولین کارگر ، پایگاه داده بعدی پردازش می شود. هر فرآیند کارگر هر جدول را در پایگاه داده خود بررسی می کند و در صورت لزوم خلاء و/یا تجزیه و تحلیل را اجرا می کند. log_autovacuum_min_duration را می توان برای نظارت بر فعالیت کارگران Autovacuum تنظیم کرد.

اگر چندین جدول بزرگ در مدت زمان کوتاهی واجد شرایط جاروبرقی شوند ، ممکن است همه کارگران Autovacuum با خلاء کردن آن جداول برای مدت طولانی اشغال شوند. این امر باعث می شود تا جداول و پایگاه داده های دیگر تا زمانی که یک کارگر در دسترس نباشد ، خالی نشوند. هیچ محدودیتی در مورد تعداد کارگران در یک پایگاه داده واحد وجود ندارد ، اما کارگران سعی می کنند از تکرار کارهایی که قبلاً توسط سایر کارگران انجام شده است ، خودداری کنند. توجه داشته باشید که تعداد کارگران در حال اجرا به محدوده MAX_CONNECTIONS یا Superuser_Reserved_Connections نمی رسد.

جداول که مقدار Relfrozenxid آن بیش از معاملات AutoVacuum_freeze_max_age قدیمی است همیشه خالی از سکنه هستند (این همچنین در مورد جداول هایی که حداکثر سن آن از طریق پارامترهای ذخیره سازی اصلاح شده است نیز صدق می کند ؛ در زیر مشاهده می کنید). در غیر این صورت ، اگر تعداد تاپل های منسوخ شده از آخرین خلاء از "آستانه خلاء" فراتر رود ، جدول تخلیه می شود. آستانه خلاء به این صورت تعریف شده است:

آستانه خلاء = آستانه پایه خلاء + فاکتور مقیاس خلاء * تعداد تاپل ها

در جایی که آستانه پایه خلاء autovacuum_vacuum_threshold است ، ضریب مقیاس خلاء autovacuum_vacuum_scale_factor است و تعداد Tuples pg_class است. reltuples.

جدول همچنین در صورتی که تعداد تاپل های درج شده از آخرین خلاء از آستانه درج تعریف شده فراتر رفته باشد ، این جدول نیز خالی شده است ، که به این صورت تعریف شده است:

آستانه درج خلاء = آستانه درج پایه خلاء + فاکتور مقیاس درج خلاء * تعداد TUPAL

جایی که آستانه پایه درج خلاء autovacuum_vacuum_insert_threshold است ، و ضریب مقیاس درج خلاء autovacuum_vacuum_insert_scale_factor است. چنین خلاء ممکن است بخش هایی از جدول را به عنوان همه قابل مشاهده نشان دهد و همچنین اجازه می دهد تا تاپل ها یخ زده شوند ، که می تواند کار مورد نیاز در خلاء های بعدی را کاهش دهد. برای جداول که عملیات درج را دریافت می کنند اما هیچ عملیاتی به روزرسانی / حذف ندارند ، ممکن است پایین آمدن جدول AutoVacuum_freeze_min_age مفید باشد زیرا این ممکن است اجازه دهد تا با خلاء های قبلی ، تاپل ها منجمد شوند. تعداد تاپل های منسوخ و تعداد تاپل های درج شده از سیستم آمار تجمعی بدست می آید. این یک شمارش نیمه دقیق است که توسط هر به روزرسانی ، حذف و درج عملیاتی به روز شده است.(این فقط نیمه دقیق است زیرا برخی از اطلاعات ممکن است در زمان بار سنگین از بین بروند.) اگر مقدار Relfrozenxid جدول بیش از معاملات Vacuum_Freeze_Table_age قدیمی باشد ، یک خلاء تهاجمی برای یخ زدن تاپل های قدیمی و پیشبرد Relfrozenxid انجام می شود. در غیر این صورت ، فقط صفحاتی که از آخرین خلاء اصلاح شده اند ، اسکن شده اند.

برای تجزیه و تحلیل ، یک شرط مشابه استفاده می شود: آستانه ، تعریف شده به عنوان:

تجزیه و تحلیل آستانه = تجزیه و تحلیل آستانه پایه + تجزیه و تحلیل فاکتور مقیاس * تعداد تاپل ها

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

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

جداول موقت توسط Autovacuum قابل دسترسی نیست. بنابراین ، خلاء مناسب و تجزیه و تحلیل عملیات باید از طریق دستورات SQL Session انجام شود.

آستانه های پیش فرض و فاکتورهای مقیاس از postgresql. conf گرفته شده است ، اما امکان غلبه بر آنها (و بسیاری دیگر از پارامترهای کنترل اتوواکوم) بر اساس هر جدول امکان پذیر است. برای اطلاعات بیشتر به پارامترهای ذخیره سازی مراجعه کنید. اگر تنظیم از طریق پارامترهای ذخیره یک جدول تغییر یافته باشد ، هنگام پردازش آن جدول از آن مقدار استفاده می شود. در غیر این صورت از تنظیمات جهانی استفاده می شود. برای اطلاعات بیشتر در مورد تنظیمات جهانی ، به بخش 20. 10 مراجعه کنید.

هنگامی که چندین کارگر در حال اجرا هستند ، پارامترهای تأخیر در هزینه AutoVacuum (به بخش 20. 4. 4 مراجعه کنید) در بین همه کارگران در حال اجرا "متعادل" هستند ، به طوری که تأثیر کل I/O بر روی سیستم صرف نظر از تعداد کارگران در واقع یکسان استبشربا این حال ، هر کارگرانی که در هر جدول Autovacuum_Vacuum_cost_delay یا Autovacuum_Vacuum_Cost_limit تنظیم شده است ، در الگوریتم متعادل در نظر گرفته نشده است.

کارگران AutoVacuum به طور کلی دستورات دیگر را مسدود نمی کنند. اگر یک فرآیند سعی در دستیابی به قفل کند که با قفل منحصر به فرد به روزرسانی مشترک که توسط AutoVacuum برگزار می شود ، در تضاد باشد ، خرید قفل باعث قطع اتوواک می شود. برای حالت های قفل متناقض ، به جدول 13. 2 مراجعه کنید. با این حال ، اگر AutoVacuum برای جلوگیری از بسته بندی شناسه معامله در حال اجرا است (یعنی نام پرس و جو AutoVacuum در نمای PG_STAT_ACTIVITY با (برای جلوگیری از بسته بندی) به پایان می رسد) ، Autovacuum به طور خودکار قطع نمی شود.

هشدار

به طور منظم در حال اجرا دستوراتی که قفل های متناقض را با یک قفل منحصر به فرد به روزرسانی به دست می آورند (به عنوان مثال ، تجزیه و تحلیل) می تواند به طور موثری از اتمام اتوواکوها جلوگیری کند.

تصحیح

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

کپی رایت © 1996-2023 گروه توسعه جهانی PostgreSQL