форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Раздел полезных советов: Оптимизация MySQL для работы с боль..."	+/–
Сообщение от auto_tips (??) on 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.../ Обсуждается: http://www.opennet.dev/tips/info/1495.shtml
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Оптимизация MySQL для работы с большой Innodb базой."	+/–
Сообщение от Veter (??) on 02-Ноя-07, 17:44
"большой Innodb базой" - что это значит? 1, 10, 100 терабайт? "если не важен ACID"- тогда это не база данных, а свалка.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	2. "Оптимизация MySQL для работы с большой Innodb базой."	+/–
	Сообщение от mirya on 08-Ноя-07, 16:03
	> "если не важен ACID"- тогда это не база данных, а свалка. ну почему же, напр. сбор статистики / логирование, где допустима потеря нескольких событий из моря
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "Оптимизация MySQL для работы с большой Innodb базой."	+/–
Сообщение от squirL (??) on 09-Ноя-07, 14:12
это, батенька, смотря какую статистику вы собираете. или какие логи. впрочем там где критично - эту поделку и не используют
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

4. "Оптимизация MySQL для работы с большой Innodb базой."	+/–
Сообщение от avatar (??) on 20-Ноя-07, 05:57
MySQL - "в сад"! Не хочу больше, задолбало.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

5. "Оптимизация MySQL для работы с большой Innodb базой."	+/–
Сообщение от Алексей (??) on 20-Мрт-11, 09:29
MySQL - удобнее, ну вот к примеру PostgreSQL - могучий но deadlock-ами валиться, в MySQL при линейной выборке данных данные извлекаются обычным списком - FIFO что очень удобно а в PostgreSQl 7.x/8.x - нужен ORDER field ASC что очень не удобно, запомните корп. Oracle купила MySQL не за красивые глазки что-то psql-Беркли не собирается покупать.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема