ترجمه مقاله در آستانه شروع دوره آماده شد .
به طور دوره ای، اینجا و آنجا، سؤالاتی در مورد توصیه های گلستر در مورد تنظیم هسته و اینکه آیا نیازی به این کار وجود دارد، مطرح می شود.
چنین نیازی به ندرت پیش می آید. در اکثر بارهای کاری، هسته عملکرد بسیار خوبی دارد. اگرچه یک نقطه ضعف وجود دارد. از لحاظ تاریخی، هسته لینوکس مایل بوده است که اگر فرصت داده شود، حافظه زیادی مصرف کند، از جمله برای کش کردن به عنوان راه اصلی برای بهبود عملکرد.
در بیشتر موارد، این کار خوب است، اما تحت بار سنگین می تواند منجر به مشکلات شود.
ما تجربه زیادی با سیستم های فشرده حافظه مانند CAD، EDA و مانند آن داریم که تحت بار سنگین شروع به کند شدن کردند. و گاهی اوقات در گلستر با مشکل مواجه می شدیم. پس از مشاهده دقیق حافظه استفاده شده و تأخیر دیسک برای چندین روز، اضافه بار، iowait بزرگ، خطاهای هسته (کرنل اوپس)، فریز و غیره را دریافت کردیم.
این مقاله حاصل بسیاری از آزمایش های تنظیمی است که در موقعیت های مختلف انجام شده است. به لطف این پارامترها، نه تنها پاسخگویی کلی بهبود یافته است، بلکه خوشه نیز به طور قابل توجهی تثبیت شده است.
وقتی صحبت از تنظیم حافظه به میان می آید، اولین چیزی که باید به آن توجه کرد، زیرسیستم حافظه مجازی (VM، حافظه مجازی) است که تعداد زیادی گزینه دارد که می تواند شما را گیج کند.
vm.swappiness
پارامتر vm.swappiness تعیین می کند که هسته در مقایسه با RAM چقدر از swap (swap، paging) استفاده می کند. همچنین در کد منبع به عنوان "تمایل به سرقت حافظه نقشه برداری" تعریف شده است. مبادله بالا به این معنی است که هسته تمایل بیشتری به مبادله صفحات نقشه برداری شده دارد. مقدار کم مبادله به معنای برعکس است: هسته کمتر از حافظه صفحه می شود. به عبارت دیگر، ارزش بالاتر است vm.swappiness، سیستم بیشتر از swap استفاده می کند.
استفاده زیاد از مبادله نامطلوب است، زیرا بلوک های عظیمی از داده ها در RAM بارگیری و تخلیه می شوند. بسیاری از مردم استدلال می کنند که مقدار تعویض باید زیاد باشد، اما در تجربه من، تنظیم آن روی "0" منجر به عملکرد بهتر می شود.
در اینجا می توانید بیشتر بخوانید -
اما، دوباره، این تنظیمات باید با دقت و تنها پس از آزمایش یک برنامه خاص اعمال شوند. برای برنامه های پخش جریانی بسیار بارگذاری شده، این پارامتر باید روی "0" تنظیم شود. هنگامی که به "0" تغییر می کند، پاسخگویی سیستم بهبود می یابد.
vm.vfs_cache_pressure
این تنظیم حافظه مصرف شده توسط هسته را برای ذخیره دایرکتوری و اشیاء inode (دنتری و inode) کنترل می کند.
با مقدار پیش‌فرض 100، کرنل سعی می‌کند تا کش‌های دندانه‌ای و inode را به‌صورت «عادلانه» به cache و swapcache آزاد کند. کاهش vfs_cache_pressure باعث می شود که کرنل کش های دندانی و inode را نگه دارد. وقتی مقدار "0" باشد، کرنل هرگز به دلیل فشار حافظه، کش دندانه ای و inode را شستشو نمی دهد و این به راحتی می تواند منجر به خطای خارج از حافظه شود. افزایش vfs_cache_pressure به بالای 100 باعث می‌شود که کرنل برای شستشوی دندانی و inode اولویت‌بندی کند.
هنگام استفاده از GlusterFS، بسیاری از کاربران با مقادیر زیاد داده و بسیاری از فایل‌های کوچک می‌توانند به راحتی از مقدار قابل توجهی RAM بر روی سرور به دلیل کش کردن inode/dentry استفاده کنند، که می‌تواند منجر به کاهش عملکرد شود زیرا هسته مجبور است ساختارهای داده را در یک سیستم پردازش کند. با 40 گیگابایت حافظه تنظیم این مقدار بالای 100 به بسیاری از کاربران کمک کرده است تا حافظه پنهان عادلانه تری داشته باشند و پاسخگویی هسته را بهبود بخشند.
vm.dirty_background_ratio و vm.dirty_ratio
پارامتر اول (vm.dirty_background_ratio) درصد حافظه با صفحات کثیف را تعیین می کند که پس از رسیدن به آن باید شروع به شستشوی صفحات کثیف در پس زمینه روی دیسک کنید. تا زمانی که به این درصد برسد، هیچ صفحه‌ای روی دیسک فلاش نمی‌شود. و هنگامی که تنظیم مجدد شروع می شود، بدون وقفه در فرآیندهای در حال اجرا در پس زمینه اجرا می شود.
پارامتر دوم (vm.dirty_ratio) درصد حافظه ای را که می تواند توسط صفحات کثیف قبل از شروع فلاش اجباری اشغال شود را مشخص می کند. پس از رسیدن به این آستانه، همه فرآیندها همزمان می شوند (مسدود می شوند) و اجازه ندارند تا زمانی که I/O درخواست شده در واقع تکمیل شود و داده ها روی دیسک قرار نگیرند، ادامه دهند. با I/O سنگین، این باعث ایجاد مشکل می‌شود، زیرا هیچ ذخیره‌سازی داده وجود ندارد و تمام فرآیندهایی که I/O را انجام می‌دهند در انتظار I/O مسدود می‌شوند. این منجر به تعداد زیادی فرآیندهای آویزان، بار بالا، بی ثباتی سیستم و عملکرد ضعیف می شود.
کاهش این تنظیمات باعث می شود که داده ها به دفعات بیشتر بر روی دیسک ریخته شوند و در RAM ذخیره نشوند. این می‌تواند به سیستم‌های پرحافظه کمک کند که در آن‌ها تخلیه کش صفحه‌های 45 تا 90 گیگابایتی روی دیسک طبیعی است، که منجر به تأخیر بسیار زیادی برای برنامه‌های جلویی می‌شود و پاسخگویی و تعامل کلی را کاهش می‌دهد.
"1" > /proc/sys/vm/pagecache
کش صفحه، کشی است که داده های فایل ها و برنامه های اجرایی را ذخیره می کند، یعنی صفحاتی با محتوای واقعی فایل ها یا دستگاه های مسدود شده هستند. این کش برای کاهش تعداد خواندن دیسک استفاده می شود. مقدار "1" به این معنی است که 1٪ از RAM برای حافظه پنهان استفاده می شود و تعداد خوانده شده از دیسک بیشتر از RAM خواهد بود. نیازی به تغییر این تنظیمات نیست، اما اگر در مورد کنترل کش صفحه پارانویا هستید، می توانید از آن استفاده کنید.
"deadline" > /sys/block/sdc/queue/scheduler
زمانبندی I/O یک جزء هسته لینوکس است که صف های خواندن و نوشتن را مدیریت می کند. در تئوری، بهتر است از "noop" برای یک کنترلر RAID هوشمند استفاده شود، زیرا لینوکس چیزی در مورد هندسه فیزیکی دیسک نمی داند، بنابراین کارآمدتر است که به کنترل کننده اجازه دهید که هندسه دیسک را به خوبی می شناسد، درخواست را با همان سرعت پردازش کند. ممکن است. اما به نظر می رسد "مهلت" عملکرد را بهبود می بخشد. می‌توانید اطلاعات بیشتری درباره زمان‌بندی‌ها در اسناد کد منبع لینوکس بخوانید: linux/Documentation/block/*osched.txt. و همچنین افزایش توان خواندن در طول عملیات مختلط (بسیاری از نوشتن) را دیده ام.
"256" > /sys/block/sdc/queue/nr_requests
تعداد درخواست‌های ورودی/خروجی در بافر قبل از ارسال به زمان‌بند. اندازه صف داخلی برخی از کنترلرها (queue_depth) بزرگتر از nr_requests زمانبندی I/O است، بنابراین زمانبندی I/O شانس کمی برای اولویت بندی و ادغام درخواست ها به درستی دارد. برای زمان‌بندی‌های مهلت و CFQ، زمانی که nr_requests 2 برابر صف داخلی کنترلر باشد، بهتر است. ادغام و ترتیب مجدد درخواست ها به زمانبندی کمک می کند تا تحت بار سنگین پاسخگوتر باشد.
echo "16" > /proc/sys/vm/page-cluster
پارامتر page-cluster تعداد صفحاتی که در یک زمان روی مبادله نوشته می شوند را کنترل می کند. در مثال بالا، مقدار با توجه به اندازه نوار RAID 16 کیلوبایت روی "64" تنظیم شده است. با swappiness = 0 معنی ندارد، اما اگر swappiness را روی 10 یا 20 تنظیم کنید، استفاده از این مقدار زمانی که اندازه نوار RAID 64K باشد به شما کمک خواهد کرد.
blockdev --setra 4096 /dev/<devname> (-sdb، hdc یا dev_mapper)
تنظیمات بلوک پیش‌فرض دستگاه برای بسیاری از کنترل‌کننده‌های RAID اغلب منجر به عملکرد وحشتناکی می‌شود. با افزودن گزینه بالا، Read-Ahead برای بخش های 4096 * 512 بایتی تنظیم می شود. حداقل، برای عملیات استریم، سرعت با پر کردن حافظه پنهان دیسک روی تراشه با خواندن پیش‌خوان در طول دوره‌ای که هسته برای آماده‌سازی ورودی/خروجی استفاده می‌کند، افزایش می‌یابد. کش می تواند حاوی داده هایی باشد که در خواندن بعدی درخواست می شود. اگر از زمان بالقوه مفید دیسک استفاده کند یا داده‌های خارج از حافظه پنهان را بارگیری کند، واکشی بیش از حد اولیه می‌تواند ورودی/خروجی تصادفی را برای فایل‌های بزرگ از بین ببرد.
در زیر چند توصیه دیگر در سطح سیستم فایل آورده شده است. اما هنوز تست نشده اند. مطمئن شوید که سیستم فایل شما اندازه نوار و تعداد دیسک های موجود در آرایه را می داند. به عنوان مثال، این یک آرایه 5K stripe raid64 از شش دیسک است (در واقع پنج دیسک، زیرا یک دیسک برای برابری استفاده می شود). این توصیه ها بر اساس مفروضات نظری است و از وبلاگ ها/مقالات مختلف توسط کارشناسان RAID گردآوری شده است.
-> ext4 fs, 5 disks, 64K stripe, units in 4K blocks
mkfs -text4 -E stride=$((64/4))
-> xfs, 5 disks, 64K stripe, units in 512-byte sectors
mkfs -txfs -d sunit=$((64*2)) -d swidth=$((5*64*2))برای فایل‌های بزرگ، اندازه نوار فهرست شده در بالا را افزایش دهید.
WARNING! هر چیزی که در بالا توضیح داده شد برای برخی از انواع برنامه ها بسیار ذهنی است. این مقاله هیچ گونه پیشرفتی را بدون آزمایش قبلی برنامه های مرتبط توسط کاربر تضمین نمی کند. فقط در صورتی باید استفاده شود که برای بهبود پاسخگویی کلی سیستم ضروری باشد یا مشکلات فعلی را حل کند.
مواد اضافی:
ادامه مطلب
منبع: www.habr.com