PHP-код Opcode блокирует Apache. Может быть, Symfony2 - Doctrine2 related

Я разработал около 10 различных веб-сайтов, размещенных на одном сервере, с описанием ниже.

История:

Все работало нормально, пока я не решил интегрировать кеш PHP-кода в систему. Я сначала попытался с APC, но та же проблема появилась с Xcache, поэтому я не думаю, что она связана с самой программой кэша.

Система остается стабильной в течение периода, варьируя от дня до недели, и падает в разные часы, но главным образом ночью около 23h-05h. Если я перезапущу службу httpd, система будет стабильной снова, в течение того же периода (от 1 дня до 1 недели), и снова сработает и т.д....

Отчет об ошибках:

Вот отчет моего глобального журнала httpd во время последнего сбоя:

[Thu Feb 18 20:00:11.270997 2016] [core:notice] [pid 24956:tid 139940499228480] AH00052: child pid 4522 exit signal Aborted (6)
httpd: hostip.c:693: Curl_resolv_unlock: Assertion `dns && (dns->inuse>0)' failed.
[Thu Feb 18 20:08:38.793218 2016] [core:notice] [pid 24956:tid 139940499228480] AH00052: child pid 6246 exit signal Aborted (6)
httpd: hostip.c:693: Curl_resolv_unlock: Assertion `dns && (dns->inuse>0)' failed.
[Thu Feb 18 22:12:33.576308 2016] [core:notice] [pid 24956:tid 139940499228480] AH00052: child pid 8362 exit signal Aborted (6)
httpd: hostip.c:693: Curl_resolv_unlock: Assertion `dns && (dns->inuse>0)' failed.
[Thu Feb 18 22:40:07.297428 2016] [core:notice] [pid 24956:tid 139940499228480] AH00052: child pid 10224 exit signal Aborted (6)
[Thu Feb 18 23:00:40.526867 2016] [core:warn] [pid 24956:tid 139940499228480] AH00045: child process 10846 still did not exit, sending a SIGTERM
...

Обратите внимание, что сервер заблокирован около 22: 41: xx. Я перезапустил сервер в 23: 00: xx, который связан с последней строкой, размещенной здесь.

Это может быть связано с завихрением, я использую его много, специально PHP curl_multi, чтобы ускорить мои вызовы API, запустив их одновременно. Но такая же ошибка возникает и без установленного (или отключенного) кэша opcode PHP, но это не приводит к сбою сервера.

Состояние сервера:

При возникновении "сбоя" система все равно может обслуживать любой файл txt, image и т.д., но не может обслуживать какой-либо файл PHP. Сервер заблокирован, и, взглянув на "Состояние сервера Apache", возможно, существует 100 запросов в состоянии "W", увеличиваясь с каждым входящим запросом.

Реализация кэша:

Как было сказано выше, я попытался использовать APC и xCache, но оба они дали ту же проблему. Мой PHP - это скомпилированная версия (которую я не скомпилировал). Существует логово лаков выше всех веб-сайтов, только кеширование нескольких голодных страниц. Я использую Symfony2 с Doctrine2, со ссылкой между Doctrine2 и xcache/apc через конфигурацию Symfony2:

doctrine:
    orm:
        auto_generate_proxy_classes: prod
        auto_mapping: true
        metadata_cache_driver: xcache
        result_cache_driver: xcache
        query_cache_driver: xcache

Кажется, Doctrine2 разрешает кэшировать объект сущности и улучшать производительность (для Doctrine2 недостаточно только кэширования)

Технические характеристики

- Debian 7.8
- Apache 2.4.12
- Mysql 
- PHP 5.4.38 (compiled version)
- Varnish
- Symfony 2.4.x

Любые подсказки или помощь будут очень приветствоваться, так как я искал решение в течение нескольких месяцев, а запуск PHP-Symfony2-сайта намного медленнее без кэша опкодов

Ответы

Ответ 1

У вас есть какие-то конкретные задания cron, которые выполняются во время сбоя сервера?

В любом случае, если вы видите Curl_resolv_unlock: Assertion 'dns && (dns->inuse>0)' failed в журналах, это означает, что у вас есть "отладочная сборка" libcurl, которая активна в PHP, что не очень хорошо.

Ваш комментарий упоминается в PHP, говорит Apache 2.0 Handler, поэтому он работает как модуль Apache.

Когда это отладочное утверждение попадает в libcurl, это приводит к завершению процесса (PHP). По сути, я думаю, что ваш PHP-процесс для Apache (который обрабатывает все запросы PHP) умирает. Вот почему вы все равно можете обслуживать статические ресурсы, но процессы PHP продолжают складываться.

cURL 7.26.0 довольно старый (май 2012 г.). Я бы предложил установить более новую версию libcurl, а затем перекомпилировать PHP с ней и убедиться, что cURL не является сборкой отладки и видит, помогает ли это.

Ответ 2

Мой API-интерфейс "Apache 2.0 Handler"

Вы должны обязательно проверить, происходит ли поведение simillar в PHP-FPM. Apache SAPI означает, что он не отделен от пространства памяти httpd как использование процесса пула FPM.

Я подозреваю, что вы столкнулись с какой-то утечкой памяти, которую трудно проследить. Переход на FPM позволит вам также автоматически перезапускать ответчика через некоторое время (количество запросов), которое намного более изящно и гибко, чем присмотр и проверка работоспособности процесса.

Честно говоря, прошло некоторое время с тех пор, как я увидел PHP, связанный с Apache SAPI.:)

Ответ 3

Я не могу предложить вам точное решение, но я могу предложить вам trick решить вашу проблему с помощью обходного пути и предложить идеи debug

Трюк: вы можете обедать с мониторингом cronjob, который будет каждый 5-10 м запросить через завиток одного из ваших сайтов, и если он получит отрицательный ответ или истечет время ожидания запроса (установите его на какой-то большой число, например 30 секунд или 1 мин), вы перезагрузите сервер httpd +, вы можете очистить свой cache, а затем перезапустите

Отладка:, чтобы отладить вашу проблему, вы можете начать с memory monitoring. Я полагаю, что корень проблемы заключается в том, что во время ошибок ваша системная память течет, из-за чего ваш сервер httpd падает, что означает, что вам нужно отлаживать и обрабатывать ваши ошибки curl с помощью try/catch и т.д....

Ответ 4

Итак, у меня есть этот cron php script, который использует pthreads и curl, и я действительно получил.

php: hostip.c: 693: Curl_resolv_unlock: утверждение `dns && & & (dns- > inuse > 0) 'не удалось.

поэтому я не уверен, но в curl у вас есть этот вариант

CURLOPT_DNS_USE_GLOBAL_CACHE ИСТИНА использовать глобальный кэш DNS. Эта опция не является потокобезопасной и включена по умолчанию.

Измените это на FALSE, я не могу получить эту ошибку на данный момент, даже если я запускаю много потоков, называя множество URL-адресов в одном месте... эта ошибка не запускалась чтобы показать, пока у меня не было большого запроса в быстрой последовательности.