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.
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