My long team laravel 4 continues to be killed

Question

I have a laravel 4 web project that implements the laravel command.

When you start development in homestead vm, it ends (about 40 seconds of total time).

However, when launched on a production server, it exits with a "killed" output on the command line.

At first I thought it was max_execution_time in cli php.ini, so I set it to 0 (unlimited time).

How to find out what kills my team?

I run it on the ssh terminal using the standard artisan instance:

php artisan commandarea: command_name

Does laravel 4 have time limits for teams?

vps is an Ubuntu 4.10 machine with mysql, nginx and php-fpm

Answer 1

So firstly, thanks to everyone who pointed me in the right direction regarding tracking usage of PHP and laravel.

I answered my own question, hoping that it would benefit laravel developers in the future, as my solution was hard to find.

After entering 'dmesg' to display system messages. I found that php script was killed by Linux.

So, I added memory log calls to my script before and after each of the key areas of my script:

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

Then I ran the script, watching the log output as well as the output of the "top" command.

I found that even though my methods were ending and the variables were out of scope, the memory was not freed.

Things I tried that DIDNTs matter in my case:

• unset ($ varname) for variables after I finished with them - hoping the GC starts.
• adding gc_enable () at the beginning of the script, and then adding calls to gc_collect_cycle () after a significant amount of vars is not set.
• Disabling mysql transactions - perhaps this is memory intensity - it is not.

Now it was strange that none of the above had any meaning. My script still used 150mb or ram in time when it was killed!

Solution that really worked:

Now this is definitely a laravel specific solution. But my task is to parse a large XML feed and then insert thousands of rows into mysql using the ORKENT ORM element.

It turns out that Laravel creates information and log objects to help you see query performance.

Disabling it with the next “magic” call, I got my script from 150 mb to 20 MB!

This is magic"; call:

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

I can tell you, when I found this call, I grabbed at a straw; - (

Answer 2

A process can be killed for several reasons:

Not enough memory

There are two ways to cause this error: to exceed the memory allocated by the PHP script in php.ini, or to exceed the available system memory. Check the PHP error log and the php.ini file to rule out the first possibility, and use dmesg output to check the second possibility.

Runtime limit exceeded

In your message, you indicate that you have disabled the timeout using the max_execution_time parameter, but I have included it here for completeness. Make sure the setting in php.ini is correct and (for those who use the web server instead of the CLI script), restart the web server to make sure that the new configuration is active.

Stack error

If your script is error-free and does not encounter any of the above errors, make sure your system is working properly. If using a web server, restart the web server software. Check the error logs for unexpected output and stop or update related daemons and necessary ones.

Answer 3

Was this a problem in the Laravel / Spark project. just wanted to share if others have this problem.

Try updating / restarting your dev server if you are using Vagrant or Ubuntu before more aggressive approaches.

I accidentally started installing dependency packages on a Vagrant server. I also deleted and replaced the mirrored folder again during installation errors. My mistake was on Laravel / Spark 4. ~. I managed to migrate to other projects; I quickly “killed” the 300 ms timeframe for a particular project for almost all teams. While reading other users, I was afraid to find a problem or corruption. In my case, a quick stray reload did the trick. the dead issue has been resolved.