部门服务器资源向来都比较紧张，每当忙碌季节到来，服务器资源消耗都较大，开发人员总是抱怨编辑代码慢、Build慢以及磁盘空间不足等问题，严重时甚至无法工作。部门也一直在尝试改善这个问题，无非加服务器、加磁盘等，但是这些措施似乎都难以满足开发和测试人员日益增长的对服务器资源的索求。

为了尽量在组内杜绝上述现象的发生，决定搭建多台PC Server给组内开发人员使用，让大家工作的更有效率，更独立自由，不受共享服务器的约束。因负责部门内部服务器的系统工程师出差在外，无奈委托一个热心同事尝试去安装一下Solaris 10 for x86版本。这位热心同事很积极也很快的将Solaris 10安到了那台空闲PC Server上。但是上午我发现系统的网络仍然未配置，决定亲自手工给这个Server配置网络参数。

对于Solaris系统的配置和管理，我就是一菜鸟级选手，一切都要从头来-到网络上查找资料。找了半天仍是一头雾水。又想到利用Solaris 10提供图形化界面去配置，但是居然没有找到对应的工具或程序的位置。只能向家中另外一位系统工程师同事求助。这位同事也是热心肠，还亲自过来为我配置网络。在他配置的过程中，我也学到了网络配置的一些皮毛。

首先查看网口是否激活，如果没有，则找到网口设备名称，并激活网口服务：
在这台Server上，执行ifconfig -a发现，只有lo0这一个本机LOOPBACK虚拟网口，显然该主机物理网口没有被激活。

寻找这个网口设备名称：
cd /dev
ls -l|more
一般网口设备名称都类似：bge0，hme0等。发现我的这台主机网口为bge0。

激活该网口设备：
ifconfig bge0 plumb up
这回你再执行ifconfig -a，你将会看到bge0网口，但是该网口尚未分配IP地址和掩码。

如果你要临时设置该网口IP和掩码的话，可直接使用ifconfig命令（ifconfig bge0 HOST_IP netmask 255.255.255.XXX）进行，但是这样的设置在主机重启后将无法保留下来。那我们就说说永久保留设置的方法。

设置静态IP:
vi /etc/hosts，在结尾添加一行：HOST_IP   主机名  loghost
vi /etc/hostname.bge0，该文件可能需要你手工创建，只有一行：主机名

设置子网掩码：
vi /etc/netmasks，增加一行格式诸如："network-number  netmask"。如果主机IP为10.10.12.77，掩码为255.255.255.0，则你可添加"10.10.12.0 255.255.255.0"。

设置网关/默认路由
vi /etc/defaultrouter，直接将你的网关的IP写入即可。

重启系统后，网络算是通了。无论是从本主机访问其他主机，还是从其他主机访问这个主机都没有问题了。但是还有一个问题：打开Firefox无法打开网页？应该是DNS没有配置，配置方法如下：

vi /etc/nsswitch.conf，在hosts:   files后面加上一个"dns"，即该行变成："hosts:   files dns"，保存退出。
vi /etc/resolv.conf，每一行是一个DNS服务器，格式如：nameserver xxx.xxx.xxx.xx

配置完，firefox顺利打开了外部网页。

配置完网络本以为该主机可以投入正式使用了，但无意间却发现'/'分区下空闲空间仅剩下20%多了，70%的空间已经被使用，再细致一看，发现'/'分区分配的空间太小了，不仅如此swap交换分区仅仅分配了500M的空间。经沟通得知，首次安装采用的是默认安装，才有了此结果。由于无法动态扩展'/'和swap分区大小，无奈只能重装，否则日后问题更多。

Solaris10的图形化安装果真比不了Ubuntu，更无法与Windows相比了，不过我还能应付，这次我选择了自定义安装，并在安装阶段就将网络配置好了。一个小时左右，安装过程结束，进入桌面，需重新按上面步骤配置DNS，其他就无需配置了。

从其他机器Telnet访问该主机，居然提示："telnet: Unable to connect to remote host: Connection refused"，是我的网络配置错了？ping和traceroute都正常，而且从这台主机Telnet访问其他主机都没有问题，估计是Telnet服务没有启动，通过“netstat -an|grep LISTEN”并未看到在监听23端口，但是如何启动Telnet服务到不是很清楚，在询问了系统工程师后，执行了一下：svcadm enable telnet，Telnet服务瞬间启动了。同理，Ftp服务也是如此。svcadm应该是Solaris 10新增的系统管理工具，低版本的OS可能都不具备这个命令。

再次从别的机器telnet这台服务器，并用root用户登录，提示："Not on system console, Connection to xxx.xxx.xxx.xxx closed by foreign host"，这又是怎么回事？从系统工程师那得到的答案是：默认不允许root用户远程登录。可打开/etc/default/login这个文件，并将“CONSOLE=/dev/console”这行注释掉就可以了。

下班前终于将该主机安装配置完毕，可正式投入使用了。但是在下班路上与另一位同事探讨这个安装配置问题时，他提示我还有一处遗漏：那就是/var没有单独分区，而是与'/'分区共享，这样给以后的使用带来了一些隐患，在测试和运行一些大程序时/var很容易被占满，导致程序无法正常运行。在不再重装系统的前提下，只能考虑定期清理/var下的文件了。

