IP.Downloads. Зависание при попытке обновить файл

[magnumspec]

Добрый день.

IPB 3.4.8

Такая проблема, при попытке сохранить изменение или загрузить новую версию файла в IPDownloads, идет бесконечная загрузка, и срабатывает лимит хостера с ошибкой 502. Если лимит убрать,  остается бесконечная загрузка.

При этом проблема возникает не на всех файлах. Какую-то закономерность среди них выявить не удалось. Проблемы с файлами разных пользователей, в разных категориях, с разным заполнением полей. С и без предыдущих версий. Никакой связи.

Вроде как напрашивается вывод об ошибках в БД, но раздел диагностики базы и индексов не показывает проблем.
Имеется странная ситуация с разделом 'Проверка соединений'. Страница долго грузится, а потом показывает:

HTTP/1.1 404 Not Found
Content-Type: text/html;charset=UTF-8
Content-Length: 46334
Connection: keep-alive
Vary: Accept-Encoding
Date: Fri, 20 Apr 2018 10:19:04 GMT
Server: Apache/2.4.27 (Amazon) OpenSSL/1.0.2k-fips PHP/7.0.29
X-Powered-By: PHP/7.0.29
Set-Cookie: ips4_IPSSessionFront=tja49vmaur3l6tu7d6cm9gd1jo; path=/; secure; HttpOnly
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
X-Cache: Error from cloudfront
Via: 1.1 8602503af95a7bac32a020063ca51410.cloudfront.net (CloudFront)
X-Amz-Cf-Id: hw0bxMe1Efncf2k8kNL1xsk15RpXd3qExRSr77zHmmGu7lDESCy63g==

Не понятно, что именно не может найти, почему указан IPS4, хотя у меня IPB 3.4, и что с этим делать.

Хостер утверждает, что идет долгий запрос к БД, но какой именно, они не логируют.

 

Пробовал разные функции перестроения кэша и самих материалов, очистка потерянных файлов IP.Downloads и т.д., безрезультатно. 

 

Помогите пожалуйста. Если проблема в базе данных, как ее исправить? Средствами оптимизации в PHPMyAdmin, или чем-то еще.

[Zero108]

Отключаются все сторонние аддоны и плагины (модули) (деактивируются), включается дефолтная тема, отключаются все сторонние сервисы (поделиться ссылкой/контентом, код отслеживания для статистики и пр.). Проверяется. Проще всего проверить на тестовой версии, только что установленной, без изменений в коде. Для отслеживания именно медленных запросов используйте: https://habrahabr.ru/post/31072/

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

/usr/bin/mysqlcheck -A -u root --password=AAAfffeee444333 --repair --analyze --optimize --all-databases --auto-repair >/dev/null 2>&1

[Zero108]

Если проблему обнаружить и исправить не удается, возможно, проблема кроется в нехватке ресурсов vds/sharing хостинга, которая возникает периодически и, возможно, не от работы ваших сайтов, а по причине неравномерного распределения ресурсов и перегружке физического сервера сайтами и другими программами других пользователей. В таком случае проще переехать на выделенный (dedicated) сервер или на свой, на своем железе.

[magnumspec]

1. попробовал поотключать хуки и прочее, включить стандартную тему - без толку.

2. развернул чистый сайт, накатил таблицы с сайтовой базы, поставил только IP.Downloads, поотключал все остальное. Попробовал воспроизвести на том же файле - та же ошибка.

3. Сделал проверку/анализ/оптимизацию/восстановление таблиц, без толку.

4. Что до ресурсов хостинга, думаю, это маловероятно, т.к. не работает обновление ряда файлов, эти файлы каждый раз одни и те же.

5. Включил по той подсказке логирование,  но не понимаю, на чем возникает затык. Похоже, замешана таблица cache_store, но я не уверен.

Подскажите пожалуйста, прикладываю файл логов вложением.  Там не должно быть ничего лишнего, т.к. он с теста.

sql_debug_log_04_21_18.txt

Также заметил упоминания таблицы пользователей. Вспомнил, что не так давно массово чистил прошлогодних неактивированных пользователей. Это может быть связано? И если да, то можно ли как-то исправить ситуацию?

 

 

sql_debug_log_04_21_18.txt

[magnumspec]

Проблема совершенно внезапно решилась. Вернее, был найден источник.

Это сервис https://mega.nz/
Зависание происходит, видимо, когда IPB пытается считать размер файла по внешней ссылке на мегу.

Учитывая, что технически на сайте ничего связанного не менялось, а хостер утверждает, что ограничений не имеет, скорее всего на стороне Меги что-то обновили.

Спасибо за помощь! 

Остается выяснить, как можно заставить IP.Downloads не считать размер файла на внешнем источнике (если дело именно в этом).