پیکربندی و تنظیمات دیتابیس:تخصیص حافظه MariaDB

تخصیص حافظه MariaDB

 

 

اگر فقط از MyISAM استفاده می کنید ، key_buffer_size را روی ۲۰٪ RAM موجود تنظیم کنید. (به علاوه innodb_buffer_pool_size = 0)

 

اگر فقط از InnoDB استفاده می کنید ، اندازه innodb_buffer_pool_ را روی ۷۰٪ RAM موجود تنظیم کنید. (به علاوه key_buffer_size = 10M ، کم ، اما صفر نیست.)

 

قوانین کلی برای تنظیم:

 

  • با کپی منتشر شده از cnf یا my.ini شروع کنید.

 

  • key_buffer_size و innodb_buffer_pool_size را با توجه به میزان مصرف موتور و RAM تغییر دهید.

 

  • کوئری های کند معمولاً از طریق ایندکس ها fixed است ، تغییرات شِما (schema) یا تغییرات SELECT قابل رفع هستند ، نه با میزان سازی (tuning).

 

  • تا زمانی که متوجه نشوید چه کاری می تواند انجام دهد و چه کاری نمی تواند انجام دهد ، از کَشِ کوئری استفاده نکنید.

 

  • هیچ چیز دیگری را تغییر ندهید ، مگر اینکه با مشکل مواجه شوید (به عنوان مثال ، max connections).

 

  • مطمئن شوید که تغییرات در بخش [mysqld] است ، نه در بخش دیگر.

 

  • ۲۰٪ تا ۷۰٪ فرض می کنید حداقل ۴ گیگابایت RAM دارید. اگر سرور عتیقه کوچک یا ماشین مجازی کوچک دارید ، این درصدها خیلی زیاد است.

 

 

اکنون برای جزئیات کار

چگونه می توان مشکل out-of-memory را عیب یابی کرد

اگر سرور MariaDB به دلیل ‘out-of-memory’ خراب شود ، احتمالاً به اشتباه پیکربندی شده است.

 

در MariaDB دو نوع بافر وجود دارد:

 

  • گلوبال (سراسری یا جهانی) که فقط یک بار در طول عمر سرور اختصاص داده می شوند:

 

  • بافرهای ذخیره سازی موتور (innodb_buffer_pool_size ، key_buffer_size ، aria_pagecache_buffer_size ، و غیره)

 

  • query_cache_size حافظه پنهان پرس و جو.

 

 

  • کَشهای گلوبال (سراسری یا جهانی) که بر اساس تقاضا کوچک و بزرگ میشوند و به حداکثر ممکن می رسند:

 

  • max_user_connections
  • table_open_cache
  • table_definition_cache
  • thread_cache_size

 

  • بافرهای محلی (Local buffers) که در صورت تقاضا هر زمان که نیاز باشد اختصاص داده می شوند

 

  • موارد داخلی که هنگام ایجاد اندیکس موتور استفاده می شوند

(myisam_sort_buffer_size, aria_sort_buffer_size).

 

  • بافرهای داخلی برای ذخیره blobها.

 

  • برخی از موتورهای ذخیره سازی در هنگام اسکن یک جدول یک کَش موقت را برای ذخیره بزرگترین blob دیده شده نگه می دارند. این کش در پایان پرس و جو آزاد خواهد شد. توجه داشته باشید که ذخیره سازی موقت blob در اطلاعات processlist منضم (include) نمیشود بلکه فقط در مجموع حافظه (total memory) استفاده میشود (نمایش وضعیت جهانی مانند “memory_used”).

 

  • بافرها و کَش های مورد استفاده در هنگام اجرای کوئری:
متغیر توضیح
join_buffer_size زمانی استفاده می شود که از هیچ کلیدی برای یافتن یک ردیف در جدول بعدی استفاده نشود
mrr_buffer_size Size of buffer to use when using multi-range read with range access

