Страницы, зависающие при ожидании запроса, используя память и, занимают 2 часа для сбоя
См. присоединенное изображение Реактора Fusion, показав страницы, которые просто продолжают работать. Времена повысились в миллионы, и я оставил их, чтобы видеть, завершились ли они, но это было, когда было всего 2 или 3.
Теперь я получаю десятки страниц, которые это просто никогда не заканчивает. И это - различные запросы, я не вижу, что любой огромный шаблон кроме него только, кажется, относится к 3 из моих 7 баз данных.
top шоу coldfusion использование ЦП, приблизительно 70-120%, и рытье глубже в Реактор Fusion детализируют шоу страниц все время, растущие, проведены только на запросах Mysql.
show processlist возвраты ничто необычное, execpt 10 - 20 соединений в состоянии сна.
В это время много страниц действительно завершаются, но как число страниц, зависающих, сборки и они никогда, кажется, не заканчивают, сервер в конечном счете просто возвращает белые страницы.
Единственное краткосрочное решение, кажется, перезапускает Coldfusion, который далек от идеала.
Сценарий Node.js был недавно добавлен, что выполнения каждые 5 минут и проверки на пакетные файлы CSV для обработки я задался вопросом, вызывало ли это проблему с кражей всех Подключений mysql, таким образом, я отключил это (сценарий не имеет никакого connection.end () метод в нем), но это - просто быстрое предположение.
Никакая идея, где запустить, кто-либо может помочь?
Худшая часть является страницами NEVER, испытывают таймаут, если бы они сделали то это не было бы настолько плохо, но через некоторое время ничто не подается.
Я выполняю стек CentOS LAMP с Coldfusion и NodeJS как мои основные языки сценариев
ОБНОВЛЕНИЕ ПЕРЕД ФАКТИЧЕСКОЙ РЕГИСТРАЦИЕЙ
В течение времени это взяло для записи этого сообщения, которое я запустил после отключения сценария Узла и перезапуска Coldfusion, проблема, кажется, ушла.
Но я все еще хотел бы некоторую справку, определяющую точно, почему страницы woudlnt' испытывают таймаут и подтверждая, что для сценария Узла нужно что-то как connection.end()
Также это могло бы только произойти при загрузке, таким образом, я не на 100% уверен, что это ушло
ОБНОВЛЕНИЕ
Все еще имея проблемы, я только что скопировал один из запросов, который в настоящее время является до 70 секунд в Реакторе Fusion и выполняет его вручную в базе данных, и он завершился в нескольких миллисекундах. Сами запросы, кажется, не проблема.
ДРУГОЕ ОБНОВЛЕНИЕ
Отслеживание стека одной из страниц, все еще идущих. Сервер не прекратил служить страницам в некоторое время, все сценарии Узла, в настоящее время отключаемые
БОЛЬШЕ ОБНОВЛЕНИЙ
У меня было еще несколько из них сегодня - они на самом деле закончили, и я определил эту ошибку в 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", поскольку я чувствовал, что тайм-аут на 7 200 000 мс был слишком большим совпадения.
Я нашел этот код:
// 3 occurrences of this
createObject( "java", "coldfusion.tagext.lang.SettingTag" ).setRequestTimeout( javaCast( "double", 7200 ) );
// 1 occurrence of this
<cfsetting requestTimeOut="7200">
4 страницы, которые ссылаются на те строки кода, выполняются очень редко, никогда не обнаруживались в журналах с 2 ч + время outs и находятся в защищенной паролем области, так не может быть очищен (они были для загрузок файла и обработки CSV, теперь перемещенной в nodejs).
Действительно ли возможно, что эти настройки могли так или иначе быть установлены на одну страницу, но существовать в сервере, и влиять на другие запросы?
Аракет кылыңыз 1) стек изин жайгаштыруу. Мен аларга асылып турганга кепилдик берем
Socket.read ()
(же ушул сыяктуу) Эмне болуп жатат, д.к. менен болгон tcp байланышынын 1/2 бөлүгү жабылып, c.f. жооп күтүп, ал эч качан ала албайт. c.f ортосунда тармактык маселелер бар. кутуча жана db. Java db драйверлери бул маселени чечүүдө начар Стек изи үчүн рахмат Бул менин tcp байланышынын 1/2 жабылышы деген божомолумду тастыктайт. Мен төмөнкүлөрдүн бирине шектенип жатам
1)mysql Linuxто жана TCP стекинде мүчүлүштүк бар, ошондуктан Linuxту ошол кутуга жаңыртышыңыз керек - ооба мен буга чейин көргөн элем
2) муздатуу линуксте жүрөт .. .1)
3) коробкалардын экөөнүн биринде же ортосунда бузулган кабель / аппаратура болсо
4) эгерде сиз иштеп жаткан Windows DISABLE TCP OFFLOAD !!! 3) номери эң кыйын. Эки кутучага тең wireshark иштетип, пакеттин жоголгонун далилдеш керек. Жөнөкөй чечим Rackspace VMни ар кандай физикалык хостторго көчүрүп, анын жок болуп кетишин текшерүү болот. (Сиздин кодуңуз өтө эле сейрек кездешүү ыктымалдыгы бар жана сиз CF кутусу менен MySQL кутучасынын ортосундагы тармакты каныктырдыңыз, бирок мындай жаман кодду жазууга мүмкүн эмес деп ойлойм) Include //vmware-host/sharedDriveOrFolderName/source/myconf.conf [11121] --301389-
Spędziłem trochę więcej czasu, przyglądając się temu i mam więcej szczegółów do dodania na temat konkretnej przyczyny problemów z siecią i obejścia znalezionego z pomocą Charliego Areharta.
Po pierwsze, połączenie sieciowe było przerywane przez automatyczne wyzwalanie skryptu restart iptables . Było to aktualizowanie listy adresów IP, które mogły uzyskać dostęp do serwera, ale także przerywanie wszelkich połączeń między aplikacją a serwerem DB.
To było bardziej prawdopodobne na wolniejszych stronach lub tych, które działały częściej, ale wszystko, co pokrywało się z 1160383] kod restartu iptables zostałby odcięty.
Rackspace znalazł to dla mnie i zasugerował zmianę kodu z:
/ sbin / service iptables restart
na
/ sbin / iptables-restore
To zatrzymuje ponowne uruchamianie usługi i ma zastosowanie tylko do nowych połączeń.
To była główna przyczyna problemu, ale prawdziwym problemem jest fakt, że Coldfusion, a właściwie JDBC pod spodem, nie przestawaj czekać na odpowiedź z serwera DB.
Nie jestem pewien, gdzie nadszedł 2-godzinny limit czasu (zakładając, że jest to domyślne), ale Charlie pokazał sposób na ustawienie niższego limitu czasu w ciągu połączenia CFIDE - to mówi CF, aby poczekał maksymalny czas, zanim zrezygnuje z DB.
Więc nasz co nnection string to:
__ fusionreactor_name = datasourcename; connectTimeout = 600000; socketTimeout = 600000;
Nie pamiętam szczegółów tych dwóch, ale ustawiają czas w milisekundach na czekanie, a następnie rezygnację z połączenia db :
- connectTimeout = 600000;
- socketTimeout = 600000;
To jest po prostu oznaczanie źródła danych w reaktorze Fusion - jeśli je masz, jest to bardzo przydatne do znajdowania problemów w aplikacjach CF. Jeśli nie masz Fusion Reactor, zostaw ten kawałek.
- __ fusionreactor_name = dsnapi;
Będziesz musiał zastosować to do KAŻDEGO źródła danych w swoim CFIDE
