Tag Archives: Unix

Unix 系统里几个尽量不要运行的命令

日复一日的 Unix/GNU Linux 使用过程中,或许总有一些命令让你感觉肝颤,看看如下几个命令是不是让你很烦?

fsck — file system consistency check

如果有可能,不要手工运行 fsck 命令。关于人为调用 fsck “修复” 系统而引起更大灾难的实例已经有很多了。

Unix 的 rm 命令问题

rm 命令可能是最容易给 Unix 使用者带来麻烦的一个命令,但我想这个命令带来的问题几率可能并不如 fsck 那么高。所以放到第二位。另请请参考我以前写的 如何避免 Unix 环境中的 ‘rm -rf’ 灾难 这个帖子。

crontab -r — 不经提示删除了 cron 内容

这条命令我从来没用过,是网友留言提示的,看来他深受其苦,或许还有同病相怜的人。

source ~/.bash_history

The source command sends the contents of a text file to the Unix shell. 我相信如果有人运行了这样的命令,肯定是命令行自动补全惹得错 :)

或许还有很多命令是尽量不要运行的,话说回来,在 Unix 系统里面运行每个命令都需要谨慎。IBM dw 上这篇关于系统管理员的”懒惰”我倒是挺认同的,无为而治。

上面提到的 Unix ,包括 GNU/Linux,具体的 Shell 具体对待。

EOF
还有个老生常谈的提醒:不要在 root 用户下做日常操作。

此文作者:, 位于 Tech.Memo 分类 标签: , on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

Unix/Linux 的 Load 初级解释

几乎每个接触类 Unix 操作系统的工程师都知道如何查看系统负载。但这东西的工作机理到底是怎样的,可能没有多少能说清楚。对比了一些相关信息,加上自己的理解,做一下笔记。

什么是 Load ? 什么是 Load Average ?

Load 就是对计算机干活多少的度量(WikiPedia: the system load is a measure of the amount of work that a computer system is doing)。也有简单的说是进程队列的长度. Load Average 就是一段时间 (1 分钟、5分钟、15分钟) 内平均 Load 。【最好的参考文章:UNIX® Load Average Part 1: How It Works

下面是一个 uptime 命令输出:

$ uptime
18:57:48 up 423 days, 3:55, 2 users, load average: 1.16, 1.12, 1.20

尽管各种信息来源的定义都不太确定。能确定的一件事情是,你不能精确获取当前时间的 Load . 最小的计算粒度是 5 秒钟(CALC_LOAD 每 5HZ 计算一次, 5HZ 为 5秒钟,这里的 HZ 是系统定义的变量). 参见 Linux Kernel 这段代码:

 869        count -= ticks;
870        if (unlikely(count < 0)) {
871                active_tasks = count_active_tasks();
872                do {
873                        CALC_LOAD(avenrun[0], EXP_1, active_tasks); 
874 CALC_LOAD(avenrun[1], EXP_5, active_tasks);
875 CALC_LOAD(avenrun[2], EXP_15, active_tasks);
876 count += LOAD_FREQ; 877 } while (count < 0); 878 } 879}

如何判断系统是否已经 Over Load ?

对一般的系统来说,根据 CPU 数量去判断,如上面的例子, 如果平均负载始终在 1.2 以下,而你是 2 颗 CPU 的机器。那么基本不会出现 CPU 不够用的情况。也就是 Load 平均要小于 CPU 的数量。

这是 Solaris 性能与工具(Solaris Performance Tools ) 一书推荐的评估方法。【在这里要推荐一下这本书,尽管在 Load 这个地方没有达到我期望的那么细致。但全书揭示了非常多的性能信息。每个 DBA、架构师 的必须书。】

这么说实际上带来另外两个疑问:

1 如果是多核 CPU / 超线程的机器怎么判断? 对这样的机器,我的建议是看操作系统怎么识别的 CPU,根据系统识别出来的逻辑 CPU 数量来判断。如果要考虑性能系数,建议参考一下 Oracle 针对不同架构下多核 CPU 的收费标准。

