Il mio comando laravel 4 a esecuzione prolungata continua a essere ucciso

Question

Possiedo un progetto Web laravel 4 che implementa un comando laravel.

Quando si esegue il vm della fattoria di sviluppo, viene eseguito fino al completamento (circa 40 secondi di tempo totale).

Tuttavia, quando viene eseguito sul server di produzione, si chiude con un output "ucciso" sulla riga di comando.

In un primo momento ho pensato che fosse il max_execution_time in cli php.ini, quindi l'ho impostato su 0 (per un tempo illimitato).

Come posso sapere che cosa sta uccidendo il mio comando?

ho eseguirlo sul terminale ssh utilizzando l'invocazione artigianale di serie:

php artigianale commandarea: nomecomando

Vuol laravel 4 hanno un limite di tempo di comando da qualche parte?

il VPS è un'Ubuntu 4.10 macchina con mysql, nginx e php-fpm

Answer 1

Quindi, innanzitutto, grazie a tutti coloro che mi hanno indirizzato nella giusta direzione per quanto riguarda il monitoraggio dell'utilizzo della memoria PHP e laravel.

Ho risposto alla mia domanda sperando che possa beneficiare degli sviluppatori di laravel in futuro, poiché la mia soluzione era difficile da trovare.

Dopo aver digitato 'dmesg' per visualizzare i messaggi di sistema. Ho scoperto che lo script php veniva ucciso da Linux.

Così, ho aggiunto le chiamate di registrazione di memoria nel mio script prima e dopo ciascuna delle aree chiave del mio script:

Log::Info('Memory now at: ' . memory_get_peak_usage()); 

Poi ho eseguito lo script mentre si guarda l'output di registro e anche l'uscita del ' top 'comando.

Ho scoperto che anche se i miei metodi stavano finendo e le variabili stavano andando fuori campo, la memoria non veniva liberata.

cose che ho provato, che DIDNT fare alcuna differenza nel mio caso:

1. unset ($ varname) sulle variabili dopo aver finito con loro - sperando di ottenere GC per dare il via
2. aggiungendo gc_enable() all'inizio dello script e quindi aggiungendo le chiamate a gc_collect_cycle() dopo che un numero significativo di vars non è stato impostato.
3. Disabilitare le transazioni mysql - il pensiero forse è che la memoria è intensiva - non lo era.

Ora, la cosa strana era che nessuno dei precedenti ha fatto alcuna differenza. Il mio script stava ancora usando 150mb o ram a tempo morto!

La soluzione che effettivamente lavorate:

Ora, questo è sicuramente una soluzione specifica laravel. Ma lo scopo dei miei script è fondamentalmente analizzare un grande feed xml e quindi inserire migliaia di righe in mysql usando Elequent ORM.

Si scopre che Laravel crea informazioni di registrazione e oggetti per aiutarvi a vedere le prestazioni della query.

Spegnendo questa funzione con la seguente chiamata "magica", ho ottenuto il mio script da 150mb a circa 20mb!

Questa è la "magia"; chiamano:.

DB::connection()->disableQueryLog(); 

posso dirvi per il momento ho trovato questa chiamata, stavo afferrando sugli specchi ;-(

Answer 2

Un processo può essere ucciso per diversi motivi:

Out of Memory

Ci sono due modi per attiva questo errore: supera la quantità di memoria allocata allo script PHP in php.ini o supera la memoria di sistema disponibile. Controlla il log degli errori PHP e il file php.ini per escludere la prima possibilità e usa l'output di dmesg per verificare la seconda possibilità.

superato il limite di timeout di esecuzione

Nel tuo post si indica che è stato disattivato il timeout tramite l'impostazione max_execution_time, ma ho incluso qui per completezza. Assicurarsi che l'impostazione in php.ini sia corretta e (per quelli che utilizzano un server Web anziché uno script CLI) riavviare il server Web per assicurarsi che la nuova configurazione sia attiva.

un errore nello stack

Se lo script è privo di errori e non incontrare uno degli errori di cui sopra, assicurarsi che il sistema sta funzionando come previsto. Quando si utilizza un server Web, riavviare il software del server Web. Controllare i log degli errori per l'output non previsto e interrompere o aggiornare i daemon correlati e necessari.

Answer 3

avuto questo problema su un progetto/Spark laravel solo voluto condividere se altri hanno questo problema.

Prova un aggiornamento/riavvio del server dev se in esecuzione Vagrant o Ubuntu prima di approcci più aggressivi.

ho accidentalmente imbattuto installazione di pacchetti di dipendenza su un server di Vagrant. ho anche rimosso e sostituito una cartella a specchio ripetutamente durante l'installazione e rrors. Il mio errore era su Laravel/Spark 4. ~. Sono stato in grado di eseguire migrazioni su altri progetti; Stavo diventando "ucciso" molto velocemente, a 300 ms di tempo, su un particolare progetto per quasi tutti i comandi. Leggendo altri utenti, temevo di provare a trovare il problema o la corruzione. Nel mio caso, una veloce ricarica di Vagrant ha fatto il trucco. il problema ucciso è stato risolto.