前段时间公司内部的版本库服务器存储空间吃紧，必须增加外部存储设备或者更换服务器。于是我面临了痛苦的选择：那台联想万全 T200 服役了近 10 年。早在不经意之中，就摩擦出了爱情的火花。更换服务器，她就面临着退役，我不忍；增加外存，我担心她太累，又心疼。

于是另购了一块希捷的 250GB SCSI 硬盘，拆开机箱，连上数据线和电源线，可开机后提示找不到可以启动的系统。于是重启，回到 BIOS 选项，发现硬盘根本没有被认到。我首先想到的是跳线，但不肯定 SCSI 硬盘也有跳线这样的说法。

再一次拆开机箱，拆下硬盘，重新观察了一下，确实有跳线这个东西。具体接法见下图：

重新接好，设置从老硬盘启动，终于进入 FreeBSD。接着 sysinstall，为第二块硬盘划分 partition 和 label。整个过程比较简单，值得注意的是需要 w 将信息写入。分区完成后，我是直接修改 /etc/fstab 的，也可以手动挂载，具体办法见这里。

现在的启动信息：

Waiting 5 seconds for SCSI devices to settle
da0 at ahc0 bus 0 target 0 lun 0
da0: <QUANTUM ATLAS10K3_18_WLS 020W> Fixed Direct Access SCSI-3 device 
da0: 160.000MB/s transfers (80.000MHz, offset 127, 16bit), Tagged Queueing Enabled
da0: 17537MB (35916548 512 byte sectors: 255H 63S/T 2235C)
da1 at ahc0 bus 0 target 1 lun 0
da1: <SEAGATE ST3146707LW D704> Fixed Direct Access SCSI-3 device 
da1: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged Queueing Enabled
da1: 140014MB (286749480 512 byte sectors: 255H 63S/T 17849C)
da2 at ahc0 bus 0 target 2 lun 0
da2: <SEAGATE ST3146707LW D704> Fixed Direct Access SCSI-3 device 
da2: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged Queueing Enabled
da2: 140014MB (286749480 512 byte sectors: 255H 63S/T 17849C) 延缓死亡的手续到此结束。

随着公司业务平台不断扩大，原先数据库服务器上 2GB 的物理内存已显得较为吃紧。前段时间，一狠心，在 DELL 下了一个 PowerEdge 2950 架构的单，直接上到 4GB。

数据库服务器最在意的事情就是数据存储的安全可靠。为此我订购了四块 SAS 硬盘，其中一块做系统盘，其余三块组成一个 RAID5 阵列。这机器成本不算低了，好歹性能也跟上去了，于是日子就这么继续……

最近发现服务器的物理内存占用情况比较有意思。无论我何时连上去看，物理内存占用量都在 1.5GB 至 1.75GB 左右，死活超不过 2GB。当然，绝大部分都被 SQL Server 所占用，但没有完全占用所有可用的剩余物理内存。而 SQL Server 被配置为动态地使用所有物理内存选项。整个情况非常神奇，让我禁不住啧啧赞叹……

这神奇的景象就像这样：

网上有文章说只要打开 /3GB 或者 /PAE 开关就可以，这样的说法是不准确的。

首先我们要分析当前操作系统是什么版本，是否需要开启 /3GB 或者 /PAE 开关。具体可以参阅微软的帮助支持中心的这篇文章。我的操作系统是 Windows Server 2003 Enterprise Edition，其本身就支持最高 32 GB 的物理内存，所以不需要打开这些开关。

我个人的理解是：如果机器上的物理内存并未被操作系统所完全识别，则需要根据操作系统的实际情况考虑打开这些开关。

另外，同时使用 /3GB 和 /PAE 开关是没有意义的。物理内存为 3GB 的时候使用 /3GB 开关，大于等于 4GB 就使用 /PAE 开关。关于 /3GB 开关的描述请见这里，关于 /PAE 开关的描述请见这里。

一个需要开启 /PAE 开关的 boot.ini 的实例类似是这样的：

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(2)\WINNT
[operating systems]
multi(0)disk(0)rdisk(0)partition(2)\WINNT="Windows Server 2000 Server" /noexecute=optout /fastdetect /PAE 如微软的文章中所说，检查完系统是否支持当前的物理内存后，然后需要启用 SQL Server 的 Address Windowing Extentions（AWE）支持。

要检查 AWE 是否已启用，请从 SQL 查询分析器运行以下脚本：

sp_configure 'show advanced options', 1
go
reconfigure
go
sp_configure 'awe enabled'
go 如果 run_value 设置为 1，则服务器上启用了 AWE。如果不是，请在 SQL 查询分析器中输入：

sp_configure 'show advanced options', 1
RECONFIGURE WITH OVERRIDE
GO
sp_configure 'awe enabled', 1
RECONFIGURE WITH OVERRIDE
GO
sp_configure 'max server memory', 4096
RECONFIGURE WITH OVERRIDE
GO 请注意，这里的 4096 适用 4GB 物理内存的系统。如果是 6GB，这个数字应改成 1024 * 6，其他情况依此类推。

值得特别说明的是，微软的原文介绍使用 RECONFIGURE 命令，而我将之改为强制更新的 RECONFIGURE WITH OVERRIDE 命令。其最终效果是一样的，只不过有些情况下 RECONFIGURE 无法完成工作。

到此为止，理论上 SQL Server 应该可以支持 2GB 以上的物理内存了。但某种情况下，依然不行。为何？我们再来看微软的一篇文章。

这里说到这样一个问题：启用了 AWE 支持，但单个 SQL Server 2000 实例还是只能使用计算机上最多 50% 的物理内存。

很不幸地，这个问题被我遇到了。经过一番折腾后，服务器的内存使用量还是在 1.75GB 左右徘徊。这个属于 SQL Server 早期版本中的一个漏洞，该问题只发生在具有超过 2 GB RAM 的计算机上运行于基于 x86 或基于 x64 的计算机上的 32 位版本的 SQL Server 2000 Service Pack 4 中。要查看此现象，请检查系统监视器中的“SQL Server：内存管理器 / 总的服务器内存（KB）”计数器。在运行 SQL Server Service Pack 3（SP3）的计算机上，该值最大可以为计算机上的物理内存量。在运行 SQL Server SP4 的计算机上，该值永远不会超过物理内存的 50%。

下载一个 8MB 的补丁，打了就好。

实践证明，现在的内存使用量已经达到了我们 BT 的要求了：

这样一番折腾之后，任务管理器可能会变得无法准确提供内存使用信息，原因请见这里。

最后补充，无论是打开 /3GB 或 /PAE 开关，还是开启 SQL Server 的 AWE 支持，还是打 for SQL Server SP4 的修复补丁，系统必须重启才能生效。

上个月，朋友朱先生单位里组织员工去日本旅游，美其名曰“考察”。临行前，我刚从哈尔滨回来。我特意交待他，请他从小日本那里带些“特产”回来。朱先生心领神会，一口应承了下来。

等待的日子总是难熬的。一个多星期后，他安然无恙地回来了。有意思的是，他很认真地告诉我，有些“特产”是无法带回国的，连动画片这样的音像出版物都只能通过邮寄。他除了给自己买了几套动漫的小人书、给他女人及其家人带了些小礼物外，还给我带回了极具有纪念价值的东西。

Mild Seven，国内称为“七星”，广东一带也有人叫“万事发”，属于混合型香烟的一种。七星是抽了几年并且一直在抽的烟了。遥想 LSD 当年，我与 lucky 同学成双入对，就是为了抽烟。他有他爱好的红双喜，我有我钟情的七星。如果说利群算情人的话，那么七星就是正房。

之前经常抽六号和八号七星。朱先生此次几乎给我带齐了一整套七星香烟，从一号到十号，颜色逐渐加深，看起来十分迷人。

美图共享。这是一整条的八号七星：

- 阅读剩余部分 -

前段时间由于工作比较忙，只好接连在公司附近的小饭店吃了几次。实在是被那些用油泡着炒出来的菜给吃怕了，周末抽空做个豆腐，再吃点粗粮，刮刮油。

中药讲“君臣佐使”，为的就是让药性相互配合。即便是“独参汤”，也需配几枚红枣。做菜也是一样。“烹调”二字，这“调”就是讲原料和调料之间的搭配了。

豆腐本身味浓，且不易入味，所以配豆腐的原料不妨用味道比较浓的，不用怕会盖住了豆腐自身的味道。香肠味浓而木耳香浓，再配上料酒。正好能压住豆腥味，却又不至于掩盖了豆香味。

原料：老豆腐一块、水发干木耳半碗、香肠或者腊肉一小块、海米适量。

调料：姜片、葱段、盐、味精、生抽、料酒。

把干木耳用热水泡开，然后用冷水冲洗干净，去根，撕成小块。海米洗干净，剥壳。处理的时候要注意，深紫色的是虾籽，不是杂质，别扔了。香肠或者腊肉切成薄片，豆腐切成厚片。

锅里放少量油，小火烧到七成热，然后把香肠、海米、姜片、葱段放进去煸炒。等香肠完全变色后，开大火，把木耳放进去翻炒几下，然后加入料酒、生抽、盐和味精，再加入大约一碗水。等水烧开后，再用小火慢炖，直至汤色变白。

然后把豆腐放到锅里，炖至色微黄而形略塌，然后调入少量水淀粉，勾薄芡出锅。

几个要点：

1、烧半锅开水，把干木耳放进去，几分钟就可泡开。
2、豆腐不易入味，所以调料要在豆腐之前就加到锅里。
3、同样是因为豆腐不易入味，所以勾芡，目的是让豆腐能沾上更多的汤汁。勾芡不宜早，早了容易糊锅。

本文原载旧版博客 2006 年 4 月 11 日。

大约在两个月前，易先生和我一起搞了一台服务器，托管在杭州萧山双线机房。除了易先生自己的两个网站：blogshang.com、neilyi.cn 之外，还陆续为 gracecode.com、yiyitoo.com、bbitt.com、ebshoe.com、typecho.net 等网站提供了空间支持。

前几天 lucky 突然告诉我，说服务器的上行好像有问题。具体表现为 POST 数据慢，FTP 上传几乎不能进行。但是我看了一下却并未发现这样的情况，随后让运营商检查也没有找到问题所在，因为他们上行到服务器也很正常。紧接着，一一、badbuild、ppeng 三位同学相继反映了与 lucky 类似的情况，讨伐之声一浪高过一浪。

经过与机房技术人员为期将近一周的亲密接触和技术测试，我们重现了问题并初步认定此问题与服务器设置或机房线路带宽无关。经过杭州以外朋友的友情测试，确定省外访问无论上下行都很正常。因此，问题极有可能出在上述几位同学所使用的网络上。他们都有一个共同特征，即杭州市区电信线路。

我们来看一下从 lucky 同学家里、公司，还有我这边的网络所做的路由跟踪结果。

这是我所在公司网络到服务器：

Tracing route to 122.224.147.37 over a maximum of 30 hops:
1     *        *        *     Request timed out.
2     *        *        *     Request timed out.
3     2 ms     2 ms     3 ms  220.191.130.133
4     3 ms     2 ms     3 ms  61.130.125.153
5     3 ms     2 ms     4 ms  61.130.125.157
6     4 ms     4 ms     4 ms  61.130.125.114
7     4 ms     3 ms     4 ms  220.191.132.18
8   102 ms   102 ms   102 ms  202.101.163.238
9     5 ms     6 ms     5 ms  122.224.147.37
Trace complete. 这是从 lucky 家里（杭州电信家庭 ADSL）到服务器：

Tracing route to 122.224.147.37 over a maximum of 30 hops:
1 * * * Request timed out.
2 17 ms 20 ms 18 ms 220.191.157.213
3 19 ms 19 ms 18 ms 220.191.156.93
4 19 ms 19 ms 20 ms 61.130.125.134
5 19 ms 31 ms 19 ms 61.130.125.114
6 19 ms 20 ms 35 ms 220.191.132.18
7 121 ms 122 ms 121 ms 202.101.163.238
8 22 ms 21 ms 21 ms 122.224.147.37
Trace complete. 这是从 lucky 公司（阿里巴巴）到服务器：

