URL: https://www.opennet.ru/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 38879
[ Назад ]
Исходное сообщение
"Раздел полезных советов: Оптимизация MySQL для работы с большой Innodb базой."
Отправлено auto_tips , 02-Ноя-07 17:44 
innodb_buffer_pool_size  - 70-80% от размера ОЗУ;

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).

URL: http://www.mysqlperformanceblog.com/2007/11/01/innodb-perfor.../
Обсуждается: https://www.opennet.ru/tips/info/1495.shtml

Содержание
Сообщения в этом обсуждении
"Оптимизация MySQL для работы с большой Innodb базой."
Отправлено Veter , 02-Ноя-07 17:44 
"большой Innodb базой" - что это значит? 1, 10, 100 терабайт?

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

"Оптимизация MySQL для работы с большой Innodb базой."
Отправлено mirya , 08-Ноя-07 16:03 
> "если не важен ACID"- тогда это не база данных, а свалка.

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

"Оптимизация MySQL для работы с большой Innodb базой."
Отправлено squirL , 09-Ноя-07 14:12 
это, батенька, смотря какую статистику вы собираете. или какие логи. впрочем там где критично - эту поделку и не используют
"Оптимизация MySQL для работы с большой Innodb базой."
Отправлено avatar , 20-Ноя-07 05:57 
MySQL - "в сад"! Не хочу больше, задолбало.
"Оптимизация MySQL для работы с большой Innodb базой."
Отправлено Алексей , 20-Мрт-11 09:29 
MySQL - удобнее, ну вот к примеру PostgreSQL - могучий но deadlock-ами валиться, в MySQL при линейной выборке данных данные извлекаются обычным списком - FIFO что очень удобно а в PostgreSQl 7.x/8.x - нужен ORDER field ASC что очень не удобно, запомните корп. Oracle купила MySQL не за красивые глазки что-то psql-Беркли не собирается покупать.