Jump to content
Дизайн и модификация IPS Community IPBSkinsBETA
Search In
  • More options...
Find results that contain...
Find results in...
Sign in to follow this  
tolik777

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

Recommended Posts

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

Share this post


Link to post
Share on other sites

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

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

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

 

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

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

 

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

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

 

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

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

Share this post


Link to post
Share on other sites
Вам нужно обратится к грамотному системному администратору.

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Причем запросы апдейта кэша и они ну очень длинные. Я никогда не мог бы подумать, что запросы могут быть такой длины. Минут 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

Share this post


Link to post
Share on other sites

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

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

Edited by tolik777

Share this post


Link to post
Share on other sites
Сегодня попробовал еще вместо memcached поставить redis посмотрим...

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

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

 

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

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

 

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

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...