اندازه بافر برای استفاده در هنگام استفاده از خواندن محدوده-چندتایی با دسترسی به محدوده

net_buffer_length Max size of network packet

حداکثر اندازه بسته شبکه

read_buffer_size هنگام وارد کردن توده وار (bulk insert)  توسط برخی موتورهای ذخیره سازی (storage engines) استفاده می شود
sort_buffer_size هنگام انجام ORDER BY یا  GROUP BY
max_heap_table_size Used to store temporary tables in memory. See Optimizing memory tables

برای ذخیره جداول موقتی در حافظه (memory) استفاده می شود. بهینه سازی جداول حافظه را مشاهده کنید که در هنگام وارد کردن توده وار (bulk insert) توسط برخی از موتورهای ذخیره سازی استفاده می شود.

 

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

در نصب پیش فرض MariaDB ، پیش فرضِ اکثر متغیرهای فوق مقدار بسیار کم است تا اطمینان حاصل شود که حافظه شما تمام نمی شود.

با اجرای دستور sql زیر می توانید بررسی کنید که کدام متغیرها در برپاسازی تغییر کرده اند. اگر با مشکل out-of-memory روبرو هستید ، به احتمال زیاد متغیر مشکل دار در این لیست وجود دارد!

 

 

 

select information_schema.system_variables.variable_name,

information_schema.system_variables.default_value,

global_variables.variable_value from

information_schema.system_variables,information_schema.global_variables where

system_variables.variable_name=global_variables.variable_name and

system_variables.default_value <> global_variables.variable_value and

system_variables.default_value <> ۰

 

 

Key Buffer چیست؟

MyISAM دو کار مختلف برای کَش کردن انجام می دهد.

بلوک های ایندکس (۱KB each, BTree structured, from .MYI file)  در “key buffer” زندگی می کنند.

کَش بلوک داده (از فایل .MYD) به سیستم عامل سپرده شده است ، بنابراین مطمئن باشید که برای این کار یک خوشه فضای خالی نیز در نظر بگیرید. Caveat: برخی از نسخه های سیستم عامل همیشه ادعا می کنند که بیش از ۹۰٪ استفاده می کنند ، حتی وقتی فضای خالی زیادی وجود دارد.

SHOW GLOBAL STATUS LIKE ‘Key%’;

 

سپس Key_read_requests / Key_reads را محاسبه کنید. اگر زیاد باشد (مثلاً بیش از ۱۰) ، بافر کلید به اندازه کافی بزرگ است ، در غیر این صورت باید مقدار key_buffer_size را تنظیم کنید.

استخر بافر(Buffer Pool) چیست؟

InnoDB همه کش خود را در یک استخر بافر انجام می دهد ، اندازه آن توسط innodb_buffer_pool_size کنترل می شود. به طور پیش فرض شامل داده های ۱۶KB و بلوک های ایندکس از جداول باز است (به innodb_page_size مراجعه کنید) ، بعلاوه برخی از هزینه های بالاسریِ تعمیر و نگهداری.

از MariaDB 5.5 ، داشتن چندین استخر بافر مجاز است. این می تواند کمک کند زیرا در هر استخر یک mutex وجود دارد و در نتیجه برخی از گلوگاه های mutex را تسکین می دهد.

اطلاعات بیشتر در مورد تنظیم InnoDB

 

الگوریتم دیگر

این تنظیمات کَش اصلی را به حداقل می رساند. این می تواند برای سیستم های دارای بسیاری پردازش های دیگر و/یا رَم ۲ گیگابایتی یا کمتر مهم باشد.

SHOW TABLE STATUS را برای تمام جداول موجود در تمام پایگاه های داده انجام دهید.

برای تمام جداول MyISAM  مورد  Index_length را اضافه کنید. key_buffer_size  را بزرگتر از آن اندازه تنظیم نکنید.

