ну, это довольно популярное мнение в "хайололоаде" - https://www.google.com/search?hl=en&q=mysql+query+cache+tuner
Но я за то, чтобы они были существенно меньше.
затык может возникнуть из-за блокировок myisam, логики работы приложения и тд. в этом случае один 10секундный всплеск числа апачей отражается в виде плохой работы кеша потом еще час.
кеш mysql - далеко не тот тип кешей, к которым привыкли программисты. Настолько не такой, что некоторые сектанты пропагандируют его полное отключение.
Для этого недостаточно просто поставить nginx. Небольшой затык на сервере и вся память будет использована апачами. Низкое значение MaxClients эту ситуацию предотвращает.
только из практики. например, делаем такой график http://ww.udaff.com/munin/localdomain/localhost.localdomain-apache_processes.html
и видим, что тут 10 хватает с запасом. единичные всплески munin выравняет.
Идея в том чтобы уменьшить MaxClients, чтобы апачи попусту не плодились, а запросы становились в очередь. Каждый апач - это лишних 64-128 мб памяти отнятых у кеша ОС. Уменьшать max-connections в mysql не нужно.
Это работает для типичных сайтов. Не для тех, на которых скрипты выполняются долго по объективным причинам - например, скрипты качающие что-то из сети.
Ну в данном случае и замеров никаких не сделано. Не известно насколько точно поможет.
тут вам должно хватить число таблиц*3.
Конкретно по этому параметру mysqltuner частенько такое выдает. Проблема в том, что он не может отличить действительное создание таблицы на диске от таблицы в памяти. А в самом mysql нет достоверных счетчиков для этого факта.
Так что повышайте без фанатизма : повысили и снова оценили mysqltuner. Если показатель не уменьшился или уменьшился несущественно - уже хватит.
ну можно и поднять key_buffer
Вообще, параметров-то много, но на порядки ускорить mysql изменением настроек обычно не получится. Сосредоточьтесь на других методиках лучше.
Вот сказал же - 42, а у вас не меньше 117. И nginx наверняка не стоит.
Тут нет прямой связи. Вы нашли текст ошибки, который выдает mysql и пытаетесь делать выводы на основании разных текстов ошибок из разных программ. Приложение может обозвать ошибку как угодно и вывести какой угодно текст.
Может. А может и не может. Гадать непродуктивно. Надо анализировать.
Опять попробую пальцем в небо, раз вам так нравится этот формат общения :
попробуйте постоянные соединения в конфиге приложения включить. Это должно исключить ситуацию, когда backlog недостаточен. Но увеличить объем памяти потребляемой mysql.
у вас же там wordpress ? ну вот как-то так http://insanergy.nl/wordpress/persistent-mysql-connections-wordpress/
Z-Style, это просто верхняя граница числа создаваемых потоков в mysql. не резервирует, то есть.
Пальцем в небо. Вы же сами хотели этого.
Хотя по-моему, это число в пределах нормального значения для обычных сайтов, обычного физического сервера гигабайт на 4, на котором обычно стоит nginx.
42.
поставьте в MaxClients 42
max-connections, я так понял, вы уже пробовали, но есть еще лимиты на соединений в час у каждого пользователя. Маловероятно, что вы их используете.
Ну как же некуда? если запросы будут обрабатываться быстрее, то число активных соединений в каждый конкретный момент времени уменьшится.
И второй путь - уменьшить MaxClients. Обычно ничего менять не надо и apache сам сделает очередь.
