说实话Shell脚本这东西入门容易写得好难写得又快又稳更难。我见过太多脚本功能没问题跑起来却要人命——明明就处理几百个文件硬生生磨叽了几分钟日志文件就几十MB循环里反复grep反复cat直接把服务器IO拖垮。这一章的标题是Shell脚本性能优化减少循环次数、避免无效IO刚好切中了我这些年写脚本踩坑最多的两个方向。所以我打算用一整篇的篇幅把循环和IO这两个性能杀手彻底讲透包含实际案例、优化前后对比、以及一套可以迁移到任何脚本的排查套路。适合谁看运维、后端、以及所有需要维护Shell脚本的人。就算你刚入门把这篇啃下来也能少走不少弯路。1. 先搞清楚Shell脚本到底慢在哪1.1 循环的隐藏成本每次迭代都是一次进程fork很多人对Shell脚本的性能有误解觉得脚本慢是因为解释执行或者语法啰嗦。其实Shell本身的语法执行非常快真正的瓶颈藏在一个容易被忽略的地方每执行一次外部命令都要fork出一个子进程。你在命令行敲一个grepShell会调用forkexec创建一个新进程去跑/usr/bin/grep。这在一个命令上一次没感觉但如果放在循环里跑一万次就是一万次进程创建和销毁这个开销远比命令本身的计算量要大。我做个简单的类比命令就像一个快递员fork就是你让快递员从公司门口出发去送一件货然后回来再领下一件。每件货本身跑腿时间也许就几秒但来回公司的通勤时间可能占据大半。循环里每u一次外部命令就是一次通勤。所以有个经验法则循环里能少调外部命令就少调能用内建命令就用内建命令。比如字符串截取、正则匹配判断、算术运算这些用Shell内建能力就能完成完全不用启动子进程。下面的对比能直观体现差距# 慢每轮循环fork一次外部命令总计1000次 sum0 for i in $(seq 1 1000); do sum$(expr $sum $i) done # 快全程使用Shell内建的算术运算不fork任何进程 sum0 for i in $(seq 1 1000); do ((sum i)) doneexpr是外部命令每跑一次就是一个新进程((...))是Bash内建语法直接在当前Shell里求值。我实测过前者跑到200轮的耗时后者跑满10000轮都追不上。可能你会觉得差个几十毫秒无所谓但把这个模式套用到100万行日志的处理流程里差距就是秒级和分钟级的差别了。1.2 无效IO的典型场景重复读写与无谓的磁盘访问循环fork是CPU层面的开销IO问题则是磁盘和管道层面的开销。同样一个常见错误# 反面教材每轮循环都打开同一个文件反复读取、反复grep for ip in $(cat ip_list.txt); do if grep -q $ip /var/log/access.log; then echo $ip result.txt fi done这段代码做了三件事循环体里grep读取access.log、每次命中后echo追加写入result.txt每轮循环都重复一个打开文件-扫描-关闭文件的过程。如果access.log有100MB循环10000次就是读取这个文件10000遍总读取量1TB。就算磁盘再快也扛不住这种写法。我自己就见过生产环境里的真实事故——一个日志统计脚本因为把大文件放进循环里反复grep直接把服务器IO打到100%整台机器的业务响应全部跟着遭殃。所以这章我把循环和IO放在一起讲就是因为大部分Shell脚本的性能问题都是这两件事叠加出来的循环让进程数爆炸IO让磁盘读取量爆炸两个一碰脚本就彻底失控了。2. 减少循环次数思路是批量处理和一次遍历2.1 awk是循环天然降维打击者一次遍历完成统计、过滤、转换提到减少循环很多人的第一反应是把for循环改成while循环。方向没错但治标不治本。真正有效的思路是让程序用一次遍历完成原本需要很多次遍历才能完成的事。awk就是干这个的绝佳工具它本身就是一个隐式循环遍历文件的每一行而且全程在一个进程内完成既不fork子进程也不反复开文件。举个例子我需要统计/var/log/nginx/access.log里每个状态码200、404、500等出现的次数。常规Shell写法# 常规循环每条访问记录都要执行一次awk/grep/sort大日志下跑得很痛苦 for code in 200 404 500 502; do count$(grep -o HTTP/1.1\ $code /var/log/nginx/access.log | wc -l) echo $code $count done这个写法的问题很明显第一for code in 200 404 500 502四次遍历整个文件第二每次grep都会创建子进程。换成awk一次遍历awk {match($0, / ([0-9]{3}) /, a); if (a[1] ! ) count[a[1]]} END {for (c in count) print c, count[c]} /var/log/nginx/access.log整个日志只读一遍所有状态码的统计结果在awk内部用关联数组累积最后在END块统一输出。对100万行日志来说这就是4次全文件扫描变成1次全文件扫描、N个外部命令变成1个外部命令的差别性能提升通常在10倍以上。我并不是让你把所有脚本都改成awk——那样可读性会很差。我跟你分享一般性原则如果要对文本进行逐行统计、过滤、汇总类操作优先考虑awk如果只是做简单的字段提取优先考虑cut和sed只有逻辑非常复杂、或者需要调用其他命令时才考虑用Shell循环逐行处理。这是经验判断不是硬性规定。2.2 xargs批量传参一次命令调用处理一整批数据循环的另一个典型场景对一批文件或一批参数执行同一个命令。很多人会写成# 慢每处理一个文件就要启动一次md5sum进程 find ./data -type f | while read f; do md5sum $f done这个写法不如直接find ./data -type f -print0 | xargs -0 -n 10 md5sum-print0和-0是为了处理文件名里的空格和特殊字符-n 10表示每10个文件作为一批传参。这样md5sum一次启动就能处理10个文件进程数量直接降为以前的十分之一。我实际在含2万个小文件的目录里测过前一种写法耗时约1分20秒后一种只用3秒性能提升超过20倍。xargs的价值在于它把多个参数合并成一批尽量减少进程启动次数。除了文件场景凡是那种循环体里只有一条命令只是参数不同的脚本都可以用xargs改写。这个改动本身很简单但收益立竿见影是性价比最高的优化手段之一。2.3 嵌套循环拍平用数组和关联数组替代多重遍历循环还有一种容易踩的坑是嵌套循环。比如遍历100个用户每个用户检查100个文件这就要循环10000次。嵌套循环的复杂度是乘法的每层加一个循环体总次数指数增长。我见过一个清理临时文件的脚本三层循环嵌套实际跑了半个多小时最后换成数组批量处理后几十秒就结束了。有个实用技巧如果外层循环的数据只是用来做查找那就把查找结果存到关联数组里。比如原本这样for user in $user_list; do for file in $file_list; do if grep -q $user $file; then # do something fi done done改为先用awk或while读取一遍文件把需要匹配的信息存进关联数组declare -A user_map while IFS read -r line; do user_map[${line%%:*}]1 done /etc/passwd for user in $user_list; do if [[ -n ${user_map[$user]} ]]; then # do something fi done原本内层循环一遍遍读取文件匹配用户现在变成读一次文件建一次索引后续查用户直接内存里查快了好几个数量级。这个思路和数据库建索引是一个道理本质都是用空间换时间。3. 避免无效IO的关键把反复读写改成一次搞定3.1 循环外做重定向循环内不要追加写文件IO优化里最常见、也最容易改的一句代码就是把重定向从循环体里挪到循环体外。看这个反例# 慢每轮循环都打开一次文件write一次关闭一次 for f in *.txt; do echo 处理: $f process.log # 其他处理逻辑 done每轮循环执行一次 process.log就是一次openwriteclose的系统调用。10000轮就是10000次openclose。改成循环整体重定向# 快整个循环只打开和关闭一次文件 for f in *.txt; do echo 处理: $f # 其他处理逻辑 done process.log这个改动带来的提升在文件数量大时非常明显。因为open和close系统调用的开销比write数据本身还要大得多。你想一下现实中的场景包好一个文件要反复开关10000次抽屉和一次性把抽屉打开写完再关上的区别。注意一个重点done process.log会覆盖文件如果你不想覆盖而是追加就写done process.log效果同样一次性打开。另外如果你需要在循环里保留一部分输出到屏幕、另一部分写入文件可以用tee或者文件描述符重定向到不同目标而不是在循环体里频繁追加。3.2 把文件读进内存再处理避免反复读同一个大文件循环里反复读取同一个大文件是我这几年见过最普遍也最致命的性能问题。前文中grep循环读大日志的例子就是典型。还有一个常见场景是在循环里用cat file | head -n 1取某一行以为只取一行开销小但文件是从头到尾扫描的文件越大越吃亏。正确的做法是一次性把文件读入变量然后基于内存数据做处理。比如读取/etc/hosts并逐行格式化输出# 差每一行都重新cat一次文件 while read -r line; do current$(cat /etc/hosts | head -n $count) # 错误示范 # do something done /etc/hosts正经写法直接用read读取就行根本不需要cat。或者需要把整个文件当作一个变量传递可以这样content$( /etc/hosts) # Bash内置的文件读取方式不开cat子进程$( file)是Bash的内建功能直接读取文件内容到变量不启动子进程比$(cat file)更高效。这在处理中小型配置文件时特别适用。大文件不要这么干会撑爆内存但几百KB级别的配置完全没问题。3.3 合并多次等效查询一次grep/awk拿到所有结果还有一种无效IO是多次查询同一文件、但过滤条件不同。比如我要知道日志里有多少条错误、多少条警告、多少条普通访问errors$(grep -c ERROR app.log) warns$(grep -c WARN app.log) infos$(grep -c INFO app.log)这个写法把app.log从头到尾读了3遍。如果文件有500MB就是1.5GB的读取量。改成一次遍历分别统计awk tolower($0) ~ /error/ {e} tolower($0) ~ /warn/ {w} tolower($0) ~ /info/ {i} END {print errors e, warns w, infos i} app.logawk只扫描文件一遍三种分类在同一个循环里各自计数。这个模式的优势在文件大、分类多时更加明显——从N次全文件扫描变成1次扫描优化效果和文件大小成正比。4. 实操案例从优化前到优化后完整对比4.1 日志统计脚本从487秒到3秒这是我在生产环境里真实遇到过的案例脚本的需求很简单统计某个应用日志中各级别日志的数量并找出最近1小时内的错误信息。优化前的原始脚本长这样#!/bin/bash logfile/var/log/app/app.log errors0 warns0 infos0 for level in ERROR WARN INFO; do count$(grep -c $level $logfile) if [[ $level ERROR ]]; then errors$count; fi if [[ $level WARN ]]; then warns$count; fi if [[ $level INFO ]]; then infos$count; fi done grep $(date -d 1 hour ago %Y-%m-%d %H) $logfile | grep ERROR recent_errors.txt这个脚本在我测试机上跑一份800MB的日志耗时487秒约8分钟。问题一目了然三次grep -c扫描全文件然后又用grepgrep再一次扫描了近1小时日志的子集。优化后#!/bin/bash logfile/var/log/app/app.log awk $0 ~ /ERROR/ {errors} $0 ~ /WARN/ {warns} $0 ~ /INFO/ {infos} END {print errors errors, warns warns, infos infos} $logfile awk -v since$(date -d 1 hour ago %Y-%m-%d %H) $0 since $0 ~ /ERROR/ {print} $logfile recent_errors.txt同样一份日志耗时3秒。核心变化文件扫描次数从累计4次降到2次外部命令从多次降到2次awk。前后对比性能差距超过160倍。我后来总结这类统计类脚本的优化思路就两句话能一次遍历解决的绝不多次遍历能在一个进程内算完的绝不多进程协作完成。4.2 批量重命名文件从逐条mv改为一条命令还有一个我经常用到的优化场景批量重命名一批文件比如把当前目录下所有.log扩展名改成.txt。常见写法for f in *.log; do mv $f ${f%.log}.txt done文件少没问题但如果目录里有5000个文件这个循环就要执行5000次mv也就是5000次进程创建。Linux的rename命令可以一条命令批量完成rename s/\.log$/.txt/ *.log这个命令一次性接收所有文件列表在perl内部完成替换和重命名完全不启动子进程。我在一次清理日志的批量操作中5000个文件的场景下for循环耗时11秒rename命令耗时0.2秒——55倍差距。你可能觉得rename的语法有点陌生它用的是perl正则但值得花10分钟学习。它是那种学一次受用一辈子的命令任何需要批量重命名的场景都能用得上。如果实在不想用renamexargs -n 50 mv把参数分批传也是可行的替代方案但启动进程数还是比rename多不少。4.3 读取配置文件while循环里的sed/cut替代配置文件读取也是Shell脚本里逃不开的场景。常见的配置文件格式是这样的[server] ip192.168.1.10 port8080 timeout30常规读取某个key的写法server_ip$(grep ^ip config.ini | cut -d -f2) server_port$(grep ^port config.ini | cut -d -f2) timeout$(grep ^timeout config.ini | cut -d -f2)三个key就得读三次文件。如果config.ini本身就是几百KB这种重复读取就是不小的开销。更合理的方式是读一次把所有配置存到关联数组declare -A config while IFS read -r key value; do if [[ -n $key $key ! \[* ]]; then config[$key]$value fi done config.ini echo server_ip${config[ip]} echo server_port${config[port]} echo timeout${config[timeout]}这里用while read加Shell内建字符串判断读取一行不启动任何外部命令。整个配置文件只读一遍后续全部是内存中的哈希查找。这个写法的前提是配置文件格式规整每行keyvalue如果你的配置格式更复杂可能需要结合awk来做首遍解析。但思路是一样的——一次加载多处使用。4.4 批量数据库操作合并多条SQL为一次提交Shell脚本经常配合MySQL等数据库做一些日常运维操作。最常见的低效写法是循环里逐条执行SQLwhile read -r user; do mysql -u root -e UPDATE users SET status1 WHERE name$user; done user_list.txt每执行一条SQL就创建一个mysql客户端进程并和数据库建立一次完整连接。1000个用户就是1000次连接。优化方式有两种一种是把SQL拼成批量语句一次性执行sql$(sed s/.*/UPDATE users SET status1 WHERE name;/ user_list.txt) mysql -u root -e $sql另一种是使用MySQL的LOAD DATA或事务批量接口。后一种尤其适合大数据量的导入场景。核心逻辑没有变与其1000次连接数据库做小事务不如一次性把活干完。这个思想跟前面说的xargs批处理完全一致只不过把减少进程创建延伸到了减少网络连接建立。5. 定位性能瓶颈的工具与方法5.1 time和TIMEFORMAT先量化再优化性能优化第一步不是改代码是量化当前慢在哪。Bash内置的time命令能告诉你一个脚本总体到底花了多少时间time ./slow_script.sh如果只想统计某一段可以用date %s%N打点。注意Bash的time支持设置格式显示用户态/内核态耗时TIMEFORMAT%R秒 用户态%U秒 内核态%S秒 占用CPU%P%% time ./slow_script.sh用户态时间高说明脚本主要在计算和命令调用上内核态时间高说明大量时间花在打开文件、读取文件、写入文件这类系统调用上。这是一个很粗略但有效的定位方向内核态占比高优先查IO问题用户态占比高优先查循环和进程创建问题。5.2 bash -x和set -x追踪每一条命令的执行路径定位脚本慢在哪一条命令最简单的办法是用bash -x启动脚本或者脚本里加set -x。它会把每一条执行的命令和变量展开后的结果打印到标准错误bash -x ./slow_script.sh # 或者 #!/bin/bash set -x # ... 脚本内容虽然它不直接告诉你耗时但你能看到脚本实际执行了哪些命令、每个变量的值是什么。比如你发现某个grep命令被循环执行了10000次这就是性能问题的直接证据。bash -x还有一个好处能暴露出脚本里隐性的子进程调用——如果某一行命令频繁出现且每次都是新的进程ID那基本可以断定是循环fork的问题。5.3 strace直接看系统调用数量如果bash -x看不出明显问题但脚本就是慢strace是下一步的利器。它会把进程的所有系统调用打印出来strace -c ./slow_script.sh-c参数会统计每个系统调用的次数和耗时占比。如果看到openat、read、close出现次数异常庞大说明IO系统调用过多。我曾用strace定位过一个诡异问题一个看起来正常的while循环脚本每次迭代都重启一次ssh连接原因是一条隐藏的ssh命令每次循环都被执行strace里connect系统调用数量直接暴露了真相。我不建议你每次优化都上strace但当你揪不出性能瓶颈时它是一个非常可靠的兜底武器。系统调用层面的数据不会撒谎。5.4 shellcheck在跑之前就发现低级性能问题最后推荐一个静态检查工具shellcheck虽然它更侧重正确性检查但也能发现一些明显的性能问题比如循环里用了cat、$(cat file)、没有引用的变量、没必要的grep等。安装通常一条命令# Ubuntu/Debian sudo apt install shellcheck # CentOS/RHEL sudo yum install epel-release sudo yum install shellcheck使用也简单shellcheck myscript.sh它不会帮你优化但会指出可疑的写法比如你在循环里使用了cat建议改用read之类的提示。我的习惯是写完脚本先跑一遍shellcheck把明显的坑扫掉再考虑具体的性能优化。毕竟有些错误模式比如变量没加引号导致的通配符扩展不仅慢还会引发脚本行为异常。6. 优化之后的深度思考何时优化、何时放弃优化6.1 性能优化的优先级先改算法再改语言Shell脚本性能优化有一个常见的误区——过于纠结细节而忽略了整体方案。比如循环里用[[替代[、用$(())替代expr这些微优化确实有效但提升比例有限。真正决定性能量级的是算法和方案本身是扫描一次文件还是扫描十次文件是启动100个进程还是启动1个进程这个差距是数量级的。所以我通常会建议按这个顺序来优化脚本先看看能不能不写Shell脚本。如果任务本身就是大量文本处理用awk/perl/python会天然高效得多Shell更多承担胶水作用。再减少命令执行次数。能一次处理的不要循环能批量传参的不要逐个执行。然后减少文件读取次数。能读一次存内存绝不读N次。最后才是细节微优化。内建命令替代外部命令、合理使用引号、避免无用的管道等。不要一上来就纠结用$()还是反引号、用[还是[[——这些优化可能在正确的思路面前毫无意义。6.2 可读性和性能之间的平衡点写优化后的Shell脚本最大的风险是代码可读性变差。用awk处理复杂逻辑时满屏的正则和条件语句下一个人接手可能完全看不懂。我自己的经验是在关键复杂代码块上方写好注释解释这段代码的意图而不是解释每一行的语法。比如你看到这样一行awk {a[$1]$2} END {for (k in a) print k, a[k]} data.txt如果没有注释新人可能要懵半天。但如果上面写一行按第一列分组累加第二列一次扫描输出汇总整个代码的意图就清楚了。优化不是让代码看起来更炫技而是让代码在保持性能的前提下尽量可维护。6.3 极端情况下的应急方案用别的语言重写如果一个脚本已经被循环、IO、字符串处理等问题折磨得面目全非且无论怎么优化都达不到要求就要有果断重写的勇气。这不是说Shell不行而是用Shell的短板硬刚问题本身就是一种低效。文本处理、复杂数据结构、需要频繁IO操作的任务Python、Perl、Go往往比Shell更合适。Shell的定位是系统管理和任务编排的胶水当胶水文化变成了胶水负担就得换方案。我在工作中就干过这种事一个数据同步脚本用Shell写了200多行运行要40分钟后来用Python重写成100行耗时3分钟。重量级任务的性能天花板还是由实现语言决定的。Shell适合快速解决问题但如果问题本身是长期频繁运行的尽早评估换语言比在Shell里反复调优更划算。6.4 我的最终建议性能优化也需要预算最后说点掏心窝的话。Shell脚本的性能优化是有收益递减规律的。对于一个每天跑一次的维护脚本优化10秒可能意义不大但对于一个每5分钟跑一次的监控脚本优化10秒就是巨大的收益。所以做优化前先明确脚本的预算它有多少执行频率它处理的数据量有多大它对响应时间的要求有多高我的个人经验是高频、大数据量的脚本值得花时间认真优化甚至值得考虑用更合适的语言低频、小数据量的脚本只要符合直观的写法、逻辑清晰就不必为了优化而优化。毕竟Shell脚本的第一价值是用最少的代码快速解决问题如果为了优化把脚本搞得比业务逻辑还复杂那就本末倒置了。这一章的内容基本覆盖了循环和IO优化的大部分常见场景。你在实际工作中遇到Shell脚本性能问题按照先量化、再定位、后优化这个顺序走通常都能找到有效的突破口。我花了很长时间把这些经验和教训整理出来核心还是希望你能少踩一些我踩过的坑。下次你自己写Shell脚本的时候不妨多问一句这个循环是不是真的有必要这个文件是不是真的需要读这么多次多问这两句性能问题往往就已经解决了一半。