2 如果应用是面向线程的怎么判断? 这实际上和 M:N 线程模型有关。你的系统是怎样的? 把这个问题考虑进去即可了。

多数情况下,Load 过高都未必和 CPU 有关。或许倒是有一个例外的,就是应用场景的问题。比如用单 CPU 的机器去做高并发 Web 服务器,麻烦就来了

Load 与容量规划(Capacity Planning)

任何一个相对成熟的站点都会利用 Cacti(基于RRDTool) 等工具进行容量规划工作。抓取的 Load 会传 1、5、15 分钟列值过去,这三个度量采用哪个呢? 15 分钟为首选【参见Gunther 的 PPT】。

Load 与系统预警

很多对可用性要求比较高的环境都建立了 邮件或SMS 报警机制。关于 Load 报警阈值的制定也有看到不太合理的时候。这里建议 Critical 值(如果用 Nagios 之类的工具你明白这是什么)上限为 物理 CPU 的个数(当然你可以设置比这个低)。但比这个值高的话,意义就不大了。比如,数据库服务器有 4 颗 CPU,那么 Load 高于 4 就应该报警出来,设置比 4 高可能意义不大,因为接到报警还有个人为响应时间...

误解 一:系统 Load 高一定是性能有问题。

真相:系统 Load 高也或许是因为在进行 CPU 密集型的计算(比如编译)

误解 二:系统 Load 高一定是 CPU 能力问题或数量不够。

真相:Load 高只是代表需要运行的队列累积过多了。但队列中的任务实际可能是耗 CPU的,也可能是耗 I/O 乃至其它因素的。

误解 三:系统长期 Load 高,首选增加 CPU。

真相:Load 只是表象,不是实质。增加 CPU 个别时候会临时看到系统 Load 下降,但治标不治本。

小小一个 Load 讲究其实不少。英文信息其实比较全的,尽量保证加入一点新信息到这篇文章里。入看到有写的不合理的地方或者有异议,请指正或告知。

--EOF--

FAQ 1:数据库服务器突然 CPU 100% 繁忙,咋办?

A :一般情况下,这是由糟糕的 SQL 引起。建议抓取 Slow Query Log ,针对 I/O 开销比较大(重点看全表扫描)的 SQL 进行优化。根据经验值,每个 CPU Core 一秒钟能处理 100-400MB 数据量。如果是大量的并发 I/O 操作,尽管存储的吞吐可能还没那么大,也可能会把 CPU "塞满"。

感慨 SCO 的没落

logo-bgblue.gif

这个圣诞对 SCO (Santa Cruz Operation)公司高层来说肯定不轻松,Nasdaq 通知信确认 SCO 将从12月27日被摘牌,这是一场终于到来的噩梦。IBM、红帽子、Novell 肯定会对这事儿拍手称快!

当年 Linux 风头正健的时候 SCO 居然下嫁给 Caldera ,无数人惊呼,”Unix 已死,Linux 当道”,真实情况却并不是这样。没多久,Caldera 就发现 Linux 在市场实在不受待见,用户也不买 “Caldera” 这个名字的账,结果 2002 年又更名回 SCO。当时还拉了一堆虾兵蟹将搞 “统一 Linux” (United Linux) ,也是属于“十八路诸侯讨董卓”的路数,没过多久就瓦解了。SCO Unix 在市场上属于找不到北的那种的,基本上比 Novell 还没感觉。

SCO 这几年混的也太臭,简直一副无赖嘴脸,仗着自己”有” UNIX System V 的代码版权,对 IBM 的 10 亿美金诉讼赔偿简直是”碰瓷”行径,只不过 IBM 也不是善茬儿,陪你玩到底;SCO 还不甘心,干脆把大家都拉进来,四面数敌,到处勒索,结果光是诉讼就搞得满头是包。最富有戏剧性的是今年 8 月份,一纸裁决下来,宣判 UNIX 与 UnixWare 属于 Novell 的,这对 SCO 简直是釜底抽薪,只有缴枪的份儿了。