برای تمام جداول InnoDB Data_length + Index_length را اضافه کنید. innodb_buffer_pool_size را در بیش از ۱۱۰٪ از مجموع تنظیم کنید.

اگر این منجر به مبادله (swapping) شد ، هر دو تنظیمات را دوباره تقلیل دهید. پیشنهاد کنید به طور متناسب آنها را کاهش دهید.

این را اجرا کنید تا مقادیر سیستم خود را مشاهده کنید. (اگر جداول زیادی دارید ، ممکن است دقایقی طول بکشد.)

SELECT  ENGINE,

        ROUND(SUM(data_length) /۱۰۲۴/۱۰۲۴, ۱) AS “Data MB”,

        ROUND(SUM(index_length)/۱۰۲۴/۱۰۲۴, ۱) AS “Index MB”,

        ROUND(SUM(data_length + index_length)/۱۰۲۴/۱۰۲۴, ۱) AS “Total MB”,

        COUNT(*) “Num Tables”

    FROM  INFORMATION_SCHEMA.TABLES

    WHERE  table_schema not in (“information_schema”, “PERFORMANCE_SCHEMA”, “SYS_SCHEMA”, “ndbinfo”)

    GROUP BY  ENGINE;

 

تخصیص حافظه کوئری

دو متغیر وجود دارد که نحوه تخصیص حافظه توسط MariaDB هنگام تجزیه و اجرای یک کوئری را تعیین می کند. query_prealloc_size  بافر استاندارد را برای حافظه تعریف می کند که برای اجرای کوئری و query_alloc_block_size استفاده می شود که اندازه بلوک های حافظه است اگر query_prealloc_size به اندازه کافی بزرگ نباشد. درست سازی این متغیرها باعث کاهش تکه تکه شدن حافظه (memory fragmentation) در سرور می شود.

 

Mutex Bottleneck

MySQL در زمان دستگاههای تک پردازنده طراحی شد و برای راحتی اتصال به معماریهای مختلف طراحی شد. متأسفانه ، این منجر به برخی از شلختگی ها در نحوه بهم پیوستن اکشنها و فعالیتها می شود. تعداد اندکی (خیلی کوچک) “mutexes” برای دسترسی به چندین پروسس بحرانی وجود دارد. توجه داشته باشید:

key_buffer متعلق به  MyISAM

 

کَش کوئری

buffer_pool در Innodb با جعبه های چند هسته ای ، مشکل mutex باعث مشکلات کارایی و پرفرمنس می شود. به طور کلی ، از ۴-۸ هسته گذشته ، MySQL کندتر می شود ، نه سریعتر. MySQL 5.5 و  XtraDB ساخت Percona در InnoDB تا حدودی بهتر شده اند. حد عملی هسته ها بیشتر به ۳۲ هسته شباهت دارد و نمودار پرفورمنس پس از آن عوض کاهش تمایل به خط افقی دارد (ثابت میماند) است. ۵.۶ ادعا می کند که تا حدود ۴۸ هسته توانایی دارد.

 

HyperThreading و چند هسته (CPU)

پاسخ کوتاه (برای نسخه های قدیمی MySQL و MariaDB):

HyperThreading را خاموش کنید

هسته های بالاتر از ۸ را خاموش کنید

HyperThreading بیشتر مربوط به گذشته است ، بنابراین این بخش ممکن است اعمال نشود.

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

علاوه بر این MySQL در استفاده از چندین هسته عالی نیست. بنابراین ، اگر HT را خاموش کنید ، هسته های باقیمانده کمی سریعتر کار می کنند.

 

سیستم عامل ۳۲ بیتی و MariaDB

 

اول ، اگر این همان چیزی است که دارید ، سیستم عامل (و سخت افزار؟) دست به یکی می کنند تا اجازه ندهند از همه ۴ گیگابایت استفاده کنید. اگر بیش از ۴ گیگابایت رم دارید ، بیش از ۴ گیگابایت RAM در کل سیستم عامل ۳۲ بیتی غیرقابل دسترسی و غیرقابل استفاده است.

 

