У меня иногда зависает веб-приложение на php. Когда я перехожу на страницу, она просто будет сидеть там, пытаясь загрузить в течение нескольких часов, даже если максимальное выполнение составляет 210. Это приложение использует curl за прокси-сервером для загрузки материалов. Отчет об ошибках установлен для всех, но это не имеет значения, поскольку страница пуста и зависла.
Не могу найти ничего по отладке зависшего PHP-процесса.






Последний раз я проверял, операции HTTP / IO происходят вне времени php, поэтому возможно, что CURL умирает или истекает время ожидания.
Его ввод-вывод, поэтому php просто выбрасывается в какую-то системную библиотеку, а затем вызывает "select", чтобы дождаться его возврата.
Если он не вернется ... PHP-код даже не будет зацикливаться и, следовательно, даже не узнает, что он не вернется.
Я бы поставил деньги на то, что это проблема завитков. Несколько лет назад у меня была аналогичная проблема с добавленной мной опцией curl, из-за которой скрипт иногда зависал. Хотел бы я точно вспомнить, в чем была проблема, но я считаю, что в конечном итоге curl ссылался на неправильную библиотеку внизу. (редактировать) на самом деле, я почти уверен, что в моем случае это была библиотека SSL, в которой curl использовал старую версию openssl.
Я бы предложил сначала удалить все вызовы curl_setopt(), а затем добавить их обратно, чтобы посмотреть, сможете ли вы изолировать ошибку. i считать, если вы запустите эквивалентную команду curl в командной строке, вы можете сразу увидеть там ошибку.
Я исправил это, обновив библиотеку openssl, которую использовал curl.
чтобы увидеть, что происходит за кулисами, вы можете установить xdebug, а затем включить триггерное профилирование (? XDEBUG_PROFILE = 1) ... он выведет журнал в файловую систему, совместимую с kcachegrind / etc ...., который вы можете использовать, чтобы увидеть где висит казнь.
конечно, это, скорее всего, проблема завитков ....
Xdebug - отличная идея, и если это не поможет, я также рекомендую запустить ваш веб-сервер через ktrace, strace или truss. Он показывает вам, что именно он делает и где может висеть.
Похоже, возникла временная проблема с подключением или что-то еще, на что полагается ваше приложение, заблокировано.
Если вы используете Apache, проверьте файл Руководство по отладке HTTP Apache. Руководство немного ориентировано на * nix, но может быть применено к любому веб-серверу.
Помимо отладки вашего веб-сервера, я также рекомендовал бы добавить проверки, всегда ли ваш прокси-сервер работает / реагирует, а источник загрузки всегда доступен. Эти проверки могут быть добавлены с помощью такого инструмента, как нагиос, или стороннего сервиса, такого как Pingdom. И последнее, но не менее важное: это также может быть временная проблема с DNS, поэтому вы можете использовать IP-адреса для подключения к прокси-серверу и источнику загрузки и / или добавить мониторинг для службы DNS.
HTH
Это будет звучать неубедительно, но просто откройте дескриптор файла в самом начале запроса страницы, а затем начните писать в /tmp/debug.txt. Посмотрите, куда записывается последний из них, а затем начните выводить различные значения переменных в файл в этой области. Используйте теорию двоичного поиска, чтобы распределить свои тексты на все более тонкие участки разрешения вашего кода.
i.e.
$fh = fopen("/tmp/debug.txt", "w");
fwrite($fh, "made it to here 1 \n");
//some code
fwrite($fh, "made it to here 2 \n");
//more code
fwrite($fh, "made it to here 3 \n");