تنظیم لینوکس برای بهبود عملکرد PostgreSQL. ایلیا کوسمودمیانسکی

رونوشت گزارش سال 2015 توسط ایلیا کوسمودمیانسکی "تنظیم لینوکس برای بهبود عملکرد PostgreSQL"

سلب مسئولیت: متذکر می شوم که این گزارش مربوط به نوامبر 2015 است - بیش از 4 سال می گذرد و زمان زیادی می گذرد. نسخه 9.4 مورد بحث در گزارش دیگر پشتیبانی نمی شود. در طول 4 سال گذشته، 5 نسخه جدید از PostgreSQL منتشر شده است و 15 نسخه از هسته لینوکس منتشر شده است. اگر این قسمت ها را بازنویسی کنید، در نهایت با گزارش متفاوتی مواجه خواهید شد. اما در اینجا ما تنظیم اساسی لینوکس برای PostgreSQL را در نظر می گیریم، که امروزه نیز مرتبط است.

نام من ایلیا کوسمودمیانسکی است. من در PostgreSQL-Consulting کار می کنم. و اکنون کمی در مورد اینکه با لینوکس در رابطه با پایگاه های داده به طور کلی و PostgreSQL به طور خاص چه باید کرد صحبت خواهم کرد، زیرا اصول کاملاً مشابه هستند.

در مورد چه چیزی صحبت خواهیم کرد؟ اگر با PostgreSQL ارتباط برقرار می کنید، تا حدی باید مدیر یونیکس باشید. چه مفهومی داره؟ اگر اوراکل و PostgreSQL را با هم مقایسه کنیم، در اوراکل باید 80% ادمین پایگاه داده DBA و 20% مدیر لینوکس باشید.

با PostgreSQL کمی پیچیده تر است. با PostgreSQL باید درک بهتری از نحوه کار لینوکس داشته باشید. و در عین حال کمی بعد از لوکوموتیو بدوید، زیرا اخیراً همه چیز به خوبی به روز شده است. و هسته های جدید منتشر می شوند و عملکردهای جدید ظاهر می شوند، عملکرد بهبود می یابد و غیره.

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

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

یک توزیع مدرن لینوکس، بسته به نحوه ساخت هسته، بیش از 1 گزینه syctl دارد. در عین حال، اگر به مهره های مختلف نگاه کنیم، می توانیم چیزی را از بسیاری جهات تنظیم کنیم. پارامترهای سیستم فایل در مورد نحوه نصب آنها وجود دارد. اگر در مورد نحوه شروع آن سؤال دارید: چه چیزی را در BIOS فعال کنید، چگونه سخت افزار را پیکربندی کنید و غیره.

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

چه اهداف تنظیم سنتی در لینوکس وجود دارد؟ من فکر می کنم از آنجایی که همه شما با مدیریت لینوکس سر و کار دارید، نیازی به توضیح اینکه اهداف چیست، وجود ندارد.

می توانید تنظیم کنید:

• پردازنده
• حافظه
• ذخیره سازی.
• دیگر. در پایان برای یک میان وعده در این مورد صحبت خواهیم کرد. حتی برای مثال، پارامترهایی مانند سیاست‌های صرفه‌جویی در مصرف انرژی می‌توانند عملکرد را به شکلی بسیار غیرقابل پیش‌بینی و نه خوشایند تحت تأثیر قرار دهند.

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

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

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

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

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

دیسک ها تحت این سیستم زندگی می کنند. من این را به عنوان دیسک ترسیم کردم. در واقع ممکن است یک کنترلر RAID و غیره وجود داشته باشد.

و این ورودی-خروجی به هر طریقی از طریق این موضوع اتفاق می افتد.

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

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

چرا این کار انجام می شود؟ اگر ما ولتاژ را از دست دادیم، پس وضعیتی که تمام داده ها از بین رفته بود، به دست نمی آمد. حافظه پایدار، که همه در مورد آن به ما گفته اند، تا کنون در تئوری پایگاه داده است - این یک آینده روشن است که البته ما برای آن تلاش می کنیم و آن را دوست داریم، اما در حال حاضر آنها در کمتر از 20 سال زندگی می کنند. و البته همه اینها نیاز به نظارت دارد.

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

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

