Evas: Совместно с hyper-cache не пробовал, лишь с Super Cache. По поводу мемлок - всё верно, должно работать.
отключил сейчас hyper-cache и нагрузка LA 0.14 0.13 0.12 стала меньше, с гипер-кешем было 0.50 0.30 0.25 похоже действительно генерация страничек в кеш много ресурсов жрёт, но без html кеша тоже никак, он спасает при обновлении сайта.
Evas: Он имеет лишь файловый кеш, если бы могли создать tmpfs - ладно. А так, я уже посоветовал SJ Object Cache с использованием например xcache(умеет кешировать в оперативку)
А куда конкретно пытались добавить?
Попробую SJ Object Cache у меня как раз xcache стоит.
надеюсь он может совместно с hyper-cache работать или его придётся отключать?
Evas: Хм, действительно так и есть... По поводу кеша - SJ Object Cache подключите с
использованием apc|xcache|memcached (по вкусу) и кеширование в оперативку, а также DB Cache
Reloaded + Fix. Если имеется свободная оперативка попробуйте сделать memlock у мускуля. Ну а
вообще, если используете сторонние плагины для вп - оптимизируйте их код, уходите от сложных и
громоздких запросов. Если же для этих плагинов чего-то требуется добавить в бд, то скорее всего
индексы там расставлены не корректно. Включите slow лог у mysql, а также включите логирование
запросов не использующих индексы. Тема конечно не об этом, но это поможет улучшить производительность.
А так, да, вам бы перейти на выделенный сервер с шустрыми дисками и всё это дело протюнить по полной.
из громоздких запросов там, самый тормоз вот
SELECT SQL_CALC_FOUND_ROWS wp_posts . *
FROM wp_posts
INNER JOIN wp_term_relationships ON ( wp_posts.ID = wp_term_relationships.object_id )
INNER JOIN wp_term_taxonomy ON ( wp_term_relationships.term_taxonomy_id = wp_term_taxonomy.term_taxonomy_id )
WHERE 1 =1
AND wp_term_taxonomy.taxonomy = 'category'
AND wp_term_taxonomy.term_id
IN (
'49'
)
AND wp_posts.post_type = 'post'
AND (
wp_posts.post_status = 'publish'
)
GROUP BY wp_posts.ID
ORDER BY wp_posts.post_date DESC
LIMIT 24000 , 10
в конфиг my.cnf пытался добавить memlock но он не срабатывает, в переменных по прежнему locked in memory OFF
Den73: wp можно в nginx по хорошему кэшировать (настраивается довольна таки просто), hyper-cache зло, мало того что оно криво состряпано (ломается сайт при переносе) так еще и увеличивает время генерации странички.
Evas: Временные таблички создаются на диске если не хватает места выделенного этими директивами. Коль у вас wp, установите кеширующие плагины для страничек и базы.
из документации: если в таблицах используются поля типов TEXT (TEXT, TINYTEXT, MEDIUMTEXT …) или BLOB, то таблица не может быть размещена в памяти, а только на диске.
из кеширующих плагинов hyper-cache стоит, помогает, но только при повторном обращении к странице, сайт довольно часто обновляется, 3-4 раза в сутки, посещалка 9-10к уников, поэтому кеш после обновлений сбрасывается, естественно эффективности мало от него.
Evas: значит увеличите до 256. А вообще необходимо глядеть на опр. переменные статуса чтобы понять чего не хватает. Ещё вариант - прогоните тюнером, он выдаст какие параметры необходимо увеличить.
в водпрессе есть запросы которые дёргают таблицу post_content с полем TEXT вот они и создают временные таблицы на диске, увеличение параметра tmp_table_size не снижает % временных таблиц на диске, тут вариантов немного, либо переписывать весь двиг WP, либо уходить на более мощное железо.
тюнерами я прогонял mysqltuner и tuning-primer, все значения выставил по ним, не удаётся только победить временные таблицы на диске 20% и размер query cache сколько не увеличивал, его всё мало, в итоге остановился на 128м
Evas: ТС, увеличте размер временных таблиц.
Значения приведены лишь как пример, вам тут нужно указать свои.
Также незачем mysql использовать swap, если достаточно оперативки сделайте memlock
tmp_table_size = 64M
max_heap_table_size = 64M
P.S. - Если необходимо, могу помочь с оптимизацией вашего mysql, а также другого ПО. Обращайтесь, буду рад помочь.
размер временных таблиц увеличивал до 128мб ничего это не изменяло.
netwind, виртуализация у меня не XEN, а FreeBSd jail, хостер говорит на этой не сделать tmpfs
А тем временем :)
24 hours until #Mega! One more day! Are you ready?
источник: https://twitter.com/KimDotcom
версия WP 2.8
что нужно добавить в код шаблона, чтобы на нём стал отображать показания WP-Tuner?
пока он только для админки показывает.
как отключить вызов 2-х опций, чтоб они не давали запросов к базе данных?
SELECT option_value FROM wp_options WHERE option_name = 'feedwordpress_automatic_updates' LIMIT 1
SELECT option_value FROM wp_options WHERE option_name = 'sidebars_widgets' LIMIT 1
виджеты и сайдбар у меня прописаны в коде темы, автоматическое обновление тоже отключено, пробовал в файл functions.php шаблона
добавлять
add_option('sidebars_widgets', $value, '', 'no');
но запрос по прежнему идёт, только уже с функций темы.
это надо добавлять ещё до вызова темы, а куда именно непонятно, может кто подскажет?
sj_object_cache+xcache помог, действительно лучшее решение для WP.
Совместно с hyper-cache не пробовал, лишь с Super Cache.
По поводу мемлок - всё верно, должно работать.
отключил сейчас hyper-cache и нагрузка LA 0.14 0.13 0.12 стала меньше, с гипер-кешем было 0.50 0.30 0.25 похоже действительно генерация страничек в кеш много ресурсов жрёт, но без html кеша тоже никак, он спасает при обновлении сайта.
Он имеет лишь файловый кеш, если бы могли создать tmpfs - ладно.
А так, я уже посоветовал SJ Object Cache с использованием например xcache(умеет кешировать в оперативку)
А куда конкретно пытались добавить?
Попробую SJ Object Cache у меня как раз xcache стоит.
надеюсь он может совместно с hyper-cache работать или его придётся отключать?
А куда конкретно пытались добавить?
в секцию [mysqld]
port = 3306
socket = /tmp/mysql.sock
skip-locking
skip-innodb
memlock
query_cache_type = 1
query_cache_limit = 2M
query_cache_size = 32M
Хм, действительно так и есть... По поводу кеша - SJ Object Cache подключите с
использованием apc|xcache|memcached (по вкусу) и кеширование в оперативку, а также DB Cache
Reloaded + Fix. Если имеется свободная оперативка попробуйте сделать memlock у мускуля. Ну а
вообще, если используете сторонние плагины для вп - оптимизируйте их код, уходите от сложных и
громоздких запросов. Если же для этих плагинов чего-то требуется добавить в бд, то скорее всего
индексы там расставлены не корректно. Включите slow лог у mysql, а также включите логирование
запросов не использующих индексы. Тема конечно не об этом, но это поможет улучшить производительность.
А так, да, вам бы перейти на выделенный сервер с шустрыми дисками и всё это дело протюнить по полной.
из громоздких запросов там, самый тормоз вот
в конфиг my.cnf пытался добавить memlock но он не срабатывает, в переменных по прежнему locked in memory OFF
wp можно в nginx по хорошему кэшировать (настраивается довольна таки просто), hyper-cache зло, мало того что оно криво состряпано (ломается сайт при переносе) так еще и увеличивает время генерации странички.
DB Cache Reloaded и WPLANG Lite найс)
можно поподробнее, как nginx кешировать?
конфиг nginx
Временные таблички создаются на диске если не хватает места выделенного этими директивами. Коль у вас wp, установите кеширующие плагины для страничек и базы.
из документации: если в таблицах используются поля типов TEXT (TEXT, TINYTEXT, MEDIUMTEXT …) или BLOB, то таблица не может быть размещена в памяти, а только на диске.
из кеширующих плагинов hyper-cache стоит, помогает, но только при повторном обращении к странице, сайт довольно часто обновляется, 3-4 раза в сутки, посещалка 9-10к уников, поэтому кеш после обновлений сбрасывается, естественно эффективности мало от него.
значит увеличите до 256. А вообще необходимо глядеть на опр. переменные
статуса чтобы понять чего не хватает. Ещё вариант - прогоните тюнером, он
выдаст какие параметры необходимо увеличить.
в водпрессе есть запросы которые дёргают таблицу post_content с полем TEXT вот они и создают временные таблицы на диске, увеличение параметра tmp_table_size не снижает % временных таблиц на диске, тут вариантов немного, либо переписывать весь двиг WP, либо уходить на более мощное железо.
тюнерами я прогонял mysqltuner и tuning-primer, все значения выставил по ним, не удаётся только победить временные таблицы на диске 20% и размер query cache сколько не увеличивал, его всё мало, в итоге остановился на 128м
[mysqld]
port = 3306
socket = /tmp/mysql.sock
skip-locking
skip-innodb
query_cache_type = 1
query_cache_limit = 4M
query_cache_size = 128M
key_buffer_size = 64M (размер всех индексов 18мб)
max_allowed_packet = 4M
table_open_cache = 256
sort_buffer_size = 4M
read_buffer_size = 4M
read_rnd_buffer_size = 4M
myisam_sort_buffer_size = 64M
thread_cache_size = 16
concurrent_insert = 2
low_priority_updates = 1
server-id = 1
ТС, увеличте размер временных таблиц.
Значения приведены лишь как пример, вам тут нужно указать свои.
Также незачем mysql использовать swap, если достаточно оперативки сделайте memlock
P.S. - Если необходимо, могу помочь с оптимизацией вашего mysql, а также другого ПО. Обращайтесь, буду рад помочь.
размер временных таблиц увеличивал до 128мб ничего это не изменяло.
netwind, виртуализация у меня не XEN, а FreeBSd jail, хостер говорит на этой не сделать tmpfs