Судя по всему - срабатывает rewrite правило...
Судя по логу - убрали данную опцию.
Благодарю за отзывы, а также сообщаю, что была проведена ещё одна оптимизация алгоритма защиты, найдена и убрана маленькая недоработка,
которая приводила к излишним проверкам, вследствие чего наблюдалось небольшая потеря производительности системы на слабых серверах.
Здравствуйте. Помимо оптимизации скриптов вам необходима оптимизация самого сервера, а именно - тонкая настройка всех компонентов веб
и mysql серверов на макс. производительность. Ну и да - необходимо больше информации... Где располагается проект? на выделенном/виртуальном
сервере или же на обычном шаред хостинге? А по теме - что за движок на сайте? Программист может помочь с кодом...
Здравствуйте. Обращайтесь, буду рад помочь.
Если не ошибаюсь, кеш этот лишь хранит, причём хранит результаты одинаковых запросов, очищается в том случае, если его размера не хватает.
Чем больше памяти под него выделено, тем больше запросов там помещается и соответственно тем легче серверу.
У вас я гляжу их ну очень много, т.е как бы мы не старались очистка будет иметь место. Но, чем больше запросов там задержится, тем лучше.
query_cache_size = 2048М, только гляньте на макс. используемую память, вроде эти параметры на неё не оказывают влияние, хотя не помню.
Если будет больше, чем есть на сервере - верните как было. А нагрузку с диска вы сняли одним лишь tmpfs. Ещё хорошим вариантом можно запретить
использовать файл подкачки с помощью параметра memlock. При этом мускл сервер поместит в озу абсолютно всё и начнёт реально расходовать выделенные
ей ресурсы под буферы и прочее. Тут надо пересмотреть, чтобы не вылести за рамки сервера, иначе быть беде)
Нет, 300 мб это не излишек. Проверяйте опытным путём, только не спешите запускать тюнер, дайте пройти времени после применения настроек, хотябы несколько часов.
Те запросы, в которых идёт NO_CACHE всегда пройдут мимо кеша, но проблема у вас не в этом, а в том, что туда не помещаются запросы, которые как раз на этот кеш расчитывают.
Об этом нам и говорит отличное от нуля значение строки Query cache prunes per day. По результату тюнера более 150 подключений я не видел.
Если же у вас наберается макс. значение (чего я не как не могу знать, зачастую параметр max_connection люди ставят просто так, от балды) - разумеется то, что получилось не есть хорошо.
Уменьшите размеры тех, буфферов что я сказал. Join до 8, sort до 4. Касаемо "консервации" я также знать не могу. Раз это хостинг, я предположил о наличии новых клиентов.
А так кроме выпадов в свою сторону я ничего не увидел, если вы всё знаете, почему же у вас возникают проблемы подобного рода?
Разводить флуд и спорить в дальнейшем я с вами не намерен, оставайтесь при своём мнении. С темы удалился, желание разговаривать с вами у меня пропало.
P.S. - на будущее, чтобы не возникало подобных ситуаций, изначально максимально описывайте ситуацию. Человек со стороны не может знать всех аспектов работы вашего проекта.
Большого запаса между Key buffer size и total MyISAM indexes быть не должно иначе будут проблемы с Key buffer hit rate.
По поводу размера выделенного под кешер запросов. Внимательно посмотрите на вывод тюнера. Если просит их увеличить, значит текущих значений недостаточно.
Эти параметры влияют на размеры кеша запросов. Как думаете, если результат запроса будет взять из кеша, вместо того, чтобы выполнять его каждый раз, нагрузка будет меньше?
Т.е в будущее вы не смотрите? Как я понял у вас общаковый хостинг и на нём распологаются разного рода клиенты с разныи сайтами, а следовательно и разными базами и типами используемых в них движков. Начнут расти таблички с типом InnoDB без базовой оптимизации получите медленную работу.
Спрашиваете почему я выбрал те или иные значения? Трудно сказать, нравится мне эти числа 😂 А если серьёзно - подобные значения подбираются опытным путём (одинаковыми для всех они не будут). Судя по размеру баз и результата тюнера я предложил их увеличить.
И дальше чего? сколько прошло с момента перезапуска мускл? 5-10 минут. Эти результаты ничего не значат, подождите хотябы несколько часов.
И да, я не помню, чтобы укзывал key_buffer равным 2GB
Чему именно? Тому, что макс. используемый объём озу увеличился?
Нет, не только из за этого. Вы увеличили глобальный Key_buffer + другие буфферы, которые выделяются на каждый поток.
Ключевым словом тут будет максимальный объём, именно столько будет использоватся при одновременных 600 подключений к вашему мускл, сейчас же у вас их меньше десятка...
Ну как что, я вижу основные проблемы, используемые движки, а также размер прочих нужных вещей.
key_buffer_size = 1,7G
tmp_table_size = 256M
max_heap_table_size = 256M
query_cache_size = 512M
query_cache_limit = 64M
sort_buffer = 32M
join_buffer_size = 64M
innodb_flush_method = O_DIRECT
innodb_flush_log_at_trx_commit = 0
Опять же это лишь моменты касающиеся базовой оптимизации.
Пропишите сиё дело, а завтра днём опять дадите результат тюнера.
Ну как всё, практически. Для максимальной производительности одних лишь тюнеров недостаточно.
Смотрю хотите, чтобы всё сделали за вас. Наглость второе счастье, да? :)
Я направил вас в нужное русло, изучайте вопрос самостоятельно, если хотите в будущем не создавать подобных тем.
Если же, по какой-то причине у вас это не получается, наймите администратора.
