InnoDB - медленно работает

[StalkerClasses]

На сайте есть условно говоря два типа таблиц
MyISAM - для контента
InnoDB - для кэша (как-то так сложилось, что идет по умолчанию, раньше в ручную был переустановлен на MyISAM )

С MyISAM - все работало и работает быстро (1-2 секунды) - даже не заметно, как открывается сайт.
А вот если поставить InnoDB - то сайт начинает работать в 10-а то и 40 раз медленнее.
Именно сам процесс записи кэша.

В интернете почитал - что рекомендуют ставить InnoDB для таблиц кэша - т.к. он может одновременно и писать и читать... Но смысл от него, если с ним там все медленно работать начинает (во всяком случае у меня)?

При обращении первый раз к не сгенерированной странице - происходит порядка 300-400 mysql-запросов. В т.ч. по записи в кэш - где-то %10-15. После когда уже кэш записан - ~50-60 запросов.

 

[Sad Spirit]

При обращении первый раз к не сгенерированной странице - происходит порядка 300-400 mysql-запросов.

ой.
из этих 300-400 запросов какой процент выполняется в цикле?..

 

[StalkerClasses]

ой.
из этих 300-400 запросов какой процент выполняется в цикле?..

Может погорячился - 100-150 (различные в т.ч. INSERT, UPDATE).
Без циклов.

 

[Gas]

для кеша лучше не базу, а memcached/redis использовать.

что касается тормозов innodb при изменении данных - ну дык acid, либо отключать durability (innodb_flush_log_at_trx_commit), либо апгредить дисковую подсистему.

в общем не нужно кеш в базу.

 

[Absinthe]

С MyISAM - все работало и работает быстро (1-2 секунды)

Это крайне медленно для внешнего сайта.

Может погорячился - 100-150 (различные в т.ч. INSERT, UPDATE).
Без циклов.

Откуда столько?

 

[StalkerClasses]

Это крайне медленно для внешнего сайта.
Если быть совсем точным - то где-то в районе - 0.6959 секунд (без кэша - т.е. он сброшен).

А вот если ставлю InnoDB
То скорость может исчесляться - 10-секунд загрузки.

Откуда столько?

Ну столько запросов есть...

Мне в принципе не критично перейти на memcache...
Просто интересно, почему - так получается с InnoDB?

 

[Активист]

count(*) наверное в запросах.

 

[Redjik]

Просто интересно, почему - так получается с InnoDB?

Gas ответил - скорее всего innodb_flush_log_at_trx_commit.

 

[StalkerClasses]

Gas ответил - скорее всего innodb_flush_log_at_trx_commit.

Спасибо - так понимаю это в настройках mysql- менять.

 

[Linker]

StalkerClasses, тема с необходимостью сотни запросов для генерации одной страницы до сих пор не раскрыта!

 

[StalkerClasses]

StalkerClasses, тема с необходимостью сотни запросов для генерации одной страницы до сих пор не раскрыта!

Ну объяснить можно очень просто
Взять любую CMS (joomla, made simple) - там так и получается при выдаче страницы первый раз в не закэшированном состоянии.
В интернете можно посмотреть среднее кол-во запросов по CMS...

Разве это удивительно и ново в WEB-мир?

 

[Активист]

Ну объяснить можно очень просто
Взять любую CMS (joomla, made simple) - там так и получается при выдаче страницы первый раз в не закэшированном состоянии.
В интернете можно посмотреть среднее кол-во запросов по CMS...

Разве это удивительно и ново в WEB-мир?

Потому что код гавно. Кешировать нужно то, что нельзя оптимизировать. Оптимизировать нельзя 0.1%

 

[StalkerClasses]

У меня my.conf - вот такой.

# Uncomment the following if you are using InnoDB tables
#innodb_data_home_dir = /var/lib/mysql
#innodb_data_file_path = ibdata1:10M:autoextend
#innodb_log_group_home_dir = /var/lib/mysql
# You can set .._buffer_pool_size up to 50 - 80 %
# of RAM but beware of setting memory usage too high
#innodb_buffer_pool_size = 16M
#innodb_additional_mem_pool_size = 2M
# Set .._log_file_size to 25 % of buffer pool size
#innodb_log_file_size = 5M
#innodb_log_buffer_size = 8M
#innodb_flush_log_at_trx_commit = 1
#innodb_lock_wait_timeout = 50

Судя по всему в нем проблема.

 

[Gas]

# - начало комментария, все эти строки у тебя закоментированы, да и похоже на дефолтные значения.

Самый простой путь, но не лучший, это изменение innodb_flush_log_at_trx_commit на 2 или 0. Но, нужно отдавать себе отчёт в том, что при падении сервера или mysql (в зависимости от значения) будут потеряны транзакции за примерно последнюю секунду. Это далеко не всем подходит.

Если это твой код, а не CMS-какая, то лучше обернуть пачку insert/update для кеша в одну транзакцию и не менять innodb_flush_log_at_trx_commit.

 

[StalkerClasses]

# - начало комментария, все эти строки у тебя закоментированы, да и похоже на дефолтные значения.

Самый простой путь, но не лучший, это изменение innodb_flush_log_at_trx_commit на 2 или 0. Но, нужно отдавать себе отчёт в том, что при падении сервера или mysql (в зависимости от значения) будут потеряны транзакции за примерно последнюю секунду. Это далеко не всем подходит.

Если это твой код, а не CMS-какая, то лучше обернуть пачку insert/update для кеша в одну транзакцию и не менять innodb_flush_log_at_trx_commit.

CMS..
Про падение сервера - это же не страшно, ведь там кэш-данные будут (сбросил весь кэш и сайт опять работает).
И по идее же если сервер упадет, то и сам сайт-то работать не будет.

 

[Gas]

>И по идее же если сервер упадет, то и сам сайт-то работать не будет.

Это актуально для всяких финансовых штук, например, человек переводит деньги куда-то и в случае успеха отправитель и получатель должны получить sms-ки о списании/начислении.
Понятно что ряд запросов со счетами нужно делать в одной транзакции и неконсистентного состояния счетов не будет, что у одного списали, а второму не начислили.
Но допустим транзакцию запустили, база данных отрапортовала что всё ok, мы отправили sms-ки. Но sms-ки уже ушли, а сервер навернулся и наша транзакция ещё не зафиксировалась на диске.
Деньги конечно никуда не пропали, они остались на старом счёте, но товарищи получившие уведомления об этом не знают и очень удивятся что за wtf.
Для не финансовых данных это всё не так важно.

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

 

[StalkerClasses]

>И по идее же если сервер упадет, то и сам сайт-то работать не будет.

Это актуально для всяких финансовых штук, например, человек переводит деньги куда-то и в случае успеха отправитель и получатель должны получить sms-ки о списании/начислении.
Понятно что ряд запросов со счетами нужно делать в одной транзакции и неконсистентного состояния счетов не будет, что у одного списали, а второму не начислили.
Но допустим транзакцию запустили, база данных отрапортовала что всё ok, мы отправили sms-ки. Но sms-ки уже ушли, а сервер навернулся и наша транзакция ещё не зафиксировалась на диске.
Деньги конечно никуда не пропали, они остались на старом счёте, но товарищи получившие уведомления об этом не знают и очень удивятся что за wtf.
Для не финансовых данных это всё не так важно.

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

Спасибо за ценное про финансы и про то , что нужно "понимать зачем расскомментировать".
По умолчанию в CMS - предполагается использование InnoDB-для всех таких таблиц кэша.
Попробую расскомментировать и посмотреть будет ли работать по скорости как.