Вопрос по базе данным

[Andrey_79]

Добрый день. Подскажите, какие данные хранятся в таблице history_uint и можно ли их уменьшить. У меня за 3 месяца работы в этой таблице скопилось 102 000 000 записей общим объемом почти 6 Гб, я с ужасом думаю, что будет через год. При всем при этом mysql уже сегодня загружает процессор более чем 50%.

[costas]

За какой период Вам нужны данные за тот и храните, у всех item есть отдельная настройка за какой период хранить хистори, по мимо этого есть настройка Housekeeper (Сборщик мусора аля домохозяйка) в разделе Configuration -> General: Housekeeper

[den_crane]

Добрый день. Подскажите, какие данные хранятся в таблице history_uint и можно ли их уменьшить. У меня за 3 месяца работы в этой таблице скопилось 102 000 000 записей общим объемом почти 6 Гб, я с ужасом думаю, что будет через год. При всем при этом mysql уже сегодня загружает процессор более чем 50%.

если вы используете стандартные шаблоны, то там по моему 3 месяца везде [Keep history (in days)], .т.е. через год будут все теже 6 гиг плюс тренды (а они маленькие).
Уменшайте [Keep history (in days)], и или увеличивайте период опроса [Update interval (in sec)], число записей упадет, потом шринкайте базу (экспорт-импорт), если не лень возится из-за 6Г.

[Andrey_79]

если вы используете стандартные шаблоны, то там по моему 3 месяца везде [Keep history (in days)], .т.е. через год будут все теже 6 гиг плюс тренды (а они маленькие).
Уменшайте [Keep history (in days)], и или увеличивайте период опроса [Update interval (in sec)], число записей упадет, потом шринкайте базу (экспорт-импорт), если не лень возится из-за 6Г.

Дело не в лени, дело в том, что mysql сильно начал тормозить в последнее время.

[costas]

Дело не в лени, дело в том, что mysql сильно начал тормозить в последнее время.

А у Вас какое железо под этим делом?

[Andrey_79]

А у Вас какое железо под этим делом?

CPU: Intel(R) Pentium(R) CPU E5200 @ 2.50GHz (2493.76-MHz 686-class CPU)
real memory = 2138832896 (2039 MB)
hpt3741: <HPT374 UDMA/ATA133 RAID Controller>

Количество узлов сети (контролируется/не контролируется/шаблоны/удалено) 1033 788 / 198 / 47
Количество элементов данных (активных/неактивных/не поддерживается)[trapper] 1737 1666 / 64 / 7
Количество триггеров (активированных/деактивированных)[истина/неизвестно/ложь] 1612 1612 / 0 [357 / 1 / 1254]
Количество пользователей 9 3
Требуемое быстродействие сервера, новые значения в секунду 11.0813 -

[Andrey_79]

Все же хочется разобраться с таблицей history_uint.
Как я понял в ней хранятся данные : номер элемента данных, время проверки и результат проверки. Нельзя ли сделать так, что бы в эту таблицу заносились только изменения состояния, я думаю это позволит уменьшить количество записей как минимум на порядок.

[mschedrin]

Можно написать простой скриптик, который будет раз в 10 минут чистить таблицу истории.

[Andrey_79]

Можно написать простой скриптик, который будет раз в 10 минут чистить таблицу истории.

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

[mschedrin]

Скриптик может и не удалять данные, а архивировать :)

[Andrey_79]

Скриптик может и не удалять данные, а архивировать :)

Как их потом посмотреть, распаковывать и базу загружать?

[mschedrin]

ну да. Или можно то же самое на отдельном сервере сделать, чтобы основной не загружать.

[den_crane]

Дело не в лени, дело в том, что mysql сильно начал тормозить в последнее время.
из-за размера базы и размера таблицы history томозить не должно.

[mschedrin]

из-за размера базы и размера таблицы history томозить не должно.
У меня sql тоже начинает жутко тормозить при большой таблице history. Тормозит на insert в эту таблицу. Я решил вопрос переносом базы на ramdisk.

[den_crane]

