حافظه نهان و ثبت نوشتن دو نقش جدا دارند
در بحث عملکرد OpenZFS معمولاً نام های ARC، L2ARC، ZIL و SLOG کنار هم شنیده می شوند. شباهت ظاهری آن ها، به ویژه وقتی چند SSD به یک سرور اضافه می شود، می تواند این تصور را ایجاد کند که همه نوعی cache برای افزایش سرعت اند. اما این اجزا نقش یکسانی ندارند. یکی به مسیر خواندن و استفاده دوباره از داده مربوط است و دیگری به قرارداد دوام نوشتن همگام. پیش از خرید یا تنظیم تجهیزات، باید بدانیم کدام انتظار برنامه کند است و کدام لایه می تواند آن را بهبود دهد.
فرض کنید سروری هم فایل های پروژه را ارائه می کند و هم دیسک چند ماشین مجازی را نگه می دارد. کاربران از کندی باز شدن فایل های تکراری شکایت دارند، در حالی که برنامه داخل یک ماشین مجازی از زمان زیاد تأیید نوشتن ناراضی است. هر دو مشکل با واژه «دیسک کند» توصیف می شوند، ولی مسیر حل می تواند متفاوت باشد. اندازه گیری باید نوع درخواست، میزان تکرار خواندن و الگوی درخواست دوام را جدا کند. افزودن SSD بدون این تفکیک ممکن است هزینه ایجاد کند و اثر اندکی داشته باشد.
ARC چه چیزی را بهبود می دهد؟
ARC حافظه نهان اصلی ZFS در RAM است و تلاش می کند داده مفید برای استفاده دوباره را نگه دارد. اگر یک بلوک مورد نیاز در این لایه موجود باشد، خواندن از ذخیره سازی کندتر لازم نیست. اما نرخ hit به الگوی بار وابسته است. خواندن یک مجموعه بزرگ برای یک بار با خواندن مکرر یک مجموعه کاری کوچک فرق دارد. از بالا بودن مصرف حافظه ARC نیز نباید بی درنگ نتیجه گرفت سیستم دچار نشت حافظه شده است؛ cache برای استفاده از حافظه قابل بهره برداری ساخته شده است.
با این حال RAM منبع مشترک میزبان است. اگر ماشین های مجازی یا پایگاه داده نیز به حافظه نیاز دارند، باید تعادل واقعی مشاهده شود. فقط عدد حافظه آزاد را نبینید؛ فشار حافظه، رفتار reclaim و عملکرد برنامه را هم بررسی کنید. تعیین سقف بر اساس نسخه و راهنمای سیستم عامل باید با آزمایش همراه باشد. سقف بسیار پایین می تواند خواندن دیسک را افزایش دهد و سقف نامتناسب ممکن است به برنامه های دیگر فشار بیاورد. هدف یک عدد زیبا در داشبورد نیست، بلکه عملکرد پایدار کل میزبان است.
مجموعه کاری از ظرفیت کل مهم تر است
ممکن است pool ده ها ترابایت داده داشته باشد ولی بخش پرکاربرد آن چند گیگابایت باشد. در این حالت مقدار RAM لازم برای cache را نمی توان فقط از اندازه pool حدس زد. برعکس، یک مجموعه کوچک تر با الگوی دسترسی تقریباً تصادفی و بدون تکرار ممکن است سود محدودی از cache اضافه بگیرد. باید بدانید چه داده ای در چه بازه زمانی دوباره خوانده می شود. این پرسش به رفتار برنامه نزدیک تر از مشخصات تبلیغاتی دیسک است.
برای آزمایش، اجرای سرد و گرم را جدا کنید. بار اول ممکن است عمدتاً به دیسک مراجعه کند و بار بعدی از ARC سود ببرد. اگر فقط بار دوم را اندازه بگیرید، توان واقعی ذخیره سازی در شروع مجدد میزبان را نمی بینید. اگر فقط بار اول را ببینید، فایده cache در کار روزانه را نادیده می گیرید. گزارش مناسب هر دو حالت و زمان رسیدن به وضعیت پایدار را نشان می دهد. این اطلاعات برای برنامه ریزی پس از reboot یا جابه جایی بار اهمیت دارد.
L2ARC ادامه همان مسئله خواندن است
L2ARC لایه اضافی cache خواندن روی دستگاه جداگانه است. وجود آن به این معنی نیست که هر خواندن فوراً از SSD انجام می شود یا کل ظرفیت اسمی آن از نخستین لحظه مفید خواهد بود. رفتار پر شدن و سیاست های مربوط به آن به پیاده سازی و تنظیمات وابسته است. همچنین مدیریت cache هزینه متادیتا و منابع دارد. پیش از اضافه کردن این لایه باید شواهدی وجود داشته باشد که داده قابل استفاده دوباره از ARC خارج می شود و خواندن از pool گلوگاه مهمی است.
در یک سرور فایل، اگر کاربرها بارها مجموعه ای بزرگ تر از RAM را مرور کنند، بررسی L2ARC می تواند منطقی باشد. اما اگر بیشتر بار نوشتن پیوسته و خواندن یک بار مصرف است، انتظار بهبود مشابه بی پایه خواهد بود. اندازه گیری hit لایه دوم و تأخیر درخواست های واقعی پس از تغییر لازم است. یک دستگاه اضافه که تقریباً هیچ hit مفیدی ندارد، شاید فقط پیچیدگی نگه داری را افزایش داده باشد. هر لایه باید با مسئله ای مشخص توجیه شود.
ZIL و قرارداد نوشتن همگام
برنامه ها همیشه درخواست نوشتن را با یک قرارداد دوام ارسال نمی کنند. برخی فقط می خواهند داده به سیستم عامل تحویل شود، در حالی که برخی درخواست می کنند پیش از تأیید، شرایط دوام لازم برقرار شود. ZIL به مسیر ثبت نیت نوشتن‌های همگام یا synchronous و امکان بازپخش لازم پس از وقفه مرتبط است. این نقش با cache عمومی برای همه نوشتن ها تفاوت دارد. فهم تفاوت synchronous و asynchronous برای تفسیر هر benchmark ذخیره سازی ضروری است.
اگر یک آزمایش فقط سرعت کپی فایل بدون درخواست دوام را اندازه بگیرد، نتیجه آن پاسخ مستقیمی به تأخیر commit یک پایگاه داده نمی دهد. برنامه پایگاه داده ممکن است پس از هر دسته تراکنش منتظر تضمین متفاوتی بماند. بنابراین باید بار آزمایشی تا حد امکان رفتار واقعی برنامه را بازسازی کند. نوع درخواست sync، اندازه نوشتن، تعداد جریان ها و سطح هم زمانی را ثبت کنید. بدون این جزئیات، مقایسه دو عدد throughput ممکن است مقایسه دو مسئله کاملاً متفاوت باشد.
SLOG چه چیزی است و چه چیزی نیست؟
SLOG دستگاه جداگانه ای برای بخش ثبت مرتبط با ZIL است. قرار دادن دستگاه مناسب می تواند بر تأخیر نوشتن‌های همگام یا synchronous اثر بگذارد، اما آن را نباید write cache عمومی دانست که همه داده برای مدت طولانی از آن عبور می کند. سود آن به میزان و الگوی نوشتن همگام و عملکرد دستگاه بستگی دارد. دستگاهی با ظرفیت زیاد ولی تأخیر نامناسب برای این نقش الزاماً انتخاب خوبی نیست. ویژگی دوام در قطع برق نیز باید در انتخاب و طراحی بررسی شود.
اگر برنامه اصلاً منتظر دوام نوشتن همگام نباشد، افزودن SLOG ممکن است تغییر محسوسی در benchmark نشان ندهد. این نتیجه لزوماً خرابی دستگاه نیست؛ شاید بار آزمایش از مسیری استفاده نمی کند که هدف تغییر بوده است. در مقابل، کاهش ظاهری تأخیر با نادیده گرفتن قرارداد sync می تواند نتیجه خطرناک و گمراه کننده بسازد. تغییر معنای تأیید نوشتن را نباید به عنوان بهینه سازی بی هزینه معرفی کرد. نیاز برنامه به دوام باید پیش از هر تغییر تنظیمات حفظ شود.
چرا عدد بزرگ سرعت کافی نیست؟
برای سرویس تعاملی، تأخیر انتهایی گاهی از میانگین throughput مهم تر است. اگر بیشتر نوشتن ها سریع باشند ولی هر چند دقیقه یک توقف طولانی رخ دهد، کاربران همچنان مشکل خواهند داشت. توزیع تأخیر، عمق صف و رفتار در زمان فعالیت هم زمان scrub یا سایر کارها را مشاهده کنید. تستی که در محیط کاملاً خالی اجرا شده، وضعیت تولید را کامل بازنمایی نمی کند. برنامه ظرفیت باید برای نگه داری و بازسازی پس از خرابی نیز جا داشته باشد.
همچنین داده آزمایش باید قابل مقایسه باشد. فشرده پذیری می تواند حجم واقعی کار دیسک را تغییر دهد. فایل پر از صفر با داده واقعی فشرده شده یا رمز شده یکسان نیست. اندازه رکورد، اندازه بلوک برنامه و طرح vdev نیز بر نتیجه اثر دارند. لازم نیست همه متغیرها را هم زمان تغییر دهید. یک فرضیه انتخاب کنید، یک تغییر محدود انجام دهید و شرایط دیگر را ثابت نگه دارید. در غیر این صورت معلوم نمی شود کدام عامل نتیجه را تغییر داده است.
پایش را به مسیر درخواست وصل کنیم
وقتی خواندن کند است، ابتدا میزان hit و تأخیر pool را با رفتار برنامه مقایسه کنید. وقتی تأیید نوشتن کند است، نوع sync و تأخیر دستگاه های مرتبط را بررسی کنید. در هر دو حالت، فشار CPU و حافظه نیز ممکن است عامل باشد. ابزارهای ZFS اطلاعات فراوانی می دهند، اما باید با پرسش مشخص به سراغ آن ها رفت. نمودار cache بدون دانستن اینکه کاربر چه عملی انجام می دهد، تفسیر محدودی دارد.
برای مثال ممکن است نرخ hit بالا باشد ولی کاربر همچنان منتظر بماند، چون گلوگاه در شبکه یا پردازش metadata برنامه است. یا نرخ hit پایین باشد ولی عملکرد کاملاً مناسب باشد، چون workload اساساً اسکن ترتیبی با پهنای باند کافی است. هدف بالا بردن یک درصد به تنهایی نیست. معیار اصلی باید زمان انجام کار مورد نیاز کاربر و پایداری آن باشد. متریک های داخلی برای توضیح علت به کار می روند، نه اینکه جای نتیجه واقعی خدمت را بگیرند.
خرابی و بازیابی بخشی از طراحی اند
هر دستگاه اضافه مسیر نگه داری و حالت خرابی جدیدی می سازد. پیش از استفاده از لایه جداگانه، رفتار از دست رفتن آن و توصیه های افزونگی را در مستندات نسخه بررسی کنید. cache خواندن و دستگاه ثبت نوشتن از نظر پیامد خرابی نقش یکسانی ندارند. این تفاوت باید در مستندات داخلی و رویه تعویض سخت افزار روشن باشد. فردی که دستگاه را عوض می کند نباید فقط از روی اندازه یا برچسب SSD تصمیم بگیرد که آن عضو چه نقشی دارد.
نام گذاری فیزیکی، شماره سریال و نقش هر دستگاه را ثبت کنید. در آزمون بازیابی از داده ساختگی استفاده کنید و رفتار قطع کنترل شده را با معیار صحت داده بسنجید. همچنین backup مستقل و آزمون بازگرداندن فایل یا حجم مورد نیاز را حفظ کنید. checksum و افزونگی برای سلامت و دسترس پذیری ارزش دارند، اما اشتباه منطقی یا حذف ناخواسته را خودکار برنمی گردانند. طراحی عملکرد باید در کنار طراحی بازیابی انجام شود تا سرعت بیشتر به اطمینان کاذب منجر نشود.
یک مسیر تصمیم گیری عملی
نخست بار را به خواندن تکراری، خواندن یک بار، نوشتن عادی و نوشتن همگام تقسیم کنید. سپس مجموعه کاری و نیاز حافظه برنامه های دیگر را بسنجید. اگر خواندن تکراری گلوگاه است، ARC و احتمالاً L2ARC را بررسی کنید. اگر تأخیر تأیید نوشتن همگام مسئله است، مسیر ZIL و تناسب SLOG مطرح می شود. این تقسیم بندی نسخه نهایی معماری نیست، اما از خرید دستگاه برای حل مسئله اشتباه جلوگیری می کند.
در پایان هر تغییر، همان کار واقعی را دوباره اندازه بگیرید و قرارداد دوام را ثابت نگه دارید. اگر نتیجه بهتر نشد، فرضیه را اصلاح کنید، نه اینکه بی دلیل تنظیمات بیشتری اضافه کنید. OpenZFS امکانات زیادی دارد، اما بهره برداری قابل اعتماد از آن با تفکیک نقش ها آغاز می شود. ARC و L2ARC به استفاده دوباره از داده مربوط اند؛ ZIL و SLOG به مسیر مشخصی از تضمین نوشتن. فهم این مرز، پایه تصمیم های دقیق تر درباره هزینه، سرعت و ریسک عملیاتی است.
