去年年底接手一套跑批系统的时候客户反复强调一句话“aix调度最近总出问题”。一开始我也以为是他们口误把“AI调度”说成了“aix调度”直到进了机房、看了环境才意识到他们聊的是 IBM AIX 系统上的作业调度与资源调度。这也不怪大家现在一提起“调度”这个词很多人第一反应是容器编排、任务队列但在银行业、制造业、零售业的核心机房里AIX 依然是批量作业和核心交易系统的绝对主力调度这件事在它身上的表现形态跟云原生那套完全不是一回事。这篇文章不聊容器、不聊 K8s专门聊聊 AIX 上的调度实战从 cron/at 这类作业级调度到 CPU 资源调度再到 WLM 工作负载管理器最后复盘几个我真实踩过的坑。无论你是刚接手 AIX 服务器的运维新人还是准备把旧的批处理体系梳理一遍的架构师这篇都应该能给你一些用得上的东西。1. 为什么 AIX 上的“调度”和 Linux 上完全不是一回事先弄明白一个基础问题同样叫“调度”Linux 和 AIX 在概念和使用方式上有哪些不同很多人拿 Linux 的使用经验直接套 AIX十有八九会踩坑。1.1 AIX 的核心定位关键业务批处理服务器AIXAdvanced Interactive eXecutive是 IBM 的 UNIX 操作系统主要跑在 IBM Power 服务器上。国内金融、电信、政企的核心系统里AIX 的存量非常庞大。这些系统的共同特征是机器动不得、稳定性要求极高、批量作业多且复杂。在 Linux 上你随手写个 shell 脚本丢给 crond 就算调度了出了问题重跑一遍也不痛不痒。但在 AIX 上跑批作业经常是凌晨 02:00 启动、关联上下游几十个环节、失败一次就要影响当天账务或生产计划的。所以 AIX 环境里的“调度”从来不是一个命令的事而是一套从作业发起、资源分配到异常兜底的整体机制。1.2 调度这个词在 AIX 环境里有三种含义我在跟客户对问题的时候发现大家对“aix调度”这个词的理解其实很发散所以先把概念对齐调度类型对应机制解决什么问题典型场景作业调度cron、at、batch什么时间点启动什么作业凌晨跑批、定时对账、每日报表CPU 资源调度nice/renice、bindprocessor、schedo进程怎么分配 CPU 资源、绑定哪个核高优先级交易进程保活、控制跑批负荷系统负载调度WLMWorkload Manager不同业务组之间按份额分配资源白天交易与夜间跑批并存时的资源分配明白这三种含义之后你再去看那些“AIX 调度出问题”的报障基本一眼就能判断对方说的是哪一种作业没跑是第一种跑起来把机器拖死了是第二种多个业务互相抢资源没个规矩是第三种。下面我按这个顺序逐一展开。2. 作业级调度cron、at、nohup 的工程化用法AIX 上最基础的调度手段和 Linux 相似但细节差异非常大。我见过太多直接从 Linux 拷过去跑不通的脚本问题大多出在环境变量、路径和 AIX 特有命令上。2.1 crontab 的冷知识权限控制与文件路径AIX 的 crontab 命令用法大致如下# 编辑当前用户的定时任务 crontab -e # 列出当前用户的所有定时任务 crontab -l # 从文件导入定时任务 crontab /tmp/my_cron.conf # 删除当前用户的定时任务 crontab -r真正容易出问题的往往不是命令本身而是权限和路径。AIX 通过/var/adm/cron/cron.allow和/var/adm/cron/cron.deny这两个文件控制哪些用户可以用 crontab。如果这两个文件都不存在AIX 默认只允许 root 使用 cron这一点恰好和某些 Linux 发行版相反。如果你新建了一个运维账号写完 crontab 之后发现没生效先别检查语法直接看一眼这两个文件在不在。另一个大坑是环境变量。cron 执行时的环境是极其精简的 PATH通常只有/usr/bin:/etc:/usr/sbin:/usr/ucb这几个目录你在交互 shell 里用的/opt/bin、/usr/local/bin里装的命令cron 里可能完全找不到。AIX 还有个特色很多命令不只是依赖 PATH还依赖库路径LIBPATH如果脚本里加载了自定义的动态库必须在脚本开头显式 export LIBPATH否则作业必挂。所以我给 AIX 写 cron 任务时有个习惯脚本第一屏就是环境变量声明#!/usr/bin/ksh export PATH/usr/bin:/etc:/usr/sbin:/usr/ucb:/opt/bin export LIBPATH/usr/lib:/opt/IBM/WebSphere/AppServer/lib export ORACLE_HOME/oracle/app/product/11.2.0 export TZAsia/Shanghai变量声明完再去写业务逻辑这样哪怕是 cron 这种精简环境也能稳定跑。2.2 at一次性延迟任务的隐形王者cron 管周期任务at 则管“某时某刻只跑一次”的任务。AIX 上 at 的用法和 Linux 差异不大但工程上有一个容易被忽略的点AIX 的 atd 守护进程默认可能没有启动。如果你敲了 at 命令之后任务迟迟不执行先检查 atd# 查看 atd 是否在运行 ps -ef | grep atd # 如果没起通过 mkitab 检查开机自启配置然后手动拉起 startsrc -s atd另外AIX 的 at 执行日志记录在/var/adm/cron/at.log任务是否真正执行、执行结果如何都要从这个日志里找线索。一个我常用的套路是前半夜先把后半夜要跑的一串作业用 at 排好每个作业之间留 5 到 10 分钟的缓冲这样一旦前一个作业延迟后一个不至于立刻并发冲上去。部分客户环境不允许随意改 cron这时候 at 就是最轻量的临时调度方案。2.3 nohup 与 AIX 特有守护进程管理很多人以为 nohup 就是“后台运行”的意思其实它的本质是“忽略挂断信号”。在 AIX 上交互会话退出时终端会向进程发送 SIGHUPnohup 恰恰屏蔽了这个信号所以进程能在会话结束后继续运行。AIX 上我通常还配合 setsid 的效果来讨论但 AIX 自带 setsid 命令并不如 Linux 那么常用。更多时候AIX 运维人员会使用系统自带的SRCSystem Resource Controller来管理长驻服务这才比 nohup 正规得多。比如我想把一个跑批程序注册成系统级服务# 把脚本注册进 SRC mkssys -s batch_svc -p /home/batch/bin/start.sh -u root -a -l /home/batch/log/start.log # 启动服务 startsrc -s batch_svc # 停止服务 stopsrc -s batch_svc # 查看服务状态 lssrc -s batch_svc我为什么建议用 SRC 而不是裸奔 nohup因为 SRC 会记录服务状态并且可以被smitty统一管理。生产环境一旦进程死了至少能通过lssrc快速看到服务不在运行状态写成监控脚本也简单清晰比去 grep 进程号可靠得多。3. CPU 与进程调度绑定、优先级、内核参数作业跑起来了接下来要考虑的是它跑得顺不顺会不会干扰其他关键进程这就进入 CPU 资源调度的战场。AIX 上这块的工具有 nice/renice、bindprocessor、schedo我逐个说。3.1 nice/renice给跑批作业“降噪”nice 值决定了进程的 CPU 调度优先级取值范围在 AIX 上是 20 到 60Linux 是 -20 到 19方向相反别记混了。在 AIX 上nice 值越高该进程占用 CPU 的优先级越低相当于“自动让路”。我处理过一个典型场景白天跑批作业偶尔会延迟到下午刚好撞上联机交易高峰。几个大数据量的报表作业一动交易响应时间立刻飙升。后来我在启动报表作业的脚本里统一加了 nice 限制# 以较高的 nice 值低优先级启动报表作业 nice -n 20 /home/batch/bin/report_runner.sh # 对已经启动的作业动态调低优先级 renice -n 40 -p 12345这样联机交易进程天然优先拿到 CPU报表跑批把资源“让”出去双方互不干扰。很多业务方并不知道是资源抢占导致交易慢单靠业务优化SQL往往收效甚微反而是这种调度层面的调整几分钟就能解决问题。3.2 bindprocessor把进程钉死在指定核上AIX 的 Power 服务器通常是多核架构运行 AIX 系统的 LPAR逻辑分区会看到一定数量的逻辑 CPU。默认情况下进程可以在所有逻辑 CPU 之间迁移有时迁移会引入缓存亲和性问题导致性能抖动。对于延迟极其敏感的交易进程可以考虑绑核。AIX 上绑核命令是bindprocessor# 查看当前机器上有哪些 CPU lsdev -Cc processor # 查看某个进程当前绑定在哪个 CPU bindprocessor -q 12345 # 把进程 12345 绑定到 CPU 4 上 bindprocessor 12345 4注意bindprocessor的第二个参数在 AIX 5.2 之前传的是逻辑 CPU 编号在 AIX 6.1 及以后可以传多个 CPU 编号。绑核之后进程就只会在指定 CPU 上运行避免“到处乱跑”。但我要提醒一句绑核是双刃剑。如果那个 CPU 上还有其他繁重作业绑核反而会让进程等待更久。所以我的建议是只对最关键、最需要性能稳定性的进程做绑核普通作业不要碰。绑核之后还要观察一段时间确认另一侧的 CPU 利用率没有异常升高再固化到脚本里。3.3 schedo内核级调度参数调优AIX 还提供schedo命令用来调整内核调度器参数类似于 Linux 的 sysctl。比较常用的几个参数# 查看所有调度器参数 schedo -a # 查看特定参数 schedo -o sched_runq # 调整参数示例真实值请按现场情况定 schedo -o sync_release1 -o busy_threshold64 -p参数含义大致如下参数说明经验值sched_runq多处理器运行队列模式1 表示各 CPU 独立队列0 表示全局队列通常保持默认 0sync_release同步释放控制锁等待进程的唤醒策略视业务而定busy_threshold空闲 CPU 判定阈值低于该值的 CPU 视为空闲可用于负载均衡常见值 64affinity_lim限制进程的 CPU 亲和性默认 7视绑定场景调整-p参数表示永久生效会写入内核参数库。调整前最好通过schedo -o 参数名原值记录下来方便回滚。这种级别的调优影响面是全局的建议先结合 topas/nmon 数据做充分评估再选择非交易窗口执行别在跑批期间直接动。4. WLM 工作负载管理器多业务共存时的资源调度利器前面说的 nice 和 bindprocessor 属于手工定点干预操作粒度是进程级。如果你管理的机器上同时跑着交易系统、报表系统、数据抽取作业且它们之间经常互相争抢资源那你需要的是 WLMWorkload Manager。这是 AIX 上最接近“真·调度”的机制比 Linux 上常见的 cgroup 要老牌得多业界落地也很成熟。4.1 WLM 解决什么问题简单类比WLM 相当于一台机器内部的“物业管理处”它允许你把 CPU 资源、内存资源在逻辑上划分成多个类然后为每个类设置资源份额或资源上限。跑批作业再猛也不能突破它所在类被允许使用的资源上限交易进程再忙也会保有自己类的最低资源保证。举个例子假设一台 16 核机器上同时跑三类业务联机交易白天核心需要不低于 60% CPU报表跑批量大但不紧急最多给 30% CPU后台管理维护日常维护操作有 10% 就够通过 WLM 把这些份额固定下来就能彻底避免“报表作业把机器打满交易响应变慢”的问题。4.2 配置步骤类、接口、规则三层结构AIX WLM 的配置不复杂但层级关系要理清“类”是资源分配单元“接口interface”负责对作业分类把进程或用户映射到某个类“规则rules”是映射条件比如用户名等于 oracle 就进入 oracle 类。先说最直观的配置路径WLM 的配置文件默认放在/etc/wlm/。你可以通过命令创建配置也可以直接通过smitty wlm进入菜单操作。命令行方式更容易做脚本化和版本控制以 AIX 6.1 及以上版本为例我习惯这样初始化# 初始化一个 WLM 配置 mkwlm -n mywlm # 进入交互式配置界面推荐 smitchclass如果你们现场不允许交互式操作也可以直接编写配置文件。下面是一个简化的示例把 CPU 资源按照份额比例分成三类# /etc/wlm/mywlm 配置片段 classes: ClassName Share CPU SystemDefault SHR 1 Trade SHR 10 Batch SHR 3上面的 SHR 代表份额。系统默认类是 1交易类是 10批处理类是 3。当 CPU 竞争激烈、机器满载时三类实际获得的 CPU 时间比例大约是 10:3:1份额越大、资源越多。当机器空闲时任何类可以用满全部 CPU没有浪费。接着要定义规则把用户或进程映射到类rules: Interface Type ClassName Value username user Trade oracle username user Batch batchusr这段配置的意思非常直白oracle 用户的进程全部进入 Trade 类batchusr 用户的进程全部进入 Batch 类。因为批量作业通常用专用账号启动按用户分流是最省事的做法如果是多个应用混在同一账号下就得考虑按进程名或参数匹配复杂度会上去一些。4.3 启用与验证配置写好后启用 WLM# 启用 WLM wlmcntrl -n mywlm # 查看当前 WLM 状态 wlmcntrl -q # 查看各类资源使用情况 lswlm我每次启用 WLM 之后都会先做一轮验证看交易类的 CPU 使用是否得到保障、批处理类是否被控制在预期比例内。最靠谱的方法是用topas按 WLM 类来观察# 进入 topas 后按 w按 WLM 类显示资源占用 topas -W再配合 nmon 记录历史数据确认前后对比。WLM 的调整是一步一步来的每次只动一个类的比重观察至少一个完整跑批周期别想一把调到位。坦白说WLM 的落地难度不在于配置本身而在于业务分类的策略设计。我见过不少团队配置了 WLM 却没效果原因就是把太多进程塞进了同一个类等于没分。WLM 见效的前提是你真的知道不同业务各自的资源权重和波峰波谷规律。5. 一次 AIX 跑批调度事故的完整复盘讲完工具来点实战复盘。上一份工作里我处理过一个很典型的“aix调度”类故障客户描述的原始症状只有一句话“每天凌晨跑批总是有一两个作业意外失败但重启一下又好了很随机。”5.1 初始排查日志与错误信息定位我先登录服务器按顺序做了四件事# 1. 看系统错误报告确认硬件层无异样 errpt -a # 2. 看 AIX 技术级别与维护补丁 oslevel -s # 3. 看系统当前负载 topas # 4. 查各作业的实际启动时间与退出码 cat /var/adm/cron/logerrpt 显示一切正常没有硬件报错说明不是链路或磁盘故障。topas 下来发现凌晨两点到三点的 CPU 使用率接近 100%负载相当高。cron 日志里则显示失败的作业启动时间完全正常但退出码五花八门。5.2 根因确认作业并发 资源上限继续往深处挖。我再检查了失败任务对应的程序日志发现这些程序几乎都在同一时刻尝试连接数据库并在极短时间内抛出了连接超时或锁等待超时。当时数据库端的告警也指向同一个方向凌晨某几个时间点会话并发数瞬间冲高。很明显这不是单一作业的代码问题而是多个 cron 作业在同一分钟集中触发把数据库连接池打满了。为什么“重启一下又好了”因为连接池的连接被逐个释放之后后续重跑的作业自然能连上数据库。这里面还叠加了一个更隐蔽的因素AIX 默认进程资源限制ulimit里max user processes的值在不少环境里是 2048。触发作业数量一多加上存在少量僵尸进程个别账号下进程数先触顶作业连 fork 子进程都做不了表现就是程序刚启动就异常退出。5.3 修复方案错峰调度 限额整顿修复分三个层面落地第一错峰。把所有 cron 作业的执行时间拉网式梳理了一遍按依赖关系分组每组之间至少错开 2 到 3 分钟启动尤其把大量并发 DB 操作的作业尽量分散。这个改动成本最低、见效最快直接解决了连接池峰值问题。第二调整资源限制。在/etc/security/limits里提高批处理账号的processes和nofiles限制。这一步要谨慎调太高也可能导致单账号失控一般按实际并发规模上浮 30% 到 50% 就行。第三统一作业封装。给所有 cron 作业套了一层通用启动脚本脚本里做三件事导出统一环境变量、自动记录开始和结束时间、失败时记录退出码并写错误标记。这样以后作业再失败也有统一的日志入口可以追溯不用再去翻散落各处的应用日志。5.4 这个坑给所有人的教训复盘完我在内部文档里写了一条总结AIX 上的“调度故障”十有八九不是调度器本身的故障而是“同时发生的事件太多”或“单个事件占用的资源超出预期”。排查的时候不要一上来就怀疑系统调度机制先看看时间线、资源水位、数据库并发这三个维度往往能覆盖绝大多数问题。6. 那些年我踩过的 AIX 调度细节坑最后分享几个比较小众但确实影响生产的小坑都属于平时没人提醒、出事现场才想起来的那种。每一个都是我实际遇到过的。6.1 时区变量 TZ 与 cron 的诡异配合AIX 的 cron 读的是/etc/environment里的 TZ 变量。如果你的用户 profile 里配置的时区跟系统环境的时区不一致那么 cron 的日志时间和你命令行的当前时间可能对不上。更麻烦的是如果系统时间做了手工调整或通过 NTP 做了跳跃式校时正在排队的 at 任务可能出现提前执行或延迟执行。我的建议是在跑批账号的.profile和每套作业脚本里显式声明 TZ同时检查 NTP 同步配置尽量不要让系统时间发生大的跳跃。时间同步用xntpd守护进程管理的环境要特别注意/etc/ntp.conf里的 drift 文件权限问题权限不对会让 NTP 校时异常影响面远比想象中大。6.2 cron 表漂移问题的灾备教训有一年做灾备切换演练业务团队发现切换后批量作业的时间点全乱了追查下来发现是灾备机的/var/spool/cron/crontabs/root文件还是一个月前的版本。平时没人同步 cron 表演练时直接暴露了。这种事情真到生产就麻烦大了。后来我在脚本里加了一条定时任务每天晚上把主机的 crontab 文件备份到灾备机# 示例主机上每天凌晨 1 点把 root 的 crontab 推到灾备机 0 1 * * * /usr/bin/scp /var/spool/cron/crontabs/root backup_srv:/var/spool/cron/crontabs/root当然推送完之后还要在灾备机上执行一次crontab -u root /var/spool/cron/crontabs/root让它生效否则文件覆盖了但 cron 没读也没用。6.3 ulimit 与数据库连接参数的联动最后讲一个容易被忽略的细节。AIX 的/etc/security/limits里可以设置每个用户的最大文件数、最大进程数、最大核心转储文件大小。但很多数据库安装时DBA 只注重数据库实例内部的参数不会在意操作系统层限制。结果就是批处理作业并发一大数据库进程打开的文件句柄数轻松破几千一旦碰到 AIX 默认限制数据库端就开始报“无法打开文件”或“无法创建新进程”。这种问题看着像数据库故障本质是 AIX 资源上限不够。排查技巧也不难遇到奇怪的“无法 fork”或“Too many open files”报错先ulimit -a看一遍当前限制八成能找到线索。7. 一些实操结束后再补充的经验其实聊了这么多真正想强调的是AIX 的调度体系并不神秘它的核心思想就是“一切皆资源、一切可管控”。cron 负责时间维度WLM 负责份额维度bindprocessor 负责核维度几个维度组合起来就能覆盖绝大多数生产场景。我自己在实际操作中的体会是不要等到故障发生了才去研究调度最好在系统上线初期就把作业列表、资源需求、执行时段全部梳理成一张表。这张表不仅服务于跑批设计将来做性能调优、灾备规划、容量评估时都会反复用到。很多团队没有这张表出了问题才开始临时梳理效率低且容易漏项。最后再分享一个小技巧如果你接手了一套存量 AIX 环境对调度情况一无所知先跑这几个命令把家底摸清楚# 看所有用户的 cron 任务 for u in $(ls /var/spool/cron/crontabs); do echo $u ; crontab -l $u; done # 看当前系统进程数最高的用户 ps -ef | awk {print $1} | sort | uniq -c | sort -nr | head # 启用 nmon 记录性能数据留作后续分析 nmon -f -s 30 -c 2880把这三条命令的输出保存起来很多“随机故障”的规律就藏在里面。调度的本质不是把任务塞进时间表而是让每一份资源在最正确的时间、给最需要的任务这一点放在 AIX 上如此放在任何系统上也一样。希望这篇基于真实经验的记录能让你下一次面对“aix调度”这个词时少一点慌乱多一点清晰的排查思路。