Назад | Перейти на главную страницу

Процессы PHP выполняются по одному, всегда занимая 100% одного ядра.

У нас есть семь веб-сайтов, написанных на PHP, работающих на сервере Windows 2008 с IIS 7.5. Они все очень сейчас медленно.

Когда я смотрю в диспетчер задач, я вижу около 10 процессов php-cgi.exe, и все они занимают 0% ЦП, за исключением одного, который занимает 25%. Это четырехъядерный сервер, поэтому он занимает 100% одного ядра.

Если я посмотрю несколько секунд, процесс, занимающий 25%, перейдет в 0%, а другой процесс php-cgi.exe перейдет на 25%. Таким образом, все процессы php-cgi.exe просто выстраиваются в очередь, ожидая одного ядра, и каждый процесс использует 100% процессора, когда это возможно.

Каждый из 7 сайтов находится в собственном пуле приложений в IIS, и мы используем FastCGI. Версия PHP - 5.3.

Любые идеи? Спасибо!

РЕДАКТИРОВАТЬ: Вот наши настройки FastCGI:

    <fastCgi>
        <application fullPath="C:\Program Files (x86)\PHP\v5.3\php-cgi.exe" monitorChangesTo="C:\Program Files (x86)\PHP\v5.3\php.ini" activityTimeout="600" requestTimeout="600" instanceMaxRequests="10000">
            <environmentVariables>
                <environmentVariable name="PHP_FCGI_MAX_REQUESTS" value="10000" />
                <environmentVariable name="PHPRC" value="C:\Program Files (x86)\PHP\v5.3" />
            </environmentVariables>
        </application>
    </fastCgi>

РЕДАКТИРОВАТЬ № 2: Частично мы в этом разобрались. PHP никогда не проводил сеансы сбора мусора из-за проблем с разрешениями, поэтому файлов сеансов были миллионы.

Но я все же хотел бы знать, почему он всегда использует только одно ядро. Сайты теперь работают намного быстрее, но мы еще не решили эту проблему. Кто-нибудь знает?

В конечном итоге проблема заключалась в том, что в папке, в которой PHP хранит файлы сеанса (sessions_). Либо сборка мусора никогда не работала с тех пор, как мы развернули этот сервер, либо она работала какое-то время, но мы изменили идентификатор пула приложений или что-то еще, чтобы у нового идентификатора не было доступа для удаления файлов. Во всяком случае, у нас в этой временной папке было более 2 миллионов файлов sessions. На это ушло несколько часов, но в итоге "del / F / Q sessions_команда завершена, мы перезапустили сайт, и все снова отлично (от среднего времени загрузки страницы 60 секунд до гораздо меньше 1 секунды). Я не знаю, исправило ли это «все вместе cgi-php.exe» процессы никогда не используют более одного "комбинированного ядра" или нет, но для меня было бы логично, что механизм в реализации PHP для Windows, который создает эти файлы sess_, может быть спроектирован таким образом, чтобы вызвать это явление (если это одноквартирный резьбовой, например).

В любом случае, мораль этой истории в том, что если вы видите очень медленное и устойчивое увеличение потребления ЦП (которое, возможно, составляет 100% от одного ядра), а время ответа HTTP также увеличивается медленно, проверьте папку, в которой вы храните свой php файлы сеанса (sess_ *) и посмотрите, не вылетает ли проводник Windows при открытии этой папки! :)

(Кстати, это W2k8 (не R2), поэтому я думаю, что это IIS 7, а не 7.5)