و اجازه دهید هر یک از این نکات را مرور کنیم.

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

• اولاً، باید کارآمدتر با حافظه کار کنید.
• ثانیا، این انتقال زمانی که صفحات از حافظه به دیسک می روند باید کارآمدتر باشد.
• و سوم اینکه باید دیسک های خوبی وجود داشته باشد.

اگر 512 گیگابایت رم در سرور دارید و همه آن بدون هیچ کش روی هارد دیسک SATA ختم می شود، کل سرور پایگاه داده نه فقط به کدو تنبل، بلکه به کدو تنبل با رابط SATA تبدیل می شود. شما مستقیماً با آن برخورد خواهید کرد. و هیچ چیز شما را نجات نخواهد داد.

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

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

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

واقعا چه خبر است؟ NUMA مخفف Non-Uniform Memory Access است. چه فایده ای دارد؟ شما یک CPU دارید، در کنار آن حافظه محلی آن وجود دارد. و این اتصالات حافظه می تواند حافظه را از CPU های دیگر بالا ببرد.

اگر بدوید numactl --hardware، سپس چنین ورق بزرگی دریافت خواهید کرد. در میان چیزهای دیگر، میدان فاصله وجود خواهد داشت. اعداد وجود خواهد داشت - 10-20، چیزی شبیه به آن. این اعداد چیزی بیش از تعداد پرش برای برداشتن این حافظه از راه دور و استفاده از آن به صورت محلی نیستند. در اصل ایده خوبی است. این کار به خوبی عملکرد را تحت طیف وسیعی از بارهای کاری سرعت می بخشد.

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

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

چرا اینطور است؟ به نظر می رسد که باید برعکس باشد. این به یک دلیل ساده اتفاق می افتد: ما به حافظه زیادی برای کش صفحه نیاز داریم - ده ها، صدها گیگابایت.

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

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

بنابراین، روش صحیح غیرفعال کردن NUMA به طور کلی استبه عنوان مثال، هنگام راه اندازی مجدد. در بیشتر موارد، بردها به اندازه ای هستند که اصلاً این سؤال مطرح نمی شود که کدام بهتر است.

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

یک پست خوب از رابرت هاس وجود دارد. این یکی از committer های PostgreSQL است. یکی از توسعه دهندگان کلیدی تمام قلوه های سطح پایین. و اگر پیوندهای این پست را دنبال کنید، چندین داستان رنگارنگ در مورد اینکه چگونه NUMA زندگی را برای مردم سخت کرده است، شرح می دهند. نگاه کنید، چک لیست مدیر سیستم را مطالعه کنید که چه چیزی باید روی سرور پیکربندی شود تا پایگاه داده ما به خوبی کار کند. این تنظیمات باید یادداشت و بررسی شوند، زیرا در غیر این صورت خیلی خوب نخواهد بود.

لطفاً توجه داشته باشید که این برای تمام تنظیماتی که در مورد آنها صحبت خواهم کرد صدق می کند. اما معمولا پایگاه های داده در حالت master-slave برای تحمل خطا جمع آوری می شوند. فراموش نکنید که این تنظیمات را روی Slave انجام دهید زیرا یک روز تصادف می کنید و به Slave سوئیچ می کنید و آن استاد می شود.

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

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

چه فایده ای دارد؟ شما یک سرور نه چندان گران با رم زیاد مثلاً بیش از 30 گیگابایت دارید. شما از صفحات بزرگ استفاده نمی کنید. این بدان معنی است که شما قطعاً از نظر استفاده از حافظه سربار دارید. و این سربار به دور از خوشایندترین است.

چرا اینطور است؟ چه خبر؟ سیستم عامل حافظه را در قطعات کوچک اختصاص می دهد. این خیلی راحت است، از نظر تاریخی اینطور اتفاق افتاده است. و اگر به جزئیات بپردازیم، سیستم عامل باید آدرس های مجازی را به آدرس های فیزیکی ترجمه کند. و این فرآیند ساده ترین نیست، بنابراین سیستم عامل نتیجه این عملیات را در بافر Translation Lookaside (TLB) ذخیره می کند.

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

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

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

و چگونه می توان با PostgreSQL دوست شد؟ در مرحله اول، صفحات بزرگ باید در هسته لینوکس فعال شوند.

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

