Пытаюсь оптимизировать БД, через
https://site.ru/bitrix/admin/repair_db.php?optimize_tables=Y
&lang=ru
В процессе оптимизации таблицы
b_iblock_11_index
(325.98 МБ) получаю 504 ошибку.
В инфоблоке около 150к товаров.
Самая большая таблица:
b_iblock_element_iprop
(437.97 МБ)
В /etc/php.d/z_bx_custom.ini выставил:
memory_limit = 2048M
request_terminate_timeout = 2400
max_execution_time = 2400
в phpinfo действительно max_execution_time 2400
Думаю, что больше не нужно..
Пробовал вставлять в скрипт perfmon_tables.php
set_time_limit(2400);
echo ini_get(‘max_execution_time’);
504 получаю через 15-20 минут после начала выполнения скрипта.
Что ещё можно изменить, чтобы сервер дождался завершения работы скрипта?
Хотелось бы провести оптимизацию БД через админку сайта, чтобы не ругалась «проверка сайта».
БУС
18.0.9
.
BVA 7.3.0
Centos 6.9
Стандартная проблема для баз данных с большими таблицами — срабатывание внутреннего там-аута, при котором система с запущенным скриптом теряет связь с бд (MySQL), битрикс так и остается в ступоре (оживет после перезагрузки сервера), а в админке появляется сообщение об ошибке 504 Gateway Timeout. Возникать ошибка может на любом этапе на первой попавшейся большой таблице.
Решение 504 ошибки при оптимизации БД
Речь идёт о внутреннем инструменте оптимизации, доступным по сссылке вида: https://domain.com/bitrix/admin/repair_db.php?optimize_tables=Y&lang=.
Решение заключается в увеличении таймаутов на стороне Nginx.
Вносим правки в /etc/nginx/nginx.conf:
proxy_connect_timeout 2400;
proxy_send_timeout 2400;
proxy_read_timeout 2400;
По умолчанию все три значения равны 300 и этого явно недостаточно; значения 2400 должно хватить на большие таблицы, только запаситесь терпением, проверка больших таблиц — долгий процесс и со стороны будет казаться, что система зависла, на время проверки админка и сайт могут не будут отвечать, поэтому проводить оптимизацию нужно глубокой ночью.
При необходимости можно создать конфиг (если его нет) /etc/nginx/bx/settings/z_bx_custom.conf и вписать туда:
fastcgi_read_timeout 2400
После оптимизации увидите долгожданное сообщение:
А битрикс будет считать базу оптимизированной.
Пытаюсь оптимизировать БД, через
https://site.ru/bitrix/admin/repair_db.php?optimize_tables=Y
&lang=ru
В процессе оптимизации таблицы
b_iblock_11_index
(325.98 МБ) получаю 504 ошибку.
В инфоблоке около 150к товаров.
Самая большая таблица:
b_iblock_element_iprop
(437.97 МБ)
В /etc/php.d/z_bx_custom.ini выставил:
memory_limit = 2048M
request_terminate_timeout = 2400
max_execution_time = 2400
в phpinfo действительно max_execution_time 2400
Думаю, что больше не нужно..
Пробовал вставлять в скрипт perfmon_tables.php
set_time_limit(2400);
echo ini_get(‘max_execution_time’);
504 получаю через 15-20 минут после начала выполнения скрипта.
Что ещё можно изменить, чтобы сервер дождался завершения работы скрипта?
Хотелось бы провести оптимизацию БД через админку сайта, чтобы не ругалась «проверка сайта».
БУС
18.0.9
.
BVA 7.3.0
Centos 6.9
Стандартная проблема для баз данных с большими таблицами — срабатывание внутреннего там-аута, при котором система с запущенным скриптом теряет связь с бд (MySQL), битрикс так и остается в ступоре (оживет после перезагрузки сервера), а в админке появляется сообщение об ошибке 504 Gateway Timeout. Возникать ошибка может на любом этапе на первой попавшейся большой таблице.
Речь идёт о внутреннем инструменте оптимизации, доступным по сссылке вида: https://domain.com/bitrix/admin/repair_db.php?optimize_tables=Y&lang=.
Решение заключается в увеличении таймаутов на стороне Nginx.
Вносим правки в /etc/nginx/nginx.conf:
proxy_connect_timeout 2400;
proxy_send_timeout 2400;
proxy_read_timeout 2400;
По умолчанию все три значения равны 300 и этого явно недостаточно; значения 2400 должно хватить на большие таблицы, только запаситесь терпением, проверка больших таблиц — долгий процесс и со стороны будет казаться, что система зависла, на время проверки админка и сайт могут не будут отвечать, поэтому проводить оптимизацию нужно глубокой ночью.
При необходимости можно создать конфиг (если его нет) /etc/nginx/bx/settings/z_bx_custom.conf и вписать туда:
fastcgi_read_timeout 2400
После оптимизации увидите долгожданное сообщение:
А битрикс будет считать базу оптимизированной.
Иногда возникает проблема — при попытке выполнить обновление системы(особенно для старых версий) страница обновления падает с 504 ошибкой. Причиной тому является высокое время обработки запроса(типа слишком много обновлений и всё такое). Эта проблема может решаться одним из двух путей:
— Попробуйте добавить в файл /bitrix/php_interface/after_connect.php следующую строчку:
$DB->Query(«SET wait_timeout=28800»);
и в /bitrix/php_interface/after_connect_d7.php:
$connection->queryExecute(«SET wait_timeout=28800»);
— Если предыдущий способ не смог разрешить проблему, то можно попробовать сделать иначе. В файле /bitrix/modules/main/classes/general/update_class.php есть функция __parse(строка примерно 4158). Её задача получать и парсить результат. Находим место, где парсится строка, и вставляем перед циклом регулярку, которая вырезает все description-ы: http://joxi.ru/DmB73v1sJJV9Z2. В данном случае используется конструкция:
$strXMLText = &preg_replace(«#(<description>(.*?)</description>)#is», «», $strXMLText);
Обычно это помогает. Если найдете другие эффективные способы решить данную проблему — пишите сюда
504 gateway time-out nginx/1.4.2 битрикс
Данная ошибка частенько вылетает при открытии страницы сайта. При просмотре логов сайта можем обнаружить следующую ошибку upstream timed out (110: Connection timed out) while reading response header from upstream В данном случае сервер nginx отправил запрос на apache и не дождался ответа. По умолчанию время ожидания ответа состовляет 60с. Бывает что сайт очень тяжелый, много скриптов и если ты уверен в работоспособности всех модулей и компонентов, можно добавить времени ожидания, прописав в конфиге nginx в секции location следующие строки
proxy_connect_timeout 300; proxy_send_timeout 300; proxy_read_timeout 300;
- На Centos конфиг хранится по следующему пути etcnginxnginx.conf
- Логи сайта храниятся в папке varwwwwww-rootdatalogs
В моем случае это не помогло. Ошибка 504 gateway time out в битрикс вылетала из-за загруженности процесса httpd на 85%.
Переведя сайт на CGI PHP 5.4.45 полетели ошибки в логах Timeout waiting for output from CGI script /var/www/php-bin-isp-php56/www-root/php и Script timed out before returning headers: php При помощи команды top я увидел загруженность процесса php на 75%. Значит все дело в исполнении php скрипта. Похоже, что есть какая-то ошибка в РНР-скриптах сайта, потому как подключений совсем немного, а нагрузка от обработки ощутимая:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 31386 www-root 20 0 619956 184084 14328 S 75.0 18.1 1:19.59 php
Как узнать, какой запрос в настоящий момент выполняет php-cgi процесс
Покопавшись в интернете, я собрал очень полезные утилиты для работы с процессами на стороне сервера. Установку делал с помощью yum install strace Благодаря команде lsof, описание дал ниже, увидел последний файл, который был открыт процессом php. Это xml-файл yandex_torg04042015.php создавался агентом CCatalog::PreGenerateXML битрикс для системы Яндекс.Товары Происходил экспорт товаров в файл из инфоблока каталога товаров в количестве 15944шт Соответственно убрав выполнение агента, сайт быстренько открылся. Т.к. ошибка возникала на тестовом сервере, убрал выполнение всех агентов прописав в dbconn.php
define("NO_AGENT_CHECK", true); define("NO_AGENT_STATISTIC", true);
- top Выводит список процессов и информации о них в режиме реалтайм
- mod_status Позволяет контролировать в реальном времени производительность сервера
- strace -p PID Показывает системные вызовы, которые происходят в данный момент в процессе
- ps ax| grep PID Выдача информации о состоянии процессов
- lsof -p PID Показывает список файлов, открытых процессом
- kill -SIGKILL PID Убивает процесс
Есть скрипт для soap запроса на обновление товаров. Товаров много, 1000+. И функция не успевает выполнить код. Страница грузится 5 мин и выдает ошибку «504 Gateway Timeout. Bitrix Environment»
Как можно увеличить время ожидания ?
-
Вопрос заданболее года назад
-
953 просмотра
Пригласить эксперта
Сделать пакетную обработку
504 это отваливается nginx по таймауту
сам скрипт при этом все еще работает.
увеличь лимиты конекта в nginx
и увеличь лимиты времени в апаче
желательно только для этого файла.
-
Показать ещё
Загружается…
28 мар. 2023, в 09:29
3000 руб./в час
12 апр. 2023, в 15:28
500 руб./за проект
12 апр. 2023, в 15:25
8000 руб./за проект
Минуточку внимания
Решение, как исправить ошибку «504 gateway timeout» при обращении к базе данных на BitrixVM
Одной из типичных проблем, с которыми сталкиваются базы данных с большими таблицами, является возникновение внутреннего таймаута, когда система теряет связь с базой данных MySQL. Это может привести к застою в работе сайта на платформе «Битрикс», который вернется в рабочее состояние только после перезагрузки сервера. В результате, административная панель сайта может выдавать ошибку 504 Gateway Timeout. Подобная проблема может возникнуть на любом этапе работы с любой большой таблицей в базе данных.
Проблема связана с тем, что при обработке больших объемов данных или сложных запросов к базе данных может потребоваться больше времени, чем установлено внутренними таймаутами системы. В результате соединение с базой данных может быть прервано, и это приведет к возникновению ошибок и неполадок на сайте.
Решение заключается в увеличении таймаутов на стороне Nginx. Увеличиваем значения с 300 до 2400.
Вносим правки в /etc/nginx/nginx.conf и перезагружаем nginx
proxy_connect_timeout 2400; proxy_send_timeout 2400; proxy_read_timeout 2400;
Есть скрипт для soap запроса на обновление товаров. Товаров много, 1000+. И функция не успевает выполнить код. Страница грузится 5 мин и выдает ошибку «504 Gateway Timeout. Bitrix Environment»
Как можно увеличить время ожидания ?
-
Вопрос задан
-
1380 просмотров
Пригласить эксперта
Сделать пакетную обработку
504 это отваливается nginx по таймауту
сам скрипт при этом все еще работает.
увеличь лимиты конекта в nginx
и увеличь лимиты времени в апаче
желательно только для этого файла.
-
Показать ещё
Загружается…
23 сент. 2023, в 01:31
6000 руб./за проект
23 сент. 2023, в 01:13
3000 руб./за проект
22 сент. 2023, в 23:30
6500 руб./за проект