ثانیا ، سیستم عامل احتمالاً محدودیتی در میزان RAM برای استفاده در هر فرآیند دارد.

 

مثال: Maxdsiz FreeBSD ، که به طور پیش فرض ۵۱۲ مگابایت است.

 

مثال:

 $ ulimit -a…max memory size (kbytes, -m) 524288

 

بنابراین ، پس از تعیین مقدار حافظه RAM برای mysqld مقدار ، ۲۰٪ / ۷۰٪ را اعمال کنید ، اما مقدار را به پایین گرد کنید.

 

اگر با خطایی مانند

[ERROR] /usr/libexec/mysqld: Out of memory (Needed xxx bytes)

 روبرو شدید ، احتمالاً به این معنی است که مقدار MySQL از آنچه سیستم عامل تمایل داشته بدهد ، تجاوز کرده است. پس تنظیمات کَش را کاهش دهید.

 

سیستم عامل ۶۴ بیتی با ماریادیبیس ۳۲ بیتی

 

در این حالت سیستم عامل به ۴ گیگابایت محدود نمی شود ، اما MariaDB محدود است.

 

اگر حداقل ۴ گیگابایت RAM دارید ، شاید این موارد خوب باشد:

 

key_buffer_size  = ۲۰% از همه رم ، اما بیش از ۳G نیست

innodb_buffer_pool_size = 3G

 

احتمالاً باید MariaDB را به ۶۴ بیتی ارتقا دهید.

 

 

 

 

سیستم عامل ۶۴ بیتی و MariaDB

 

فقط  در MyISAM:  تنظیم کنید key_buffer_size: حدود ۲۰٪ RAM را استفاده کنید. (در my.cnf / my.ini) innodb_buffer_pool_size=0 تنظیم کنید.

 

فقط  در InnoDB:  تنظیم کنید  innodb_buffer_pool_size = 70٪ RAM. اگر RAM زیادی دارید و از ۵.۵ (یا بالاتر) استفاده می کنید ، داشتن چندین pool را در نظر بگیرید. شرایط ۱-۱۶ innodb_buffer_pool_instances را توصیه کنید ، به این ترتیب که هرکدام از ۱ گیگابایت کوچکتر نباشند. (متأسفیم ، هیچ معیاری در مورد میزان کمک به شما وجود ندارد ؛ احتمالاً زیاد نیست.)

 

در همین حال ، تنظیم کنید:key_buffer_size = 20M (کوچک ، اما غیر صفر)

 

اگر ترکیبی از موتور دارید ، هر دو عدد را کم کنید.

 

max_connections و thread_stack هر “thread(نخ)” مقداری RAM را می گیرد. قبلاً این حدود ۲۰۰ کیلوبایت بود. ۱۰۰ نخ۲۰ مگابایت خواهد بود ، اندازه قابل توجهی ندارد. اگر max_connections = 1000 دارید ، در مورد ۲۰۰ مگابایت صحبت می کنید ، شاید بیشتر. داشتن بسیاری از اتصالات احتمالاً بیانگر موارد دیگری است که باید مورد توجه قرار گیرند.

 

در ۵.۶ (یا MariaDB 5.5) ، اتصال نخ اختیاری با max_connections ارتباط برقرار می کند. این یک موضوع پیشرفته تر است

 

اضافه شدن پشته نخ (Thread stack overrun) به ندرت اتفاق می افتد. اگر چنین شد ، کاری مانند thread_stack=256K انجام دهید

 

اطلاعات بیشتر در مورد max_connections ، wait_timeout ، استخر اتصال و غیره

 

table_open_cache

 

(در نسخه های قدیمی این table_cache بود)

 

