2012-02-14 12 views
7

esecuzione WordPress su IIS 7 (Windows Server 2008) con WP-Supercache secondo IIS.net's guide.WordPress su IIS 7 php-cgi monopolizzavano CPU

era in esecuzione grande, ma di recente abbiamo cambiato le autorizzazioni per alcune cartelle e la password di amministratore e stiamo ottenendo enormi picchi nell'utilizzo della CPU come risultato dei processi PHP-cgi.exe.

cpu usage

php-cgi.exe processes

Questo mi porta a credere che non è la memorizzazione nella cache tuttavia le pagine stessi hanno il "Copia cache con WP-Supercache" commenti in fondo, e il caching sembra funzionare correttamente.

Che altro potrebbe essere il problema qui?

+1

si può aggiungere qualsiasi ulteriore informazione come tronchi, di rendering della pagina volte, se si è attivato xdebug, ecc ...? Per uno, Wordpress utilizza molta memoria (6 MB +).Due plugin per wordpress usano molta memoria (qualche cosa di extra installato ultimamente?). Tre, il server Windows utilizza molta memoria rispetto a una casella debian che esegue nginx (che è solo 40 MB). – Xeoncross

risposta

1

Guardando quel mgr compito sembra proprio mancare la cache su ogni richiesta. Inoltre, l'articolo risale al 2008, quindi è difficile dire se le indicazioni come scritte funzionerebbero ancora. Qualcosa con WP-SuperCache potrebbe essere cambiato.

mi consiglia di utilizzare W3 Total Cache. Ho eseguito test approfonditi con Windows Server 2008 e IIS 7 e funziona perfettamente. È anche compatibile con e sfrutta l'estensione WinCache per PHP. Ha anche alcune altre grandi funzionalità se sei interessato, minification, supporto CDN, ecc. È un ottimo plugin per le prestazioni di WordPress. È possibile ottenere il plugin qui, http://wordpress.org/extend/plugins/w3-total-cache/

alcune altre cose da controllare ...

Che taglia è la piscina app? (numero di processi?) Assicurati di utilizzare PHP 5.3. Assicurati di utilizzare WinCache. Assicurati di impostare MaxInstanceRequests su qualcosa di meno di PHP_FCGI_MAX_REQUESTS. Sicuramente non permettere a PHP di gestire il riciclo del pool di app. L'impostazione predefinita è 10K richieste. Se vedi questi risultati durante un test di caricamento, questa potrebbe essere la causa. Aumenta MaxInstanceRequests e mantieni uno in meno di PHP_FCGI_MAX_REQUESTS.

Spero che questo aiuti.

8

Credo di aver trovato una soluzione o almeno un round di lavoro a questo problema, almeno sembra funzionare per me in modo affidabile.

Provare a impostare le istanze Max impostazione, in IIS Server -> Impostazioni FastCGI, a 1.

Mi sembrava che solo alcune richieste stavano causando un processo php-cgi.exe per andare canaglia e hog la CPU, di solito quando si aggiorna un post. Durante la lettura di altri post su questo problema, uno di essi ha menzionato l'impostazione Max istanze e che è impostato su 0 o automatico predefinito. Mi chiedevo se questo potrebbe non avere un buon effetto quando le cose non sono come dovrebbero essere. Sto indovinando (ma questo non è esattamente il mio campo di competenza) se una o più richieste stanno causando il blocco del processo, quindi FastCGI ne crea solo un'altra, lasciando il primo posto in essere. In qualche modo sembra che solo una singola istanza consenta a PHP di passare dal lock-up e la CPU rimane sotto controllo.

Per i server con alti livelli di richieste di impostazione FastCGI ad una sola istanza non può essere l'ideale, ma batte sicuramente i ritardi mi stavo prima. Utilizzato in combinazione con WP-SuperCache e WinCache, le cose sembrano andare molto meglio ora.

+1

Sto svuotando questa risposta perché mentre non risolve la radice del problema, acquista tempo per risolvere la radice. –