MariaDB TAF؛ اندازه‌گیری هزینهٔ subsystem‌ها روی سخت‌افزارهای مختلف

چرا مهم است

اگر با تنظیمات MariaDB کار می‌کنی، هزینهٔ هر قابلیت روی سخت‌افزار تو لزوماً با ماشین دیگر یکسان نیست. این مجموعه نشان می‌دهد چطور می‌توان اثر هر subsystem را جداگانه و با workload ثابت اندازه گرفت.

قبل از خواندن، این‌ها را بدان۴ مفهوم
throughput

مقدار کاری که یک سیستم در واحد زمان انجام می‌دهد؛ برای نمونه، تعداد transaction‌هایی که در هر ثانیه پردازش می‌شوند.

در حال نگارش: throughput

buffer pool

بخشی از memory که موتور database برای نگهداری صفحه‌های داده و index استفاده می‌کند تا نیاز به خواندن دوبارهٔ آن‌ها از storage کمتر شود.

در حال نگارش: buffer pool

isolation level

سطحی که تعیین می‌کند transaction‌ها تا چه اندازه تغییرات یکدیگر را می‌بینند و چه محدودیت‌هایی برای دسترسی هم‌زمان به داده دارند.

در حال نگارش: isolation level

instrumentation

افزودن سازوکارهای اندازه‌گیری و ثبت رویداد به سیستم برای مشاهدهٔ رفتار و بررسی عملکرد آن.

در حال نگارش: instrumentation

MariaDB Foundation در TAF مجموعه‌ای ساختاریافته از profile‌های عملکردی آماده کرده تا هزینهٔ subsystem‌های MariaDB را روی سخت‌افزارهای مختلف اندازه بگیرد. هدف این مجموعه tuning نیست؛ هر آزمایش یک subsystem را جدا می‌کند و اثر آن را بر throughput می‌سنجد. ایدهٔ اولیه را Monty در MDEV‑39497 مطرح کرده بود و حالا به مجموعه‌ای از آزمایش‌های تکرارپذیر گسترش یافته است.

دلیل این رویکرد، ثابت نبودن هزینهٔ قابلیت‌هاست. معماری CPU،؜ تعداد core،؜ چیدمان NUMA،؜ نوع storage،؜ filesystem،؜ پهنای باند memory،؜ network stack و شکل workload همگی بر نتیجه اثر می‌گذارند. بنابراین هزینه‌ای که یک تنظیم روی یک ماشین دارد، لزوماً روی ماشین دیگر تکرار نمی‌شود. این profile‌ها برای بررسی همین تفاوت‌ها، در هر مرحله فقط یک تنظیم را تغییر می‌دهند.

پیش از اجرای آزمایش‌ها، تعداد warehouse‌هایی تعیین می‌شود که داده‌هایشان کاملاً در buffer pool جا می‌گیرد. این مرحله برای جلوگیری از جابه‌جایی مداوم داده در buffer pool و محدود شدن آزمایش به I/O انجام می‌شود و یک baseline پایدار برحسب TPS می‌سازد. سپس profile‌ها با workload و تعداد warehouse یکسان اجرا می‌شوند تا مبنای مقایسه ثابت بماند.

دامنهٔ آزمایش‌ها چند بخش اصلی را پوشش می‌دهد. profile‌های binlog هزینهٔ durability و تضمین‌های replication را بررسی می‌کنند؛ از روشن یا خاموش بودن binlog تا حالت‌های minimal،؜ no-blob و semi-sync. در بخش InnoDB،؜ تنظیم‌هایی مانند doublewrite،؜ adaptive hash index،؜ مقدار flush log at trx commit و isolation level بررسی می‌شوند. profile‌های Performance Schema نیز هزینهٔ instrumentation را در چند سطح اندازه می‌گیرند.

بخش‌های دیگر به مقایسهٔ زمان‌بندی threadpool با زمان‌بندی thread در OS،؜ هزینهٔ تبدیل charset برای latin1 و utf8mb3،؜ هزینهٔ general log و slow query log و هزینهٔ connection رمزگذاری‌شده با SSL اختصاص دارند. این‌ها ترکیبی از توصیه‌های تنظیماتی نیستند؛ هر profile برای پاسخ دادن به یک پرسش مشخص طراحی شده است.

به‌گفتهٔ MariaDB Foundation،؜ این مجموعه مبنایی برای تفکیک هزینهٔ خود MariaDB از محدودیت‌های سخت‌افزار، مقایسهٔ ماشین‌ها و بررسی regression میان نسخه‌ها فراهم می‌کند. profile‌ها، script‌های اجرا، ابزارهای تعیین اندازهٔ warehouse و نمونه‌های اتصال به TAF در README.md مربوط به repository مستند شده‌اند. متن معرفی، عدد مشخصی از نتایج آزمایش‌ها ارائه نمی‌کند.

نکته کلیدی

برای چنین مقایسه‌ای، اول تعداد warehouse را طوری تعیین کن که داده‌ها در buffer pool جا بگیرند و baseline پایدار شود. بعد در هر آزمایش فقط یک تنظیم را تغییر بده؛ هدف این profile‌ها اندازه‌گیری است، نه ارائهٔ تنظیمات بهینه.

خواندن مقاله اصلی (در زبانه‌ی جدید باز می‌شود)
برچسب‌ها (۵)