سیستم عامل دارای محدودیتی در تعداد فایل های باز است که به شما اجازه می دهد یک پروسس داشته باشد. هر جدول به ۱ تا ۳ فایل باز نیاز دارد. هر PARTITION در واقع یک جدول است. بیشتر عملیات روی یک جدول پارتیشن بندی همه پارتیشن ها را باز می کند.

 

در *nix ،دستور  ulimit به شما می گوید که محدودیت فایل چیست. حداکثر مقدار ده ها هزار است ، اما گاهی اوقات فقط ۱۰۲۴ تنظیم می شود. این شما را به حدود ۳۰۰ جدول محدود می کند. بحث بیشتر در مورد ulimit

 

(این پاراگراف مورد اختلاف است.) در طرف دیگر ، کَش جدول به طور ناکارآمد اجرا میشود – جستجوها با یک اسکن خطی انجام شد. از این رو ، تنظیم table_cache به هزار نفر در واقع می تواند سرعت mysql را کاهش دهد. (بنچمارکها این را نشان داده اند.)

 

از طریق SHOW GLOBAL STATUS می توانید خوبی عملکرد سیستم خود را مشاهده کنید. و محاسبه opens/second از طریق Opened_files/Uptime اگر این بیش از مثلا ۵ باشد ، باید table_open_cache افزایش یابد. اگر کمتر از ، مثلاً ۱ باشد ، ممکن است با کاهش table_open_cache بهبود پیدا کنید.

 

از MariaDB 10.1  مقدار  table_open_cache به طور پیش فرض تا ۲۰۰۰ است.

 

کَش کوئری

 

پاسخ کوتاه: query_cache_type = OFF و query_cache_size = 0

 

Query Cache (QC) در واقع یک نگاشت هش (hash mapping) است که عبارات SELECT را به مجموعه نتایج می زند.

 

پاسخ طولانی … جنبه های بسیاری از “Query cache” وجود دارد. بسیاری منفی هستند.

 

هشدار تازه کار! QC کاملاً با key_buffer و buffer_pool ارتباطی ندارد.

وقتی مفید است ، QC مثل برق سریع است. ایجاد بنچمارکی که ۱۰۰۰ برابر سریعتر باشد کار سختی نخواهد بود.

یک mutex وجود دارد که QC را کنترل می کند.

QC  برای هرکدام از SELECT ها مشاوره می شود ، مگر اینکه OFF و ۰ باشد.

بله ، mutex زده می شود حتی اگر query_cache_type = DEMAND.

بله ، mutex حتی برای SQL_NO_CACHE هم زده می شود.

هرگونه تغییر در پرس و جو (حتی افزودن فاصله) منجر به (به طور بالقوه) ورودی متفاوت در QC می شود.

اگر my.cnf بگوید type=ON و بعداً آن را OFF کنید ، کاملاً خاموش نمیشود. مراجعه: https://bugs.mysql.com/bug.php?id=60696

 

“هرس” پرهزینه و مکرر است:

 

وقتی _ همه_ نوشتن روی میز اتفاق می افتد ، _ همه_ ورودی های QC برای آن جدول حذف می شوند.

این حتی در یک Slave فقط خواندنی اتفاق می افتد.

خالی کردن (purge) با یک الگوریتم خطی انجام می شود ، بنابراین یک QC بزرگ (حتی ۲۰۰ مگابایت) می تواند به طور محسوسی کند باشد.

 

برای مشاهده عملکرد QC خود ،

SHOW GLOBAL STATUS LIKE ‘Qc%’;

 سپس میزان خواندن ضربه را محاسبه کنید: Qcache_hits / Qcache_inserts اگر تمام شود ، مثلاً ۵ ، QC ممکن است ارزش نگهداری داشته باشد.

 

اگر تصمیم گرفتید QC برای شما مناسب باشد ، پس من توصیه می کنم

 

query_cache_size = نه بیش از ۵۰M

query_cache_type = DEMAND

SQL_CACHE یا SQL_NO_CACHE در همه SELECT ها ، که بر آن اساس که کوئری ها از کَش سود می برند.

 

