حل کرد چقدر مبادله

من در نظر دارم (رویای) گرفتن یک دستگاه جدید خوب با مقدار زیادی رم و یک NVME (یا دو آینه) برای دیسک سیستم. دو برابر مقدار رم معادل مبادله از بخش قابل توجهی از دیسک سیستم استفاده می کند.

تفکر فعلی چیست؟

آخرین باری که یک دستگاه جدید را راه اندازی کردم ، 4 گیگابایت مبادله کردم. این به اندازه کافی بزرگ است که در صورت خرابی دستگاه ، یک minidump را نگه دارید.

بی نظمی

سرپرست

تا اندازه مبادله در حدود 8 گیگابایت ، بله. اغلب داشتن چیزی بیش از این مفید نیست. برخی موارد لبه وجود دارد که مبادله بسیار بیشتری می تواند مفید باشد اما به طور کلی من در 4 یا 8 گیگابایت تعویض می کنم ، حتی اگر اندازه رم 380 گیگابایت یا بیشتر باشد.

عضو حذف شده 67440

مهمان

هشدار: بعضی اوقات قوس قوچ می خورد ، بنابراین ، به عنوان یک قاعده شست ، من 4 گیگابایت را خیلی کوچک می دانم

من 16 گیگابایت را برای سرورهایم انتخاب می کنم (ماشین آلات با استفاده فشرده).

بی نظمی

سرپرست

ARC از مبادله ای استفاده نمی کند (که هدف خود را شکست می دهد) و حافظه استفاده شده خود را به نفع نیازهای حافظه فشرده تر از دست می دهد (یا باید تسلیم شود).

عضو حذف شده 67440

مهمان

ARC از مبادله ای استفاده نمی کند (که هدف خود را شکست می دهد) و حافظه استفاده شده خود را به نفع نیازهای حافظه فشرده تر از دست می دهد (یا باید تسلیم شود).

قوس قوچ را می خورد ، و تقریباً هرگز تسلیم نمی شود<13.

بنابراین طبیعی است که سایر فرآیندهای فشرده حافظه (VirtualBox ، برنامه های بایگانی برای تهیه نسخه پشتیبان) تا زمان تعویض ، در نهایت به تعویض برسند.

این مشکلی است که بلافاصله حل می شود (استفاده از قوس را محدود کنید) در هنگام کار در دستگاه های VirtualBox ، با چیزی مانند

بی نظمی

سرپرست

VFS. ZFS. ARC_MAX را محدود کنید. به طور پیش فرض سعی خواهد کرد از تمام حافظه منهای 1 گیگابایت استفاده کند. در قبل از 13. 0 قوس نوعی تمایلی یا حداقل به اندازه کافی سریع نبود ، حافظه مورد استفاده خود را آزاد کرد. که گاهی اوقات باعث می شود همه چیز از کنترل خارج شود ، با سایر برنامه ها (به ویژه MySQL/Mariadb و ماشین های مجازی) و قوس همه در حال جنگ با همان حافظه است. هنوز هم ممکن است ، من هنوز این کار را به طور گسترده آزمایش نکرده ام ، اما از افراد دیگر می شنوم که با 13. 0 اوضاع بسیار بهبود یافته است. هنوز ایده خوبی برای محدود کردن قوس برای از بین بردن هرگونه مشاجره بالقوه است.

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

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

توجه داشته باشید که قوانین قدیمی انگشت شست امروز دیگر اعمال نمی شود. این قانون قدیمی "SWAP = 2 × RAM" از زمانی بود که سیستم ها رم کمی داشتند و دیسک های سخت نسبت به RAM بسیار سریعتر بودند (طی دهه های گذشته ، پهنای باند RAM سفارشات بزرگی را بیشتر از سرعت دیسک های سخت رشد می داد). 30 سال پیش بسیار معمول بود که یک دستگاه از فضای مبادله خود در حین کار عادی استفاده کرد و کار بزرگی نبود. امروز ، شما نمی خواهید ماشین ها به هیچ وجه تعویض شوند.

عضو حذف شده 67440

مهمان

