Моя давняя команда laravel 4 продолжает быть убитой
У меня есть веб-проект laravel 4, который реализует команду laravel.
При запуске в усадьбе разработчиков vm он запускается до завершения (общее время около 40 секунд).
Однако, когда он запускается на рабочем сервере, он завершается с «убитым» выводом в командной строке.
Сначала я подумал, что это max_execution_time в cli php.ini, поэтому я установил его на 0 (неограниченное время).
Как я могу узнать, что убивает мою команду?
Я запускаю его на ssh-терминале, используя стандартный вызов artisan:
php artisan commandarea: имя команды
У laravel 4 есть лимит командного времени где-нибудь?
Vps — это машина с Ubuntu 4.10 с mysql, nginx и php-fpm
Решение
Итак, во-первых, спасибо всем, кто указал мне верное направление в отношении PHP и отслеживания использования памяти Laravel.
Я ответил на свой вопрос, надеясь, что в будущем это принесет пользу разработчикам Laravel, так как мое решение было трудно найти.
После ввода ‘dmesg’, чтобы показать системные сообщения. Я обнаружил, что PHP-скрипт был убит Linux.
Итак, я добавил вызовы регистрации памяти в мой сценарий до и после каждой из ключевых областей моего сценария:
Log::Info('Memory now at: ' . memory_get_peak_usage());
Затем я запустил скрипт, наблюдая за выводом журнала, а также выводом команды top.
Я обнаружил, что, хотя мои методы заканчивались и переменные выходили из области видимости, память не освобождалась.
Вещи, которые я пытался, что Didnt в моем случае какая-то разница:
- unset ($ varname) для переменных после того, как я закончил с ними — в надежде, что GC начнет работу
- добавление gc_enable () в начале скрипта, а затем добавление вызовов gc_collect_cycle () после того, как значительное число переменных не установлено.
- Отключение транзакций mysql — думая, что это может потребовать много памяти — не было
Теперь странным было то, что ничего из вышеперечисленного не имело никакого значения. Мой сценарий все еще использовал 150 МБ или оперативную память, когда он убил!
Решение, которое действительно сработало:
Теперь это определенно решение для Laravel.
Но моя цель сценариев в основном состоит в том, чтобы проанализировать большой канал xml и затем вставить тысячи строк в mysql, используя Elequent ORM.
Оказывается, что Laravel создает информацию для регистрации и объекты, чтобы помочь вам увидеть производительность запроса.
Отключив это с помощью следующего «магического» вызова, я уменьшил свой сценарий с 150 МБ до 20 МБ!
Это «магия»; вызов:
DB::connection()->disableQueryLog();
Я могу сказать вам, когда я нашел этот звонок, я цеплялся за соломинку ;-(
Другие решения
Процесс может быть остановлен по нескольким причинам:
Недостаточно памяти
Есть два способа вызвать эту ошибку: превысить объем памяти, выделенный PHP-скрипту в php.ini, или превысить доступную системную память. Проверьте журнал ошибок PHP и файл php.ini, чтобы исключить первую возможность, и используйте вывод dmesg для проверки второй возможности.
Превышен лимит времени ожидания выполнения
В своем сообщении вы указываете, что отключили тайм-аут через max_execution_time настройки, но я включил его здесь для полноты. Убедитесь, что параметр в php.ini указан правильно и (для тех, кто использует веб-сервер вместо сценария CLI), перезапустите веб-сервер, чтобы убедиться, что новая конфигурация активна.
Ошибка в стеке
Если ваш скрипт не содержит ошибок и не обнаруживает ни одной из перечисленных выше ошибок, убедитесь, что ваша система работает должным образом. При использовании веб-сервера перезапустите программное обеспечение веб-сервера. Проверьте журналы ошибок на наличие неожиданных выходных данных, а также остановите или обновите связанные демоны и при необходимости.
Была эта проблема в проекте Laravel / Spark. просто хотел поделиться, если другие имеют эту проблему.
Попробуйте обновить / перезапустить ваш dev-сервер, если вы используете Vagrant или Ubuntu, прежде чем использовать более агрессивные подходы.
Я случайно запустил установку пакетов зависимостей на сервере Vagrant. Я также удалял и заменял зеркальную папку несколько раз во время ошибок установки. Моя ошибка была на Laravel / Spark 4. ~. Я был в состоянии выполнить миграции на других проектах; Я был «убит» очень быстро, за 300 мс, на конкретном проекте почти для всех команд. Читая других пользователей, я боялся попытаться найти проблему или искажение. В моем случае быстрая перезагрузка Vagrant сделала свое дело. убитая проблема была решена.