چرا QC را خاموش کنیم

بحث درباره اندازه

 

thread_cache_size

ازنسخه  MariaDB 10.2.0نیازی به تنظیم thread_cache_size نیست. قبلاً ، آن متغیر قابل تنظیم جزئی بود. صفر ایجاد نخ (اتصال) را کند می کند. یک عدد کوچک (مثلاً ۱۰) غیر صفر خوب است. این تنظیم اساساً تاثیری در میزان استفاده از RAM ندارد.

تعدادی فرآیندهای اضافی هست که باید به آنها متصل شود. این تعداد رشته ها را محدود نمی کند؛ ولی max_connections می کند.

ثبت وقایع مربوط به باینری

اگر ثبت وقایع باینری (از طریق log_bin) را برای تکثیر و/یا بازیابی به موقع روشن کرده باشید ، سیستم برای همیشه فایل های باینری ایجاد می کند. پس می توانند به آرامی دیسک را پر کنند. برای نگه داشتن تنها ۱۴ روز گزارش ، تنظیم کنید expire_logs_days = 14.

swappiness

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

MariaDB دوست دارد که تخصیص RAM از ثبات بالایی برخوردار باشد – کَش (بیشتر) از قبل اختصاص یافته است. رشته ها و غیره (بیشتر) دامنه محدودی دارند. هر تعویض (swapping) احتمالاً عملکرد MariaDB را به شدت آسیب می زند.

با داشتن مقدار بالایی برای قابلیت swap ، مقداری RAM را از دست می دهید زیرا سیستم عامل سعی دارد فضای زیادی را برای تخصیص های بعدی خالی نگه دارد (که MySQL احتمالاً نیازی به آن نخواهد داشت).

با swappiness = 0 ، سیستم عامل احتمالاً خراب می شود تا مبادله. من ترجیح می دهم که MariaDB لنگ لنگان باشد تا اینکه بمیرم. آخرین توصیه swappiness = 1. (2015)

اطلاعات بیشتر

جایی در این بین (مثلاً ۵؟) ممکن است برای یک سرورِ که فقط MariaDB میزبانی میکند ارزش خوبی داشته باشد.

 

NUMA

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

سپس سیستم عامل وارد صحنه می شود. حداقل در یک مورد (RHEL؟) ، دو کار انجام شده است:

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

حالا برای مشکل.

سیستم عامل و MariaDB تمام “اولین” RAM را اختصاص داده اند.

MariaDB مقداری ازحافظه داخلی دوم را اختصاص داده است.

سیستم عامل نیاز به اختصاص چیزی دارد. Ouch – در CPU جایی که مایل است چیزهای خود را اختصاص دهد جای زیادی نیست ، بنابراین برخی از MariaDB را swaps out می کند. بد است.

dmesg | grep -i numa # to see if you have numa

راه حل احتمالی: BIOS را برای “مخلوط کردن(interleave)” تخصیص RAM تنظیم کنید. این باید با swapping زودرس ، با هزینه دسترسی RAM خارج از پردازنده (off-CPU RAM accesses)، به نصف زمان برسد. خوب ، به هر حال شما دسترسی های پرهزینه ای دارید ، زیرا واقعاً می خواهید از همه RAM استفاده کنید. نسخه های قدیمی MySQL: numactl –interleave = all. یا: innodb_numa_interleave = 1

 

راه حل ممکن دیگر: numa را خاموش کنید (اگر سیستم عامل راهی برای انجام آن دارد)

به طور کلی از دست دادن عملکرد/افزایش عملکرد: چند درصد خواهد بود.

صفحات عظیم

این یکی دیگر از ترفندهای عملکرد سخت افزاری است.

