Laravel队列中cURL error 6问题排查与求助

核心问题分析 #

你遇到的错误本质是长期运行的队列Worker进程中TCP连接资源泄漏，导致系统线程/文件描述符耗尽。虽然已调整ulimit、设置Guzzle强制关闭连接，但仍未解决，且仅在队列任务中出现、其他同配置项目无此问题，需从「Guzzle配置有效性」「Laravel-Shopify包的连接管理」「系统深层资源限制」「Worker进程特性」这几个维度排查。

具体解决方案 #

1. 修正Guzzle配置（关键：确保强制关闭连接的选项生效） #

你当前的Guzzle配置存在格式错误：CURLOPT_FORBID_REUSE和CURLOPT_FRESH_CONNECT属于cURL原生选项，必须嵌套在curl子数组中才会被Guzzle识别，直接放在根数组里不会生效。修正后的配置如下：

$opts->setGuzzleOptions([
    'headers' => [
        'Accept' => 'application/json',
        'Content-Type' => 'application/json',
        'Connection' => 'close'
    ],
    'curl' => [
        CURLOPT_FORBID_REUSE => true,
        CURLOPT_FRESH_CONNECT => true,
    ],
    'timeout' => 20.0,
    'connect_timeout' => 30.0,
    'allow_redirects' => false
]);

该配置会强制每次请求创建新连接，且请求后立即关闭，避免连接复用导致的资源泄漏。

2. 排查Laravel-Shopify包的客户端复用逻辑 #

Laravel-Shopify包默认可能维护Guzzle客户端的单例实例，即使你设置了强制关闭连接，单例复用仍会导致资源无法释放。可尝试：

• 在队列任务中每次请求前手动初始化新的Shopify客户端，而非依赖全局单例：

  use Osiset\ShopifyApp\Services\ShopifyAPI;
  
  class YourQueueJob implements ShouldQueue
  {
      public function handle(ShopifyAPI $shopifyApi)
      {
          // 手动创建新的客户端实例，避免复用全局单例
          $client = $shopifyApi->make()->client();
          // 执行API请求
          $client->get('/admin/api/2024-07/orders.json');
      }
  }
  

• 检查Laravel-Shopify包版本，升级到最新稳定版，确认是否存在已知的连接泄漏修复。

3. 系统层面的深层资源限制排查 #

仅调整用户级ulimit（2048）可能不足，需检查系统级资源限制：

• 查看系统最大文件描述符数：sysctl fs.file-max，若数值过低，可临时调整：sysctl -w fs.file-max=65535，并写入/etc/sysctl.conf永久生效。
• 查看系统最大线程数：sysctl kernel.threads-max，确保数值足够支撑队列Worker的并发需求。
• 检查进程的线程栈大小：ulimit -s，若栈过小可能导致线程创建失败，可调整为8192或更高。

4. 优化队列Worker的生命周期配置 #

临时方案--max-jobs=XX可优化为组合配置，降低资源泄漏的影响：

• 同时设置--max-time=3600（让Worker运行1小时后自动重启），结合--max-jobs=100，双重保障资源重置。
• 使用Laravel的队列监控工具（如Horizon），自动重启异常Worker或达到资源阈值的Worker。

为什么其他同配置项目无此问题？ #

可能的原因包括：

• 其他项目的任务量/请求频率更低，资源泄漏速度慢，尚未达到触发错误的阈值。
• 其他项目的Laravel-Shopify包版本、PHP版本或cURL扩展版本不同，已修复相关泄漏问题。
• 其他项目的队列Worker已配置--max-jobs或--max-time，自动重置资源，未显现问题。
• 其他项目的系统资源限制更高（如系统级文件描述符数更大），可容纳更多泄漏的连接。

内容的提问来源于stack exchange，提问作者Bobolito