Часто вы так тестируете? Поделитесь статистикой какой движек когда используете. Или расскажите в каких случаях что использовать. Какой смысл говорить, что всё меняется от случая к случаю и лучше тестировать? Это и так очевидно.
> Вот мы и пошли в сторону MyISAM :)
Ненене :) Мы решили, что надо базу уменьшать, а не бинарники) Кстати, там на больших объемах разница в размере далеко не в 4 раза.
> Так репликам ж тоже с дисков читать надо
Не увидел проблемы.
> Если база одного сайта будет весить 1ГБ, достаточно лишь 100 таких сайтов, чтобы превысить ваш лимит
В базу в 1Гб можно поверить, но в 100 таких проектов на одном сервере (с зеркалированием/реплицированием и т.п.) нет. Я достаточно проработал админом в одном из лучших шаред-хостеров России, чтобы утверждать, что вы скорее упретесь поочереди во все другие ресурсы, чем в размер дисков под базы.
Если будете оверселить ресурсы, то всё будет жутко тормозить и лагать, т.е. клиенты такого размера как вы описываете, просто свалят. Если не будете оверселить ресурсы, то на один сервер ну клиентов 20 влезет и то, базы у больше части не будут такие здоровые.
Если у вас базы уже дошли до 100G+ и вы используете MyISAM для экономии места, то это архитектурная проблема, которая всё равно вылезет потом.
По первой части — я бы посмотрел решение проблем с блокировками более детально, думаю это уже не совсем стандартный WP. Так навскидку не вижу возможности играться с приоритетностью без потерь. Я бы, честно, пошел в сторону уменьшения размера БД или (если надо подешевле) поставил бы рейд из SAS-дисков или даже SATA в несколько Тб. Всё равно ведь используются реплики.
> Мультисайт: wpmag.ru/2014/wordpress-multisite/
Простите, может я что-то проглядел, но не увидел там причины того, что базы под WP должны занимать 100G+. :((
> Мы так не бэкапимся :) тем не менее: STOP SLAVE; FLUSH TABLES;
Могу дополнить — если выводите реплику и с неё бекапите, то нужно еще засинкать логи и перемонтировать раздел в RO (обычного sync после флаша таблиц недостаточно, хотя уже лучше). MySQL 5.6 умеет подниматься на RO девайсах. :)
1) > Во-вторых, блокировка таблиц влияет только на запись...
Это не так и это очень важный момент.
Когда идет SELECT, блокируется вся таблица на запись и на обновление.
Когда идет запись, ставится блокировка на чтение всей таблицы (в MyISAM таблица — минимальная еденица блокировки). А это жуткие проседания времени ответа при обновлении данных или добавлении новых постов. Вы приводите пример с огромным ресурсом, где данные переваливают за 100G, значит записи в базу идут с достаточно высокой скоростью. И тогда варианта два — или изменяемые таблицы постоянно недоступны для чтения или часто изменяемые данные (как например таблица с коментами) переводится в InnoDB. Если таблицу с коментами на таком ресурсе не перевести в InnoDB, то будут большие задержки на сайте и попросту будет забиваться очередь запросов в MySQL. Если забьется очередь, то сляжет всё.
Если допустить, что мы таблицу с коментами перевели в InnoDB, т.к. в неё идет много записей, то стоит вспомнить, что у таблицы с постами есть поле comment_count, которое обновляется при каждом добавлении или удалении комента. И не только оно постоянно обновляется, но и to_ping и pinged.
Т.е. локи идут и на таблицу с постами.
Интересно у вас, как у Wordpress core-developer-а узнать, что вы с этим делаете в MyISAM.
2) Всё таки я не понимаю, что может занимать такие размеры (100G+) в БД. Медиафайлы же хранятся не в базе.
3) > Если говорить о резервном копировании при таком объеме данных, то скорее это делается все на реплике на отдельном сервере, поэтому тип блокировки и наличие транзакций никакого влияния не окажет.
Если вы пишете бинлог, то из MyISAM никаких увеличений скорости вы не выжмете.
4) > Плюс, как вы сами отметили в статье, MyISAM позволяет скопировать базу данных на уровне файловой системы, что гораздо быстрее, чем любой mysqldump.
Прочитали? А теперь забудьте про этот метод бекапа)
Если вы так бекапитесь, что у вас почти 100% будут недописанные данные. А я напомню как MyISAM восстанавливает поврежденные данные — он их просто удаляет.
Вот так вы обновляли значение количества комментариев под постом, а в результате пропал весь пост.
P.S: вы скинули ссылку на конференцию, где вы будуте рассказывать про масштабирование WordPress. Запишите видео доклада, я бы послушал.
> Спасибо автору, но после «Ubuntu 12.04» советы по оптимизации и безопасности — не воспринимаются серьезно.
Обоснуйте, пожалуйста.
Мы-то как раз не используем NGinx+Apache, у нас php-fpm стоит и CDN и много чего еще, но это другая история. Статья написана для клиентов, а Apache более универсальный. Иногда костыль удобней.
> посоветовать закрыть просмотр директорий на сервере, чтобы не пришлось таких еще пустых файлов создавать по всем папкам плагинов
Это же написано в статье, читайте внимательнее.
> iThemes Security решает большую половину проблем с безопасностью
«Я закрыл половину дыр в безопасности, теперь всё ок».
Советы давались исходя из того как часто встречаются такие проблемы, а не для админов senior-уровня.
> почему ничего не написано про Wordpress+Nginx+Fast_CGI_Cache
Еще не написано про squid и varnish, про CDN, рассылку новостей по миллионам подписчиков и многое другое.
Про размер InnoDB намеренно не говорил. БД редко бывают размеров больше 100G (в InnoDB), чтобы это стало существенно. Тем более в блогах. Даже если вы выделяете под MySQL отдельную дисковую подсистему из SSD дисков, их хватит в большинстве случаев за глаза и за уши.
Использовать же на таких объемах MyISAM без гарантий консистентности и с блокировками на полные таблицы как-то странно.
Размер бинарников может быть существенен, когда речь идет о резервном копировании. Вроде как чем меньше бинарников, тем быстрее все скопируется. Но здесь стоит упомянуть, что у MyISAM нет нормального механизма резервного копирования. Хотя это можно попробовать обойти через снапшоты — надо лочить всю базу на запись, сбросить кеш, создать снапшот и разлочить. Но у InnoDB можно без блокировок создать косистентный дамп.
Это не формулирование по-другому, это другой вопрос.
php-fpm в качестве бекенда это очень хороший вариант, его легче настроить на производительность, не имея навыков администрирования.
Apache же более гибкий. Много нужного и часто лишнего их коробки.
В статье мы рассматривали Apache, потому что до сих пор часто ставится только он один. По этой же причине многие конфиги писались под Apache, хотя могли бы быть написаны под NGinx и тогда производительность была бы выше.
Плюсов много, согласен. Но сейчас 5.6 не является дефолтной версией в дистрибутивах ОС.
Очень многое переписано, от этого переход в дефолтную стабильную ветку не такой быстрый. Из опыта помню сам как повелся на mysql 5.5 и поставил его, а потом нарвался на баг и моя InnoDB-шная база покрашилась.
Ради интереса провел небольшой тест:
Померил выборки из MyISAM и InnoDB
root@blog:/home/www# time for i in {1..1000}; do mysql wordpress -e "SELECT * FROM wp_options" >/dev/null; done
real 0m14.314s
user 0m10.729s
sys 0m2.060s
root@blog:/home/www# free -m
total used free shared buffers cached
Mem: 2012 1378 634 0 164 464
-/+ buffers/cache: 749 1263
Swap: 0 0 0
root@blog:/home/www# for n in `mysql wordpress -B -N -e "show tables;"`;do mysql wordpress -B -N -e "ALTER TABLE $n ENGINE=InnoDB;";done
root@blog:/home/www# time for i in {1..1000}; do mysql wordpress -e "SELECT * FROM wp_options" >/dev/null; done
real 0m16.113s
user 0m12.037s
sys 0m2.628s
2 секунды разницы на 1000 запросов. Т.е. MyISAM быстрее выполняет запрос на 0,002 секунды.
Если у вас такие объемы, что эта разница существенна, то вы не будете использовать MyISAM уже по соображениям надежности в Highload.
99% это вы немножко загнули, 70-80%. Пишутся сессии и т.п.
Там была ссылка на тесты, где описаны варианты Read-only для MyISAM и InnoDB.
На шаред-хостиге, когда ваши данные из БД наверняка будут читаться с дисков, MyISAM может быть производительнее.
Было бы здорово добавить:
1) Показ текущей очереди запросов;
2) slow-log
3) error-log
4) Показать вывод mysqltuner.pl.
Однако InnoDB всё равно быстрее.
Можно, к примеру, посмотреть тест Oracle:
www.oracle.com/partners/en/knowledge-zone/mysql-5-5-innodb-myisam-522945.pdf
График RO — разница в 4,5 раза это очень много.
Ненене :) Мы решили, что надо базу уменьшать, а не бинарники) Кстати, там на больших объемах разница в размере далеко не в 4 раза.
> Так репликам ж тоже с дисков читать надо
Не увидел проблемы.
> Если база одного сайта будет весить 1ГБ, достаточно лишь 100 таких сайтов, чтобы превысить ваш лимит
В базу в 1Гб можно поверить, но в 100 таких проектов на одном сервере (с зеркалированием/реплицированием и т.п.) нет. Я достаточно проработал админом в одном из лучших шаред-хостеров России, чтобы утверждать, что вы скорее упретесь поочереди во все другие ресурсы, чем в размер дисков под базы.
Если будете оверселить ресурсы, то всё будет жутко тормозить и лагать, т.е. клиенты такого размера как вы описываете, просто свалят. Если не будете оверселить ресурсы, то на один сервер ну клиентов 20 влезет и то, базы у больше части не будут такие здоровые.
Если у вас базы уже дошли до 100G+ и вы используете MyISAM для экономии места, то это архитектурная проблема, которая всё равно вылезет потом.
> Мультисайт: wpmag.ru/2014/wordpress-multisite/
Простите, может я что-то проглядел, но не увидел там причины того, что базы под WP должны занимать 100G+. :((
> Мы так не бэкапимся :) тем не менее: STOP SLAVE; FLUSH TABLES;
Могу дополнить — если выводите реплику и с неё бекапите, то нужно еще засинкать логи и перемонтировать раздел в RO (обычного sync после флаша таблиц недостаточно, хотя уже лучше). MySQL 5.6 умеет подниматься на RO девайсах. :)
Это не так и это очень важный момент.
Когда идет SELECT, блокируется вся таблица на запись и на обновление.
Когда идет запись, ставится блокировка на чтение всей таблицы (в MyISAM таблица — минимальная еденица блокировки). А это жуткие проседания времени ответа при обновлении данных или добавлении новых постов. Вы приводите пример с огромным ресурсом, где данные переваливают за 100G, значит записи в базу идут с достаточно высокой скоростью. И тогда варианта два — или изменяемые таблицы постоянно недоступны для чтения или часто изменяемые данные (как например таблица с коментами) переводится в InnoDB. Если таблицу с коментами на таком ресурсе не перевести в InnoDB, то будут большие задержки на сайте и попросту будет забиваться очередь запросов в MySQL. Если забьется очередь, то сляжет всё.
Если допустить, что мы таблицу с коментами перевели в InnoDB, т.к. в неё идет много записей, то стоит вспомнить, что у таблицы с постами есть поле comment_count, которое обновляется при каждом добавлении или удалении комента. И не только оно постоянно обновляется, но и to_ping и pinged.
Т.е. локи идут и на таблицу с постами.
Интересно у вас, как у Wordpress core-developer-а узнать, что вы с этим делаете в MyISAM.
2) Всё таки я не понимаю, что может занимать такие размеры (100G+) в БД. Медиафайлы же хранятся не в базе.
3) > Если говорить о резервном копировании при таком объеме данных, то скорее это делается все на реплике на отдельном сервере, поэтому тип блокировки и наличие транзакций никакого влияния не окажет.
Если вы пишете бинлог, то из MyISAM никаких увеличений скорости вы не выжмете.
4) > Плюс, как вы сами отметили в статье, MyISAM позволяет скопировать базу данных на уровне файловой системы, что гораздо быстрее, чем любой mysqldump.
Прочитали? А теперь забудьте про этот метод бекапа)
Если вы так бекапитесь, что у вас почти 100% будут недописанные данные. А я напомню как MyISAM восстанавливает поврежденные данные — он их просто удаляет.
Вот так вы обновляли значение количества комментариев под постом, а в результате пропал весь пост.
P.S: вы скинули ссылку на конференцию, где вы будуте рассказывать про масштабирование WordPress. Запишите видео доклада, я бы послушал.
Обоснуйте, пожалуйста.
Мы-то как раз не используем NGinx+Apache, у нас php-fpm стоит и CDN и много чего еще, но это другая история. Статья написана для клиентов, а Apache более универсальный. Иногда костыль удобней.
Это же написано в статье, читайте внимательнее.
> iThemes Security решает большую половину проблем с безопасностью
«Я закрыл половину дыр в безопасности, теперь всё ок».
Советы давались исходя из того как часто встречаются такие проблемы, а не для админов senior-уровня.
> почему ничего не написано про Wordpress+Nginx+Fast_CGI_Cache
Еще не написано про squid и varnish, про CDN, рассылку новостей по миллионам подписчиков и многое другое.
Ссылка на managed-hosting интересная, спасибо.
Про размер InnoDB намеренно не говорил. БД редко бывают размеров больше 100G (в InnoDB), чтобы это стало существенно. Тем более в блогах. Даже если вы выделяете под MySQL отдельную дисковую подсистему из SSD дисков, их хватит в большинстве случаев за глаза и за уши.
Использовать же на таких объемах MyISAM без гарантий консистентности и с блокировками на полные таблицы как-то странно.
Размер бинарников может быть существенен, когда речь идет о резервном копировании. Вроде как чем меньше бинарников, тем быстрее все скопируется. Но здесь стоит упомянуть, что у MyISAM нет нормального механизма резервного копирования. Хотя это можно попробовать обойти через снапшоты — надо лочить всю базу на запись, сбросить кеш, создать снапшот и разлочить. Но у InnoDB можно без блокировок создать косистентный дамп.
В 5.6 их в два раза больше, хотя и в 5.5 много.
Скиньте свой «mysqladmin status», посмотрим соотношение чтения/записи.
2) www.opennet.ru/base/dev/keepalive_apache.txt.html
dev.mysql.com/doc/relnotes/mysql/5.6/en/
php-fpm в качестве бекенда это очень хороший вариант, его легче настроить на производительность, не имея навыков администрирования.
Apache же более гибкий. Много нужного и часто лишнего их коробки.
В статье мы рассматривали Apache, потому что до сих пор часто ставится только он один. По этой же причине многие конфиги писались под Apache, хотя могли бы быть написаны под NGinx и тогда производительность была бы выше.
Очень многое переписано, от этого переход в дефолтную стабильную ветку не такой быстрый. Из опыта помню сам как повелся на mysql 5.5 и поставил его, а потом нарвался на баг и моя InnoDB-шная база покрашилась.
Не все готовы пользоваться MySQL 5.6
Померил выборки из MyISAM и InnoDB
2 секунды разницы на 1000 запросов. Т.е. MyISAM быстрее выполняет запрос на 0,002 секунды.
Если у вас такие объемы, что эта разница существенна, то вы не будете использовать MyISAM уже по соображениям надежности в Highload.
Там была ссылка на тесты, где описаны варианты Read-only для MyISAM и InnoDB.
На шаред-хостиге, когда ваши данные из БД наверняка будут читаться с дисков, MyISAM может быть производительнее.