و اگر کل سرور شما به PostgreSQL اختصاص داده شده است، یک نقطه شروع خوب این است که 25٪ از RAM را به بافرهای مشترک اختصاص دهید، یا 75٪ اگر مطمئن هستید که پایگاه داده شما قطعاً در این 75٪ قرار می گیرد. نقطه شروع یک. و در نظر بگیرید، اگر 256 گیگابایت رم دارید، بر این اساس، 64 گیگابایت بافر بزرگ خواهید داشت. تقریباً با مقداری حاشیه محاسبه کنید - این رقم باید روی چه مقدار تنظیم شود.

قبل از نسخه 9.2 (اگر اشتباه نکنم از نسخه 8.2)، امکان اتصال PostgreSQL با صفحات بزرگ با استفاده از یک کتابخانه شخص ثالث وجود داشت. و این باید همیشه انجام شود. ابتدا به هسته نیاز دارید تا بتوانید صفحات بزرگ را به درستی اختصاص دهید. و دوم اینکه اپلیکیشنی که با آنها کار می کند بتواند از آنها استفاده کند. فقط به این شکل استفاده نخواهد شد. از آنجایی که PostgreSQL حافظه را در سبک سیستم 5 تخصیص داده است، این کار را می توان با استفاده از libhugetlbfs انجام داد - این نام کامل کتابخانه است.

در 9.3، عملکرد PostgreSQL هنگام کار با حافظه بهبود یافت و روش تخصیص حافظه سیستم 5 کنار گذاشته شد. همه بسیار خوشحال بودند، زیرا در غیر این صورت شما سعی می کنید دو نمونه PostgreSQL را روی یک دستگاه اجرا کنید، و او می گوید که من حافظه مشترک کافی ندارم. و می گوید sysctl باید اصلاح شود. و چنین sysctl وجود دارد که شما هنوز باید راه اندازی مجدد کنید و غیره. در کل همه راضی بودند. اما تخصیص حافظه mmap استفاده از صفحات بزرگ را شکست. اکثر مشتریان ما از بافرهای مشترک بزرگ استفاده می کنند. و ما قویاً توصیه می کنیم به 9.3 تغییر ندهید ، زیرا سربار در آنجا شروع به محاسبه با درصدهای خوبی کرد.

اما جامعه به این مشکل توجه کرد و در 9.4 این رویداد را به خوبی بازسازی کردند. و در 9.4 پارامتری در postgresql.conf ظاهر شد که در آن می توانید try، روشن یا خاموش کردن را فعال کنید.

سعی کنید امن ترین گزینه است. هنگامی که PostgreSQL شروع می شود، زمانی که حافظه مشترک را اختصاص می دهد، سعی می کند این حافظه را از صفحات بزرگ بگیرد. و اگر کار نکرد، به حالت انتخاب عادی برمی گردد. و اگر FreeBSD یا Solaris دارید، می توانید امتحان کنید، همیشه بی خطر است.

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

قبل از اینکه جلوتر برویم یک نکته کوچک دیگر. صفحات بزرگ شفاف هنوز درباره PostgreSQL نیستند. او نمی تواند به طور معمول از آنها استفاده کند. و با صفحات عظیم Transparent برای چنین حجم کاری، هنگامی که به یک حافظه مشترک بزرگ نیاز است، مزایا فقط با حجم بسیار زیاد حاصل می شود. اگر ترابایت حافظه دارید، این ممکن است وارد عمل شود. اگر ما در مورد برنامه های روزمره بیشتر صحبت می کنیم، زمانی که شما 32، 64، 128، 256 گیگابایت حافظه در دستگاه خود دارید، صفحات بزرگ معمولی Ok هستند و ما به سادگی Transparent را غیرفعال می کنیم.

و آخرین نکته در مورد حافظه ارتباط مستقیمی با میوه ندارد، واقعاً می تواند زندگی شما را خراب کند. تمام توان عملیاتی به شدت تحت تأثیر این واقعیت است که سرور دائماً در حال تعویض است.

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

چه اتفاقی می افتد؟ شما مقدار زیادی رم در آنجا دارید، همه چیز به خوبی کار می کند. اما به دلایلی سرور در swap هنگ می کند و به همین دلیل سرعتش کند می شود. به نظر می رسد که حافظه زیادی وجود دارد، اما این اتفاق می افتد.

