Страницы зависают в ожидании запроса, потребляют память и выходят из строя 2 часа
См. Прикрепленное изображение Fusion Reactor, на котором показаны страницы, которые продолжают работать. Времена пошли на миллионы, и я оставил их, чтобы посмотреть, закончат ли они, но тогда их было всего 2 или 3.
Теперь я получаю десятки страниц, которые никогда не заканчиваются. И это разные запросы, я не вижу большой закономерности, за исключением того, что она, кажется, применима только к 3 из моих 7 баз данных.
top показывает холодный синтез Загрузка ЦП составляет около 70–120%, а более глубокое изучение страниц сведений о Fusion Reactor показывает, что все время, которое создается, тратится исключительно на запросы Mysql.
show processlist не возвращает ничего необычного, кроме 10-20 соединений в спать штат.
В течение этого времени многие страницы все же завершаются, но по мере того, как количество висящих страниц увеличивается, и кажется, что они никогда не заканчиваются, сервер в конечном итоге просто возвращает белые страницы.
Единственным краткосрочным решением кажется перезапуск Coldfusion, что далеко от идеала.
Недавно был добавлен сценарий Node.js, который запускается каждые 5 минут и проверяет наличие пакетных файлов csv для обработки. Я подумал, не вызывает ли это проблема с кражей всех подключений MySQL, поэтому я отключил его (у сценария нет подключения. 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">
4 страницы, которые ссылаются на эти строки кода, запускаются очень редко, никогда не отображались в журналах с тайм-аутом 2 часа + и находятся в защищенной паролем области, поэтому их нельзя очистить (они были для загрузки файлов и обработки CSV, теперь переехал на nodejs).
Возможно ли, что эти настройки каким-то образом могут быть заданы одной страницей, но существуют на сервере и влияют на другие запросы?
1) опубликуйте трассировку стека.
Я гарантирую, что они будут висеть на Socket.read () (или подобном)
Что происходит, так это то, что половина TCP-соединения с базой данных закрывается, оставляя c.f. ожидая ответа, он никогда не получит.
Есть сетевые проблемы между c.f. коробка и db.
Драйверы Java db в целом плохо справляются с этим
Спасибо за трассировку стека
Это подтверждает мое предположение, что это 1/2 закрытия TCP-соединения.
Я подозреваю, что одно из следующих: 1) mysql находится на Linux, и в стеке TCP есть ошибка, поэтому вам нужно обновить Linux на этом компьютере - да, я видел это раньше 2) coldfusion находится на Linux .. как на 1 ) 3) неисправный кабель / оборудование на любом из боксов или между ними 4) если вы работаете в Windows ОТКЛЮЧИТЕ TCP OFFLOAD !!!
номер 3) - сложный. Вам нужно будет запустить wirehark на обоих ящиках и доказать потерю пакетов. Более простым решением было бы переместить виртуальные машины Rackspace на разные физические хосты и посмотреть, исчезнет ли она. (Есть редкая вероятность, что ваш код очень-очень плохой, и вы переполняете сеть между ящиком CF и ящиком MySQL, но я не уверен, что можно написать такой плохой код)
Я потратил немного времени на изучение этого и хочу добавить еще несколько подробностей о конкретной причине сетевых проблем и обходных путей, найденных с некоторой помощью Чарли Арехарта.
Во-первых, подключение к сети прерывалось автоматическим запуском скрипта. iptables restart. Это обновляло список IP-адресов, которые могли получить доступ к серверу, но также разрывали любые соединения между приложением и сервером БД.
Это было более вероятно на медленных страницах или тех, которые запускались чаще, но все, что совпадало с iptables restart код будет отрезан.
Rackspace нашел это для меня и предложил изменить код с:
/sbin/service iptables restart
к
/sbin/iptables-restore < /etc/sysconfig/iptables
Это останавливает перезапуск службы и применяется только к новым соединениям.
Это было основной причиной проблемы, но настоящая проблема заключается в том, что Coldfusion, или на самом деле JDBC под ним, не перестанет ждать ответа от сервера БД.
Я не уверен, откуда пришел 2-часовой тайм-аут (при условии, что это значение по умолчанию), но Чарли показал способ установить меньшее время ожидания в строке подключения CFIDE - это говорит CF подождать максимальное время, прежде чем отказаться от БД.
Итак, наша строка подключения:
__fusionreactor_name=datasourcename;connectTimeout=600000;socketTimeout=600000;
Я не могу вспомнить особенности этих двух, но они устанавливают время в миллисекундах, чтобы ждать, а затем отказываться от соединения с БД:
- connectTimeout = 600000;
- socketTimeout = 600000;
Это просто метка источника данных в Fusion Reactor - если он у вас есть, он очень полезен для поиска проблем в ваших CF-приложениях. Если у вас нет термоядерного реактора, оставьте этот бит.
- __fusionreactor_name = dsnapi;
Вам нужно будет применить это к КАЖДОМУ источнику данных в вашем CFIDE.