در تجربه من 4 گیگابایت پرونده های مبادله ای بسیار اندک است: اگر رم پر باشد - معمولاً به این معنی است که شما در راه Thrasing هستید (که واقعاً مشکل بزرگی با درایوهای حالت جامد نیست).

بنابراین 4 گیگابایت ، حداقل برای بارهای من ، تصادفات ناگهانی VirtualBox (بارها در طول سالها) را می دهد.

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

به همین دلیل من از 16 گیگابایتی استفاده می کنم ، که فکر می کنم سازش خوبی برای سرورهایم است: به طور متناقض ، با 16 گیگابایت حافظه فایله ای-Virtual Swap FreeBSD با 4 مطمئناً (در آنجا بوده است ، انجام شده است ، صدها بار)

البته همه افراد هر شب بازیابی چند ترامد را راه اندازی نمی کنند ، در حالی که 5 نسخه دیگر را همزمان در دو NIC می سازد و ماشین های مجازی پشتیبان گیری داخلی خود را (از MS SQL در ویندوز) شروع می کنند و غیره

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

سپس با توجه به تقاضای حافظه برنامه خود ، آن را به درستی پیکربندی کنید. و بر این اساس حافظه نهان VNODE خود را محدود کنید.(بله ، کمی ریاضی درگیر است.)

بنابراین طبیعی است که سایر فرآیندهای فشرده حافظه (VirtualBox ، برنامه های بایگانی برای تهیه نسخه پشتیبان) تا زمان تعویض ، در نهایت به تعویض برسند.

مبادله برنامه های سقوط را انجام نمی دهد ، فقط آنها را کند می کند (و درایوهای SSD ROTS). مگر اینکه به هر حال شکسته شوند.

این مشکلی است که بلافاصله حل می شود (استفاده از قوس را محدود کنید) در هنگام کار در دستگاه های VirtualBox ، با چیزی مانند

ARC_META_LIMIT فقط مشاوره است. این متا را محدود نمی کند ، فقط هنگام اخراج ترجیح می دهد.

در مورد سوال اصلی: من توصیه می کنم به همان اندازه مبادله ای را ارائه دهید که دستگاه ممکن است در زمان واقع بینانه حرکت کند. برای یک SSD استاندارد با یک روش عملی 250MBSEC ، می تواند در طی یک دقیقه 15 گیگابایت را پر کند. بنابراین من می گویم این یک اندازه واقع بینانه است که شما را برای رسیدن به یک روند فراری قبل از اینکه قاتل OOM وارد شود ، به شما می دهد. دستگاه های سریعتر بر این اساس بزرگتر هستند.

پسر یک جانور

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

برای یک دسک تاپ که قصد دارید تمام وقت را ترک کنید ، احتمالاً 4 گیگابایت خوب است. برای یک سرور ، در صورت وجود به چیز زیادی احتیاج ندارید.

عضو حذف شده 67440

مهمان

سپس با توجه به تقاضای حافظه برنامه خود ، آن را به درستی پیکربندی کنید. و بر این اساس حافظه نهان VNODE خود را محدود کنید.(بله ، کمی ریاضی درگیر است.)

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

مبادله برنامه های سقوط را انجام نمی دهد ، فقط آنها را کند می کند (و درایوهای SSD ROTS). مگر اینکه به هر حال شکسته شوند.

در تئوری. مبادله به طور عملی می تواند برنامه ها را خراب کند ، حداقل در FreeBSD ، این فقط آنها را کندتر نمی کند. واقعیتی که سالها بر روی ده ها سرور تأسیس شده است ، به روش سخت.

این اساساً بستگی به این دارد که کدام برنامه ها: همانطور که در بالا ذکر شد ، من به طور خاص به VirtualBox اشاره می کنم ، و تا حدی کمتر MySQL قطعاً شکسته است ، اما گزینه دیگری وجود ندارد.