У меня sql тоже начинает жутко тормозить при большой таблице history. Тормозит на insert в эту таблицу. Я решил вопрос переносом базы на ramdisk.
тип таблицы innodb?

пробовали увеличить
.... /etc/my.cnf
innodb_buffer_pool_size = 400M -> 800M

[mschedrin]

Сейчас у меня
innodb buffer pool size 8,388,608, т.е. всего 8М.
Увеличивать не пробовал. Поможет?

[dotneft]

попробуйте партиционирование

http://habrahabr.ru/blogs/webdev/66151/

но для начала воспользуйтесь твикерами MySQL (mysqltuner and etc) + почитайте документацию по оптимизации БД MySQL

[den_crane]

Сейчас у меня
innodb buffer pool size 8,388,608, т.е. всего 8М.
Увеличивать не пробовал. Поможет?
конечно, начните с 400М

[mschedrin]

Спасибо за совет. Очень большой прирост дал этот параметр.

[den_crane]

Спасибо за совет. Очень большой прирост дал этот параметр.
двигло innodb (в отличии от myisam), не использует системный кеш фс, а создает собственный буфер (как нормальные энтерпрайз субд), что логично потому что субд лучше знает что как надо кешировать.
За размер этого буфера и отвечает параметр innodb_buffer_pool_size.
В обычных субд туда стараются отдать всю свободную память, т.е. ~70% RAM.

[den_crane]

В принципе можно довести уровень кеширования до 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 не смог выполнить из буферного пула и использовал постраничное чтение.

[ugh]

проверьте еще раз
очень врятли, что у вас тормоза из-за инсерта в хистори

[Andrey_79]

У меня история такая. 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, двое суток индексировалось так процесс и не был закончен. У меня идеи закончились как восстановить систему. Какие будут ваши рекомендации и советы?

[mschedrin]

Если размер этого кэша будет больше чем размер всей этой базы, можно рассчитывать, что она скешируется полностью?

[den_crane]

mysql перестал понимать таблицы innodb.
а это как? Сообщение об ошибке было или что?

Я слабо разбираюсь в mysql.

[den_crane]

Если размер этого кэша будет больше чем размер всей этой базы, можно рассчитывать, что она скешируется полностью?
Скешируется. Только зачем? Т.е. работать будет возможно медленнее чем рамдиск, потому что запись будет идти на обычный диск. А операций записи в журнал транзакции бд ждет обычно (зависит от параметра innodb_flush_log_at_trx_commit)


Основы оптимизации производительности InnoDB http://boombick.org/blog/posts/11

[costas]

У меня история такая. mysql 5.0.77 установился без файла my.cnf. Почитав документацию, создал этот файл и скопировал его в etc вписал в него innodb_buffer_pool_size = 400M (по умолчанию был 8М), перезапустил mysql. mysql перестал понимать таблицы innodb.
Обычное так сказать явление, если Вы посмотрите на состояние движка InnoDB, то увидите, что он имеет статус Disable, если внимательно почитаете лог файл то найдёте там запись о том что InnoDB вывалился крашингом, это проблема характерна для некоторых версий MySQL (точнее сказать для многих начиная с версий 4.х.х), если возмьёте дефолтный конфиг для MyISAM то всё стартанёт в нормальном режиме без крашингов, как только начнёте тюнить InnoDB сразу получите плюху в виде неработающего InnoDB. Лечится это дело путём смены версии MySQL (для 5.х вроде с версии 5.1.17 начали фиксить, точно не скажу) или наложить патчики на текущую..

З.Ы. бага характерна для 32-х битных систем, я её словил на CentOS-5.3 x86 и на x86_64 в дистрибутивной версии мускуля...

[Andrey_79]

если возмьёте дефолтный конфиг для MyISAM то всё стартанёт в нормальном режиме без крашингов...

У меня в том проблема, что я вернул настройки назад, а база не заработала. Выдает ошибки на все таблицы: Ошибка при выполнении sql запроса (1146). Ответ от сервера Table 'xxxxx.xxx' doesn't exist.