周六，对于上班族来说是多么好的日子，能在家里享受自由的无拘无束的生活而且不用担心第二天的工作，应该说是一周中最没有压力的一天。六点半起床，慢慢喝下一杯225ml左右的凉白开（保健医生说20-25摄氏度的凉白开比较适宜作为起床后的第一杯水），套上运动短裤和上衣，打开MP3播放器，塞上耳机，出门在园区内慢跑。昨晚下了一场雨，所以园区早上的空气很好。耳畔酷玩乐队的“Viva La Vida”让我跑起来很轻松，30分钟的有氧慢跑能让我的大脑和心脏获得足够的氧气，心情也变得更好。最后绕着园区走上一圈结束锻炼。

回房间后，舒舒服服的冲了个热水澡。简单的吃过早饭后就回到了本本前，本来计划解决一下本周五发现的一个GB2312转Unicode码的问题。但此时远在南方某省的技术支持人员打来电话，说我们的产品又出现问题了。这个问题早有端倪，曾先后引起客户总部的投诉、当地一些客户的投诉以及计费部门的投诉。前些时间在查这个问题时一直很迷惑，同样的机器和配置在其他省就没有问题，为什么唯独在该省问题严重。而且从业务量上来说，该省虽然业务量上比其他省高出一些，但按照目前我们产品的处理能力来看，还是完全可以满足要求的。在没有找到根本问题前，本周一直在做一些程序部署上的优化以及参数调整，希望能通过这些手段来缓解问题的严重程度。

本周五刚刚完成了一些I/O上优化，周六却又出现了问题，而且这次是客户集团总部的投诉。前方的技术人员已经是火急火燎，但是查问题也不是一蹴而就的事情，还是需要细心、耐心和稳定的心理的，不能头脑发热。

所有问题的查找都只能从已出现的问题现象着手。今天问题的现象是：我们的产品作为Server端时无法及时收消息并回应答，导致客户端异步发送窗口中的消息超时并重发该消息，而这条重发的消息因与前一条消息有着同样的消息ID而被我们的产品拒绝。还有一个现象就是：我们的产品作为Client端向一内部的鉴权子系统发鉴权请求，因未能及时收到应答而导致我们自己的异步发送窗口中的消息过期而直接进行了下一个环节的处理，这样一来这些消息在用户体验和计费上都会出现问题而导致投诉。

试着调整一下两端通信的参数以及一些队列的缓存参数，生效后也仅仅缓解了一段时间就再次出现了类似的问题，严重时双方居然因为socket阻塞而导致链接断开。这时技术支持同事提到主机I/O特别高。I/O高倒是很好的解释了socket未能及时被读取的问题，但是本周明明做了些I/O优化，为什么I/O还是这么高，而且此时该省的业务量相当的小，基本排除因业务量过大而导致I/O高的可能了。但是又是什么导致阵列I/O高呢？甚是疑惑！

究竟是什么问题导致大量磁盘操作呢？无意间在产品运行环境里发现一个Core文件，如果只发现一个core文件倒不足意外，但是发现这个core文件有上G的容量，而且一直在不断被刷新。难道就是这个core的不断刷新导致了I/O特高？遂尝试写了个脚本每个2秒尝试rm一次该core文件。果然经过这一处理，I/O降了下来，上面的问题也不再出现了。停掉脚本，I/O又攀升了上来，上面的问题就又出现了。“罪魁祸首”终于找到了！

虽然使用脚本可以临时解决问题，但是这样解决问题显然是不负责任的。到底是什么导致Core的出现呢? 停掉脚本，让程序产生core，对core文件进行分析。通过pstack和gdb打开core文件，core文件输出的信息很少，很多信息都成了“???”，似乎栈被破坏了。不过可以获得出core文件的进程号以及dump core的接口函数名字。通过进程号和程序日志共同定位，发现出core的进程都是在处理同一个客户端提交的消息。让技术支持同事封掉该客户端的IP，果然再没有Core产生，看来是我们的程序在处理这家客户端提交的消息时出了问题。

到目前为止已经大有收获了。继续！利用snoop工具获得了该客户端提交的消息包的信息。经过对比分析发现，该客户端提交的包信息与协议中定义的格式不符合。但是我们的程序居然没有发现这样的非法格式包，进一步结合代码、包信息和core信息进行分析，终于定位到了问题所在。原来是我们的程序的一个函数实现逻辑有误，而这种错误在处理正常格式包时是不会发生的，但是处理这种非法格式包时，会导致严重的栈上缓冲区溢出，直至进程运行混乱，dump core并退出。

这时想起周五同事发来的一封邮件，说的是我们的另一个产品在另外一个省也遇到了类似情况，core的输出与今天处理的情况几乎相同。想必是一个问题。因为出问题的函数是很久以前的代码了，而且是复用库中的一处代码。估计所有复用了该库的产品都要做一次升级了。

解决完问题已是日落时分，虽然身体感觉一丝疲乏，但是心情还是不错的，一天的努力终于有了成果，程序员的成就感就是由此而来的。