Соединения закрываются (MySQL)

Очень нужна ваша помощь решить такую проблему:
Сайт работал год на одном хостинге без каких либо серьёзных проблем. Количество посетителей стабильно (я его год назад перенес от другого хостера).Пару дней назад сайт временами стал грузится медленно и очень часто нажав на любую ссылку сразу выдает 500 server internal error и если пару раз перегружать страницу с ошибкой после несколько неудачных попыток она откроется секунд через 20.
Кэширование включено (hyper cache),запросов к базе на главной странице 8 на странице с новостью 13 (стоит DB cache reloaded).
Все переговоры с службой технической поддержки хостера не дали никаких результатов.Они сказали чтобы я проверил скрипты,оптимизировал код и чтобы проверил если все соединения с базой закрываются в конце запроса.Как это сделать я понятие не имею?
Может кто сталкивался с такой проблемой ?

вот текст сообщения на английском :

Your site does appear to load a bit slowly but I'm not showing any issues with the server that you are on. If you try loading any static content on the page (such as images, plain html documents) you will see that these load very quickly so it appears that the issue is not with the server but with the code on some pages. The best solution in most cases is to optimize the code for efficiency to ensure it loads as fast as possible. (If your site uses databases, check those as well. Make sure all database connections are closed at the end of query.)

В логах ошибок тысячи таких ошибок :

[Mon Apr 11 11:24:43 2011] [error] [client 95.26.119.69] Premature end of script headers: index.php
[Mon Apr 11 11:25:14 2011] [error] [client 66.220.156.245] SystemException in API_Linux.cpp:174: setuid() failed: Resource temporarily unavailable

Спасибо заранее.

Ой, кажется мне, что тут не в БД проблема, а в общем количестве разрешенных для запуска процессов. Если лимит маленький, а серверок тормознутенький, то будет болтаться куча одновременно выполняющихся процессов. Если куча достигла разрешенного предела, то очередной процесс прсто не сможет запуститься и система грязно выругается.

Если не используется mysql_pconnect (persistent connection), а в WP он не используется, то по завершении php-скрипта должны закрываться все файлы и все соединения с БД.

Короче: сервер не держит нагрузку.

Ой, кажется мне, что тут не в БД проблема, а в общем количестве разрешенных для запуска процессов. Если лимит маленький, а серверок тормознутенький, то будет болтаться куча одновременно выполняющихся процессов. Если куча достигла разрешенного предела, то очередной процесс прсто не сможет запуститься и система грязно выругается.

Если не используется mysql_pconnect (persistent connection), а в WP он не используется, то по завершении php-скрипта должны закрываться все файлы и все соединения с БД.

Короче: сервер не держит нагрузку.

Ю.Б. Спасибо за ответ
у меня сейчас хостинг план на 600 соединений.А можно как нибудь узнать какое количество соединений используется?
Может так совпало но я заметил что с тех пор как сайт тормозит начал глючить PostViews (показывает на много больше просмотров чем это есть на самом деле) ,просмотров одной новости может быть на много больше чем посетителей на сайте.

У Вас VPS/VDS или обычный shared? 600 соединений – кого с кем? Разные хостеры ставят разные рогатки, лишь бы юзера вытолкать на тариф подороже.

Посмотрите в логах Апача, может сайт ddosят или он просто попал под "хабраэффект". Какая вообще посещаемость?

Про PostViews я знаю только одно: он создает дополнительную нагрузку.

У меня обычный shared. 600 соединений – так написано в акаунте (Linux Grid Unlimited: 600 connections or more) . Я его поменял 2 месяца назад раньше был на 300 соед. тогда трудно открывались страницы но 500 ошибку выдавал только при попытке добавить или редактировать запись.
Посещаемость ~ 22 – 24 тысячи (просмотров ~ 120000).Бывали наплывы и в 40 тысяч но сайт работал без проблем.

Если 600 – это лимит одновременных http-соединений, то по моим очень-очень грубым прикидкам, если время генерации страницы не больше 10 секунд и нагрузка более-менее равномерно распределена по времени, то должно бы хватать, хотя и без запаса. Если на сайте нет интерактива, можно попробовать использовать другое кеширование – скажем, SuperCach в режиме создания статических html. Но думается мне, Ваш проект просто дорос до более серьезного сервера.

Ю.Б. спасибо большое за советы.
Я как-то пользовался Super-Cach но были проблемы с комментариями , ночью попробую поставить снова (ночью сайт работает хорошо)).Напишу я еще раз в службу поддержки посмотрим что они ответят.

Я как-то пользовался Super-Cach но были проблемы с комментариями

Вот поэтому я и уточнил насчет интерактива. К сожалению, не существует способа обеспечить динамику без увеличения нагрузки на сервер.

Чтобы определить в чем проблема (база или сервер) можно в phpMyAdmin во вкладке Процессы посмотреть висящие запросы. Периодически обновляя страницу можно получить представление о самых длинных запросах и сколько тратится времени на их отработку.

Чтобы определить в чем проблема (база или сервер) можно в phpMyAdmin во вкладке Процессы посмотреть висящие запросы. Периодически обновляя страницу можно получить представление о самых длинных запросах и сколько тратится времени на их отработку.

MAX
Я посмотрел процессы как вы сказали но не разобрался какой запрос висит.В основном таблица выглядит так :
скриншоты

Иногда при обновлении страницы появляется вот такое :

Если не затруднит объясните мне что это значит.
Спасибо заранее.

В колонке Время отображается время выполнения запроса. Чем меньше значение, тем лучше. На хороших серверах обычно 1-2 секунды максимум. Если больше, значит есть проблемы с базой. Особое внимание запросам, котоыре висят очень долго (более десятка секунд). Тут нужно раздираться откуда он идёт, например какой-то плагин.

Если база справляется, то дело в самом сервере – он не справляется с количеством http-запросов. Нужно уменьшить количество запросов с одной страницы – объединять js, css и оптимизировать графику. Проверять например, через httpfox в FireFox. Ну и крайне желательно включить кэширование, вроде моего. 🙂 Правда в этом случае вся «динамика» потеряется.

В колонке Время отображается время выполнения запроса. Чем меньше значение, тем лучше. На хороших серверах обычно 1-2 секунды максимум. Если больше, значит есть проблемы с базой. Особое внимание запросам, котоыре висят очень долго (более десятка секунд). Тут нужно раздираться откуда он идёт, например какой-то плагин.

Если база справляется, то дело в самом сервере - он не справляется с количеством http-запросов. Нужно уменьшить количество запросов с одной страницы - объединять js, css и оптимизировать графику. Проверять например, через httpfox в FireFox. Ну и крайне желательно включить кэширование, вроде моего. :) Правда в этом случае вся «динамика» потеряется.

Я только что прочитал про ваш скрипт кэширования .Как вы считаете с установкой MAXCACHE сайт будет работать? Я читал что он лучше hyper cache (сейчас он установлен). А на счет динамики – я и так по отключал все плагины.Главное чтобы комментарии добавлялись нормально а то с super cache (они появлялись не сразу).
Я почитаю немножко о вашем плагине.
Спасибо вам за ответ.

Вот сайт http://www.trozo.ru/ имеющий примерно вашу посещаемость и где стоит мой кэш. Главное, чтобы ваш сервер выдерживал пиковые нагрузки WordPress, потому что в момент сброса кэша (а это происходит раз в несколько часов) кэш начинает формировать заново, а это уже работа WordPress. Если сервер выдерживает, то кэш поможет. Если нет, то придется переходить на более производительный сервер.

Спасибо MAX
Кажется что все эти ошибки из-за hyper cache,он почему-то не работает в некоторых браузерах. Я внимательно прочитаю подробную информацию о вашем творение и определюсь с кэшированием.

Anonymous
Отправить
Ответ на: