Linux 下的 df 命令以及其他

手边有 AIX 以及 Linux 环境，df 算是我用的频率较高的系统命令了。这个小小的命令在不同的环境中差别还是很大的。比如 “-v” 这个参数，在 AIX 上可以配合 -k -m -g 等参数显示可读性更强的信息, Linux 上只是为了兼容 System V 的 df 命令而保留 “-v”。在 Linux 上类似的命令是 “-B” ，可以接 k 、m、g 等. 如 df -Bg 按照 GB 显示。如果同时维护这样的混合环境，在命令的使用上也要考虑“兼容性”。

以前介绍过 GNU 核心工具，不过没介绍那份有趣的 GNU Core Utilities FAQ，前两天又重新读了一遍。多少有点新内容。比如那个比较经典的问题，“Linux 下 df 与 du 显示的为什么不一样” (我自己就遇到过一次)，在 FAQ 上更新了很有权威性的线索: df and du report different information。

我这里补充一下的是，在比较大的文件系统上，保留给超级用户的数据块也可能会产生混淆。默认是 5%，如果文件系统比较大，这里的浪费还是比较惊人的，需要就实际情况作权衡。这个也会对 df 的显示有影响。如果创建文件系统的时候需要修改，用”-m”参数指定特定的百分数。

虽说差不多每天都在用 Unix ，但是总有无数知识盲点.

–EOF–

大脚(Footbig) 准备开放 API

Livid 总能搞些让人惊喜的 Web 应用。之前的备受好评的 V2EX 被阻尼后，新开发的大脚社区也赢得了不少朋友关注。今天早晨 Livid 给我演示了几张截图：大脚准备开放 API了。

查看截图：
1、界面展示
2、样例代码截图

目前 API 主要是针对先前大脚的便签本功能(?)。如果客户能够比较轻松的把便签内容集成到自己的站点或者 Blog 上，那么和 Livid 早前的个人数据中心的想法还是有些一致的。

本周应该就能看到这个服务了，Livid 还在继续提高程序的健壮性。至于性能，现在「普通的 1U PC-server，性能大概在 100RPS」。

更多的小道消息：现在每条便签可存储最多 50000 个 UTF8 字符，每个帐号可以存储最多 10000 条 note，「还计划让每条 Note 都支持带中文分词的 $nc->match() 及 Tagging」

有想法，能实现，这两条加在一起就非常难了，Livid 正在做…..非常有意思。~~算起来，大脚也是国内 Web 2.0 站点第二三个提供 API 服务的了(除了 Yupoo 和豆瓣，还有谁? Updated: Faint ,还有N多)。~~

–EOF–

Google 的计算能力仍是独步武林

从 Greg Linden 的文章看到的数据：Google 的 MapReduce 平均每天处理 20 Petabytes 的数据。每天能跑完 10 万个工作任务。光是 07 年 9 月，就用掉了 11081 个”机器年” ，跑了 220 万个 Mapreduce 任务。这个计算能力是惊人的。

Yahoo! 也用 Hadoop 实现了 Mapreduce , 我个人感觉和 Google 可能还有一段距离。光有计算环境还不行，还要有应用程序来实现功能，Google 已经实现了超过 1 万个应用程序，Yahoo! 有多少呢?

这方面估计微软更没戏了，要是弄个不包括 “Window” 的 Windows 服务器集群估计还能差不多，否则，光是一个视窗要耗费多少计算资源? 如果服务器规模是几万、几十万台，计算能力的浪费是惊人的。微软的对抗计划是 Dryad.

所以说啊，Google 的计算能力仍是独步武林，虽然有不服气的，但有什么办法? 这方面 Google 就是强啊

–EOF–
补充：
更多的数据(来源):

用 DBMS_STATS 构造 STATS 环境

保存表或者相关数据对象统计信息的历史数据是个不错的习惯。万一新的分析(ANALYZE 或者 DBMS_STATS) 过后发现统计信息有问题，急于恢复的时候又找不到备份，是个比较糟糕的事情。
虽然我在维护的过程中很少使用 DBMS_STATS 来收集数据对象统计信息，不过用这个工具来进行统计信息的管理还是很方便的。
首先建立资料库, DBMS_STATS 的具体语法暂且就跳过去了, 毕竟手册上写的更清楚)：

EXECUTE  DBMS_STATS.CREATE_STAT_TABLE ('SCOTT', 'STATTAB','SYSAUX');

在 SYSAUX 表空间上创建 STATTAB 用以存储统计信息, 所有者是 SCOTT 用户。

导出统计信息. (在任何可能更改表的统计信息的 DDL 操作之前, 一定要导出统计信息)

EXEC dbms_stats.EXPORT_SCHEMA_STATS
(ownname=>'scott',stattab=>'stattab',STATID=>'foo_20080107');

这里建议手动设定一下 STATID. STATID 命名规则建议用对象名(SCHEMA名)+ 时间(注意粒度).

至于导入整个 SCHEMA 的信息，一定要慎重再慎重。

在任何可能更改表的统计信息的 DDL 操作之前, 导出(备份)统计信息

EXEC dbms_stats.export_table_stats
(OWNNAME=>'scott',TABNAME=>'foo',STATTAB=>'stattab',STATID=>'foo_20080107');

恢复该表的统计信息(之前要导出当前的统计信息):

EXEC dbms_stats.import_table_stats
(OWNNAME=>'scott',TABNAME=>'foo',STATTAB=>'stattab',STATID=>'foo_20080107');

为了避免误导，需要说明的是，我只收集表和索引的统计信息。尽量不用 DBMS_STATS 收集统计信息，要问为什么? 去看看 DBMS_STATS 相关的 Bug 就知道了(比如飞龙说的这个问题)。只有在 ANALYZE 力有未逮之时才会考虑用 DBMS_STATS.

这里说的和 ADDM 无关，建议在熟知 ADDM 之前，最好别用这玩意儿。

–EOF–