из громоздких запросов там, самый тормоз вот
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
можно поподробнее, как nginx кешировать?
конфиг nginx
из документации: если в таблицах используются поля типов TEXT (TEXT, TINYTEXT, MEDIUMTEXT …) или BLOB, то таблица не может быть размещена в памяти, а только на диске.
из кеширующих плагинов hyper-cache стоит, помогает, но только при повторном обращении к странице, сайт довольно часто обновляется, 3-4 раза в сутки, посещалка 9-10к уников, поэтому кеш после обновлений сбрасывается, естественно эффективности мало от него.
в водпрессе есть запросы которые дёргают таблицу 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
tmp_table_size = 64M max_heap_table_size = 64M
размер временных таблиц увеличивал до 128мб ничего это не изменяло.
netwind, виртуализация у меня не XEN, а FreeBSd jail, хостер говорит на этой не сделать tmpfs
для файлов 644 для папок 755
не буду тему создавать, спрошу здесь.
Почему ispmanager стал менять права на запись с 644 на 666 заметил сегодня.
может кто то сталкивался с такой проблемой, куда копать?
Спасибо, но не сработало, хостер сказал, что на vps это не возможно сделать из за ограничения ядра, буду думать о переезде на дедик, а пока покручу my.cnf
проблема с временными таблицами которые пишутся на диск, выделение памяти под mysql не даёт ощутимого результата.
Есть категория в ней более 40000 записей, как её разделить на несколько отдельных категорий, может есть какой нибудь плагин для этого или скрипт?
дело в том что из за неё тормозит база.
Вот ещё хорошая для нас новость:
Закрытие крупнейшего файлообменника Megaupload около года назад оказало противоречивое воздействие на кассовые сборы кинофильмов. Исследование влияния этого события на сборы 1344 фильмов в 49 странах, проведённое немецкими и датскими учёными, выявило, что от закрытия Megaupload выиграли только высокобюджетные блокбастеры, идущие более чем на 500 экранах. Фильмы со средним и маленьким бюджетом скорее проиграли — их кассовые сборы только уменьшились, хоть и не очень значительно.
Исследователи предполагают, что этот эффект может быть связан с тем, что блокбастеры получают достаточную раскрутку централизованными средствами — через традиционную рекламу. А малобюджетные фильмы гораздо сильнее зависят от «вирусной» рекламы, и свободный файлообмен играет в этом настолько важную роль, что положительный эффект от более быстрого распространения информации о фильме перевешивает отрицательный от замещения походов в кинотеатр бесплатным домашним просмотром. Благодаря файлообмену больше платёжеспособных зрителей узнают о фильме, и пираты фактически бесплатно рекламируют кино, рассказывая о нём знакомым и делясь ссылками.
источник: http://habrahabr.ru/post/160131/