قبلاً توصیه می‌کردیم که vm.swappiness را روی صفر تنظیم کنید، یعنی تعویض را غیرفعال کنید. قبلاً به نظر می رسید که 32 گیگابایت رم و بافرهای مشترک مربوطه مقدار زیادی است. هدف اصلی سوآپ این است که در صورت افتادن، جایی برای پرتاب پوسته داشته باشیم. و دیگر به طور خاص برآورده نشد. و بعد با این پوسته چه کار خواهی کرد؟ این وظیفه ای است که در آن خیلی واضح نیست که چرا به مبادله نیاز است، به خصوص در چنین اندازه ای.

اما در نسخه های مدرن تر، یعنی نسخه های سوم هسته، رفتار تغییر کرده است. و اگر swap را روی صفر تنظیم کنید، یعنی آن را خاموش کنید، دیر یا زود، حتی اگر مقداری RAM باقی مانده باشد، یک OOM killer به سراغ شما می آید تا پرمصرف ترین مصرف کنندگان را بکشد. زیرا او در نظر خواهد گرفت که با چنین حجم کاری هنوز کمی باقی مانده است و ما از آن بیرون خواهیم پرید، یعنی نه اینکه روند سیستم را از بین ببریم، بلکه چیزی کم اهمیت تر را از بین ببریم. این مورد کم اهمیت، مصرف کننده فشرده حافظه مشترک، یعنی مدیر پست خواهد بود. و بعد از آن خوب خواهد بود اگر پایه لازم نباشد بازسازی شود.

بنابراین، در حال حاضر پیش فرض، تا آنجا که من به یاد دارم، اکثر توزیع ها در حدود 6 هستند، یعنی از چه نقطه ای باید بسته به مقدار حافظه باقی مانده، استفاده از swap را شروع کنید. اکنون توصیه می کنیم vm.swappiness = 1 را تنظیم کنید، زیرا عملاً آن را خاموش می کند، اما اثرات مشابه با یک OOM-killer که به طور غیرمنتظره ای وارد شده و کل چیز را از بین می برد، نمی دهد.

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

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

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

در اینجا من دو عکس دارم. حالا توضیح می دهم که چیست. این دو نمودار همبسته با زمان هستند. نمودار اول استفاده از دیسک است. در اینجا تقریباً در این نقطه از زمان به 90٪ می رسد. اگر با دیسک های فیزیکی خرابی پایگاه داده دارید، با استفاده از کنترلر RAID در 90٪، این خبر بدی است. یعنی کمی بیشتر می شود و به 100 می رسد و I/O متوقف می شود.

اگر آرایه دیسک دارید، داستان کمی متفاوت است. بستگی به نحوه پیکربندی، نوع آرایه و غیره دارد.

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

برای غلبه بر این مشکل چه باید کرد؟ اگر IO را در پایگاه داده متوقف کرده باشید، به این معنی است که همه کاربرانی که برای انجام درخواست های خود آمده اند منتظر خواهند ماند.

اگر از دیدگاه لینوکس نگاه کنید، اگر سخت افزار خوبی گرفته اید، آن را به درستی پیکربندی کرده اید، PostgreSQL را به طور معمول پیکربندی کرده اید تا این چک پوینت ها را کمتر کند، آنها را در طول زمان بین یکدیگر پخش کند، سپس وارد پارامترهای پیش فرض دبیان می شوید. برای اکثر توزیع های لینوکس، این تصویر است: vm.dirty_ratio=20، vm.dirty_background_ratio=10.

چه مفهومی داره؟ یک دیو در حال گرگرفتگی از هسته 2.6 ظاهر شد. Pdglush، بسته به اینکه چه کسی از کدام استفاده می‌کند، که درگیر حذف پس‌زمینه صفحات کثیف از بافر هسته و دور انداختن در مواقعی که لازم است صفحات کثیف را صرفنظر کنید، وقتی دور انداختن پس‌زمینه کمکی نمی‌کند.