در حقیقت ، این اتفاق می افتد که ، به دلایل غیر قابل توضیح ، MySQL (Mariadb) (یا به اصطلاح FreeBSD) تصمیم می گیرد برای چند ده Mbs تعویض کند حتی اگر استفاده از حافظه آن محدود باشد و حداقل صد گیگابایت وجود داردقوچ رایگان چرا؟من نمی دانم ، در واقع دیدن سرورهای شلوغ خیلی سخت است. من باید یکی را متوقف کنم و آن را کاملاً نظارت کنم ، اما تلاش ارزش نتیجه را ندارد.

ARC_META_LIMIT فقط مشاوره است. این متا را محدود نمی کند ، فقط هنگام اخراج ترجیح می دهد.

در مورد سوال اصلی: من توصیه می کنم تا آنجایی که ماشین ممکن است در زمان واقعی جابجا شود، مبادله ارائه کنید. برای یک SSD استاندارد با سرعت عملی 250 مگابایت بر ثانیه، می تواند در عرض یک دقیقه 15 گیگابایت را پر کند. بنابراین من می توانم بگویم که اندازه ای واقعی است که به شما فرصتی می دهد تا قبل از اینکه قاتل oom وارد شود، یک فرآیند فرار را بگیرید. دستگاه های سریع تر بر این اساس بزرگ تر هستند.

در تجربه من (با درایوهای بسیار سریعتر از 250 مگابایت بر ثانیه، حداقل 10 برابر سریعتر، زمانی که 30 برابر نیست) هرگز به بیش از 16 گیگابایت نیاز نداشتم تا سیستم های پایداری داشته باشم که قادر به آپتایم نامحدود هستند. البته من به سرورهایم اشاره می کنم که کارهای مشتریانم را اجرا می کنند. من مطمئنا نمی توانم برای "هر" سرور و "هر" استفاده ای توصیه کنم. همه آنها 11 یا 12، هیچ 13+

نسخه کوتاه: من 4 گیگابایت فایل swap را به هیچ عنوان پیشنهاد نمی کنم. مطمئناً 2 برابر RAM نیست (در مورد من به بیش از 1 ترابایت تعویض نیاز دارد!)

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

همانطور که در مثال بالا یک فرآیند mysql وجود دارد که بنا به دلایلی تصمیم به تعویض اجباری در دستگاهی با 768 گیگابایت رم گرفت. من واقعا سرورهای BSD را بدون فایل های مبادله توصیه نمی کنم. مطمئناً بزرگ نیست، برای مثال من هرگز و هرگز از خواب زمستانی استفاده نمی کنم. اما مطمئناً صفر نیست

ریچاردتوهی2

فکر می کنم بیشتر از mysql باشد. من نیز فرآیندهای rsync بسیار طولانی مدتی داشته ام که مبادله داده شده است.

به نظر می رسد - در تجربه من - فرآیندهای طولانی مدتی هستند که باعث فشار ناگهانی حافظه می شوند (به عنوان مثال وارد کردن 10s از میلیون ها ردیف در مورد MySQL) که به جای حافظه غیرفعال، مبادله داده می شود. اما من در یک سوراخ خرگوشی از tcmalloc در مقابل jemalloc گم شدم و به نظر می رسد نسخه جدید jemalloc در 13. 0 به مورد استفاده من کمک کرده است (در آزمایش مختصر).

تعویض 4 گیگابایتی بیکن من را نجات داده است، 8 گیگابایت ممکن است بهتر باشد، اما همانطور که دیگران گفتند به محض اینکه swap به طور جدی مورد استفاده قرار گرفت، چیزی وجود دارد که ارزش بررسی دارد (به شرط زمان!)

عضو حذف شده 67440

مهمان

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

من همچنین در مورد بهبود تعامل حافظه، تا حدی به دلیل OpenZFS، در 13 خوانده ام. با این حال، فکر نمی کنم چنین سروری را برای یک سال، شاید 18 ماه نصب کنم. همین امروز منتظر CPU یک دستگاه تست فیزیکی 13+ هستم که از آن به عنوان "خرد کننده پشتیبان" استفاده خواهم کرد.

من کاملاً قانع نیستم، خواهیم دید.

ریچاردتوهی2

