Глюк с 2000 SQL запросами в WordPress + анализ SQL запросов

В последний месяц в блоге о дизайне design-mania.ru постоянно наблюдались проблемы с загрузкой веб-страниц. При всем при том, что там используется VPS сервер + установлен кэш MaxCache. Для 2к посетителей в сутки этого должно было хватать с головой. Несколько раз совместно с тех.поддержкой пытались решить проблему, однако в итоге периодически сайт «оказывался в дауне». Собственно, сегодня будет история о том, как удалось решить эту проблему, а также как можно провести анализ SQL запросов.

Первым делом я добавил в футер код отображения числа запросов.

<?php if (is_user_logged_in()) { ?>
<?php echo get_num_queries(); ?> запросов за <?php timer_stop(1); ?> секунд. <br/>
<?php } ?>

Как вы уже поняли из заголовка, результат был равен более 2000 запросам SQL к базе данных. Для такой посещаемости, да и вообще для нормального сайта, это чересчур много. Как следствие — проблемы с загрузкой. Для несколько остальных WordPress блогов и обычных сайтов число запросов колебалось от 50 до 80 штук.

Но как узнать что именно приводит к такому большому числу SQL запросов? К счастью мне попалась соответствующая статья с сайта 4remind.ru. Спасибо автору за описание решения проблемы. Я продублирую его для вас здесь + для себя дабы не забыть. По ссылке найдете более детальное описание.

1. Итак, в файле wp-settings.php из корневого каталога WordPress добавляете строку:

define( 'SAVEQUERIES', true );

Она позволяет системе запоминать SQL запросы к базе данных.

2. Дальше в файле footer.php пишем код:

<?php
if ( current_user_can( 'administrator' ) ) {
	global $wpdb;
 
	echo '<br /><br />########## SQL запросы ##########<br /><br />';
	echo '<span style="margin-left: 10px;"><b>';
	echo 'Количество SQL-запросов = ' . sizeof($wpdb->queries);
	echo '</b></span><br />';
 
	$sqlstime = 0;
	foreach ( $wpdb->queries as $qrarr ) {
		$sqlstime += $qrarr[1];
	}
 
	echo '<span style="margin-left: 10px;"><b>';
	echo 'Затрачено времени = ' . round( $sqlstime, 4 ) . ' секунд';
	echo '</b></span><br /><br />';
 
	foreach ( $wpdb->queries as $qrarr ) {
		echo '<span style="color: blue;margin-left: 10px;">SQL-запрос = </span>' . $qrarr[0] . '<br />';
		echo '<span style="color: blue;margin-left: 10px;">Время выполнения = </span>' . round( $qrarr[1], 4 ) . ' секунд<br />';
		echo '<span style="color: blue;margin-left: 10px;">Файлы и функции: </span><br />';
		$filesfunc = split( ",", $qrarr[2] );
		foreach ( $filesfunc as $funcs ) {
			echo '<span style="margin-left: 20px;">+ ' . $funcs . '</span><br />';
		}
		echo '<br />';
	}
 
	echo '<br />########## END: SQL запросы ##########<br /><br />';
}
?>

Можете добавить его вместо указанного мной в начале поста метода проверки числа запросов, т.к. это решение делает абсолютно все: и считает количество SQL запросов, показывая их время выполнения и, конечно, отображает сами запросы.

Вот как примерно выглядит результат:

Таким образом, вы можете проанализировать сколько времени занимает выполнение того или иного обращения к БД, какой плагин злоупотребляет SQL запросами и т.п. Тем пользователям, кто разбирается в веб-разработке, должно быть полезно.

3. После того как вы закончили анализ SQL запросов обязательно удалите из файла wp-settings.php определенную переменную SAVEQUERIES (закомментировать недостаточно).

…..

Что же касается моего случая, то данный анализ SQL запросов выдал мне ну очень большой список из 2000 разных позиций. Просматривать их все я бы стал очень долго. Поэтому я пошел немного иным путем и начал «традиционный поиск проблемы в WordPress» в шаблоне (убирая сомнительный код) и плагинах (отключая некоторые из них).

1. Первым делом я решил «избавиться» от модуля Simple Tags и моего хака с добавлением миниатюр в Simple Tags для связных постов. Во-первых, плагин довольно старый, во-вторых, я мог допустить ошибку при правке PHP кода. Но нет, отключение плагина ни к чему не привело.

2. После решил убрать из шаблона WP-PostRatings, что также мог нагружать БД. Эффекта не последовало.

3. Дальше я буквально вырезал из шаблона целые куски кода: футер, сайдбар целиком. При этом код анализа SQL запросов все равно показывал 2000 обращений к базе. Теоретически этого быть не могло. Точнее, это значило, что проблема не в шаблоне.

4. Следующий шаг — отключение плагинов. Если быть точным, некоторые модули, например, Broken Link Checker для поиска битых ссылок я убрал заранее, а сейчас добрался и до остальных. Мало ли что там могло заглючить. Однако и эта манипуляция ни к чему не привела.

5. Последний шаг — обновление WordPress. Не хотел к нему прибегать, так как пришлось бы обновлять разные модули, а в код некоторых из них я вносил правки + не хотелось получить несовместимость какого-то плагина с самой последней версией WordPress 4.0.

Вы будете смеяться, но после обновление WordPress запросов к БД опять стало 60-80. Проблема исчезла. Мистика, как говорится, в таких случаях. Нужно, наверное, было с этого начинать. Автоматическая процедура апдейта заняла считанные минуты, тогда как поиск решения забрал у меня парочку часов. Притом, что никаких изменений с системой, плагинами, шаблоном до появлениях глюка с 2000 SQL запросами я не проводил. Как бы там ни было, теперь вы знаете как можно решить подобную проблему и как искать вероятную причину поломки.

Понравился пост? Подпишись на обновления блога по RSS, Email или twitter!

Оцените статью:

(голосов - 4, средний балл: 5,25 из 7)

Загрузка...

Категории: Начинающим;
Теги: sql запросы, база данных, глюки плагинов, новичкам, обновление, разные ошибки.