پس زمینه کی میاد؟ هنگامی که 10٪ از کل RAM موجود در سرور توسط صفحات کثیف در بافر هسته اشغال می شود، یک تابع حذف ویژه در پس زمینه فراخوانی می شود. چرا پس زمینه است؟ به عنوان یک پارامتر، تعداد صفحات را در نظر می گیرد که باید حذف شوند. و، فرض کنید، او N صفحه را می نویسد. و برای مدتی این چیز به خواب می رود. و سپس دوباره می آید و چند صفحه دیگر را کپی می کند.

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

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

ترفند چیست؟ ترفند این است که این پارامترها در دنیای مدرن 20 و 10٪ از کل RAM موجود در دستگاه هستند، آنها از نظر توان عملیاتی هر سیستم دیسکی که دارید کاملاً هیولا هستند.

تصور کنید 128 گیگابایت رم دارید. 12,8 گیگابایت به سیستم دیسک شما می رسد. و مهم نیست چه حافظه پنهانی در آنجا دارید، مهم نیست چه آرایه ای در آنجا دارید، آنها آنقدر دوام نخواهند داشت.

بنابراین توصیه می کنیم بلافاصله این اعداد را بر اساس قابلیت های کنترلر RAID خود تنظیم کنید. من بلافاصله در اینجا توصیه ای برای کنترلری کردم که 512 مگابایت کش دارد.

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

چه اتفاقی می افتد اگر شما مناسب نباشید؟ من نوشته ام که هرگونه گرگرفتگی عملاً متوقف می شود، اما در واقع این یک شکل گفتاری است. سیستم عامل یک مشکل بزرگ دارد - صفحات کثیف زیادی دارد، بنابراین IO که کلاینت های شما تولید می کنند به طور موثر متوقف می شود، یعنی برنامه آمده است تا یک پرس و جو sql را به پایگاه داده ارسال کند، منتظر است. هر ورودی/خروجی به آن از کمترین اولویت برخوردار است، زیرا پایگاه داده توسط یک نقطه بازرسی اشغال شده است. و اینکه او کی تمام خواهد شد کاملاً نامشخص است. و هنگامی که به فلاشینگ غیر پس‌زمینه دست یافتید، به این معنی است که تمام IO شما توسط آن اشغال شده است. و تا زمانی که تمام شود، هیچ کاری نخواهید کرد.

دو نکته مهم دیگر در اینجا وجود دارد که از حوصله این گزارش خارج است. این تنظیمات باید با تنظیمات postgresql.conf، یعنی تنظیمات checkpoints مطابقت داشته باشد. و سیستم دیسک شما باید به اندازه کافی پیکربندی شده باشد. اگر روی RAID حافظه نهان دارید، باید باتری داشته باشد. مردم RAID را با کش خوب و بدون باتری می خرند. اگر SSD در RAID دارید، پس باید سرور باشد، باید خازن وجود داشته باشد. در اینجا یک چک لیست دقیق است. این پیوند حاوی گزارش من در مورد نحوه پیکربندی یک دیسک عملکرد در PostgreSQL است. همه این چک لیست ها در آنجا وجود دارد.

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

دو چیز نسبتا جدید وجود دارد. آنها قبلاً در هسته های سوم ظاهر شده اند. این sched_migration_cost در نانوثانیه و sched_autogroup_enabled است که به طور پیش فرض یکی است.

و چگونه زندگی شما را خراب می کنند؟ sched_migration_cost چیست؟ در لینوکس، زمان‌بند می‌تواند فرآیندی را از یک CPU به CPU دیگر منتقل کند. و برای PostgreSQL که کوئری ها را اجرا می کند، مهاجرت به CPU دیگر کاملاً نامشخص است. از نقطه نظر سیستم عامل، وقتی ویندوز را بین openoffice و terminal سوئیچ می کنید، ممکن است خوب باشد، اما برای یک پایگاه داده این بسیار بد است. بنابراین، یک سیاست معقول این است که migration_cost را روی مقداری بزرگ، حداقل چند هزار نانوثانیه تنظیم کنید.

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

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

همکار من Alexey Lesovsky تست هایی را با یک pgbench ساده انجام داد، جایی که migration_cost را به ترتیبی افزایش داد و autogroup را خاموش کرد. تفاوت در سخت افزار بد تقریبا 10٪ بود. بحثی در لیست پستی postgres وجود دارد که در آن افراد نتایج تغییرات مشابهی را در سرعت پرس و جو ارائه می دهند تحت تاثیر 50 درصد. چنین داستان هایی بسیار زیاد است.

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

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

