Отключал кеширование, и написал об этом в первом пункте (когда менял еще тип кеша). Не помогло. И вот только что еще раз перепроверил — то же самое.

Насчет InnoDB/MyISAM. Я просто попробовал варианты, которые нагуглил тут на сайте. Кому-то смена типа на myisam как раз помогла, хотя да, все говорят, что целостность-безопасность-итп.

Дело не в InnoDB, а в том как он настроен.

innodb-flush-log-at-trx-commit    = 2
innodb_locks_unsafe_for_binlog    = 1

И будет вам счастье.

Думаю это счастье отсечет от общего времени около 200-300мс.
А у ТС загрузка около 2-7 сек. Думаю проблема скорее в «незаточенности» железа под сервер.

Это «счастье» повысило у нас производительность UPDATE/INSERT в 10 раз.

А как должно быть заточено железо? 2ГГц, 2Гб оперативки (может быть, не очень быстрый диск, это да). Или есть какая-то принципиальная разница?

innodb-flush-log-at-trx-commit    = 2

уже было, только в формате

innodb_flush_log_at_trx_commit = 2

Стали появляться цифры 1,6-2,1 вместо 2,1-2,6 но на некоторых страницах все равно вылетает и 4,6. Но 1,6 уже лучше (:

Вот весь конфиг innodb:

innodb_data_home_dir = "%dprogdir%\\userdata\\%mysql_driver%"
innodb_data_file_path = ibdata1:10M:autoextend
innodb_read_io_threads=4
innodb_write_io_threads=4
innodb_buffer_pool_size = 20M
innodb_additional_mem_pool_size = 1M
innodb_log_file_size = 64M
innodb_log_buffer_size = 1M
innodb_log_files_in_group = 2
innodb_max_dirty_pages_pct = 90
innodb_flush_log_at_trx_commit = 2

innodb_locks_unsafe_for_binlog    = 1

innodb_lock_wait_timeout = 30
innodb_thread_concurrency=4
#innodb_force_recovery=1
#innodb_file_per_table = 1
#innodb_fast_shutdown
#skip-innodb_doublewrite

Стали появляться цифры 1,6-2,1 вместо 2,1-2,6 но на некоторых страницах все равно вылетает и 4,6. Но 1,6 уже лучше (:

Вы не очень поняли что произошло. У нормально настроенного LS база данных не является узким местом. Узкое место там Smatry. Поэтому тестировать это дело надо на топике с несколькми сотнями комментариев от кучи пользователей — вот там заметно что и как. Если у вас скажем такая страница генерируется 2 секунды, то база там будет занимать не больше 25% общего времени и даже если вы уберете базу в ноль — на общем времени генерации эффект не будет особо заметен.

как я уже писал, при прочих равных innodb_flush_log_at_trx_commit = 2 очень увеличивает скорость INSERT/UPDATE. где вы почувствуется эффект от этого? — там где они есть, а ничего другого нет. Например Ajax запроса на "+" или "-" заметки или топика, или добавление нового комментария — должны заработать намного быстрее.

Если у вас скажем такая страница генерируется 2 секунды, то база там будет занимать не больше 25% общего времени и даже если вы уберете базу в ноль — на общем времени генерации эффект не будет особо заметен.

Примерно понял. Но вот цифры-то поменялись? В конфиге уже был

innodb_flush_log_at_trx_commit = 2

Я добавил только

innodb_locks_unsafe_for_binlog    = 1

и цифра общего времени упала до 1,6 сек.

Тогда вернулись с чего начинали, если это не БД, тогда что? Причем да, меня удивляло, что в цифрах в футере MysQL time: 0.109, Cache time: 0.14063, PHP time load modules: 1.125, а full time: 2.688. То есть, 0.109+0.14063+1.125 = 1.37463 != 2.688 Куда-то уходят еще 1.31337 сек.

И 1.125 сек на php на пустой странице? Это нормально?

Тогда вернулись с чего начинали, если это не БД, тогда что? Причем да, меня удивляло, что в цифрах в футере MysQL time: 0.109, Cache time: 0.14063, PHP time load modules: 1.125, а full time: 2.688. То есть, 0.109+0.14063+1.125 = 1.37463 != 2.688 Куда-то уходят еще 1.31337 сек.

Время кеширования больше времени базы? Это как??? Так быть не должно файловый кеш что ли?

На тот момент да. Я просто взял цифры из поста. Вот сейчас

$config['sys']['cache']['type']   = 'memory'; 

такие цифры:

MySql
query: 4
time: 0 	
Cache
query: 41
— set: 1
— get: 21
time: 0.04688 	
PHP
time load modules: 0.984
full time: 2.016

И, кстати, все равно 0.04688 > 0.
И все равно, около секунды куда-то уходит, помимо перечисляемых потребителей.

time load modules: 0.984 — очень много. Не должно такого быть. APC или XCache стоит? php-fpm я надеюсь?

Эм… Давайте разбираться. APC — это Alternative PHP Cache? Если стоит, то неочевидно для меня. XCache тоже вроде бы нигде не упоминается в конфиге. Сейчас тестирую на OpenServer: Apache/2.4.6, PHP 5.3.27, MySQL 5.5.33 (InnoDB), включен Memcached 1.4.5

php-fpm я надеюсь?

а как узнать точно? в phpinfo ни «fpm», ни «fastcgi» не употребляется.

Ну, у вас такое время загрузки модулей что я выдаю два предположения: либо у вас катастрофически не хватает CPU (что сомнительно) либо у вас php по каким-то причинам работает медленно.
копать тут livestreet.ru/blog/dev_documentation/14961.html

Уточню: надо и часть 6 посмотреть с php и 7 c memcached? Или толко настройки memcached в 7й части? Дело осложняется тем, что там выкладки под *nix, а у меня wamp и так просто на него APC не запилишь. Я уж думаю, не бросить ли все и уехать на хостинг. Но, опасаюсь, имеющийся виртуальный хостинг не шибко будет круче.

*поправка: часть 8 вместо 7.

Читать лучше вообще все части. Если у вас не *nix сервер то это не ко мне — не знаю и не умею :)

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

Вы что думаете что только в «форейн ключах» разница между MyISAM и InnoDB? Любая DML операция в рамках MyISAM вешает lock на всю таблицу, что цитирую «Приводит к отсутствию масштабируемости, то есть к сильной деградации производительности с повышением нагрузки.»

Забудьте про существование MyISAM. Никогда не используйте MyISAM.

(хоть смена типа не помогла, спрошу на будущее) А вот если бы с myisam работало бы быстрее, можно ли было разрабатывать на ней, а потом при переезде на хостинг конвертировать это все в innodb и продолжать работать?

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

а потом при переезде на хостинг конвертировать это все в innodb и продолжать работать?

внешние ключи для каждой таблицы сами будете назначать?

просто сконвертировать — можно, но это будет уже не та база, если она была изначально в иннодб.

параллельно у меня висит скрипт на nodejs который пишет стату просмотров топика.
У него пул в 5 персистент-коннектов к БД. Обрабатывает успешно 200 инсерт/апдейт запросов. Таблицы все в MyISAM.
Таблица, куда пишется стата, участвует в выборке.
На работе сайта никак не сказывается.

200 запросов в сек имеется в виду. Кластер из 8 скриптов при тестировании делал до 1,5k записей в сек.

не согласен.
Однозначно нельзя так говорить. InnoDB лучше в плане надежности. Но на нагруженных проектах у вас эта надежность аукнется тем, что инсерт и апдейт запросы по базе будут увеличиваться по времени из-за большого количества селектов в это время. У InndoDB да, блокировка может осуществляться на уровне строк, но по сути оно навесит вам еще блоки на все реляции.
У меня лично траблы с InnoDB начались после 50к посетителей из-за innodb_flush_log_at_trx_commit = 1 (2 существенно не влияло). И решались установкой параметра в 0, из-за чего вся надежность исчезала. После чего пришлось перейти на MyISAM.
Да если думаете, что во всем виновато железо, то работает все на Intel® Xeon® CPU E5-2620 0 @ 2.00GHz 64Гб ОЗУ. Так что для мускула простора много.

P.S. Я думаю тут масштабируемостью можно пожертвовать.

а вот скорость работы заметно будет быстрее с MyISAM.

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

это практически не заметно

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

kpoxas… вы категорически заблуждаетесь во многом.

Во-первых MyISAM не хуже InnoDB в плане надёжности. Целостность данных и надёжность — это не одно и то же.

Во-вторых, просто в силу своей природы, при хоть какой-то параллельной нагрузке MyISAM проигрывает InnoDB в производительности всегда. И чем больше такая нагрузка — тем больше проигрыш. И с какого-то момента (high load), MyISAM умирает полностью.

Однако, бывают «single thread» конфигурации, для отдельного класса задач, и вот там — да, MyISAM имеет смысл. Но это совершено точно, не случай LiveStreet.

innodb_flush_log_at_trx_commit = 0 не убивает вам надёжность. C этой опцией вы имеете шанс потерять изменения за последние несколько секунд в случае краша MySQL демона или сервера. Ужасная потеря для LS :).

