Перейти к публикации
Дизайн и модификация IPS Community IPBSkinsBETA
Поиск в
  • Дополнительно...
Искать результаты, содержащие...
Искать результаты в...
tolik777

InnoDB и myISAM. Долгая загрузка

Рекомендованные сообщения

Недавно обновил форум с трйоки на последнюю 4.1. Сегодня залез в phpMyADmin и обнаружил, что у меня часть таблиц InnoDB, а часть MyISAM

Вопрос в том , все должны быть в InnoDB или еще как-то?

 

Дело в том, что после обновления на серваке тоже был апгрейд HDD->SSD, 32Gb -> 64Gb, Ethernet 200MB-1Gb.

Но 4-ка очень сильно тормозит, slow-log с величиной 5 сек разрастается до десятков мегабайт уже через час работы. Постоянно 502 ошибка на серваке (30 сек таймаут) и при отправке сообщения форум долго думает и только через 10-15 секунд обновляет страницу. При этом навигация происходит практически нормально.

Стоит Debian8, NGINX, PHP7.0-FPM, MySQL 5.5. Стоял memcached но был обнаружен баг в нем и я его отключил. Все вроде оптимизировано, т.к. не раз оптимизировал, да и тройка на меньшей конфигурации просто летала. Думаю может быть из-за этих несоответствий InnoDB/MyISAM?

 

Вот скрин всех таблиц: http://www.filedropper.com/phpmyadmin46

 

Пробую сделать вручную вот такой запрос:

INSERT INTO `ibf_core_view_updates` ( `classname`, `id` ) VALUES ( 'IPS\\blog\\Entry', 341 )

Первый раз он выполнился аж за 4 секунды. Затем стал нормально выполняться

Поделиться сообщением


Ссылка на сообщение

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

Тип таблиц в одной базе данных может быть разным, смешанность на производительность не сказывается. Влияет только сам тип. Один выигрывает в одном, другой проигрывает в другом. Поэтому для каждой задачи подбирают индивидуальный тип, например сессии загоняют в память типом MEMORY, или обеспечивают блокировку на уровне строки типом InnoDB и более надежное хранилище данных.

Если у вас используются какойто определенный тип таблиц (преобладает) лучше привести и остальные к этому типу.

Для оптимизации нужно смотреть слоу лог, анализировать запросы и смотреть почему так долго выполняются. Также установить профайлер для анализа выполнение кода, и выявить узкие места в генерации страницы.

Поделиться сообщением


Ссылка на сообщение

Частично решил проблему увеличив tmp_table_size max_heap_table_size аж до 512 МБайт со 128Мб. Но все равно в slow query log (10 сек) иногда прилетают запросы. Причем запросы апдейта кэша и они ну очень длинные. Я никогда не мог бы подумать, что запросы могут быть такой длины. Минут 20 ничего нет, потом прилетает один, за ним еще несколько таких же и буквально через минуту лог составляет уже десятки мегабайт.

4.1 очень и очень прожорлива в плане ресурсов по сравнению с тройкой. Загрузка проца на тройке выше 1-ки никогда не поднималась, а на новом серваке проц помощнее I7 стоит, а загрузка 3-4 в среднем...

Поделиться сообщением


Ссылка на сообщение

MyISAM кстати еще используют для полно-текстового индекса, который до версии MYSQL 5.6 в innoDB небыло. Для поддержке старых версии некоторые таблицы могут быть в MyISAM.

 

Частично решил проблему увеличив tmp_table_size max_heap_table_size аж до 512 МБайт со 128Мб

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

 

Причем запросы апдейта кэша и они ну очень длинные.

1МБ текста может казаться очень длинным, хотя по объему данных не так уж и много. Нужно смотреть, что какие запросы и почему.

 

4.1 очень и очень прожорлива в плане ресурсов по сравнению с тройкой. Загрузка проца на тройке выше 1-ки никогда не поднималась, а на новом серваке проц помощнее I7 стоит, а загрузка 3-4 в среднем...

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

Поделиться сообщением


Ссылка на сообщение
Вам нужно обратится к грамотному системному администратору.