اگر از این موارد روی سروری با پایگاه داده تحت بار سنگین استفاده می کنید، انتخاب شما acpi_cpufreq + permormance است. حتی در صورت تقاضا نیز مشکلاتی وجود خواهد داشت.

Intel_pstate یک درایور کمی متفاوت است. و اکنون به این یکی ترجیح داده می شود، زیرا بعداً است و بهتر عمل می کند.

و بر این اساس، فرماندار تنها عملکرد است. Ondemand، powersave و هر چیز دیگری در مورد شما نیست.

نتایج توضیح تحلیل PostgreSQL ممکن است با چندین مرتبه بزرگی متفاوت باشد اگر ذخیره انرژی را فعال کنید، زیرا عملا CPU زیر پایگاه داده شما به روشی کاملاً غیرقابل پیش بینی اجرا می شود.

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

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

پرسش:

متشکرم! به عنوان مثال، اگر یک شرکت بخواهد در هزینه خود صرفه جویی کند و پایگاه داده و منطق برنامه را روی یک سرور قرار دهد، یا اگر شرکت از روند مد روز معماری های میکروسرویس پیروی کند، که در آن PostgreSQL در یک کانتینر اجرا می شود. ترفند چیست؟ Sysctl بر کل هسته در سطح جهانی تأثیر می گذارد. من نشنیده ام که sysctls به نحوی مجازی شده باشد تا به طور جداگانه روی یک کانتینر کار کنند. فقط یک cgroup وجود دارد و تنها بخشی از کنترل در آنجا وجود دارد. چگونه می توان با این زندگی کرد؟ یا اگر می خواهید کارایی داشته باشید، PostgreSQL را روی یک سرور سخت افزاری جداگانه اجرا کنید و آن را تنظیم کنید؟

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

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

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

اما از سوی دیگر، برخی از این پارامترها همچنان برای شما مرتبط خواهند بود. برای مثال dirty_ratio را با sysctl تنظیم کنید تا اینقدر دیوانه نباشد - در هر صورت این کمک می کند. به هر طریقی، شما با دیسک تعامل خواهید داشت. و طبق الگوی اشتباه خواهد بود. این به طور کلی یک پیش فرض برای پارامترهایی است که من نشان دادم. و در هر صورت بهتر است آنها را تغییر دهید.

اما ممکن است مشکلاتی با NUMA وجود داشته باشد. به عنوان مثال، VmWare با NUMA دقیقاً با تنظیمات مخالف به خوبی کار می کند. و در اینجا باید انتخاب کنید - سرور آهنی یا غیر آهنی.

من یک سوال در رابطه با Amazon AWS دارم. آنها تصاویر از پیش پیکربندی شده دارند. یکی از آنها Amazon RDS نام دارد. آیا تنظیمات سفارشی برای سیستم عامل آنها وجود دارد؟

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

چرا صفحات بزرگ شفاف در مقایسه با Huge TLB هیچ تاثیری ندارند؟

نده. این را می توان از بسیاری جهات توضیح داد. اما در واقع آنها به سادگی آن را نمی دهند. تاریخچه PostgreSQL چیست؟ در هنگام راه اندازی، بخش بزرگی از حافظه مشترک را به خود اختصاص می دهد. شفاف بودن یا نبودن آنها کاملاً بی ربط است. این واقعیت که آنها در ابتدا برجسته می شوند همه چیز را توضیح می دهد. و اگر حافظه زیادی وجود داشته باشد و شما نیاز به بازسازی بخش shared_memory داشته باشید، صفحات عظیم Transparent مرتبط خواهند بود. در PostgreSQL، به سادگی در ابتدا در یک بخش بزرگ تخصیص داده می شود و تمام، و بعد از آن هیچ اتفاق خاصی در آنجا رخ نمی دهد. البته می‌توانید از آن استفاده کنید، اما زمانی که shared_memory چیزی را دوباره اختصاص می‌دهد، احتمال خراب شدن آن وجود دارد. PostgreSQL از این موضوع اطلاعی ندارد.

منبع: www.habr.com