1.4.4 Проблемы загрузки после авторизации

Добрый день!

Возникла проблема совсем не понятная для меня.

Форум стал очень медленно грузиться, т.е. после нажатия на любую из страниц задержка до начала загрузки 3-5 секунд, но это когда под логином, у не авторизованного всё летает как и полагается.

БД оптимизировал, все кэши перестраивал...

Уже не знаю что делать.

Посоветуйте что это может быть и что копать.

Недавно обновился с 1,2 до 1,4,4 но форум хорошо работал после обновления, видимых изменений больше не помню. Ничего не трогал, как-то само по себе.

 

Ощущение что настроили систему "нежелательных пользователей" и сами на себя ее применили. Проверьте в разделе настроек админки соответствующий раздел.

 

это точно нет.

Сейчас немного стал копать и решил поставить все скрипты чистые, а БД перетащить. Заработало, а потом временнами всё же появляются такие глюки.

Снёс и поставил уже полностью чистую версию (скрипты + БД)
1. не показывает кол-во новых сообщений
2. глюк иногда сохраняется при нажатии на категорию, либо на новые сообщения

Хостинги 3шт менял, сейчас вообще VPS

Вот у меня возник вопрос, а не глючная ли вообще версия 1.4.4? (у меня nulled)

 

Basoleg, у меня не нулл, но я не думаю что проблема как-то может быть с этим вообще связана. Скорее всего проблема именно в хостинге, а если быть точнее в работе кеша и тем что сервер по каким-то причинам с ней не справляется. Попробуйте настроить кеширование через memcache, для начала: https://xenforo.com/help/cache/ - снизу пример настройки в файле config.php + сам модуль должен быть на сервере установлен.

 

Снес сейчас все модули, вроде заработал (вроде, т.к. изредка проскакивает всё же). Буду по новой их ставить.

Спасибо за совет. Попробую его

 

Фуух нашел от чего беда.

Сначала нашел, а потом еще поставил http://www.xf-russia.ru/forum/threads/vkljuchaem-vyvod-otladochnoj-informacii-debug-mode.304/ и убедился

Короче модуль Unread Post Count почему-то создает такую нагрузку
Вот инфа:

один из запросов:
SELECT COUNT(*)
FROM xf_post AS post
Params: 1, 1, 1420473394
Run Time: 2.491606

Вот и задержка в общем в 3-5 секунд.

Сообщений на форуме у меня 150k

Работал работал, а тут перехотел((( Это видимо после обновления с 1.2 до 1.4.4

 

Плагин Unread Post Count вроде не использует такой запрос. Вы уверены, что именно данный плагин генерирует этот запрос?
Ради интереса проверил, сколько же потянет такой запрос по времени. У меня выполняется в первый вызов где-то за 0.65 секунды, а во второй и последующий разы - за 0.15 секунды.

Порядка 170 тысяч сообщений, если что.

 

Да у меня вообще что-то беда.
Запрос от него был. Но все равно проблемы проскакивают иногда.

Уже и не знаю что думать.

debug mode больше не видит долгих запросов, но проблема редко, но проскакивает, да так что и страница с инфой от
debug mode не грузится.

Вот думаю что-то с БД таблицей xf_post
--- добавлено : 5 фев 2015 в 14:06 ---
Причем проблема такая противная.
Обновился и все норм было. Но эта зараза всплывает, когда онлайн хотя бы больше 5, а лучше 10 человек и вот тогда начинаются "чудеса"
--- добавлено : 5 фев 2015 в 14:07 ---
Нагрузки на ВПС нету, ощущение что когда именно одновременно пару запросов в БД идет

 

А Вы статистику с сервера БД посмотрите. Там узкие места будут отображены. Также есть скрипт тюнинга сервера MySQL. Должен быть в дистрибутиве ОС. Во всяком случае в Debian он точно есть. Называется mysqltuner. Он сам снимает статистику, а затем выводит предложения по настройке. Естественно, скрипт работает в консоли сервера.

 

Basoleg, ощущение что нет индекса у таблицы. Запустите скрипт установки для проверки целостности базы - /install/ который. Просто ненормально большое время выполнения для такого запроса.

 

Для запроса SELECT COUNT(*) индекс не используется в принципе. Поэтому для данного конкретного случая отсутствие каких-то индексов не даст снижения производительности. А вот буферизация и кеши, используемые самим сервером MySQL могут дать такой эффект. Также и отсутствие необходимого объема оперативной памяти может существенно снизить производительность сервера базы данных.
Если у него вообще выпадает генерация страниц при каком-то онлайне, то это обычно означает, что сервер перегружен запросами, либо присутствуют очень медленные запросы. Соответственно, несколько запросов, которые выполняются значительное количество времени, запросто приводят к отказу в обслуживании. Поэтому для начала и надо проверить статистику сервера базы данных.

 

install запустил, не помогло.

я просто только переехал на ВПС и не особо в них понимаю.

Смотреть в phpmyadmin?

Вот скрин, если это оно


--- добавлено : 5 фев 2015 в 15:14 ---
По нагрузке смотрю проц. сильно умирает.

Оперативки у меня 2гб, думаю с запасом хватает и нагрузки нету.

Тут дело именно в БД и запросе каком-то. Отключение модулей не помогает.
--- добавлено : 5 фев 2015 в 15:27 ---
Еще сделал "проверить таблицу"
SQL запрос: CHECK TABLE `xf_post`, `xf_session`, `xf_session_activity`, `xf_session_admin`;
Строки: 4
бд.xf_post check status OK
бд.xf_session check status OK
бд.xf_session_activity check note The storage engine for the table doesn't support c...
бд.xf_session_admin check status OK

Индексы unread_post_count_post_date и post_date равнозначны и один из них может быть удалён.

Вот это нормально или в этом причина бед?

 

Я не использую phpMyAdmin. Но в интернетах пишут следующее: "Заходим в phpmyadmin под любым пользователем во вкладку «Состояние». Далее в «Советчик»".

Индексы не трогайте. Не в них проблема.

 

Советчик там далее нету,только то что на предыдущем скрине, а скрин из состояния и есть. Есть еще такое


+ с учетом то что пишется после проверить таблицу ощущение что реально что-то с таблицей сообщений

 

Просто это самая большая по количеству записей таблица. Вот у меня таблица:

Код:

CREATE TABLE xf_post (
  post_id int(10) UNSIGNED NOT NULL AUTO_INCREMENT,
  thread_id int(10) UNSIGNED NOT NULL,
  user_id int(10) UNSIGNED NOT NULL,
  username varchar(50) NOT NULL,
  post_date int(10) UNSIGNED NOT NULL,
  message mediumtext NOT NULL,
  ip_id int(10) UNSIGNED NOT NULL DEFAULT 0,
  message_state enum ('visible', 'moderated', 'deleted') NOT NULL DEFAULT 'visible',
  attach_count smallint(5) UNSIGNED NOT NULL DEFAULT 0,
  `position` int(10) UNSIGNED NOT NULL,
  likes int(10) UNSIGNED NOT NULL DEFAULT 0,
  like_users blob NOT NULL,
  warning_id int(10) UNSIGNED NOT NULL DEFAULT 0,
  warning_message varchar(255) NOT NULL DEFAULT '',
  last_edit_date int(10) UNSIGNED NOT NULL DEFAULT 0,
  last_edit_user_id int(10) UNSIGNED NOT NULL DEFAULT 0,
  edit_count int(10) UNSIGNED NOT NULL DEFAULT 0,
  PRIMARY KEY (post_id),
  INDEX post_date (post_date),
  INDEX thread_id_position (thread_id, `position`),
  INDEX thread_id_post_date (thread_id, post_date),
  INDEX unread_post_count_post_date (post_date),
  INDEX user_id (user_id)
)
ENGINE = INNODB
AUTO_INCREMENT = 408467
AVG_ROW_LENGTH = 908
CHARACTER SET utf8
COLLATE utf8_general_ci;

Если у Вас не хватает каких-то индексов, то можете их добавить сами. Удалять индексы не надо.

 

У меня все также, только внизу предупреждение


--- добавлено : 5 фев 2015 в 16:34 ---
Не из-за этого проблемы?
--- добавлено : 5 фев 2015 в 16:52 ---
Может удалить индекс unread_post_count_post_date он потом заново создастся? (а то я в этом не так много понимаю)

Не в нем ли проблема?
--- добавлено : 5 фев 2015 в 17:33 ---

и это значение только увеличивается и увеличивается

 

Нет, не в нем. Хотя действительно можно удалить.

Оно и будет увеличиваться. У меня за 11,5 дней "набежало":

Код:

Handler_read_rnd   9314817   Количество запросов для чтения записи, базирующейся на фиксированной позиции.
Handler_read_rnd_next   84139899   Количество запросов для чтения следующей записи в файле данных.

При этом загрузка главной страницы около 0.4 секунды, новых сообщений - меньше 0.2 секунды, просмотр темы - менее 0.15 секунды, список пользователей - 0.07 секунды. Меня эти цифры вполне устраивают, так как они почти не меняются и при высоком онлайне.

 

фууух как минимум с этим разобрался. Завтра при посещалке и нагрузке проверю уже точно.

Короче фишка в чем.
В настройках Срок хранения (в днях) в базе данных отметок о прочтении пользователями тем
Стояло 30 дней, поставил 1 день, смотрю запрос с 2,5 секунд до 0,002 примерно)))
Короче нашел критическую точку (ну она наверно разная, но при моем кол-во сообщений) короче 12 дней примерно 0,12 секунд, а 13 дней резко 2,5 секунды...

Поставил сейчас 10 дней. Проверю при нагрузке действительно ли 1 эта настройка так косячила всё

 

Все равно так не должно работать. У меня (да и у большинства) установлено 30 дней. При этом таких тормозов, как у Вас, не наблюдается.

 

Я хз... но это реально так. К вечеру еще скажу при нагрузке помогло ли точно