The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Оптимизация MySQL для работы с большой Innodb базой.
innodb_buffer_pool_size  - чем больше, тем лучне, например 70-80% от размера ОЗУ, 
   но нет смысла устанавливать значение превышающее размер базы более чем на 10%. 
   По идее нужно экспериментально вычислить сколько требуется памяти для системы, 
   и отдать остальное под буферизацию с небольшим запасом, чтобы не допустить своппинг.

innodb_log_file_size - зависит от требований к скорости восстановления после сбоя,  
   256Мб - хороший баланс между скоростью восстановления и производительностью системы;

innodb_log_buffer_size=4M,  4Мб подходит для большинства ситуаций, 
   за исключением случая работы с большими блоками данных, хранимых в Innodb таблицах;

innodb_flush_logs_at_trx_commit=2 - если не важен ACID и после краха системы 
   допустимо потерять транзакции за последние 1-2 секунды;

innodb_thread_concurrency=8, значение по умолчанию вполне адекватно, 
   можно попробовать уменьшить или увеличить и посмотреть на изменение производительности.

innodb_flush_method=O_DIRECT - исключает двойную буферизацию и уменьшает воздействие 
   на файл подкачки. Но следует соблюдать осторожность, если ваш RAID без аварийной батарейки.

innodb_file_per_table - можно использовать, если число таблиц невелико.

При разработке приложения можно обратить внимание на использование режиме
READ-COMMITED (transaction-isolation=READ-COMITTED).
 
Ключи: mysql, tune, speed, optimization, innodb / Лицензия: CC-BY
Раздел:    Корень / Программисту и web-разработчику / SQL и базы данных / MySQL специфика / Оптимизация и администрирование MySQL

Обсуждение [ RSS ]
  • 1, Veter (??), 17:44, 02/11/2007 [ответить]  
  • +/
    "большой Innodb базой" - что это значит? 1, 10, 100 терабайт?

    "если не важен ACID"- тогда это не база данных, а свалка.

     
     
  • 2, mirya (?), 16:03, 08/11/2007 [^] [^^] [^^^] [ответить]  
  • +/
    > "если не важен ACID"- тогда это не база данных, а свалка.

    ну почему же, напр. сбор статистики / логирование, где допустима потеря нескольких событий из моря

     

  • 3, squirL (??), 14:12, 09/11/2007 [ответить]  
  • +/
    это, батенька, смотря какую статистику вы собираете. или какие логи. впрочем там где критично - эту поделку и не используют
     
  • 4, avatar (??), 05:57, 20/11/2007 [ответить]  
  • +/
    MySQL - "в сад"! Не хочу больше, задолбало.
     
  • 5, Алексей (??), 09:29, 20/03/2011 [ответить]  
  • +/
    MySQL - удобнее, ну вот к примеру PostgreSQL - могучий но deadlock-ами валиться, в MySQL при линейной выборке данных данные извлекаются обычным списком - FIFO что очень удобно а в PostgreSQl 7.x/8.x - нужен ORDER field ASC что очень не удобно, запомните корп. Oracle купила MySQL не за красивые глазки что-то psql-Беркли не собирается покупать.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:




    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру