Mysql
 sql >> база данни >  >> RDS >> Mysql

Изчисляване на размера на InnoDB буферния пул за вашия MySQL сървър

Какво е InnoDB буферен пул?

InnoDB буферен пул е пространството на паметта, което съдържа много структури от данни в паметта на InnoDB, буфери, кешове, индекси и дори данни от редове. innodb_buffer_pool_size е конфигурационният параметър на MySQL, който определя количеството памет, разпределено на InnoDB буферния пул от MySQL. Това е една от най-важните настройки в конфигурацията на хостинг MySQL и трябва да се конфигурира въз основа на наличната системна RAM.

В тази публикация ще ви преведем през два подхода за настройка на стойността на размера на вашия InnoDB буферен пул, ще разгледаме плюсовете и минусите на тези практики, а също така ще предложим уникален метод за достигнете до оптимална стойност въз основа на размера на вашата системна RAM.

Подход 1. Метод на правилото на палеца

Най-често следваната практика е да зададете тази стойност на 70% – 80% от системната RAM. Въпреки че работи добре в повечето случаи, този метод може да не е оптимален във всички конфигурации. Да вземем за пример система със 192 GB RAM. Въз основа на горния метод стигаме до около 150 GB за размера на буферния пул. Това обаче всъщност не е оптимално число, тъй като не използва напълно големия размер на RAM, който е наличен в системата, и оставя след себе си около 40 GB памет. Тази разлика може да бъде още по-значителна, когато преминем към системи с по-големи конфигурации, където би трябвало да използваме наличната RAM памет в по-голяма степен.

Подход 2. По-нюансиран подход

Този подход се основава на по-подробно разбиране на вътрешните елементи на буферния пул InnoDB и неговите взаимодействия, което е описано много добре в книгата High Performance MySQL.

Нека разгледаме следния метод за изчисляване на размера на буферния пул на InnoDB.

  1. Започнете с обща налична RAM.
  2. Извадете подходяща сума за нуждите на ОС.
  3. Извадете подходяща сума за всички нужди на MySQL (като различни MySQL буфери, временни таблици, пулове за връзки и свързани с репликацията буфери).
  4. Разделете резултата на 105%, което е приблизителна стойност на режийните разходи, необходими за управление на самия пул от буфери.

Например, нека разгледаме система със 192GB RAM, използваща само InnoDB и с общ размер на регистрационния файл от около 4GB. Можем да използваме правило като „максимум 2GB или 5% от общата RAM“ за разпределяне на нуждите на ОС, както е препоръчано в горната книга, което достига до около 9,6GB. След това ще разпределим и около 4 GB за други нужди на MySQL, главно като вземем предвид размера на регистрационния файл. Този метод води до около 170 GB за размера на нашия InnoDB буферен пул, което е около 88,5% използване от наличния размер на RAM.

Въпреки че използвахме правилото „максимум 2GB или 5% от общата RAM“, за да изчислим разпределението на паметта за нуждите на ОС по-горе, същото правило не работи много добре във всички случаи , специално за системи със среден размер RAM между 2GB и 32GB. Например, в система с 3GB RAM, разпределянето на 2GB за нуждите на ОС не оставя много за буферния пул на InnoDB, докато разпределянето на 5% от RAM е твърде малко за нуждите на нашата ОС.

И така, нека прецизираме горното правило за разпределение на ОС и да разгледаме изчислителния метод на InnoDB в различни конфигурации на RAM:

За системи с малък размер RAM (<=1GB)

За системи, работещи с по-малко от 1GB RAM, е по-добре да използвате конфигурационната стойност по подразбиране на MySQL от 128MB за размера на буферния пул на InnoDB.

За системи със среден размер RAM (1GB – 32GB)

Като се има предвид случая на системи с размер на RAM от 1GB – 32GB, можем да изчислим нуждите на ОС, използвайки тази груба евристика:

256MB + 256 * log2 (размер на RAM в GB)

Рационализацията тук е, че за ниски RAM конфигурации започваме с базова стойност от 256MB за нуждите на ОС и увеличаваме това разпределение в логаритмичен мащаб като количеството RAM памет се увеличава. По този начин можем да измислим детерминирана формула за разпределяне на RAM за нуждите на нашата ОС. Също така ще разпределим същото количество памет за други нужди на MySQL. Например, в система с 3GB RAM, бихме направили справедливо разпределение на 660MB за нуждите на ОС и още 660MB за други нужди на MySQL, което води до стойност от около 1,6GB за размера на нашия InnoDB буферен пул.

За системи с по-голям размер RAM (> 32GB)

За системи с размери на RAM, по-големи от 32GB, ще се върнем към изчисляването на нуждите на ОС като 5% от размера на нашата системна RAM и същото количество за MySQL други нужди. Така че, за система с размер на RAM от 192 GB, нашият метод ще достигне около 165 GB за размера на буферния пул на InnoDB, което отново е оптимална стойност, която трябва да се използва.

Калкулатор за размера на буферния пул на InnoDB

Изчислете оптималната стойност за RAM с всякакъв размер:





Калкулатор за размера на буферния пул на InnoDB - Изчислете оптималния брой за всеки размер на системната RAM Щракнете за Tweet

Графика на размера на буферния пул на InnoDB за различни размери на RAM

Внимание за изчисления на размера на буферния пул на InnoDB

Съображенията в тази публикация в блога са за Linux системи, които са предназначени за MySQL. За Windows системи или системи, които изпълняват множество приложения заедно с MySQL, тези наблюдения могат да бъдат неточни. Също така е важно да се отбележи, че въпреки че можем да използваме тези инструменти като препратки, наистина са необходими добър опит, експериментиране, непрекъснато наблюдение и фина настройка, за да получите правилния размер за вашия innodb_buffer_pool_size.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Единични кавички, двойни кавички и обратни кавички в MySQL

  2. ГРЕШКА 1067 (42000):Невалидна стойност по подразбиране за 'created_at'

  3. Как да експортирате данни от SQL Server 2005 в MySQL

  4. Най-доброто DBaaS решение за MySQL

  5. JSON_PRETTY() – Форматирайте JSON документи за по-лесна четливост в MySQL