想当年,在国内, SCO 占据了国内 Unix 绝大部分市场,那时候 SCO Unix 相关的图书也是卖到洛阳纸贵。中软和东方龙马是相当大的两个分销商,而这两个公司也走出了国内无数的 Unix 技术人才(这两个公司的发展状况和 SCO 倒是也有几分相似之处)。前几天和一位中软前同事吃饭,谈及此事,仍是不胜唏嘘。我刚毕业的时候,在中软的一家子公司工作,一部分业务就是操作系统分销,当时就感觉这玩意儿有点过时,但是国内很多单位(比如邮政)对 SCO Unix (主要是 Open Server)依赖性还是很大,我算是赶上了末班车,说起来,对 SCO 也算是有很深的感情啊。

市场是残酷的,时间也是残酷的。SCO 快死掉了,多少年后我也会怀念 OpenServer、Unixware 这些产品。

EOF
EOF

如何避免 Unix 环境中的 ‘rm -f’ 灾难

在 ITPub 论坛上,最近有朋友发起了一个”请列出你在从事DBA生涯中,最难以忘怀的一次误操作“话题讨论,如果有足够的耐心看下去的话,会发现很多误操作都是类似的,最上镜的就是这个操作系统级别的 “rm -f” / “rm -rf” 了。

在那本著名的 Unix 痛恨者手册 上,rm 问题也作为一个罪状而提出。的确,Unix/Linux 的这个 rm 的 -f 参数是系统管理员(SA)乃至数据库管理员(DBA)最容易引发系统灾难的导火索。

如何避免这样的灾难发生呢?

如果一个人能不犯任何误操作就好了。但这是不可能的。我相信肯定有很多 DBA 或 SA 到现在也没烦过这样的错误,但不要忘了墨菲定律的诅咒。

1.有安全的 rm 命令麽?

一种比较理想的是如果编译源代码的时候把这个 -f 选项去掉,肯定能让不少人少犯错误。不过搜索了整个网络,好像还真没有具体如何操作的。Sun 的 Solaris 10 对 rm 作了一点改进处理,”rm -rf /” 是不允许的。可惜的是 “rm -rf *”类似的操作是没限制的。另外,对于其他系统也不可用。或许,将来 GNU/Linux 能有改进。

2.Alias 方式

第二个方式是在 Profile 层次上设置命令别名( alias ).

alias rm="rm -i"

这也是最常用的方式。如果脚本上直接调用了 rm 命令的全路径,还是不管用的。这其实也是如果功能上没办法完全禁止,那就提高用户的使用成本 :)

3.替代命令

第三个方法是使用替代命令。如用一个 del 命令来替代 rm. 这个就要挑战用户的使用习惯了。真的会始终用替代命令麽? 这个方式需要注意的是,无论如何不要真的把 rm 命令挪走(比如物理的 rename 名字),如果这样,是很糟糕的策略。

4.修改权限

也有不少人直接把 rm 的权限修改,比如只允许 root 用户而不允许普通用户执行命令。这在调用一些脚本或者编译文件的时候,很容易引来很多麻烦。

任何一种策略,如果要扩大应用到一个团队的话,还需要考虑使用习惯对其他成员带来的影响。毕竟,”不爽”也会让很多人更容易犯错。

最后,友情提示,有的人经常通过层层跳板 Login 到主机上,可能会因为忘记了”身在何处” 而犯错误,最管用的方式是设置一下 PS1 环境变量。比如我在 Dreamhost 上用这样的:

PS1="\n\e[1;37m[\e[m\e[1;32m\u\e[m\e[1;33m@\e[m\e[1;35m\h\e[m \e[4m\`pwd\`\e[m\e[1;37m]\e[m\e[1;36m\n\e[m\\$ "

EOF