【问题标题】:Laravel queue listener times outLaravel 队列监听器超时
【发布时间】:2019-08-20 22:55:30
【问题描述】:

在我的 Linux 服务器上,我有以下 cron:

* * * * * php /var/www/core/v1/general-api/artisan schedule:run >> /dev/null 2>&1

CRON 工作正常。我在Kernel.php 中定义了一个预定命令:

    protected function schedule(Schedule $schedule)
    {
        $schedule->command('pickup:save')
            ->dailyAt('01:00');
        $schedule->command('queue:restart')->hourly();
    }

凌晨 1 点的计划任务运行我的自定义命令 php artisan pickup:save。该命令唯一要做的就是调度我定义的作业:

    public function handle()
    {
        $job = (new SaveDailyPropertyPickup());
        dispatch($job);
    }

所以这个作业被分派了,因为我正在为我的队列使用数据库驱动程序,一个新的行被插入到jobs 表中。

到目前为止一切正常。

由于我需要一个队列监听器来处理队列,并且这个队列监听器必须基本上永远运行,所以我这样启动队列监听器:

nohup php artisan queue:listen --tries=3 &

这会将来自nohup 的所有日志写入我的/home 目录中名为nohup.out 的文件中

发生的情况是:第一次处理队列,并执行我的SaveDailyPropertyPickup 作业的handle 函数中定义的代码。

在它执行一次之后,我的队列监听器只是退出。当我检查日志nohup.out 时,我可以看到以下错误:

In Process.php line 1335:

  The process "'/usr/bin/php7.1' 'artisan' queue:work '' --once --queue='default' 
  --delay=0 --memory=128 --sleep=3 --tries=3" exceeded the timeout of 60 seconds.

我检查了this answer,它说在我启动队列侦听器时将超时指定为 0,但也有不推荐这种方法的答案。我还没有尝试过,所以我不知道它是否适用于我的情况。

对我目前的情况有什么建议吗?

Laravel 版本是 5.4

谢谢

【问题讨论】:

  • 这项工作是做什么的,可能需要超过 60 秒?

标签: php laravel laravel-5.4


【解决方案1】:

使用超时参数调用它,计算出你的工作需要多长时间并从那里扩展。

nohup php artisan queue:listen --tries=3 --timeout=600

在您的配置中,您需要更新重试后,它必须大于超时,以避免同时运行相同的作业。假设您使用beanstalkd

    'beanstalkd' => [
        ...
        'retry_after' => 630,
        ...
    ],

在更专业的环境中,我通常会为短期运行的作业和长时间运行的作业排队。

【讨论】:

  • 嗨.. 感谢您的回答。所以有问题的工作需要相当长的时间。最后我检查了至少 15-18 分钟。它必须查询一个数据库,处理结果集然后将其插入另一个数据库。我在明确指定超时时会遇到的另一个小问题是,随着数据库中数据量的不断累积,这项工作将花费越来越长的时间。那么,例如,指定 1000 之类的超时是否可以?
  • 我会创建两个队列,一个用于快速作业,一个用于长时间运行的作业。高超时对于崩溃的快速工作并不好,然后它必须等待超时时间,直到它可以断定它崩溃。另一种策略可能是将您的工作拆分为更小的工作,假设您要解析 1000 个元素,为其中的 10 个元素创建一个工作,然后创建 100 个工作。
  • 明白。那么在需要很长时间的作业上设置任意的高超时值是不好的做法吗?我还用您建议的更改更新了服务器,如果问题在今天凌晨 1 点(7 小时内)解决,我会通知您
  • 那么在需要很长时间的作业上设置任意的高超时值是不好的做法吗?是的,我在生产环境中看到有很多工作出现问题的环境崩溃了,因为超时是 4 小时,所以花了一段时间才发现它崩溃并重试了
  • 更新您。调度程序现在工作,它不再超时。调度程序第一次运行需要 21 分钟,因此我将 --timeout 设置为 1350 并将 retry_after 设置为 1400。它现在可以工作,但是随着数据量的增加,完成此操作所需的时间总是会增加。我试图按照您的建议将其分解为较小的工作,但不幸的是,我无法将耗时的部分分解。我可以分解的部分不需要那么长时间。无论如何,你回答了我原来的问题,所以非常感谢你的帮助
猜你喜欢
  • 2019-07-03
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2014-05-07
  • 2018-08-12
  • 2018-06-20
  • 2016-10-07
  • 2016-12-29
相关资源
最近更新 更多