innodb_flush_log_at_trx_commit = 2 — тоже самое что выше, но только при краше сервера. Краш MySQL демона к потере данных не приведет.

Если вам innodb_flush_log_at_trx_commit = 0 помогает, а innodb_flush_log_at_trx_commit = 2 — нет, то это уже знак знак где копать. например в конфигурации лога: innodb_log_file_size?
Ну и innodb_locks_unsafe_for_binlog = 1 всё же рекомендую. :)

я не спорю про заявленные характеристики обоих типов, но все же говорить, что MyISAM умерло, все же рано.
Я просто дал советы по практическому использованию. Разные проекты имеют разное отношение запросов insert/update/select. И в выигрыше по производительности InnodB над MyISAM в зависимости от преобладания тех или иных запросов не все так однозначно.

я не спорю про заявленные характеристики обоих типов, но все же говорить, что MyISAM умерло, все же рано.
Я просто дал советы по практическому использованию. Разные проекты имеют разное отношение запросов insert/update/select. И в выигрыше по производительности InnodB над MyISAM в зависимости от преобладания тех или иных запросов не все так однозначно.

MyISAM — мёртв, за исключением узкого класса специфических задач. И то. для тех задач есть лучшие решения уже. там вообще лучше не связываться с MySQL.

В контексте LiveStreet (конкурентная среда с большой мещаниной разнотипных запросов) — не вариант никогда и нигде.

