InnoDB и myISAM. Долгая загрузка - Дизайн и модификация Invision Power Board

Перейти к содержимому

 

СвернутьПрикрепленные теги

Теги не найдены

Страница 1 из 1

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

#1 Пользователь не на сайте   tolik777 ответил: »

 
 
  • Member
  • **
  • Insert nick to fast reply form
  • Quote selected text to fast reply form
  • Группа: Пользователи
  • Сообщений: 92
  • Регистрация: 11-Февраль 10
  • Репутация: 6
  • IPB version:4.1.x
 

Отправлено 30 Сентябрь 2016 - 14:31

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

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

Цитата

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

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

#2 Пользователь не на сайте   siv1987 ответил: »

 
 
  • Advanced
  • Insert nick to fast reply form
  • Quote selected text to fast reply form
  • Группа: IPB Skins Team
  • Сообщений: 8 720
  • Регистрация: 20-Март 09
  • Репутация: 2 269
  • IPB version:3.1.x
 

Отправлено 30 Сентябрь 2016 - 15:23

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

#3 Пользователь не на сайте   tolik777 ответил: »

 
 
  • Member
  • **
  • Insert nick to fast reply form
  • Quote selected text to fast reply form
  • Группа: Пользователи
  • Сообщений: 92
  • Регистрация: 11-Февраль 10
  • Репутация: 6
  • IPB version:4.1.x
 

Отправлено 01 Октябрь 2016 - 17:38

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

#4 Пользователь не на сайте   siv1987 ответил: »

 
 
  • Advanced
  • Insert nick to fast reply form
  • Quote selected text to fast reply form
  • Группа: IPB Skins Team
  • Сообщений: 8 720
  • Регистрация: 20-Март 09
  • Репутация: 2 269
  • IPB version:3.1.x
 

Отправлено 01 Октябрь 2016 - 22:40

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

Просмотреть сообщениеtolik777 сказал(а):

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

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

Просмотреть сообщениеtolik777 сказал(а):

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

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

Просмотреть сообщениеtolik777 сказал(а):

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

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

#5 Пользователь не на сайте   tolik777 ответил: »

 
 
  • Member
  • **
  • Insert nick to fast reply form
  • Quote selected text to fast reply form
  • Группа: Пользователи
  • Сообщений: 92
  • Регистрация: 11-Февраль 10
  • Репутация: 6
  • IPB version:4.1.x
 

Отправлено 03 Октябрь 2016 - 10:44

Цитата

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

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

#6 Пользователь не на сайте   tolik777 ответил: »

 
 
  • Member
  • **
  • Insert nick to fast reply form
  • Quote selected text to fast reply form
  • Группа: Пользователи
  • Сообщений: 92
  • Регистрация: 11-Февраль 10
  • Репутация: 6
  • IPB version:4.1.x
 

Отправлено 17 Октябрь 2016 - 08:20

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

#7 Пользователь не на сайте   siv1987 ответил: »

 
 
  • Advanced
  • Insert nick to fast reply form
  • Quote selected text to fast reply form
  • Группа: IPB Skins Team
  • Сообщений: 8 720
  • Регистрация: 20-Март 09
  • Репутация: 2 269
  • IPB version:3.1.x
 

Отправлено 17 Октябрь 2016 - 09:46

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

#8 Пользователь не на сайте   danilka ответил: »

 
 
  • Advanced
  • ***
  • Insert nick to fast reply form
  • Quote selected text to fast reply form
  • Группа: Пользователи
  • Сообщений: 134
  • Регистрация: 10-Март 10
  • Репутация: 6
  • IPB version:2.3.x
 

Отправлено 18 Октябрь 2016 - 08:05

Просмотреть сообщениеtolik777 01 Октябрь 2016 - 17:38 сказал(а):

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


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

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

https://www.percona....basics-updated/
https://www.opennet....b_tune.txt.html
0

#9 Пользователь не на сайте   tolik777 ответил: »

 
 
  • Member
  • **
  • Insert nick to fast reply form
  • Quote selected text to fast reply form
  • Группа: Пользователи
  • Сообщений: 92
  • Регистрация: 11-Февраль 10
  • Репутация: 6
  • IPB version:4.1.x
 

Отправлено 18 Октябрь 2016 - 18:02

Основные таблицы (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 (18 Октябрь 2016 - 18:09)

0

#10 Пользователь не на сайте   danilka ответил: »

 
 
  • Advanced
  • ***
  • Insert nick to fast reply form
  • Quote selected text to fast reply form
  • Группа: Пользователи
  • Сообщений: 134
  • Регистрация: 10-Март 10
  • Репутация: 6
  • IPB version:2.3.x
 

Отправлено 19 Октябрь 2016 - 07:52

Цитата

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

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

Цитата

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

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

советую сходить на sql.ru http://www.sql.ru/forum/mysql
там ребята толковые и не злые) помогут, подскажут
0

Сообщить об этой теме:


Страница 1 из 1


Быстрый ответ

  

1 пользователей читают эту тему
0 зарегистрированных, 1 гостей, 0 скрытых


Контактная информация

Вопросы по работе сайта

+7 (917) 501-4765
C 10 до 20 в рабочие дни (время московское)

Техническая поддержка

Контактные данные специалистов

Дизайн форумов

IPB 3.x ¦ IPB 2.x

Бесплатные шаблоны

IPB 3.2 – 3.4 ¦ IPB 3.1 ¦ IPB 3.0 ¦ IPB 2.2 – 2.3 ¦ IPB 2.1 ¦ Клипарт
Лицензия на использование ¦ Ваша поддержка ¦ О проекте
Copyright © 2005-2016 IPBSkins.ru Team
При копировании материалов с сайта
прямая ссылка на источник обязательна