原帖由 MichaelBibby 于 2008-11-9 17:40 发表 http://bbs3.chinaunix.net/images/common/back.gif
从你的言语来看，你的许多考虑都是从网上别人的帖子看来的，感觉还是缺少了自己的分析和研究，并且不够严谨。（Sorry，没有贬义的意思，只是纯讨论，希望不要介意。）
对于做技术、做研究来说，我个人希望 ...
首先需要说明，本人在文章中总结出的7条所谓的“定理”，是本人自己的原话，小部分参考。
其次，关于软链的问题。
不如这位朋友在高速上开车，1号和2号公路都可到达目的地，一号公路属于常规公路，二号公路属于绿色通道。正在你准备选择走哪条公路的时候从别人口中得知二号公路安检，可能反而会比一号公路慢。那您如何选择？
对于生产环境这样相对谨慎的课题，如果老路慢新路快，而新路又有传言说有问题的话，我的性格和经验决定我一定会选择老路。所以在原文中说了“请不要在生产服务器上吃螃蟹”
至于是否让其他人confuse了，我可不好说，就比如我说一句话我认为是这个意思，而这位朋友却以为是那个意思一样。 我只知道我在原文中不止一次说明诸如“不要盲目仿照”之类的话。各位看官完全可以认为我的方案就是一坨屎，为什么还说我故意放一些不明所以的论点在这里making people confused？
我要严正在这里声明，请查看我以前的帖子，我关于服务器配置、服务器优化等等的论点必须建立在自己的经验或者是权威的发言上。我一向不推荐盲目听从他人的意见所做的优化。所以我常说：应用需要决定生产环境。 别人做了半天的优化总结，可能在你的环境中连P都不算。
哈，楼主不要激动，我不是来砸场子的 :mrgreen:
原帖由 MichaelBibby 于 2008-11-9 17:50 发表 http://bbs3.chinaunix.net/images/common/back.gif
Sorry，没有说清楚，我的是理论上的分析，不是说理论上这是浪费硬盘空间，所以你不能这样分。而是说没有必要这样分。
4G 内存都用不完，那么几乎 swap 是 1M/10M/100M 都用不到的，所以理论上来说，任意空 ...
呵呵，那我这里不妨再说得明白一些。我完全同意你的说法，并且在我观察过的服务器中一旦有SWAP被使用百兆以上的情况，服务器都已经遇到的问题。
但说白了就是我手头有近20G的空间没地方放置，有参照2-3倍内存云云之说法，就分了16G给SWAP。实际上我也很清楚这仅仅是个套路上的东西而已。
原帖由 MichaelBibby 于 2008-11-9 17:53 发表 http://bbs3.chinaunix.net/images/common/back.gif
哈，楼主不要激动，我不是来砸场子的 :mrgreen:
不好意思 到底修炼不纯啊。继续讨论 继续讨论，哇哈哈~
原帖由 MichaelBibby 于 2008-11-9 17:46 发表 http://bbs3.chinaunix.net/images/common/back.gif
我觉得你没有弄明白什么叫“平衡点”。
为了保证数据的安全，牺牲一些性能是必要的，而且牺牲的这部分性能也是可以接受的。
一天 24 小时，任意一块硬盘挂掉了，请问你是否有恢复方案？我要求数据 0 损失。
我感觉正是这个平衡点让我做出的决定。
实话说当初客户是决意要做RAID1的，但后来我说了近一个小时，他才决定做双硬盘物理隔离。
我的出发点就是这样的服务器也许丢失一整天的数据也并不十分严重，但如果让服务器一直运行在低迷状态却是损失客户流量的一个好办法。
平衡点在于此环境对数据安全的需求比对服务器性能的需求要小很多。大概就是这样，不知道朋友高见如何？
好机会，学习中。:P
好久不与人争辩了，这次觉得自己有点浮躁了。
宁静、淡泊。。。
我感觉还是raid1好，要是有点什么事情。。。:mrgreen:
当然是要花钱地，
我问个浮浅点的问题，lz把/usr分50g那么大是为什么，有什么特殊原因吗？我没有弄过服务器，只弄过desktop。
原帖由 fender0107401 于 2008-11-9 18:27 发表 http://bbs3.chinaunix.net/images/common/back.gif
我感觉还是raid1好，要是有点什么事情。。。:mrgreen:
当然是要花钱地，
我问个浮浅点的问题，lz把/usr分50g那么大是为什么，有什么特殊原因吗？我没有弄过服务器，只弄过desktop。
理论256M就好，这里说实话是为了凑数，并且防止以后有新引入的数据类型需要挂在/下，提前放一些空间。
实话说我当时也很犹豫关于RAID1的问题，后面大胆这样做的原因就是冒部分丢失数据的风险来提高性能。到底哪个值得说实话还得等时间去验证。
我个人的建议是：把自己放在客户的位置上去考虑问题。