myhand: Бегите от таких сектантов. Те, у кого прямые руки - без проблем учитывают наличие такой сущности с пользой для себя. WP не исключение, он не настолько паршив.
myhand: Разумные лимиты на число апачей должны быть и так и эдак меньше доступной памяти (на сервере есть и другие зверушки кроме апача, а все еще и "шевелиться" должно в пике).
Но я за то, чтобы они были существенно меньше.
затык может возникнуть из-за блокировок myisam, логики работы приложения и тд. в этом случае один 10секундный всплеск числа апачей отражается в виде плохой работы кеша потом еще час.
myhand: Ну какие тут еще замеры? WP - должно помочь. Сейчас явно кеш используется, мягко говоря - слабо.
кеш mysql - далеко не тот тип кешей, к которым привыкли программисты. Настолько не такой, что некоторые сектанты пропагандируют его полное отключение.
myhand: Единственное достоинство этого подхода _в среднестатистическом случае_ (хайлоад всякий пока не рассматриваем) - "тяжелые" процессы не висят впустую в памяти, занимаясь запихиванием контента "в трубу" до медленных клиентов.
Для этого недостаточно просто поставить nginx. Небольшой затык на сервере и вся память будет использована апачами. Низкое значение MaxClients эту ситуацию предотвращает.
Z-Style: Не понимаю, зачем мне уменьшать max-connections, если ресурсы позволяют? Чтобы возникла ошибка "too many connections"?
Идея в том чтобы уменьшить MaxClients, чтобы апачи попусту не плодились, а запросы становились в очередь. Каждый апач - это лишних 64-128 мб памяти отнятых у кеша ОС. Уменьшать max-connections в mysql не нужно.
Это работает для типичных сайтов. Не для тех, на которых скрипты выполняются долго по объективным причинам - например, скрипты качающие что-то из сети.
myhand: Зато в разы, в данном случае, -запросто. Особенно, если пишут относительно мало.
Ну в данном случае и замеров никаких не сделано. Не известно насколько точно поможет.
Пока что возник вопрос: как правильно выставить параметр table_cache ?
тут вам должно хватить число таблиц*3.
myhand:
[!!] Temporary tables created on disk: 49% (441K on disk / 884K total)
Если не получится избавиться от временных таблиц по объективным причинам - попробуйте использовать tmpfs для временных файлов mysql.
Конкретно по этому параметру mysqltuner частенько такое выдает. Проблема в том, что он не может отличить действительное создание таблицы на диске от таблицы в памяти. А в самом mysql нет достоверных счетчиков для этого факта.
Так что повышайте без фанатизма : повысили и снова оценили mysqltuner. Если показатель не уменьшился или уменьшился несущественно - уже хватит.
[OK] Key buffer size / total MyISAM indexes: 6.0M/45.1M
ну можно и поднять key_buffer
Z-Style: настраивать mysql я так понимаю еще нужно.
Вообще, параметров-то много, но на порядки ускорить mysql изменением настроек обычно не получится. Сосредоточьтесь на других методиках лучше.
[OK] Highest usage of available connections: 29% (117/400)
Вот сказал же - 42, а у вас не меньше 117. И nginx наверняка не стоит.
Z-Style: В моем случае проблема точно не в этом параметре, т.к. ошибка выдается "error establishment database", а изменение max-connections в большую сторону ничего не дает.
Тут нет прямой связи. Вы нашли текст ошибки, который выдает mysql и пытаетесь делать выводы на основании разных текстов ошибок из разных программ. Приложение может обозвать ошибку как угодно и вывести какой угодно текст.
Может эта ошибка возникает в следствии того что на обработку запросов к БД не хватает процессорного времени? (Во времена загрузки когда может возникнуть такая ошибка, в top видно, что id=0) А может то же самое, но из-за того что не хватает оперативной памяти? (т.к. опять же, во время сильной загрузки свободной памяти практически не остается)
Может. А может и не может. Гадать непродуктивно. Надо анализировать.
Опять попробую пальцем в небо, раз вам так нравится этот формат общения :
попробуйте постоянные соединения в конфиге приложения включить. Это должно исключить ситуацию, когда backlog недостаточен. Но увеличить объем памяти потребляемой mysql.
Хотя по-моему, это число в пределах нормального значения для обычных сайтов, обычного физического сервера гигабайт на 4, на котором обычно стоит nginx.
Бегите от таких сектантов. Те, у кого прямые руки - без проблем учитывают наличие такой сущности с пользой для себя. WP не исключение, он не настолько паршив.
ну, это довольно популярное мнение в "хайололоаде" - https://www.google.com/search?hl=en&q=mysql+query+cache+tuner
Разумные лимиты на число апачей должны быть и так и эдак меньше доступной памяти (на сервере есть и другие зверушки кроме апача, а все еще и "шевелиться" должно в пике).
Но я за то, чтобы они были существенно меньше.
затык может возникнуть из-за блокировок myisam, логики работы приложения и тд. в этом случае один 10секундный всплеск числа апачей отражается в виде плохой работы кеша потом еще час.
Ну какие тут еще замеры? WP - должно помочь. Сейчас явно кеш используется, мягко говоря - слабо.
кеш mysql - далеко не тот тип кешей, к которым привыкли программисты. Настолько не такой, что некоторые сектанты пропагандируют его полное отключение.
Единственное достоинство этого подхода _в среднестатистическом случае_ (хайлоад всякий пока не рассматриваем) - "тяжелые" процессы не висят впустую в памяти, занимаясь запихиванием контента "в трубу" до медленных клиентов.
Для этого недостаточно просто поставить nginx. Небольшой затык на сервере и вся память будет использована апачами. Низкое значение MaxClients эту ситуацию предотвращает.
Тогда встречный вопрос: как правильно определить для себя параметр MaxClients?
только из практики. например, делаем такой график http://ww.udaff.com/munin/localdomain/localhost.localdomain-apache_processes.html
и видим, что тут 10 хватает с запасом. единичные всплески munin выравняет.
Не понимаю, зачем мне уменьшать max-connections, если ресурсы позволяют? Чтобы возникла ошибка "too many connections"?
Идея в том чтобы уменьшить MaxClients, чтобы апачи попусту не плодились, а запросы становились в очередь. Каждый апач - это лишних 64-128 мб памяти отнятых у кеша ОС. Уменьшать max-connections в mysql не нужно.
Это работает для типичных сайтов. Не для тех, на которых скрипты выполняются долго по объективным причинам - например, скрипты качающие что-то из сети.
Зато в разы, в данном случае, -запросто. Особенно, если пишут относительно мало.
Ну в данном случае и замеров никаких не сделано. Не известно насколько точно поможет.
тут вам должно хватить число таблиц*3.
Если не получится избавиться от временных таблиц по объективным причинам - попробуйте использовать tmpfs для временных файлов mysql.
Конкретно по этому параметру mysqltuner частенько такое выдает. Проблема в том, что он не может отличить действительное создание таблицы на диске от таблицы в памяти. А в самом mysql нет достоверных счетчиков для этого факта.
Так что повышайте без фанатизма : повысили и снова оценили mysqltuner. Если показатель не уменьшился или уменьшился несущественно - уже хватит.
ну можно и поднять key_buffer
настраивать mysql я так понимаю еще нужно.
Вообще, параметров-то много, но на порядки ускорить mysql изменением настроек обычно не получится. Сосредоточьтесь на других методиках лучше.
Вот сказал же - 42, а у вас не меньше 117. И nginx наверняка не стоит.
В моем случае проблема точно не в этом параметре, т.к. ошибка выдается "error establishment database", а изменение max-connections в большую сторону ничего не дает.
Тут нет прямой связи. Вы нашли текст ошибки, который выдает mysql и пытаетесь делать выводы на основании разных текстов ошибок из разных программ. Приложение может обозвать ошибку как угодно и вывести какой угодно текст.
Может эта ошибка возникает в следствии того что на обработку запросов к БД не хватает процессорного времени? (Во времена загрузки когда может возникнуть такая ошибка, в top видно, что id=0) А может то же самое, но из-за того что не хватает оперативной памяти? (т.к. опять же, во время сильной загрузки свободной памяти практически не остается)
Может. А может и не может. Гадать непродуктивно. Надо анализировать.
Опять попробую пальцем в небо, раз вам так нравится этот формат общения :
попробуйте постоянные соединения в конфиге приложения включить. Это должно исключить ситуацию, когда backlog недостаточен. Но увеличить объем памяти потребляемой mysql.
у вас же там wordpress ? ну вот как-то так http://insanergy.nl/wordpress/persistent-mysql-connections-wordpress/
Z-Style, это просто верхняя граница числа создаваемых потоков в mysql. не резервирует, то есть.
Почему 42 чем это определяется?
Пальцем в небо. Вы же сами хотели этого.
Хотя по-моему, это число в пределах нормального значения для обычных сайтов, обычного физического сервера гигабайт на 4, на котором обычно стоит nginx.
42.
поставьте в MaxClients 42
Каких именно?
max-connections, я так понял, вы уже пробовали, но есть еще лимиты на соединений в час у каждого пользователя. Маловероятно, что вы их используете.
Ну как же некуда? если запросы будут обрабатываться быстрее, то число активных соединений в каждый конкретный момент времени уменьшится.
И второй путь - уменьшить MaxClients. Обычно ничего менять не надо и apache сам сделает очередь.