Недавно обновил форум с трйоки на последнюю 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

Основные таблицы (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 посмотрим...

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

Изменено 18 октября 20169 г пользователем tolik777

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

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

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

 

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

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

 

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

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