Tracing route to 122.224.147.37 over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 10.1.28.2
2 <1 ms <1 ms <1 ms 10.0.99.113
3 1 ms <1 ms <1 ms 10.0.99.170
4 <1 ms <1 ms <1 ms 10.0.3.241
5 1 ms 1 ms 1 ms 121.0.31.124
6 1 ms 1 ms 1 ms 121.0.31.5
7 2 ms 1 ms 1 ms 121.0.31.73
8 1 ms 1 ms 1 ms 61.130.125.114
9 2 ms 2 ms 2 ms 220.191.132.18
10 1 ms 1 ms 2 ms 202.101.163.238
11 3 ms 2 ms 2 ms 122.224.147.37
Trace complete. 然后，我们各自又跟踪了一下到新浪网的路由。

我的：

Tracing route to jupiter.sina.com.cn [61.172.201.194]over a maximum of 30 hops:
1     *        *        *     Request timed out.
2     *        *        *     Request timed out.
3     2 ms     2 ms     3 ms  220.191.130.129
4     2 ms     2 ms     3 ms  61.130.125.145
5     2 ms     2 ms     3 ms  220.191.158.233
6    19 ms     6 ms     5 ms  61.152.80.145
7     7 ms     6 ms     6 ms  61.152.87.154
8     7 ms     7 ms     6 ms  222.72.243.250
9     6 ms     6 ms     6 ms  61.172.201.194
Trace complete. lucky 的：

Tracing route to jupiter.sina.com.cn [61.172.201.194]over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 10.1.28.2
2 <1 ms <1 ms <1 ms 10.0.99.113
3 1 ms <1 ms <1 ms 10.0.99.170
4 1 ms <1 ms <1 ms 10.0.3.241
5 * 1 ms 1 ms 121.0.31.124
6 1 ms 1 ms 1 ms 121.0.31.5
7 2 ms 1 ms 1 ms 121.0.31.73
8 1 ms 2 ms 1 ms 220.191.129.117
9 4 ms 4 ms 4 ms 61.152.80.145
10 5 ms 5 ms 5 ms 61.152.87.106
11 5 ms 5 ms 5 ms 222.72.243.234
12 4 ms 5 ms 4 ms 61.172.201.194
Trace complete. 与此同时，聪明伶俐的 lucky 同学通过使用代理服务器成功地规避了这个问题。于是，一传十、十传百，变成了全国皆知的秘密。上述几位同学因突然终于可以发文而激动万分、兴奋不已，纷纷发文讨伐我的恶劣行径。这是一一同学的，这是 badbuild 同学的。

中午的时候，请教了一位在当地电信从事数据工作的朋友。他一听到我报 IP 地址给他，他就说：你这个 IP 的网段本身就是有问题的。然后他向我解释了这件事情的原委：电信在杭州地区、七县市范围内的大城域网中部署了多个域，萧山、余杭及周边地区在同一个域内，而杭州市区另属几个其他的域。换言之，从杭州市区走路由到萧山的服务器，是需要经过多个域的路由。这次故障刚好出现在上述几位同学所在网络的上级出口上，因此产生了“东边日出西边雨”的神奇现象。

因此，需要彻底解决这个问题，只能等电信调整好市区线路的出口路由。

因为突然不喜欢服务器 IP 所在的网段，下午的时候要求机房把服务器的电信网通两个 IP 全换了。虽说问题没有得以解决，至少心里舒服多了。我一直在想，这些种种神奇的事情，会不会与运动会有关呢？

今天距离运动会只有不到 30 天时间了。在这举世瞩目、普天同庆的时刻即将到来的时期里，我们的生活也变得越来越和谐。最近发现，小巷子里的路边摊没了、夜市暂停了、停车要咪表了、交警城管巡逻得更勤了，这种种一切都在向世人传递着一个信息：不惜一切，办好运动会。

就在我们的生活被这场即将到来的运动会潜移默化地影响并改变的时候，殊不知，我们的互联网（这里也可以称为中国局域网）也被悄然改变着……