当然可以调整这些内存参数来解决OOM问题，下面分几种常用场景给你具体操作方法，还有关键注意事项：

1. 控制台配置（最常用） #

在AWS Glue控制台新建或编辑Job时，找到Job parameters区域，添加对应的键值对参数：

• 调整Executor内存：添加键 --conf，值设为 spark.executor.memory=XXg（把XX换成你需要的数值，比如10g、16g）
• 调整Driver内存：同样用--conf键，值设为 spark.driver.memory=XXg

这里要注意：Glue的实例类型决定了最大可用内存，比如G.1X实例对应16GB总内存，G.2X对应32GB，设置的内存不能超过实例本身的可用额度（建议留2-3GB给系统进程，别拉满）。

2. AWS CLI提交Job时配置 #

如果习惯用CLI提交Glue Job，直接在启动命令里带上参数：

aws glue start-job-run --job-name 你的Job名称 --arguments='{"--conf": "spark.executor.memory=10g,spark.driver.memory=10g"}'

3. 脚本内配置（不推荐） #

虽然可以在Spark脚本里尝试设置，比如PySpark脚本里写：

from pyspark.context import SparkContext
sc = SparkContext.getOrCreate()
sc._conf.set("spark.executor.memory", "10g")
sc._conf.set("spark.driver.memory", "10g")

但非常不推荐这种方式——Glue的底层环境会优先读取Job参数中的配置，脚本里的设置大概率会被覆盖，还容易导致配置不一致引发问题。

额外优化建议 #

• 内存调整要和实例类型匹配：比如选了G.1X实例，Executor内存最多设到14G左右，超过的话Glue会自动降到实例允许的最大值，甚至启动失败。
• 配合调整核心数：可以同时设置spark.executor.cores参数（比如--conf spark.executor.cores=4），让每个Executor的资源分配更合理，避免内存浪费。
• 优先优化处理逻辑：如果还是出现OOM，先检查你的数据处理流程——有没有大的shuffle操作？是否可以拆分大分区？有没有不必要的全量加载数据？有时候优化逻辑比单纯加内存效果更好。

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