у меня при росте посещаемости, в топе остается только apache либо php-fpm. Мускул живет и здравствует на MyISAM.

давайте не будем холиварить. Здесь в ветке приведены объективно дововоды. Пусть уже юзер сам выбирает.

И с какого-то момента (high load), MyISAM умирает полностью.

Тут можно поподробней. Почему умирает и как надо нагрузить, чтобы это произошло?

Тут можно поподробней. Почему умирает и как надо нагрузить, чтобы это произошло?

Параллельность подразумевает в данном случае большое количество не спящих коннектов к базе одновременно. т.е. ваш пример с 5-ю коннектами — это фигня. PHP как работает? — Ecли грубо то 1 процесс = 1 коннект. (мы рузумеетеся в контексте php-fpm говорим, ок?) Т.е. если у вас 200 человек одновременно страницу запросят вы получите 200 PHP процессов и 200 коннектов к базе — вот такой сценарии для MyISAM очень плох. Сглаживать ситуацию могут всякие-разные кэши — особенно кэш запросов.

В продолжение дискуссии:
tag1consulting.com/mysql_engines_myisam_vs_innodb

Статья старая. 5 лет, типа того. Вся правда о том кто лучше (и в том числе быстрее) MyISAM или InnoDB. C тех пор InnoDB стал намного мощнее.

спасибо, я где-то видел еще с реальными тестами.