Мишо, для начала зайдите в SSH и выполните в корне своей домашней директории что-то типа :
find . -mtime -1 -print
Посмотреть файлы измененные не более суток назад. Циферку по желанию подставьте сами
Потому что кроме config.php есть еще масса разных файлов (включая саму БД) которые могут редирект выдавать.... И повторюсь для вас еще раз, телепатов тут нет и никто не будет сидеть и угадывать ваши проблемы, давайте доступ - давайте домены - посмотрим...
Мишо, вы бы домены указали свои, а то телепатов нет тут.
Возможно доступов дали бы людям, мало вероятно что без этого кто-то что-то подскажет дельное, а время судя по всему идет....
Если вы говорите что не работают только ваши сайты и только на WP скорее всего поломали вас, а редирект уже может и в базе самого WP находится...
Посмотрите какие файлы менялись за последние несколько суток на акаунте. Посмотрите логи доступа к акаунту если таковые имеются. Что у вас вообще за услуга ? Хостинг? Сервер? ВПС?
Да да , буду смотреть в этом направлении, винты одинаковые и там soft-mirror , т.е писать должно одинаково....
spbrf, обращайтесь, настроим, подскажем.
pupseg, насчет анализа лога, понимаю, но расскажет он не совсем мне, а расскажет клиентам что у них где-то нет индексов, а где-то их программист сделал какашку, я так понимаю :D Первоначальная задача оградить сервер от зависаний по желанию mysql ;)))) А уже конечно позже будем анализировать данные вместе с клиентами и их программистами если будет надо.. но пока рано. :)
Спасибо за рекомендации и напутствия, если у кого-то еще есть что сказать - я внимательно выслушаю.
Не за что, будут вопросы - обращайтесь.
Всем остальным напоминаем, о том что:
Создаются файлы размером от 50 до 500 MB. А кто именно их создает .... не ясно.... Как кстати посмотреть от каких запросов эти временные таблицы? ---------- Добавлено 06.02.2013 в 13:26 ----------
Кстати тоже это интересно, можт один из драйвов шабашит? Но как бы SMART молчит, все ок! ---------- Добавлено 06.02.2013 в 13:36 ---------- После 7 часов работы:
+-------------------------+------------+
| Variable_name | Value |
| Qcache_free_blocks | 3774 |
| Qcache_free_memory | 1008126648 |
| Qcache_hits | 16367635 |
| Qcache_inserts | 4043140 |
| Qcache_lowmem_prunes | 1022268 |
| Qcache_not_cached | 159970 |
| Qcache_queries_in_cache | 61687 |
| Qcache_total_blocks | 153160 |
[!!] Total fragmented tables: 34
[!!] Query cache prunes per day: 3,541,660
[!!] Joins performed without indexes: 2083
[!!] Temporary tables created on disk: 29% (77K on disk / 259K total)
Интересно откуда берутся фрагментированные таблицы, после optimize они начали появляться почти что моментально, при перезапуске sql последнем их было всего 2 (предлагает их пересоздать, так как они не могут быть оптимизированы), а сейчас уже 34..... Как часто надо делать optimize и от чего зависит фрагментация в какие моменты она появляется ?
Запросов много , спору нет , но и сервер не P4 / 512 ram :)
В общем "Query cache prunes per day" это экстраполяция результата на сутки при текущем положении дел с Qcache_lowmem_prunes..... т.е значение весьма относительное..... Но при этом всплывают новые вводные. В моем первом посте, планируемое значение было 46 миллионов, сейчас это значение 1 миллион, соответственно понизился рейт Qcache_lowmem_prunes в работе кеша.
В общем судя по тому, что я вижу, 1 GB при интенсивности и "качестве" моих запросов хватает на 60-70 тысяч записей в кеше, попробую поднять до 2 GB как вы и писали, посмотрим, возможно 120-140 тысяч записей будут давать меньший рейт Qcache_lowmem_prunes.
// Небольшой промах в данных, при 80 MB свободного кеша, в кеше находится ~110k записей. Ниже 90-70 мб не падает, уже появляются Qcache_lowmem_prunes и Qcache_queries_in_cache не ростет , видимо еще резерв какой-то :D 10% :)
При этом всем возник еще вот такой вот момент интересный, если в 900 MB влезло 110k записей, это получается около 8 килобайт на запрос, среднее тут конечно не совсем уместно :D но все равно значение query_cache_limit=64MB выглядит монстром по сравнению с 8 килобайтами :) что-то мне подсказывает, что даже 1 MB для этого лимита - много :D
Спасибо.
Пока что привел буферы к такому положению дел:
[OK] Maximum possible memory usage: 23.4G (74% of installed RAM)
Думаю 75% вполне нормально... рекомендованное значение 80 (где-то в доках или на очередном сайте с вариацией настройки)
Поднял пока до :
| query_cache_size | 1073741824 |
посмотрю через часок на количество prune.... замеряю среднее в секунду... станет понятно , влияет или не влияет..---------- Добавлено 06.02.2013 в 05:51 ----------+-------------------------+-----------+
+-------------------------+-----------+
| Qcache_free_blocks | 10 |
| Qcache_free_memory | 726589992 |
| Qcache_hits | 87370 |
| Qcache_inserts | 63245 |
| Qcache_lowmem_prunes | 0 |
| Qcache_not_cached | 580 |
| Qcache_queries_in_cache | 61096 |
| Qcache_total_blocks | 122654 |
Это после 5 минут работы, от 1Г осталось ~700 метров, думаю что минут через 15-20 пойдут четко Qcache_lowmem_prunes, возможно следует "меньше хранить" (в плане времени).. ?
/// Я только что перестал полагать, что max connections достигает 500 эффективно, ведь по сути это могут быть и WAIT сессии которые в силу нагрузки fs висят длительное время.....
/// В общем сутки - двое посмотрю в этом положении. Qcache_free_memory осталось 550 mb :) Верно ли я понимаю, что значение надо выверять таким образом, что бы не достигалось состояние окончание памяти в кеше и при этом уже начинали удаляться те запросы, которые должны выпасть из кеша, освобождая в нем память?
//// Так же хочу понять, достаточно ли будет собрать файл всех запросов за какой-то период времени, найти в нем все JOIN и следом просмотреть в каких из этих таблиц нет индексов?
//// Для того что бы свести к минимуму: "Joins performed without indexes"
//// Память в кеше все еще стремится к нулю.... ~350MB осталось ;) (Должна ли она вообще высвобождаться там? Или принцип то кеша в сборе информации в памяти.... как бы... просто уже получается около 60k запросов в кеш помещено, должно быть разумное количество перед тем как они начнут повторяться? :) ) при этом Qcache_not_cached ~1k. Т.е процент довольно не плох, попаданий в кеш уже ~250k.
Не влез 1 график :)