اگر با MySQL مشکل دارید، ارزش آن را دارد که از tcmalloc استفاده کنید. این قطعاً روی ماشین های آزمایشی من کار می کند - هنوز آنقدر شجاع نبودم که تولید را امتحان کنم!

zirias@

فقط برای افزودن "اثبات حکایتی"، در دستگاه 13. 0-RELEASE من با ARC محدود به 32 گیگابایت (!) در طول ساخت پودریر بزرگ که به رم زیادی نیاز دارد، اینگونه به نظر می رسد:

حدس می زنم بالاخره می توانم محدودیت ARC را به کلی کنار بگذارم. به محض اینکه نیاز باشد در 13 به خوبی کار می کند

ریچاردتوهی2

با وجود اینکه 1 گیگابایت رایگان و 11 گیگ غیرفعال است، هنوز 3G از مبادله جویده شده است - این چیزی است که من سعی می کنم بفهمم. اما من فکر می کنم که سعی می کند از حافظه غیرفعال محافظت کند، زیرا فکر می کند ممکن است مهم تر باشد (به کار گرفته شود) و تصمیم می گیرد از swap استفاده کند. اما مطمئن نیستم!

zirias@

این 3G مدتها قبل از شروع این ساخت در حال مبادله بودند، IIRC پس از یک ساخت بزرگ دیگر در آنجا به پایان رسید. این واقعیت که آنها هنوز آنجا نشسته اند، اشاره ای است که سیستم عامل هوشمندانه آن را انتخاب کرده است.(چند روز به آنها دسترسی نداشتند!)

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

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

ریچاردتوهی2

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

دستگاه شما قبلاً 3 گیگابایت از swap استفاده کرده است - که 75٪ از 4 گیگابایت پیش فرض است.

من فقط به سوال OP و تجربه خود در مورد 4 گیگابایت پیش فرض 4 گیگابایتی علاقه مندم - وارد کردن داده ها به MySQL چند بار باعث ایجاد OOM برای من شده است ، بنابراین دفعه بعد که سرور را راه اندازی کردم که قصد داشتم برای آن بروم8 گیگابایت به جای استفاده از پیش فرض ها ، اما شاید 16 گیگابایت بهتر باشد. فقط اتاق و زمان بیشتری را به من می دهد تا توجه و مرتب سازی چیزها را انجام دهم.

zirias@

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

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

من فقط به سوال OP و تجربه خود در مورد 4 گیگابایت پیش فرض 4 گیگابایتی علاقه مندم - وارد کردن داده ها به MySQL چند بار باعث ایجاد OOM برای من شده است ، بنابراین دفعه بعد که سرور را راه اندازی کردم که قصد داشتم برای آن بروم8 گیگابایت به جای استفاده از پیش فرض ها ، اما شاید 16 گیگابایت بهتر باشد. فقط اتاق و زمان بیشتری را به من می دهد تا توجه و مرتب سازی چیزها را انجام دهم.

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

توجه 1: من فقط به این دلیل که بعد از حذف یک "بوتپول" قدیمی در اتاق HDD ها وجود داشت ، اینقدر وجود دارد. من از آن زمان تاکنون هرگز ندیده ام که سیستم من بیش از 8 گرم مبادله مصرف کند.

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

عضو حذف شده 67440

مهمان

صادقانه استفاده از پرونده مبادله (<12, for 13 I don't know) has always left me quite confused. There is no, or at least I don't know, a precise and reproducible logic.

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

نسخه کوتاه: در تئوری پرونده مبادله ممکن است به هیچ وجه به هیچ وجه وجود نداشته باشد ، حتی ممکن است محدود به 1MB باشد.

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

آیا این امکان وجود دارد که بنا به دلایلی ، صفحاتی که می توانستند (باید) در قوچ قرار داشته باشند در مبادله قرار می گیرند؟شاید آره. من فکر نمی کنم داشتن دستگاهی با بیش از 700 گیگابایت رم و شاید 3 مگابایت پرونده مبادله استفاده شود.

چرا یک صفحه واحد در مبادله استفاده می شود؟

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

این فقط یک حدس است ، من واقعاً نمی خواهم منبع مدیریت FreeBSD