Найти грамотного сисадмина из той же области, что и грамотного сантехника. Мне сантехник что за 1000 руб, что за 5000 руб (все говорили что они крутые спецы) делали так, что самому приходилось потом переделывать и устранять течи. В итоге сейчас все отопление и водоподготовку сделал сам, намного лучше чем любой сантехник. Пусть и дольше. Но это все лирика, искать сисадмина - лотерея, за 10-лет аренды дедиков с кем только не сталкивался - а искать по отзывам на веблансере/фрилансере - дело гиблое... Поэтому анализирую mysqltuner и др. данные с статуса, читаю статьи, параметры и потихоньку настраиваю сам.

Поделиться сообщением


Ссылка на сообщение

Пипец я уже не рад что переехал. Месяц оптимизирую, оптимизирую и оптимизирую и PHP и MySQL. А форум все также тупит, по сравнению с тройкой он раз в 10-ть прожорливей наверное стал. Запросы MySQL в нем явно не оптимизированы. У кого форумы милионники, и с посещяемостью более 20-30к уников в сутки - будьте аккуратнее! Даже современный сервак 8-ми ядерный с SSD и 64 ГБайт RAM еле тянет все это.

Поделиться сообщением


Ссылка на сообщение

Хз, запросы конечно стали на порядок больше, но я бы не назвал их уж совсем неоптимизирование. Если они по вашему неоптимизированы приведите запрос и план его выполнения (EXPLAIN). Вот в соседней теме был плагин с непродуманым запросам, там да, с таким количеством страниц как в той теме он бы завалил весь ваш сервер. Может быть все же стоит обратится к специалистам? И не обязательно с ф милан са, на специализированных форумов есть много толковых людей где о их квалификации можно судить по сообщениям. Посмотрите на searchengines.

Поделиться сообщением


Ссылка на сообщение

Причем запросы апдейта кэша и они ну очень длинные. Я никогда не мог бы подумать, что запросы могут быть такой длины. Минут 20 ничего нет, потом прилетает один, за ним еще несколько таких же и буквально через минуту лог составляет уже десятки мегабайт.

 

таблица с кешем innodb? если да, покрутите innodb_buffer_pool_size.

вообще наивно полагать, что "сейчас перепрыгнем на innodb и всё будет летать". уже на двух проектах убедился в этом. у вас первый запрос во что-то втыкается, а остальные виснут за ним, при этом, скорее всего, даже лока нет.

 

если не хотите нанимать специалиста, почитайте про оптимизацию innodb

 

https://www.percona.com/blog/2013/09/20/innodb-performance-optimization-basics-updated/

https://www.opennet.ru/base/dev/mysql_innodb_tune.txt.html

Поделиться сообщением


Ссылка на сообщение
10/18/16 15:03 (изменено)

Основные таблицы (posts и т.д. которые по несколько гигов) в MyIsam. У меня 5.5 мускул (обновление на 5.6 или 5.7 что-то даст?). Таблица ibf_core_cache да в innodb, но она не сильно большая - 800 метров с 3000 записей.

Буфер крутил, сейчас стоит 2.5 гига (сегодня поставил 12 Гиг сразу). Проблема тормоза судя по отчетам MySQL тюнеров - в том, что ~40% таблиц находятся на диске, а не в памяти. tmp_table_size и max_heap_table_size крутил начиная с 128 до неприличных 8 Гигов в течении пары недель. Ничего не меняется...

Сегодня попробовал еще вместо memcached поставить redis посмотрим...

На днях выложу все настройки, параметры переменных мускула и отчеты, может что толковое посоветуете.

Изменено пользователем tolik777

Поделиться сообщением


Ссылка на сообщение
Сегодня попробовал еще вместо memcached поставить redis посмотрим...

нет смысла, если используете его так же как memcached, т.е. ключ-значение.

скорость чтения-записи на не хайлоад проектах мало чем отличается

 

но она не сильно большая - 800 метров с 3000 записей

тут дело скорее не в размере, а в кол-ве обращений к ней. вообще данные в этой табличке кешироваться должны же через ту же memcached прослойку. т.е. таблица по факту должна дергаться не так часто, только для прогревания кеша.

 

советую сходить на sql.ru http://www.sql.ru/forum/mysql

там ребята толковые и не злые) помогут, подскажут

Поделиться сообщением


Ссылка на сообщение

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас

  • Сейчас на странице   0 пользователей

    Нет пользователей, просматривающих эту страницу.

×
×
  • Создать...