برای دسترسی CPU به RAM ، به ویژه نگاشتن آدرس ۶۴ بیتی در جایی از RAM مثلاً ۱۲۸GB یا رم “واقعی” ، از TLB استفاده می شود. (TLB = بافر جستجوی ترجمه-Translation Lookup Buffer.) TLB را به عنوان جدول جستجوی حافظه انجمنی سخت افزاری در نظر بگیرید. با توجه به یک آدرس مجازی ۶۴ بیتی ، آدرس واقعی چیست؟

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

به طور معمول ، RAM در ۴KB «صفحه-paged» میشود. TLB در واقع بیت های بالا (۶۴-۱۲) را در یک صفحه خاص نگاشت یا مپ می کند. سپس ۱۲ بیت پایین آدرس مجازی دست نخورده منتقل می شود.

به عنوان مثال ، ۱۲۸GB حافظه RAM که به صفحات ۴KB شکسته است ، به معنای ورودی های جدول صفحه ۳۲M است. این مقدار بسیار زیاد است و احتمالاً بسیار بیشتر از ظرفیت TLB است. بنابراین ، ترفند “صفحه عظیم-Huge page” را وارد کنید.

با کمک سخت افزار و سیستم عامل می توان مقدار کمی RAM را در صفحات عظیم مثلا ۴MB (به جای ۴KB) در اختیار داشت. این امر منجر به ورود TLB بسیار کمتری می شود ، اما به این معنی است که واحد صفحه بندی (unit of paging) برای چنین قسمتهای  رم ۴ مگابایت است. از این رو ، صفحات عظیم غیر قابل صفحه بندی (non-pagable) هستند.

در حال حاضر RAM به قطعات قابل صفحه (pagable) و غیر قابل صفحه تقسیم شده است؛ چه بخشهایی می توانند غیر قابل صفحه باشند؟ در MariaDB ، استخر بافر Innodb یک نامزد کامل است(Innodb Buffer Pool). بنابراین ، با پیکربندی صحیح این موارد ، InnoDB می تواند کمی سریعتر اجرا شود:

  • صفحات عظیم فعال شده است
  • به سیستم عامل بگویید که مقدار مناسب را اختصاص دهد (یعنی برای مطابقت با buffer_pool)
  • به MariaDB بگویید که از صفحات عظیم استفاده کند
  • استفاده از حافظه innodb در مقابل swap

این بخش دارای جزئیات بیشتری در مورد آنچه را که باید جستجو کنید و چه چیزی را تنظیم کنید، هست.

بدست آوردن پرفورمنس کلی: چند درصد. خمیازه. دردسر بیش از حد برای سود کم.

صفحات جامبو؟ خاموش کردن

 

ENGINE=MEMORY

Memory Storage Engine یک گزینه کم استفاده برای MyISAM و InnoDB است. داده ها پایدار نیستند ، بنابراین استفاده محدودی دارند. اندازه یک جدول MEMORY به حداکثر max_heap_table_size محدود است ، که به طور پیش فرض ۱۶ مگابایت است. من آن را ذکر می کنم در صورتی که مقدار را به چیزی عظیم تغییر داده باشید. این امر ممکن است از دیگر مصارف احتمالی RAM سرقت کند.

نحوه تنظیم متغیرها

در فایل متنی my.cnf (my.ini در ویندوز) ، یک خط را اضافه کنید یا تغییر دهید تا چیزی شبیه به این بگویید:

innodb_buffer_pool_size = 5G

یعنی ، نام متغیر ، “=” ، و یک مقدار. برخی از اختصارات مجاز هستند ، مانند M برای میلیون (۱۰۴۸۵۷۶) ، G برای میلیارد.

برای دیده شدن توسط سرور ، تنظیمات باید در بخش “[mysqld]” فایل باشد.

تنظیمات موجود در my.cnf یا my.ini تا زمانی که سرور را مجدداً راه اندازی نکنید ، اعمال نمی شوند.

با اتصال به عنوان کاربر root (یا کاربر دیگری با امتیاز SUPER) و انجام کارهایی مانند این ، بیشتر تنظیمات را می توان در سیستم مثل این تغییر داد:

SET @@global.key_buffer_size = 77000000;

توجه: هیچ پسوند M یا G در اینجا مجاز نیست.

برای دیدن تنظیمات متغیر جهانی چیزی مانند این را انجام دهید:

SHOW GLOBAL VARIABLES LIKE “key_buffer_size”;

+—————–+———-+

| Variable_name   | Value    |

+—————–+———-+

| key_buffer_size | 76996608 |

+—————–+———-+

توجه داشته باشید که این تنظیم خاص به چند موردی که MariaDB پسندیده بود گرد شد.

ممکن است بخواهید هر دو را انجام دهید (SET ، و my.cnf را اصلاح کنید) تا بلافاصله تغییر را انجام دهید و آنرا انجام دهید تا راه اندازی مجدد بعدی (به هر دلیلی) دوباره مقدار را بدست آورد.

Web Server

یک وب سرور مانند Apache چندین نخ را اجرا می کند. اگر هر نخ یک اتصال به MariaDB را باز کند ، ممکن است اتصالات شما تمام شود. اطمینان حاصل کنید که MaxClients (یا معادل آن) روی برخی از شماره های متمدن (زیر ۵۰) تنظیم شده باشد.

ابزارها

  • MySQLTuner
  • TUNING-PRIMER

ابزارهای مختلفی وجود دارد که به حافظه توصیه می کنند. آنها یک ورودی گمراه کننده ارائه می دهند

حداکثر استفاده از حافظه ممکن: ۳۱.۳G (266٪ RAM نصب شده)

اجازه ندهید شما را بترساند – فرمول های استفاده شده بیش از حد محافظه کارانه هستند. آنها تصور می كنند كه تمام max_connections در حال استفاده و فعال هستند و كاری را انجام می دهند كه حافظه فشرده (memory-intensive) است.

مجموع جداول جداگانه(fragmented tables): 23 این به معنایِ شاید کمک به OPTIMIZE TABLE است. من آن را برای جداول با درصد زیاد “free space” (نگاه کنید به SHOW TABLE STATUS) یا جایی که می دانید تعداد زیادی DELETE یا / وUPDATE را انجام می دهید ، پیشنهاد می کنم. هنوز هم ، خیلی اوقات خود را به زحمت OPTIMIZE نیندازید. یک بار در ماه ممکن است کافی باشد.

MySQL 5.7

۵.۷ اطلاعات بسیار بیشتری را در RAM ذخیره می کند ، که منجر به این می شود که ردپا (footprint) شاید نیم گیگابایت بیشتر از ۵.۶ باشد. به افزایش حافظه در ۵.۷ مراجعه کنید.

Postlog

۲۰۱۰ ایجاد شده است تازه سازی اکتبر ، ۲۰۱۲ ، ژانویه ، ۲۰۱۴

نکات موجود در این سند برای MySQL ، MariaDB و Percona اعمال می شود.

موارد زیر را مطالعه فرمایید:

  • Configuring MariaDB for Optimal Performance
  • More in-depth: Tocker’s tuning for 5.6
  • Irfan’s InnoDB performance optimization basics (redux)
  • ۱۰ MySQL settings to tune after installation
  • Magento
  • Peter Zaitsev’s take on such (5/2016)

Rick James graciously allowed us to use this article in the Knowledge Base.

Rick James’ site has other useful tips, how-tos, optimizations, and debugging tips.

Original source: http://mysql.rjweb.org/doc.php/random

 

شناسنامه مطلب:

لبنک منبع: https://mariadb.com/kb/en/mariadb-memory-allocation/

نویسنده: سایت تولید کننده ماریا دیبیس

مترجم: گوگل ترانسلیت

ویراستار: علیرضا صدر ثقةالاسلامی

پیکربندی و تنظیمات دیتابیس:تخصیص حافظه MariaDB

 

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *