Сейчас у меня
innodb buffer pool size 8,388,608, т.е. всего 8М.
Увеличивать не пробовал. Поможет?
innodb buffer pool size 8,388,608, т.е. всего 8М.
Увеличивать не пробовал. Поможет?
-
-
попробуйте партиционирование
http://habrahabr.ru/blogs/webdev/66151/
но для начала воспользуйтесь твикерами MySQL (mysqltuner and etc) + почитайте документацию по оптимизации БД MySQLLast edited by dotneft; 20-11-2009, 19:00.Comment
-
Спасибо за совет. Очень большой прирост дал этот параметр.Comment
-
двигло innodb (в отличии от myisam), не использует системный кеш фс, а создает собственный буфер (как нормальные энтерпрайз субд), что логично потому что субд лучше знает что как надо кешировать.
За размер этого буфера и отвечает параметр innodb_buffer_pool_size.
В обычных субд туда стараются отдать всю свободную память, т.е. ~70% RAM.Comment
-
В принципе можно довести уровень кеширования до 99.90%, увеличивая размер, буфера и остановится.
у меня:
mysql> show status like 'Innodb_buffer_pool_read_requests';
| Innodb_buffer_pool_read_requests | 2391577516 |
mysql> show status like 'Innodb_buffer_pool_reads';
| Innodb_buffer_pool_reads | 324308 |
(1-324308/2391577516)*100=99,986%
Innodb_buffer_pool_read_requests Количество последовательных запросов на чтение, выполненных InnoDB.
Innodb_buffer_pool_reads Количество последовательных запросов на чтение, которые InnoDB не смог выполнить из буферного пула и использовал постраничное чтение.Last edited by den_crane; 23-11-2009, 13:38.Comment
-
проверьте еще раз
очень врятли, что у вас тормоза из-за инсерта в хисториComment
-
У меня история такая. mysql 5.0.77 установился без файла my.cnf. Почитав документацию, создал этот файл и скопировал его в etc вписал в него innodb_buffer_pool_size = 400M (по умолчанию был 8М), перезапустил mysql. mysql перестал понимать таблицы innodb. Удалил my.cnf, пезапустил mysql, теперь выдает ошибку база повреждена и читать ее содержимое отказывается. Попытался откатить данные, но из-за большого количества записей в таблице history, процесс оказался очень долгим за 8 часов не восстановилась система. Пошел другим путем, удалил индекс history_uint_1, база откатилась за 2 часа. Данные вроде все наместе, по snmp данные снимаются , по icmp почему то нет (ошибка на странице триггеры Zabbix was down). Попітался создать индекс history_uint_1, двое суток индексировалось так процесс и не был закончен. У меня идеи закончились как восстановить систему. Какие будут ваши рекомендации и советы?Comment
-
Если размер этого кэша будет больше чем размер всей этой базы, можно рассчитывать, что она скешируется полностью?Comment
-
Скешируется. Только зачем? Т.е. работать будет возможно медленнее чем рамдиск, потому что запись будет идти на обычный диск. А операций записи в журнал транзакции бд ждет обычно (зависит от параметра innodb_flush_log_at_trx_commit)
Основы оптимизации производительности InnoDB http://boombick.org/blog/posts/11Last edited by den_crane; 23-11-2009, 16:04.Comment
-
Обычное так сказать явление, если Вы посмотрите на состояние движка InnoDB, то увидите, что он имеет статус Disable, если внимательно почитаете лог файл то найдёте там запись о том что InnoDB вывалился крашингом, это проблема характерна для некоторых версий MySQL (точнее сказать для многих начиная с версий 4.х.х), если возмьёте дефолтный конфиг для MyISAM то всё стартанёт в нормальном режиме без крашингов, как только начнёте тюнить InnoDB сразу получите плюху в виде неработающего InnoDB. Лечится это дело путём смены версии MySQL (для 5.х вроде с версии 5.1.17 начали фиксить, точно не скажу) или наложить патчики на текущую..
З.Ы. бага характерна для 32-х битных систем, я её словил на CentOS-5.3 x86 и на x86_64 в дистрибутивной версии мускуля...Last edited by costas; 24-11-2009, 07:52.CentOS-5.5 i386, Zabbix 1.8.4 (stable), MySQL 5.0.92, PHP 5.2.17 (cli)
...эта проверка бесполезная, вредная, и она зло.Comment
Comment