У меня странная проблема, связанная с default_socket_timeout в Apache2 / php, но это происходит только в сочетании с подключением MySQL и, более конкретно, с Wordpress.
По сути, каждый раз, когда я загружаю наш Wordpress, он «зависает» и не выполняет запрос.Если я попробую еще раз (перезагрузить) или нажму ESC и открою новый браузер, новое соединение загружается мгновенно.Я полагаю, что с «первым» соединением что-то не так, и последующие соединения в порядке (пока цикл не начнется), но я не могу понять, как это исправить.Мне нигде не удалось найти подобную проблему, поэтому я предполагаю, что это довольно уникальная ситуация.
Изначально проблема с подключением длилась ровно 60 секунд, после чего сайт загружался (быстро).Это привело меня к изучению настроек php / MySQL, и я обнаружил, что изменение default_socket_timeout в /etc/php5/apache2/php.ini влияет на проблему.Теперь я изменил это значение в файле .htaccess, который я поместил в каталог Wordpress, и это делает проблему более терпимой (php_value default_socket_timeout 13).
Однако это не идеальное решение,поэтому я был бы очень признателен, если бы кто-нибудь смог пролить свет на эту проблему.
Вы можете проверить это сами на http://frozenbyte.com/test_wordpress/ - скорее всего, вы получите 13 секунд "Ожидание ...", а затем он загрузится.Это стандартная установка Wordpress на 100%.
Сайт находится на виртуальном хосте, и у меня есть доступ к оболочке (однако у меня нет доступа к phpmyadmin).Я могу опубликовать значения php.ini, хотя я твердо верю, что они все по умолчанию.Я не обнаружил ничего подозрительного в лог-файлах, но я не эксперт в этом.Я не установил / не выполнил конфигурацию для этого сервера (и мои навыки в любом случае ограничены), поэтому я не очень хорошо знаю внутреннюю работу, но я предполагаю, что она довольно стандартная.
Еще немного предыстории:
Эта проблема случалась со всем, что имело отношение к базе данных (например, phpBB, и особенно с некоторыми пользовательскими, но простыми сценариями базы данных), но где-то вдольлиния, кажется, стала проблемой только для Wordpress.Проблема не должна быть связана с нагрузкой или чем-то подобным, и не связана со временем суток.Так было уже два года.Эта проблема началась с первой установки Wordpress, хотя, если память служит, все раньше работало просто отлично (много лет назад).Теперь это влияет на все установки Wordpress (у меня три запущенных, с разными префиксами таблиц).Я на 99% уверен, что проблема не в MySQL как таковой - использование внешней базы данных MySQL не помогает.Сервер / хост обновлялся провайдером на протяжении многих лет, и я подозреваю, что, возможно, одно из этих обновлений могло бы ввести это, и, возможно, более позднее обновление исправило это для всего, кроме Wordpress.Просто теория, хотя.Поставщик на самом деле не имеет никакого понятия об этом, мне, вероятно, нужно спросить что-то более конкретное.
В некоторых тестах включение инструментов разработчика в Google Chrome помогло решить проблему (так, чтобы это происходило реже), но в моих собственных тестах я не вижу большой разницы.Это происходит во всех браузерах (я тестировал Firefox2 / Firefox3, IE6 / IE7, последнюю версию Opera, последнюю версию Chrome).
Отключение / удаление всех файлов .htaccess не имеет никакого эффекта.
Обычные веб-страницы, не относящиеся к MySQL, загружаются совершенно нормально, включая некоторые сложные php-страницы - например, проверьте корневой сайт (у него нет ссылки на Wordpress, хотя).Также phpBB (/ board) в настоящее время работает нормально (но он также имел обыкновение иметь ту же проблему в меньшей степени, не знаю, когда и почему они исчезли).
Так что я в растерянности.Вся помощь очень ценится!
Редактировать:
Похоже, что это действительно может быть связано с проблемами DNS / привилегиями MySQL ... Хотя я до сих пор не могу заставить его работать.
Вот два гранта, которые я добавил (согласно http://slackwiki.org/MySQL):Предоставьте все привилегии в базе данных. * «Dbuser» @ «hosts-ip», идентифицированный паролем «passwordhash»;
ПРЕДОСТАВИТЬ ВСЕ ПРИВИЛЕГИИ В БД. * TO 'dbuser'@'frozenbyte.com' ИДЕНТИФИЦИРОВАНО ПАРОЛЕМ 'passwordhash';
Вот / etc / hosts:
127.0.0.1 localhost localhost.localdomain
195.xx.xx.107 frozenbyte.com
В Wordpress есть только материал dbuser (например, define ('DB_USER', 'dbuser');), но я не уверен, нужно ли мне использовать здесь другого пользователя, например, www-data или что-то в этом роде ...
WordPress-хост - это localhost. Если я изменю это на «127.0.0.1», то поведение будет таким же. «frozenbyte.com» и «195.xx.xx.107» приводят к тому, что сайт загружается бесконечно и заканчивается белой страницей (я бы сказал, через 60 секунд).
Редактировать 2:
Я, похоже, теперь дал mysql все необходимые ему разрешения, но все равно без изменений. Вот что я сделал:
ПРЕДОСТАВИТЬ ВСЕ ПРИВИЛЕГИИ В БД. * TO 'dbuser' @ '%' ИДЕНТИФИЦИРОВАНО ПАРОЛЕМ 'passwordhash';
mysql> выберите пользователя, хоста из mysql.user;
+ ------------------ + ---------------- +
| Пользователь | Host |
+ ------------------ + ---------------- +
| dbuser | % |
| dbuser | 195.xx.xx.107 |
| dbuser | frozenbyte.com |
| debian-sys-maint | localhost |
| dbuser | localhost |
| корень | localhost |
+ ------------------ + ---------------- +
6 рядов в наборе (0,00 с)
mysql> сбросить привилегии;
Я думаю, что теперь это должно быть правильно, или, по крайней мере, не должно вызывать проблем с привилегиями.
Возможная проблема с DNS и способы ее решения, которую мне еще предстоит выяснить - любые советы будут полезны.
Редактировать 3:
Хорошо, это озадачивает. Используя 'show processlist;', я обнаружил, что MySQL фактически спит в течение этого периода отсутствия соединения Здесь:
mysql> показать список процессов;
| 88752 | dbuser | местный хост | база данных | Спать | 13 | | NULL |
Когда эти 13 секунд или то, что я установил в default_socket_timeout, истекло, MySQL обработает запрос. Я немного читал о проблемах DNS, и похоже, что они будут производить команды другого типа (например, «Подключиться» вместо «Спящий режим»), поэтому я думаю, что это не связано с проблемами DNS.
У кого-нибудь есть подсказка, почему будет инициирован такой процесс сна? У кого-то была похожая проблема, которая, очевидно, была вызвана session_start () в php и решена с помощью session_save_path (), но я добавил «php_value session.save_path / mypath /» в мой файл .htaccess, и это ничего не помогло, поэтому Вероятно, это аналогичная, но не та проблема, с которой столкнулся этот пользователь ...