См. прикрепленную картинку Fusion Reactor, показывающую страницы, которые просто продолжают работать. Время достигло миллионов, и я оставил их, чтобы посмотреть, завершатся ли они, но это было, когда их было всего 2 или 3.
Теперь я получаю десятки страниц, которые просто никогда не заканчиваются. И это разные запросы, я не вижу никакой большой закономерности, за исключением того, что это, кажется, применимо только к 3 из 7 моих баз данных.
topпоказываетхолодный синтезЗагрузка ЦП составляет около 70–120%, а более детальное изучение страниц сведений о Fusion Reactor показывает, что все время, необходимое для его создания, тратится исключительно на запросы Mysql.
show processlistне возвращает ничего необычного, за исключением 10-20 соединений вспатьсостояние.
За это время многие страницы завершаются, но поскольку число зависших страниц растет и они, похоже, никогда не завершаются, сервер в конечном итоге просто возвращает белые страницы.
Единственным краткосрочным решением, по-видимому, является перезапуск Coldfusion, что далеко от идеала.
Недавно был добавлен скрипт Node.js, который запускается каждые 5 минут и проверяет наличие пакетных CSV-файлов для обработки. Я задался вопросом, не вызывает ли это проблему с кражей всех соединений MySQL, поэтому я отключил его (в скрипте нет метода connection.end()), но это всего лишь предположение.
Не знаю, с чего начать. Может кто-нибудь помочь?
Хуже всего то, что страницы НИКОГДА не закрываются по истечении времени ожидания. Если бы это было так, все было бы не так плохо. Но через некоторое время ничего не отправляется.
Я использую стек CentOS LAMP с Coldfusion и NodeJS в качестве основных языков программирования.
ОБНОВЛЕНИЕ ПЕРЕД ФАКТИЧЕСКИМИ ОПУБЛИКОВАНИЯМИ
За время написания этого поста, который я начал после отключения скрипта Node и перезапуска Coldfusion, проблема, похоже, исчезла.
Но мне все равно нужна помощь в определении точной причины, по которой страницы не будут загружены по тайм-ауту, и в подтверждении того, что скрипту Node нужно что-то вродеconnection.end()
Кроме того, это может происходить только под нагрузкой, поэтому я не уверен на 100%, что это исчезло.
ОБНОВЛЯТЬ
Все еще есть проблемы, я только что скопировал один из запросов, который в настоящее время занимает до 70 секунд в Fusion Reactor, и запустил его вручную в базе данных, и он завершился за несколько миллисекунд. Сами запросы, похоже, не являются проблемой.
ЕЩЕ ОДНО ОБНОВЛЕНИЕ
Трассировка стека одной из страниц все еще продолжается. Сервер не прекращал обслуживание страниц в течение некоторого времени, все скрипты Node в настоящее время отключены
БОЛЬШЕ ОБНОВЛЕНИЙ
Сегодня у меня было еще несколько таких процессов — они действительно закончились, и я заметил эту ошибку в FusionReactor:
Error Executing Database Query. The last packet successfully received from the server was 7,200,045 milliseconds ago. The last packet sent successfully to the server was 7,200,041 milliseconds ago. is longer than the server configured value of 'wait_timeout'. You should consider either expiring and/or testing connection validity before use in your application, increasing the server configured values for client timeouts, or using the Connector/J connection property 'autoReconnect=true' to avoid this problem.
ЕЩЕ БОЛЬШЕ ОБНОВЛЕНИЙ
Покопавшись в коде, я попытался найти «2 ч», «120» и «7200», поскольку мне показалось, что тайм-аут в 7200000 мс — это слишком большое совпадение.
Я нашел этот код:
// 3 occurrences of this
createObject( "java", "coldfusion.tagext.lang.SettingTag" ).setRequestTimeout( javaCast( "double", 7200 ) );
// 1 occurrence of this
<cfsetting requestTimeOut="7200">
Четыре страницы, ссылающиеся на эти строки кода, запускаются очень редко, никогда не отображались в журналах с тайм-аутами более 2 часов и находятся в защищенной паролем области, поэтому их нельзя скопировать (они предназначались для загрузки файлов и обработки CSV, а теперь перемещены в nodejs).
Возможно ли, что эти настройки каким-то образом задаются одной страницей, но существуют на сервере и влияют на другие запросы?
решение1
1) опубликовать трассировку стека.
Я гарантирую, что они будут зависать на Socket.read() (или подобном)
Происходит то, что половина TCP-подключения к базе данных закрывается, и cf остается в ожидании ответа, который он никогда не получит.
Возникли проблемы с сетью между cf box и базой данных.
Драйверы баз данных Java в целом плохо справляются с этой задачей.
Спасибо за трассировку стека
Это подтверждает мое предположение, что закрытие соединения TCP происходит наполовину.
Я подозреваю, что произошло одно из следующего: 1) mysql работает на Linux, и в стеке TCP есть ошибка, поэтому вам нужно обновить Linux на этом компьютере — да, я уже видел это раньше; 2) coldfusion работает на Linux... согласно 1); 3) на одном из компьютеров или между ними неисправен кабель/оборудование; 4) если вы используете Windows, ОТКЛЮЧИТЕ TCP OFFLOAD!!!
Номер 3) — сложный. Вам нужно будет запустить Wireshark на обоих ящиках и доказать потерю пакетов. Более простым решением было бы переместить виртуальные машины Rackspace на другие физические хосты и посмотреть, исчезнет ли проблема. (Есть редкая вероятность, что ваш код очень-очень плох, и вы перегружаете сеть между ящиком CF и ящиком MySQL, но я не уверен, что возможно написать настолько плохой код)
решение2
Я потратил некоторое время на изучение этого вопроса и могу добавить некоторые подробности о конкретной причине сетевых проблем и способе их решения, найденном с помощью Чарли Арехарта.
Во-первых, сетевое соединение прерывалось из-за автоматического запуска скрипта iptables restart. Это обновляло список IP-адресов, которые могли получить доступ к серверу, но также разрывало любые соединения между приложением и сервером БД.
Чаще всего это происходило на медленных страницах или на тех, которые запускались чаще, но все, что совпадало с iptables restartкодом, обрезалось.
Rackspace нашел это для меня и предложил изменить код с:
/sbin/service iptables restart
к
/sbin/iptables-restore < /etc/sysconfig/iptables
Это останавливает перезапуск службы и применяется только к новым подключениям.
Это было основной причиной проблемы, но настоящая проблема заключалась в том, что Coldfusion или, по сути, JDBC, лежащий в его основе, не прекращал ждать ответа от сервера БД.
Я не уверен, откуда взялся двухчасовой тайм-аут (предполагаю, что это значение по умолчанию), но Чарли показал способ установить меньшее время ожидания в строке подключения CFIDE — это сообщает CF о необходимости выждать максимальное время, прежде чем отказаться от базы данных.
Итак, наша строка подключения:
__fusionreactor_name=datasourcename;connectTimeout=600000;socketTimeout=600000;
Я не помню подробностей этих двух, но они устанавливают время ожидания в миллисекундах, а затем прекращают соединение с базой данных:
- connectTimeout=600000;
- socketTimeout=600000;
Это просто маркировка источника данных в Fusion Reactor - если у вас он есть, он очень полезен для поиска проблем в ваших приложениях CF. Если у вас нет Fusion Reactor, то пропустите этот кусок.
- __fusionreactor_name=dsnapi;
Вам придется применить это к КАЖДОМУ источнику данных в вашем CFIDE.
