尧图网站建设 
Presto故障排查手册12个生产环境常见报错的快速定位与解决【免费下载链接】prestoThe official home of the Presto distributed SQL query engine for big data项目地址: https://gitcode.com/gh_mirrors/pre/prestoPresto 是面向大数据的分布式 SQL 查询引擎the official home of the Presto distributed SQL query engine广泛用于实时查询、日志分析和跨源联邦查询。但在生产环境中Presto 故障排查从来不是看懂报错信息这么简单——报错可能来自 Coordinator、Worker、资源组、安全层或底层 JVM。本手册整理了Presto 12 个生产环境常见报错按照报错信息 → 根本原因 → 快速解决方案的格式逐一拆解配合错误码体系和排查清单帮助新手运维在几分钟内定位并解决问题。先懂报错体系PrestoException 与 ErrorCode 快速入门 在逐条看报错之前先花 2 分钟理解 Presto 的错误机制后面所有排查都会事半功倍。Presto 的所有可识别错误都继承自PrestoException并携带一个唯一的ErrorCode错误码。定义见异常基类PrestoException.java标准错误码表StandardErrorCode.java客户端收到失败响应时返回的QueryResults中包含一个error字段即QueryError对象里面有message、errorCode、失败阶段和堆栈位置这是你定位问题的第一手资料。协议细节见 client-protocol.rst。小技巧任何报错都先抄下三样东西——错误消息message、错误码errorCode、失败发生的阶段planning / scheduling / execution。这决定了该查 SQL、查配置还是查机器。Presto生产环境12个常见报错定位与解决1. 报错Query failed: Insufficient resources: query execution was cancelled现象查询提交后被资源组直接取消。原因查询违反了资源组Resource Group策略——并发已满、内存软限被触发或排队超时。解决检查当前查询归属的资源组调大max-concurrency或soft-memory-limit高峰期可配合soft-concurrency-limit让查询排队而非直接失败业务侧可对大查询显式SET RESOURCE_GROUP ...路由到大资源组。2. 报错Query exceeded the memory limit of the local node现象单个 Worker 节点内存超限任务失败错误码EXCEEDED_LOCAL_MEMORY_LIMIT。原因数据倾斜导致某节点局部内存爆掉或节点本身内存配置过小。解决开启内存溢写SET SESSION query_spill_enabled true把中间数据落盘提高节点可用内存query.max-memory-per-node检查 SQL 是否数据倾斜如某个 key 占比过大考虑加盐打散。3. 报错Query exceeded the global memory limit现象整个查询的总内存超过集群限制错误码EXCEEDED_GLOBAL_MEMORY_LIMIT。原因全局内存池耗尽——要么查询确实太大要么集群 Worker 数不够。解决短期调大query.max-memory-in-mb注意别超过集群物理内存总量长期增加 Worker 节点分摊负载优化 SQL减少 shuffle 数据量、加过滤条件、避免不必要的DISTINCT与全量 Join。4. 报错Failed to connect to worker: Connection refused现象调度阶段失败Coordinator 连不上某个 Worker。原因常见三类——Worker 没启动、node.internal-address配置成内网不可达地址、防火墙拦截了 HTTP 端口。解决在 Coordinator 上直接curl http://worker地址:8080/v1/info验证连通性确认 node.properties 中node.internal-address是集群内可路由的地址核对两端http-server.http.port与防火墙/安全组放行情况。5. 报错No node available for the queryWorker 注册失败现象集群里明明有 WorkerCoordinator 却说没有可用节点。原因Worker 向 Coordinator 注册失败多为 discovery 配置错误或node.data-dir下节点身份文件不一致改过 IP 后未清理旧数据目录。解决对照 config.properties.example 检查discovery-server.enabled、discovery.uri配置两端一致若 Worker 更换过 IP清空该 Worker 的node.data-dir数据目录后重启观察server.log中 discovery 相关的注册日志确认原因。6. 报错Table not found/Schema not found现象明明表存在查询却说找不到。原因catalog 未加载或catalog.properties中连接配置如 Hive Metastore 地址错误catalog.schema.table三段式命名写错Metastore 服务本身不可达。解决SHOW CATALOGS;确认 catalog 已加载检查对应 catalog 配置文件参考 catalog 配置示例确认hive.metastore.uri等连接参数用SELECT * FROM information_schema.schemata验证可见 schema。7. 报错Access Denied现象认证通过但访问被拒或根本进不来客户端。原因文件认证方式下用户名/密码不匹配password-authenticator-file对应的 properties 里无此用户访问控制策略file-based access control未授权对应 schema/表。解决核对密码文件用户 key 必须与认证方式匹配如password Authenticator: username在访问控制 JSON 中补充对应用户/组的allow规则认证模块相关实现见 presto-password-authenticators。8. 报错Request Header Fields Too LargeHTTP 431现象CLI 或 JDBC 客户端报Bad Message 431官方在 troubleshoot/query.rst 中专门记录过。原因请求头过大——典型场景是设置了大量 session properties、clientInfo塞了过多信息或用 prepared statement 提交了超长 SQL 模板。解决在 Coordinator 的 config.properties 中调大请求头上限例如http-server.max-request-header-size5MB避免对超长 SQL 使用 prepared statement精简自定义 session 属性。9. 报错Query exceeded the maximum runtime/Query was cancelled现象长查询跑到一半被系统取消。原因超过query.max-execution-time默认 36 小时或query.max-queued-time也可能是资源组抢占、人工 cancel。解决确认真实需求绝大多数查询不该超过默认时限优先优化 SQL确实需要时可调大query.max-execution-time到 Query UI 的 Failed 页签查询被取消的具体原因抢占/超时/手动。10. 报错Permission denied: .../launcher.pid现象执行bin/launcher run或bin/launcher start直接报权限错误见 troubleshoot/deploy.rst。原因当前用户对data/var/run/目录没有写权限。解决不要用 root 启动生产服务正确做法是把 Presto 的data、plugin、var目录属主改为启动用户临时验证可sudo bin/launcher run但正式环境应修目录权限。11. 报错VM option UseG1GC is experimental/Could not create the Java Virtual Machine现象服务直接起不来JVM 初始化阶段退出官方记录见 troubleshoot/deploy.rst。原因JDK 版本不匹配——旧版本 JDK 中 G1GC 属于实验特性或系统装了不受支持的 JDK。解决按项目 README 的 Requirements 安装支持的 JDK 版本推荐 JDK 11 的长期支持版用java -version确认JAVA_HOME指向正确检查 jvm.config.example 中的 JVM 参数是否与当前 JDK 兼容。12. 报错Insufficient file descriptors/ Worker 被系统 OOM Kill现象并发升高后连接大量失败或dmesg里看到Out of memory: Kill process。原因文件描述符上限太低ulimit -n默认 1024 远不够JVM 堆配置超过物理内存GC 压力过大被内核 OOM Killer 杀掉。解决系统层面ulimit -n 65535写入 systemd unit 的LimitNOFILE按公式配置堆内存JVM 堆 ≈ 物理内存 − 预留建议预留至少 20% 给堆外与 OS修改jvm.config中-Xmx/-Xms监控server.log中 GC 日志老年代长期 80% 时优先加内存而非调参数。生产环境Presto故障排查速查清单⚡ 按下面顺序排查覆盖 90% 的现场问题步骤检查项常用手段1️⃣抄下 message errorCode 失败阶段客户端返回的QueryErrorJSON2️⃣报错发生在哪个环节planning查 SQL/ scheduling查节点/ execution查资源3️⃣Query UI 的 Failed 页签看失败 query 的完整失败原因与运行图4️⃣资源组策略是否拦截资源组指标排队数、拒绝数、内存使用5️⃣节点间连通性curl http://worker:8080/v1/info6️⃣系统资源top、ulimit -n、dmesg \| grep -i oom7️⃣服务日志server.logCoordinator 与 Worker 都要看官方故障排查文档与相关模块路径官方故障排查入口troubleshoot.rst部署类问题launcher 权限、JDK 版本等troubleshoot/deploy.rst查询类问题431 请求头过大等troubleshoot/query.rst错误码体系定义StandardErrorCode.java、PrestoException.java客户端协议QueryError 结构client-protocol.rst服务配置示例config / jvm / nodedocker/etc/资源组管理模块presto-resource-group-managers最后提醒Presto 的报错信息往往已经把答案写在了错误码里。养成先读 errorCode 再动手的习惯绝大多数故障都能在 10 分钟内定位。【免费下载链接】prestoThe official home of the Presto distributed SQL query engine for big data项目地址: https://gitcode.com/gh_mirrors/pre/presto创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Presto故障排查手册：12个生产环境常见报错的快速定位与解决
Presto故障排查手册12个生产环境常见报错的快速定位与解决【免费下载链接】prestoThe official home of the Presto distributed SQL query engine for big data项目地址: https://gitcode.com/gh_mirrors/pre/prestoPresto 是面向大数据的分布式 SQL 查询引擎the official home of the Presto distributed SQL query engine广泛用于实时查询、日志分析和跨源联邦查询。但在生产环境中Presto 故障排查从来不是看懂报错信息这么简单——报错可能来自 Coordinator、Worker、资源组、安全层或底层 JVM。本手册整理了Presto 12 个生产环境常见报错按照报错信息 → 根本原因 → 快速解决方案的格式逐一拆解配合错误码体系和排查清单帮助新手运维在几分钟内定位并解决问题。先懂报错体系PrestoException 与 ErrorCode 快速入门 在逐条看报错之前先花 2 分钟理解 Presto 的错误机制后面所有排查都会事半功倍。Presto 的所有可识别错误都继承自PrestoException并携带一个唯一的ErrorCode错误码。定义见异常基类PrestoException.java标准错误码表StandardErrorCode.java客户端收到失败响应时返回的QueryResults中包含一个error字段即QueryError对象里面有message、errorCode、失败阶段和堆栈位置这是你定位问题的第一手资料。协议细节见 client-protocol.rst。小技巧任何报错都先抄下三样东西——错误消息message、错误码errorCode、失败发生的阶段planning / scheduling / execution。这决定了该查 SQL、查配置还是查机器。Presto生产环境12个常见报错定位与解决1. 报错Query failed: Insufficient resources: query execution was cancelled现象查询提交后被资源组直接取消。原因查询违反了资源组Resource Group策略——并发已满、内存软限被触发或排队超时。解决检查当前查询归属的资源组调大max-concurrency或soft-memory-limit高峰期可配合soft-concurrency-limit让查询排队而非直接失败业务侧可对大查询显式SET RESOURCE_GROUP ...路由到大资源组。2. 报错Query exceeded the memory limit of the local node现象单个 Worker 节点内存超限任务失败错误码EXCEEDED_LOCAL_MEMORY_LIMIT。原因数据倾斜导致某节点局部内存爆掉或节点本身内存配置过小。解决开启内存溢写SET SESSION query_spill_enabled true把中间数据落盘提高节点可用内存query.max-memory-per-node检查 SQL 是否数据倾斜如某个 key 占比过大考虑加盐打散。3. 报错Query exceeded the global memory limit现象整个查询的总内存超过集群限制错误码EXCEEDED_GLOBAL_MEMORY_LIMIT。原因全局内存池耗尽——要么查询确实太大要么集群 Worker 数不够。解决短期调大query.max-memory-in-mb注意别超过集群物理内存总量长期增加 Worker 节点分摊负载优化 SQL减少 shuffle 数据量、加过滤条件、避免不必要的DISTINCT与全量 Join。4. 报错Failed to connect to worker: Connection refused现象调度阶段失败Coordinator 连不上某个 Worker。原因常见三类——Worker 没启动、node.internal-address配置成内网不可达地址、防火墙拦截了 HTTP 端口。解决在 Coordinator 上直接curl http://worker地址:8080/v1/info验证连通性确认 node.properties 中node.internal-address是集群内可路由的地址核对两端http-server.http.port与防火墙/安全组放行情况。5. 报错No node available for the queryWorker 注册失败现象集群里明明有 WorkerCoordinator 却说没有可用节点。原因Worker 向 Coordinator 注册失败多为 discovery 配置错误或node.data-dir下节点身份文件不一致改过 IP 后未清理旧数据目录。解决对照 config.properties.example 检查discovery-server.enabled、discovery.uri配置两端一致若 Worker 更换过 IP清空该 Worker 的node.data-dir数据目录后重启观察server.log中 discovery 相关的注册日志确认原因。6. 报错Table not found/Schema not found现象明明表存在查询却说找不到。原因catalog 未加载或catalog.properties中连接配置如 Hive Metastore 地址错误catalog.schema.table三段式命名写错Metastore 服务本身不可达。解决SHOW CATALOGS;确认 catalog 已加载检查对应 catalog 配置文件参考 catalog 配置示例确认hive.metastore.uri等连接参数用SELECT * FROM information_schema.schemata验证可见 schema。7. 报错Access Denied现象认证通过但访问被拒或根本进不来客户端。原因文件认证方式下用户名/密码不匹配password-authenticator-file对应的 properties 里无此用户访问控制策略file-based access control未授权对应 schema/表。解决核对密码文件用户 key 必须与认证方式匹配如password Authenticator: username在访问控制 JSON 中补充对应用户/组的allow规则认证模块相关实现见 presto-password-authenticators。8. 报错Request Header Fields Too LargeHTTP 431现象CLI 或 JDBC 客户端报Bad Message 431官方在 troubleshoot/query.rst 中专门记录过。原因请求头过大——典型场景是设置了大量 session properties、clientInfo塞了过多信息或用 prepared statement 提交了超长 SQL 模板。解决在 Coordinator 的 config.properties 中调大请求头上限例如http-server.max-request-header-size5MB避免对超长 SQL 使用 prepared statement精简自定义 session 属性。9. 报错Query exceeded the maximum runtime/Query was cancelled现象长查询跑到一半被系统取消。原因超过query.max-execution-time默认 36 小时或query.max-queued-time也可能是资源组抢占、人工 cancel。解决确认真实需求绝大多数查询不该超过默认时限优先优化 SQL确实需要时可调大query.max-execution-time到 Query UI 的 Failed 页签查询被取消的具体原因抢占/超时/手动。10. 报错Permission denied: .../launcher.pid现象执行bin/launcher run或bin/launcher start直接报权限错误见 troubleshoot/deploy.rst。原因当前用户对data/var/run/目录没有写权限。解决不要用 root 启动生产服务正确做法是把 Presto 的data、plugin、var目录属主改为启动用户临时验证可sudo bin/launcher run但正式环境应修目录权限。11. 报错VM option UseG1GC is experimental/Could not create the Java Virtual Machine现象服务直接起不来JVM 初始化阶段退出官方记录见 troubleshoot/deploy.rst。原因JDK 版本不匹配——旧版本 JDK 中 G1GC 属于实验特性或系统装了不受支持的 JDK。解决按项目 README 的 Requirements 安装支持的 JDK 版本推荐 JDK 11 的长期支持版用java -version确认JAVA_HOME指向正确检查 jvm.config.example 中的 JVM 参数是否与当前 JDK 兼容。12. 报错Insufficient file descriptors/ Worker 被系统 OOM Kill现象并发升高后连接大量失败或dmesg里看到Out of memory: Kill process。原因文件描述符上限太低ulimit -n默认 1024 远不够JVM 堆配置超过物理内存GC 压力过大被内核 OOM Killer 杀掉。解决系统层面ulimit -n 65535写入 systemd unit 的LimitNOFILE按公式配置堆内存JVM 堆 ≈ 物理内存 − 预留建议预留至少 20% 给堆外与 OS修改jvm.config中-Xmx/-Xms监控server.log中 GC 日志老年代长期 80% 时优先加内存而非调参数。生产环境Presto故障排查速查清单⚡ 按下面顺序排查覆盖 90% 的现场问题步骤检查项常用手段1️⃣抄下 message errorCode 失败阶段客户端返回的QueryErrorJSON2️⃣报错发生在哪个环节planning查 SQL/ scheduling查节点/ execution查资源3️⃣Query UI 的 Failed 页签看失败 query 的完整失败原因与运行图4️⃣资源组策略是否拦截资源组指标排队数、拒绝数、内存使用5️⃣节点间连通性curl http://worker:8080/v1/info6️⃣系统资源top、ulimit -n、dmesg \| grep -i oom7️⃣服务日志server.logCoordinator 与 Worker 都要看官方故障排查文档与相关模块路径官方故障排查入口troubleshoot.rst部署类问题launcher 权限、JDK 版本等troubleshoot/deploy.rst查询类问题431 请求头过大等troubleshoot/query.rst错误码体系定义StandardErrorCode.java、PrestoException.java客户端协议QueryError 结构client-protocol.rst服务配置示例config / jvm / nodedocker/etc/资源组管理模块presto-resource-group-managers最后提醒Presto 的报错信息往往已经把答案写在了错误码里。养成先读 errorCode 再动手的习惯绝大多数故障都能在 10 分钟内定位。【免费下载链接】prestoThe official home of the Presto distributed SQL query engine for big data项目地址: https://gitcode.com/gh_mirrors/pre/presto创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考