GCP实例传输Google Drive数据报Broken pipe等错误求助

两个错误存在明确先后因果关系，按以下顺序排查即可，不用盲目猜测是磁盘还是网络问题：

• 先排查代码逻辑硬伤：
  贴出的代码存在3个会直接触发随机报错的问题，和“报错文件不固定、运行1-2小时崩溃”的特征完全匹配：
  1. 分支逻辑漏初始化对象：走export_media的Google原生格式文件（文档、表格、幻灯片等）分支，没有初始化fh字节流对象和downloader实例，只要遍历到这类文件，代码走到后面fh.seek(0)的时候直接抛错，而遍历文件时碰到这类文件的顺序不固定，所以看起来报错完全随机。
  2. 异常捕获逻辑失效：下载阶段的所有异常都被笼统捕获，既不打印完整堆栈，也不终止当前文件的处理流程，下载失败后还是强行执行写磁盘逻辑，此时文件句柄状态异常、资源没释放，很容易触发/data/挂载点的设备忙报错。
  3. 内存溢出风险：当前实现用io.BytesIO把整个文件全加载到进程内存，碰到1-3GB的大文件时，内存占用会随下载进度线性上涨，长时运行下内存碎片、资源泄漏累积1-2小时就会触发系统OOM回收，OOM时会强制断连所有TCP连接（即看到的Broken pipe错误）、回收IO句柄，连带触发磁盘资源异常。
• 代码问题修复后再分层验证底层资源：
  1. 网络层验证：在计算实例上开启TCP连接监控，看和Google Drive API的长连接是不是被网关静默切断——GCP默认的TCP keepalive超时是2小时，如果设置的下载chunk太大，单块下载耗时超过超时阈值就会触发断管。
  2. 磁盘层验证：在/data/挂载点上跑连续4小时的随机写压测，同时查dmesg内核日志，看有没有磁盘IO超时、SCSI总线重置、挂载点被自动重新挂载为只读的记录，如果附加磁盘被多实例同时挂载、或者IOPS/吞吐量打满触发云盘节流，就会随机报设备忙错误。

• 代码逻辑修正：
  把文件写入逻辑从“全量加载到内存再写盘”改成“直接流式写临时文件”，对齐所有分支的对象初始化，细分异常捕获，强制释放资源，修正后的核心代码如下：

import os
import io
from googleapiclient.http import MediaIoBaseDownload

# 保留原有MIMETYPE_CONVERSOR配置即可
def download_files(service, item, dfilespath):
    file_name = item['name']
    target_path = os.path.join(dfilespath, file_name)
    if os.path.isfile(target_path):
        return
    if item['mimeType'] == 'application/vnd.google-apps.shortcut':
        logger.log('Skip unsupported shortcut file: %s' % file_name)
        return

    # 初始化下载请求
    if item['mimeType'] in MIMETYPE_CONVERSOR:
        request = service.files().export_media(
            fileId=item['id'],
            mimeType=MIMETYPE_CONVERSOR[item['mimeType']]
        )
    else:
        request = service.files().get_media(fileId=item['id'])

    tmp_path = target_path + ".part"
    fh = None
    try:
        # 直接写磁盘临时文件，不占用大内存
        fh = io.open(tmp_path, 'wb')
        # chunk设为10MB，单块下载耗时控制在10秒内，避开TCP超时
        downloader = MediaIoBaseDownload(fh, request, chunksize=10*1024*1024)
        done = False
        while not done:
            # 内置3次单块重试，规避临时网络波动
            status, done = downloader.next_chunk(num_retries=3)
            logger.log("File %s download: %d%%" % (file_name, int(status.progress() * 100)))
        # 下载完成后原子重命名，避免残留半下载坏文件
        os.rename(tmp_path, target_path)
    except BrokenPipeError:
        logger.log("Broken pipe when downloading %s, temp file will be cleaned" % file_name)
        raise
    except Exception as e:
        logger.log("Download %s failed: %s" % (file_name, str(e)))
        return
    finally:
        # 强制释放文件句柄，避免占用磁盘资源
        if fh and not fh.closed:
            fh.close()
        # 清理异常残留的临时文件
        if os.path.exists(tmp_path):
            os.remove(tmp_path)

• 系统配置调整：
  • 修改计算实例的TCP内核参数：将net.ipv4.tcp_keepalive_time设为60、net.ipv4.tcp_keepalive_intvl设为10、net.ipv4.tcp_keepalive_probes设为6，让长连接主动发送心跳包，避免被网关静默断开。
  • 检查/data/磁盘的挂载参数，使用defaults,noatime,nofail挂载，跑任务前用lsof /data/确认没有自动快照、日志采集、病毒扫描等进程占用挂载点。
  • 调整任务流程：单文件下载完成后立刻做压缩、上传、删除本地文件的操作，不要等全量文件下载完再批量处理，把磁盘使用率稳定控制在70%以下，避免磁盘写满触发系统保护。
• 容错机制补充：
  增加断点续传标记，每成功处理完一个文件就把文件ID写入本地记录文件，任务重启后直接跳过已处理文件。碰到Broken pipe类网络错误时等待10秒重试3次，不要直接终止整个任务。

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