paulwong

[搬金砖]买笔记本绕坑指南，附天梯图地址已更新（1.7）

写在前面：新的一年开始了，又有一大批刚工作的和刚入学的兴致勃勃的，即将购买人生中的第一个笔记本电脑了，在此本老鸟根据混迹中关村在线，太平洋电脑5年，外加大量实战经验（改装，清灰，升级，装系统等等。。。）为大家献上一篇笔记本电脑选购指南。PS，本文仅供参考，购机需谨慎。
（附图如需详看，请移步网盘yunpan.cn/cyPFVpCrij7Fr  提取码：f61c。上传尺寸太大，传图还不是很熟悉！！！）
废话不多说，现在开始详细解读：

真心感谢各位聚聚和大大们的支持，帖子是我混论坛发掘出来的不错的，会做了搬运和少量修改罢了（原帖开头已给出说明）。虽然对于买电脑有些体会，但未达到高深境界。回复已一一拜读并根据掌握的微小知识面来回答给出了些微建议。如不满意，可回复讨论。
说明一下：回复的比较集中的问题，没有写华硕电脑原因：华硕的主板的强悍自不必说，电脑也是全球第三大出货。可小草周边的同事之前的同学，都没有购买过该品牌，所以想得到些建议只能从网络，但是真心的褒贬不一，所以未亲自验证过还是不敢妄加增减。至于三星的也没写是因为小草对三星无爱，虽然很多实用三星手机的人说质量如何如何好，可能三星大公司在韩毕竟是可生产军工，质量过硬。可要知道4000亿的年广告费可都是需要加到消费者的腰包里的。哎，算了，姑且把它也加到未来人类一类吧（虽说三星的配置比不上）。

购机步骤一：

明确购机目的

这一点非常重要，主要分图形视频设计（需要大量使用PS，AE，CAD，3DMAX等专业软件的）；编程和高强度办公（经常使用编程，数据库，虚拟机，使用word处理几十页上百页资料排版等）；大型游戏（指的是单机大型3D游戏，比如看门狗，比如生化危机，古墓丽影，尘埃，杀手5.。。等等）；网络游戏（指的是各种高中低档网游，如魔兽世界，剑灵，LOL，DOTA等等）；简单上网看视频（没事看看快乐大本营，聊聊QQ，看个漫画，斗个地主之类）；移动办公类（额，就是移动办公）；装X（这个就不解释了）。

购机步骤二：明确预算

一句话的事，分3000以下、3000~5000、5000~8000、8000~12000、12000以上 共五个档次。

购机步骤三：讲解各配置代表的意义


3.1 CPU

cpu,即中央处理器，是一台电脑的最核心硬件，直接决定了一台电脑的退休年龄。

选一个好的CPU，首先要学会屏蔽各种商家的“坑爹广告语”：急速双核处理器、高端四核处理器、主频高达2.5G。切记推销核心数，主频数的，可以直接忽略掉，直接查询CPU型号，然后根据CPU天梯图推算CPU性能，这里就不深入讲解了，只是简单说明一下各种购机目的对应的CPU需求，大家可以根据天梯图进行推测（最近出的I7-4710MQ，性能跟I7-4700MQ接近）。

图形视频设计，网络游戏：5000以下的（至少I5-4200M）； 5000~8000预算的，围绕I5-4200M~I7-4700MQ选择；8000预算以上的，选择I7-4700MQ以及以上性能的

编程和高强度办公，大型游戏：无论多少预算，选择I7-4700MQ以及以上

简单上网看视频：3000~5000预算的，I3-4000M~I5-4200M范围；5000预算以上的，I5-4200M以上即可。

移动办公：无论多少预算，要选择低功耗的（即天梯图最右边的区域，型号带U），也就是所谓超极本。（当然低功耗的I5，I7，应对简单的网络游戏，上网看视频也是够用的，只是可能会卡，不推荐）；3000~5000预算的，I3-4100U附近；5000~8000预算的，I5-4200U附近；8000预算以上的，I7-4500U以上

装X：哪个贵买哪个。

这里有几点提示：

1，本文笼统的以I3，I5，I7作为性能的分界线，实际性能可以对应天梯图来判断；推荐使用Intel出产的I系列处理器，因为AMD公司出产的笔记本处理器，不管主频多少，核心数多少，最顶级的也才堪堪达到I3的水平。

2，笔记本CPU中，I7和I5有着极其巨大的差距，实际体现为：编程运行时，游戏加载时，解压缩时，批量调整格式时，处理大图片时等等，其他配置相同情况下，需要时间差距在100%以上；而I3与I5的实际体验差距不甚明显，目测差30%顶天了；

3，对于整机寿命，纵观笔记本电脑发展史，I7处理器（这里指正常电压的，后缀没有U的。带U的是低电压的，性能较弱）从发布到完全落伍时间，几乎为无限，也就是简单地说，任何时代出产的配备I7处理器的笔记本电脑的，因为CPU性能落伍而导致换机非常非常少。而对于I5处理器，退伍时间为4-5年；I3处理器，退伍时间为3-4年；I3处理器性能以下的，寿命3年左右。

这个原因可以解释一下，由于I7系列属于顶级处理器，在早期出现时就遥遥领先与其他处理器，而且限于功耗太高，很难大幅提升性能，所以退伍时间长，而I3，I5处理器在初期性能较低，近年来性能提升非常快，淘汰速度也很快。

4，处理器的升级。对于笔记本的cpu，很多人都不甚了解，其实后缀是带M的（比如I5-4200M），都是可以更换升级的，淘宝可以买到这种CPU，找个技术高点的修电脑的就可以换。但是后缀带H，HQ的（比如I5-4200H，I7-4700HQ）是不能更换的，是焊接在主板上的。这种升级一般在笔记本临近退休的时候，已经过保很久了，搞坏了不心疼，换好了可以再战3年无压力。

5，关于发热量:I7>>I5或I3（I3与I5档次的发热量差距不大，I3略小一点点而已）>>低电压，型号带U的（例如I5-4200U）

配备I7处理器，夏天高负荷运转（玩大游戏，编程模拟，编辑视频等），一般会到烫手的程度；配备I5及其以下处理器，夏天高负荷运转（性能接近I7的一半左右），也会比较热；低电压处理器，几乎感觉不到发热。

具体情况下面会详谈。


3.2 显卡

显卡，决定了整个电脑的图形处理，视频处理，游戏性能，同样决定了一台电脑的退休年龄，嘿嘿，退休年龄基本就是CPU和显卡决定的咯~~

选一个好的显卡，首先要学会首先要学会屏蔽各种商家的“坑爹广告语”：1G独显、2G独显、双显卡、集成加独立双显卡。类似于CPU，我们屏蔽掉这些坑爹广告语，找到真实的显卡型号，然后对比给出额显卡天梯图，查出对应性能。

图形视频设计，大型游戏：5000~8000预算的，围绕GTX850M选择；8000~12000预算的，选择GTX860M~GTX870M左右；12000预算以上，选择GTX870M以上

网络游戏：3000~5000预算的，GT740，或者GT840M左右范围；5000预算以上的，GTX850M以上即可。（魔兽世界和剑灵这种档次的网游，最少GTX860M才能跑的开，所以玩这两种游戏的，参照大型游戏的显卡需求来选择）

简单上网看视频，移动办公，编程和高强度办公：这种需求，无视显卡，随便，不管是独立的集成的，怎样的都能满足需求。

装X：哪个贵买哪个。

这里有几点提示：

1，对于显卡，英伟达和AMD的都具有实力，上文选择英伟达的只是做例子，在天梯图上可以找到AMD的对应档次。

2，对于集成显卡，现在能买到的集成显卡，大多为HD4600，HD4400，这些集成显卡性能足够满足看视频玩斗地主，但是其他需求就难为它们了。所以推荐，如果不玩游戏不做绘图不做视频可以忽略显卡选择，独显集显无所谓。

3，关于升级，跟CPU不同，显卡大多是焊接在主板上，不能更换的，只有在比较高端的（至少GTX860M以上），才能更换升级。不过技术难度较高，会导致不给保修。推荐过保后在升级显卡。


3.3 硬盘

硬盘主要分为固态硬盘SSD，机械硬盘HDD，和混合硬盘SSHD

SSD固态硬盘，容量低，价格高，速度非常快，尤其是杂乱的数量巨大的小文件（举个例子，其他配置相同的情况下（都比较高），装SSD的电脑开机速度为5-10秒，打开word速度为3秒左右，打开PS速度为5秒左右；装普通HDD的电脑开机最少得20秒，打开Word速度为10秒，打开PS速度为30秒    这些都是估计值），但是对游戏卡顿无提升作用，仅限于打开快一点，读图快一点。（备注，苹果的任何笔记本电脑的SSD固态硬盘性能都比普通SSD固态硬盘高一半以上。）

HDD硬盘，容量大，别的不用说了。

SSHD硬盘，容量大，在开机速度和打开软件速度具有类似SSD的功能，但是需要多次重复才能达到近似SSD速度，而持续读写，拷贝大文件，拷贝大量小文件，解压缩这些性能几乎与HDD一样慢。

另外有一种极其土豪的硬盘组合，叫做硬盘阵列，简单介绍就是多块SSD固态硬盘组合而成，速度等于N块SSD速度的线性叠加

下面，介绍硬盘需求：

对于移动办公，编程和高强度办公，图形视频设计：推荐使用SSD固态硬盘

其他需求，预算足够尽量上SSD，或者SSHD；预算不足可以以后再加装SSD。

这里有几点提示：

1，所有硬盘都是可以更换的，其中有一些比较高端的电脑会预留一些硬盘接口，这样可以方便以后添加SSD固态硬盘；没有预留接口的，可以把光驱拆掉，在光驱位加装硬盘；没有预留接口，又没有光驱的，只能使用一块硬盘，速度和容量不能兼顾，推荐使用SSHD，或者日后升级SSHD。

2，要长时间大量使用优特或迅雷，保种和下载电影的同学，推荐配备两块硬盘，把下载目录放在非系统硬盘上，否则容易导致系统卡死，尤其是单HDD硬盘的情况下，咱学校的网速够快，容易导致卡死。

3，硬盘容量，SSD的话，60~64G勉强够装系统；120~128G足够使用；HDD和SSHD的话，500G以上都可以，想存储大量电影，大量文件的，日后购买移动硬盘更方便。

3.4 内存

现在购买笔记本电脑，内存基本上就不在考虑范围了，4G起步，日常使用就够了，8G怎么用都用不完，而且加装一个4G的内存条也就300块钱，加装过程非常简单。

3.5 屏幕大小以及分辨率

玩游戏，制图，大量处理办公文件，推荐15.6英寸或17.3英寸，1080P分辨率。大屏幕分辨率太低，会看着满屏幕都是颗粒。PS，17寸的本，体积比较大，很难放进包里带走，而且很重，需要经常移动的，请谨慎。

便携式的，推荐14英寸，13.3英寸，1366*768或者1600*900分辨率。小屏幕分辨率太高，会导致屏幕字非常小，闪瞎眼

关于屏幕的更换和升级，也是可以做到的，淘宝找到对应型号，买下来就能换高分屏了，不过技术难度较高，会导致不给保修。推荐过保后在升级屏幕。

3.6笔记本外观散热

外观和散热放到一起说，是因为这两个联系紧密。一般来说，笔记本越厚散热越好，金属部分越多，散热越好，风扇口越多的，散热越好，新出的模具的笔记本，比老模具的散热好。超极本散热都很好。CPU和显卡是散热大户，CPU发热前边已经介绍了，显卡的发热就是跟随性能，指数增长，集成显卡发热可以忽略，GTX850M之类的，发热量比较均衡，不会烫手。GTX870m之流，不到90度都不叫高负荷。

总而言之，超薄和散热良好不可兼得，性能高跟散热良好不可兼得。又有性能，又薄，有散热好的，价格在15000以上，土豪可以考虑。

至于重量，3KG左右的本本，女生背起来负重较大，女汉子可选，男生可以忽视。2.5KG左右的本本男女老少皆宜。2KG一下的本本，适合土豪。

3.7 关于现在很流行的“游戏本”

相信最近看过广告的都知道，一些厂商的“游戏本”非常火爆，比如什么外星人，雷蛇灵刃，未来人类，雷神，机械革命，机械师，微星，神舟战神，宏碁A神，华硕ROG，联想大Y等等，上述产品基本都是性能强劲的游戏本，但是有一些其他笔记本则是真正的噱头。。。尤其是一些带着GT740M，GT840M的，配I3级别或者低电压CPU的，配15.6英寸屏幕带1366*768分辨率的，这种号称是“游戏本”的都是很坑爹的，能玩的游戏非常差非常少，当然，你要说LOL……集成显卡都能撸的毫无压力，这些伪游戏本倒是能胜任。

真正的游戏本，CPU和显卡对应价位都应该满足我在3.1,3.2中的描述，至于硬盘内存这种东西，加上500块能加装120G SSD，加上300块能升级到8G内存。对比价格的话，自己衡量。

游戏本也分等级的，大型3D游戏，大型单机游戏，需要I7级别cpu，GTX860M及其以上显卡

主流网游，I5，GTX850M之流就可以胜任。配置的选择要根据所玩的游戏来决定。

总而言之，这些游戏本，硬件配置不坑爹的话，是值得广大宅男购买的，对于女生的话，这类本本都外观霸气，个儿大，够重，女汉子可选。

3.8 关于品牌

品牌这东西，掺杂了很多个人观点，这段我说的仅仅是我个人的理解，不算太客观，仅供大家参考：第一部分，上边提到的游戏本，都是质量比较可靠的，配置比较均衡，性价比很高的。

当然对于一些非游戏爱好者中的图形设计视频制作需求者，这些本本也是很合适的，对于日常看个小片写个word来说，这些笔记本性能过剩严重，没有必要。

有人说神舟渣质量，其实神舟的这些游戏本都是蓝天代工自己贴牌的，质量还可以，但是用的都是低价模具，其中有一些模具设计有缺陷，散热通常比较差的，例如K590S系列。不过最近神舟新机已经不在使用这些，已经推荐妹子买过，散热还不错。
第二部分，联想的ThinkPad，戴尔。这两类都是质量很好，配置很低，价钱很贵的类型。尤其是戴尔，被称为“傻多戴”即人傻钱多买戴尔。其实这几年，这俩品牌也出了很多配置不错的高端办公商用本，买这些的大多是不差钱的商务人士，比如ThinkPad New X1 Carbon，戴尔Inspiron 灵越 17 7000等等，这些目测不是我们学生的菜。

第三部分，联想的ideapad，性能高中低档都有，选择范围较广，G系列主打入门办公，V系列主打时尚办公，Y系列是游戏本。他们的共同点是，性价比低，售后服务较好。

第四部分，惠普，索尼。这几个经常出现的是外观党，配置偏中低档，做工较好，外观设计丰富多彩，性价比一般。

第五部分，神舟，话说，宏碁。这些品牌主打性价比，配置较高，质量做工相对其他厂家较弱，但是近年来发展迅速，提升很快，可以一试。

第六部分，雷蛇灵刃，外星人，微星GS系列，GT系列：土豪专属，不差钱的值得你拥有

性能强劲能够满足任何工作的需求。

第七部分，苹果macbook。。。这个相信大家都明白，就不多解释了

关于品牌，纯属个人观点，如有雷同纯属巧合，请轻喷

购机步骤四：选择购买渠道

众位注意，根据以上描述，大家想必已经想到了买什么型号的笔记本了，那么接下来就是怎么买到手。

首先，分为网购和专卖店，还有大卖场。其中大卖场指的是中关村，华强北等地强烈推荐，不想死的别进去。

专卖店指的是分布于各地的品牌专卖店，这些地方买到的本本质量有保证，价钱稍贵，保修方便

网购的话，某东和某猫的质量可以基本保证，某东的到货快，发票全，某猫的价格便宜，种类全。至于某宝的小店，价钱最便宜，但是质量难以保证。
）。

CPU天梯图

 

显卡天梯图

 

posted @ 2015-02-01 23:34 paulwong 阅读(3053) | 评论 (2) | 编辑 收藏

性能测试资源

http://www.360doc.com/relevant/369752956_more.shtml

posted @ 2015-01-30 00:20 paulwong 阅读(373) | 评论 (0) | 编辑 收藏

几大NOSQL数据库性能比较

Apache Cassandra NoSQL Performance Benchmarks
http://planetcassandra.org/nosql-performance-benchmarks

NoSQL Benchmarking
http://www.cubrid.org/blog/dev-platform/nosql-benchmarking/


http://www.badrit.com/blog/2013/11/18/redis-vs-mongodb-performance#.VMpfW2SUfsg

How many requests per second can I get out of Redis?
http://skipperkongen.dk/2013/08/27/how-many-requests-per-second-can-i-get-out-of-redis/

redis性能测试，测试并发性能
http://my.oschina.net/pblack/blog/102394

posted @ 2015-01-30 00:16 paulwong 阅读(546) | 评论 (0) | 编辑 收藏

Apache自带的压力测试工具——ab初体验

     摘要:   我们知道压力测试的软件确实很多，诸如微软的WAST，惠普的LoadRunner以及等等其他的，但这些软件学习起来还是需要花费些时间，在选择上实在头痛，后来在郭欣的那本《构建高性能WEB站点》上看到了他介绍的这款Apache自带的压力测试工具ab，十分喜爱，于是今天终于有机会体验下ab对网站的压力测试。    实验之前我的apache已经安装了，操作系统：...  阅读全文

posted @ 2015-01-08 19:02 paulwong 阅读(1178) | 评论 (0) | 编辑 收藏

ab --- apache自带的压力测试工具 (apache benchmark )

posted @ 2015-01-08 18:38 paulwong 阅读(2041) | 评论 (0) | 编辑 收藏

修改LINUX能打开的文件的最大数

2、 修改目标
我们的目标是：让每一个用户登录系统后系统打开的最大文件数都是我们设定好的。
但我这里不得不说的是：非常遗憾，网上很多这方面关于ulimit设置修改资源限制的文章，但没一篇文章管用。
把这个目标分解为两个目标：

2.1、设置对root用户登录系统生效
这个目标可以实现起来不难

2.2、设置对所有用户生效
这个就非常麻烦了，弄不好还会把你的系统给整坏，因为要重编译Linux的内核才行！
所以权衡之下，我只实现了第一个目标，因为第二个目标的风险太大，我想如果我之前知道这点，那么我在装系统的时候我会先做这个处理，但现在我觉得已经晚了。

3、 修改的地方

3.1、修改/etc/security/limits.conf
通过 vi /etc/security/limits.conf修改其内容，在文件最后加入（数值也可以自己定义）：
* 表示该配置对所有用户均有效,root用户要特别加两行。

3.2、修改/etc/profile
通过vi /etc/profile修改，在最后加入以下内容
然后重新登录即可生效了。

说明：
其实只修改/etc/profile就可以生效了，但我还是建议把/etc/security/limits.conf也修改一下。
最后强调的是，你如果要使得修改对所有用户都生效，那么现在看来你只能重新编译Linux的内核才行。

3.3 修改/etc/pam.d/login添加如下一行

posted @ 2015-01-07 11:36 paulwong 阅读(549) | 评论 (0) | 编辑 收藏

开源中国 2014 最受关注开源软件排行榜 TOP 50

posted @ 2015-01-07 00:08 paulwong 阅读(679) | 评论 (0) | 编辑 收藏

Mongodb 查询性能的事情

上一篇：Mongodb VS Mysql 查询性能，测试了 mongodb 与 mysql 的查询性能。结果说明 mongodb 性能可以， 可以代替 mysql 来使用。

但是这个测试都是在百万级别，我的场景在 KW 级别。所以还要对 mongodb 在 kw 级别下测试效果。

我测试环境是 4G 内存（有好些内存被其它程序占用），2kw 数据，查询随机生成 id（一次查询 20 个id）。

在这样的环境中测试不理想，比较失望。平均一次查询 500ms（比 mysql 还差，特别是在并发查询下，性能较差。很底的吞吐量）。查看其索引大小（用 db.mycoll.stats() 可以查询）：2kw 数据中有 1.1G 左右的索引，存储的数据在 11G 左右。

测试过程中发现 iowait 占 50% 左右，看来还是 io 的瓶颈。还看到 mongodb 使用的内存不多（小于索引的大小，看来这机器不足够来测试）。

换了个有可用 6G 内存的机器。在 50 个并发下，可以达到平均 100 ms 左右，算比较满意，但是并发好像能力不够强。但这个性能不能由我控制，还由机器的可用内存控制。原因就是 mongodb 没有指定可占用的内存大小，它把所有空闲内存当缓存使用，既是优点也是缺点：优点--可以最大限度提升性能；缺点--容易受其它程序干扰（占用了它的缓存）。由我测试来看，它抢占内存的能力不强。mongodb 是用内存映射文件 vmm，官方的说明：

Memory Mapped Storage Engine

This is the current storage engine for MongoDB, and it uses memory-mapped files for all disk I/O. Using this strategy, the operating system's virtual memory manager is in charge of caching. This has several implications:

There is no redundancy between file system cache and database cache: they are one and the same.
MongoDB can use all free memory on the server for cache space automatically without any configuration of a cache size.
Virtual memory size and resident size will appear to be very large for the mongod process. This is benign: virtual memory space will be just larger than the size of the datafiles open and mapped; resident size will vary depending on the amount of memory not used by other processes on the machine.
Caching behavior (such as LRU'ing out of pages, and laziness of page writes) is controlled by the operating system: quality of the VMM implementation will vary by OS.
所以这么来看，我觉得 mongodb 没有指定内存大小来保证正常的缓存是个缺点。应该至少保证索引全部能放到内存中。但这个行为不是由启动程序决定，而是由环境决定（美中不足）。

官方也有段内容说到索引放到内存中：

If your queries seem sluggish, you should verify that your indexes are small enough to fit in RAM. For instance, if you're running on 4GB RAM and you have 3GB of indexes, then your indexes probably aren't fitting in RAM. You may need to add RAM and/or verify that all the indexes you've created are actually being used.

还是希望 mongodb 中可以指定内存大小，确保它有足够内存加载索引。

小结：大数据量下（kw级）mongodb 并发查询不够理想（100-200/s）。写数据很快（我的环境，远程提交近 1w/s，估计达到 1.5W/s 是没问题的，基本不受大数据量的影响）。

贴个测试数据：

1 id(内存使用 <1.5g) 10 id(内存使用 2-3g) 20 id(内存使用 >4g)
1 2 3 1 2 3 1 2 3
total time 17.136 25.508 17.387 37.138 33.788 25.143 44.75 31.167 30.678
1 thread thruput 583.5668 392.0339 575.1423 269.266 295.9631 397.725 223.4637 320.8522 325.9665
total time 24.405 22.664 24.115 41.454 41.889 39.749 56.138 53.713 54.666
5 thread thruput 2048.76 2206.142 2073.398 1206.156 1193.631 1257.893 890.6623 930.8733 914.6453
total time 27.567 26.867 28.349 55.672 54.347 50.93 72.978 81.857 75.925
10 thread thruput 3627.526 3722.038 3527.461 1796.235 1840.028 1963.479 1370.276 1221.643 1317.089
total time 51.397 57.446 53.81 119.386 118.015 76.405 188.962 188.034 138.839
20 thread thruput 3891.278 3481.53 3716.781 1675.238 1694.7 2617.63 1058.414 1063.637 1440.517
total time 160.038 160.808 160.346 343.559 352.732 460.678 610.907 609.986 1411.306
50 thread thruput 3124.258 3109.298 3118.257 1455.354 1417.507 1085.357 818.4552 819.6909 354.2818
total time 2165.408 635.887 592.958 1090.264 1034.057 1060.266 1432.296 1466.971 1475.061
100 thread thruput 461.8067 1572.606 1686.46 917.209 967.0647 943.1595 698.1797 681.6767 677.9381
上面的测试分别用三种查询（每次 1,10,20 id），在不同并发下测试3次，每次发出 1w 次查询。第一行数据为所有线程累加时间（单位 ms），第二行数据为吞吐量(1w /(total time / thread num))。测试中内存使用慢慢增加，所以后面的数据可能比较高效的（高效的环境）。

从上表看，10 - 20线程比较高的吞吐量。看到内存使用，前提就是索引加载到内存中，并有些内存作为缓存。

下面有个索引查询优化的 pdf。

Indexing and Query Optimizer

Indexing and Query Optimizer (Aaron Staple)
ps:

默认 mongodb 服务器只有10个并发，如果要提高它的连接数，可以用 --maxConns num 来提高它的接收并发的数据。

mongodb 的 java 驱动默认最多只有 10 并发连接池。要提高它，可以在 mongo.jar 的环境中加入 MONGO.POOLSIZE 系统参数，如 java -DMONGO.POOLSIZE=50 ...

posted @ 2015-01-06 23:39 paulwong 阅读(713) | 评论 (0) | 编辑 收藏

关于MongoDB最大连接数的查看与修改

在Linux平台下，无论是64位或者32位的MongoDB默认最大连接数都是819，WIN平台不知道，估计也没有人在 WIN平台下使用MongoDB做生产环境


途中available显示818少了一个，表示空闲的。current表示已经占用了的连接数，两数一加就等于819，如果我现在在连接一个，那么available就是817，current就是2


819个连接数对于一般的站点我认为已经够用，并且都是现连现取现断。但这个连接数也可以修改，只要在启动的时候加入--maxConns即可
服务器启动


查询最大连接数


发现还是819？其实是Linux默认进程能打开最大文件数有关，可以通过ulimit 解决


再查看最大连接数，搞定


关于ulimit的更多知识大家可以去网上检索检索

客户端程序通常是通过DRIVER来链接，由于每次建立链接的成本都挺高，因此都用链接池来实现，SPRING DATA MONGODB中是如下配置

• autoConnectRetry simply means the driver will automatically attempt to reconnect to the server(s) after unexpected disconnects. In production environments you usually want this set to true.

• connectionsPerHost are the amount of physical connections a single Mongo instance (it's singleton so you usually have one per application) can establish to a mongod/mongos process. At time of writing the java driver will establish this amount of connections eventually even if the actual query throughput is low (in order words you will see the "conn" statistic in mongostat rise until it hits this number per app server).

  There is no need to set this higher than 100 in most cases but this setting is one of those "test it and see" things. Do note that you will have to make sure you set this low enough so that the total amount of connections to your server do not exceed

  db.serverStatus().connections.available

  In production we currently have this at 40.

• connectTimeout. As the name suggest number of milliseconds the driver will wait before a connection attempt is aborted. Set timeout to something long (15-30 seconds) unless there's a realistic, expected chance this will be in the way of otherwise succesful connection attempts. Normally if a connection attempt takes longer than a couple of seconds your network infrastructure isn't capable of high throughput.

• maxWaitTime. Number of ms a thread will wait for a connection to become available on the connection pool, and raises an exception if this does not happen in time. Keep default.

• socketTimeout. Standard socket timeout value. Set to 60 seconds (60000).

• threadsAllowedToBlockForConnectionMultiplier. Multiplier for connectionsPerHost that denotes the number of threads that are allowed to wait for connections to become available if the pool is currently exhausted. This is the setting that will cause the "com.mongodb.DBPortPool$SemaphoresOut: Out of semaphores to get db connection" exception. It will throw this exception once this thread queue exceeds the threadsAllowedToBlockForConnectionMultiplier value. For example, if the connectionsPerHost is 10 and this value is 5 up to 50 threads can block before the aforementioned exception is thrown.

  If you expect big peaks in throughput that could cause large queues temporarily increase this value. We have it at 1500 at the moment for exactly that reason. If your query load consistently outpaces the server you should just improve your hardware/scaling situation accordingly.

• readPreference. (UPDATED, 2.8+) Used to determine the default read preference and replaces "slaveOk". Set up a ReadPreference through one of the class factory method. A full description of the most common settings can be found at the end of this post

• w. (UPDATED, 2.6+) This value determines the "safety" of the write. When this value is -1 the write will not report any errors regardless of network or database errors. WriteConcern.NONE is the appropriate predefined WriteConcern for this. If w is 0 then network errors will make the write fail but mongo errors will not. This is typically referred to as "fire and forget" writes and should be used when performance is more important than consistency and durability. Use WriteConcern.NORMAL for this mode.

  If you set w to 1 or higher the write is considered safe. Safe writes perform the write and follow it up by a request to the server to make sure the write succeeded or retrieve an error value if it did not (in other words, it sends a getLastError() command after you write). Note that until this getLastError() command is completed the connection is reserved. As a result of that and the additional command the throughput will be signficantly lower than writes with w <= 0. With a w value of exactly 1 MongoDB guarantees the write succeeded (or verifiably failed) on the instance you sent the write to.

  In the case of replica sets you can use higher values for w whcih tell MongoDB to send the write to at least "w" members of the replica set before returning (or more accurately, wait for the replication of your write to "w" members). You can also set w to the string "majority" which tells MongoDB to perform the write to the majority of replica set members (WriteConcern.MAJORITY). Typicall you should set this to 1 unless you need raw performance (-1 or 0) or replicated writes (>1). Values higher than 1 have a considerable impact on write throughput.

• fsync. Durability option that forces mongo to flush to disk after each write when enabled. I've never had any durability issues related to a write backlog so we have this on false (the default) in production.

• j *(NEW 2.7+)*. Boolean that when set to true forces MongoDB to wait for a successful journaling group commit before returning. If you have journaling enabled you can enable this for additional durability. Refer to http://www.mongodb.org/display/DOCS/Journaling to see what journaling gets you (and thus why you might want to enable this flag).

ReadPreference The ReadPreference class allows you to configure to what mongod instances queries are routed if you are working with replica sets. The following options are available :

• ReadPreference.primary() : All reads go to the repset primary member only. Use this if you require all queries to return consistent (the most recently written) data. This is the default.

• ReadPreference.primaryPreferred() : All reads go to the repset primary member if possible but may query secondary members if the primary node is not available. As such if the primary becomes unavailable reads become eventually consistent, but only if the primary is unavailable.

• ReadPreference.secondary() : All reads go to secondary repset members and the primary member is used for writes only. Use this only if you can live with eventually consistent reads. Additional repset members can be used to scale up read performance although there are limits to the amount of (voting) members a repset can have.

• ReadPreference.secondaryPreferred() : All reads go to secondary repset members if any of them are available. The primary member is used exclusively for writes unless all secondary members become unavailable. Other than the fallback to the primary member for reads this is the same as ReadPreference.secondary().

• ReadPreference.nearest() : Reads go to the nearest repset member available to the database client. Use only if eventually consistent reads are acceptable. The nearest member is the member with the lowest latency between the client and the various repset members. Since busy members will eventually have higher latencies this should also automatically balance read load although in my experience secondary(Preferred) seems to do so better if member latencies are relatively consistent.

Note : All of the above have tag enabled versions of the same method which return TaggableReadPreference instances instead. A full description of replica set tags can be found here :Replica Set Tags

参考网址：
http://api.mongodb.org/java/2.10.1/com/mongodb/MongoClientOptions.Builder.html#connectionsPerHost(int)
https://github.com/spring-projects/spring-data-mongodb/blob/master/spring-data-mongodb/src/main/resources/org/springframework/data/mongodb/config/spring-mongo-1.5.xsd

posted @ 2015-01-06 22:10 paulwong 阅读(5393) | 评论 (0) | 编辑 收藏

TOMCAT调优

1. 安装AB
   
   rpm -ivh http://repo.webtatic.com/yum/centos/5/`uname -i`/webtatic-release-5-0.noarch.rpm
   yum install httpd-tools
   
   
2. 使用AB
   
   ab -r -n 100000 -c 10000 http://10.120.151.223:8080/
   需加-r，则在收到SOCKET错误的时候不会退出
   这段的意思是发送100000个请求，其中并发是10000个
   
   
3. 修改LINUX能打开的文件的最大数
   
   2、  修改目标
   我们的目标是：让每一个用户登录系统后系统打开的最大文件数都是我们设定好的。
   但我这里不得不说的是：非常遗憾，网上很多这方面关于ulimit设置修改资源限制的文章，但没一篇文章管用。
   把这个目标分解为两个目标：
   
   2.1、设置对root用户登录系统生效
   这个目标可以实现起来不难
   
   2.2、设置对所有用户生效
   这个就非常麻烦了，弄不好还会把你的系统给整坏，因为要重编译Linux的内核才行！
   所以权衡之下，我只实现了第一个目标，因为第二个目标的风险太大，我想如果我之前知道这点，那么我在装系统的时候我会先做这个处理，但现在我觉得已经晚了。
   
   3、  修改的地方
   
   3.1、修改/etc/security/limits.conf
   通过 vi /etc/security/limits.conf修改其内容，在文件最后加入（数值也可以自己定义）：
   * soft  nofile = 65536
   * hard  nofile = 65536
   root soft nofile 65536
   root hard nofile 65536
   * 表示该配置对所有用户均有效,root用户要特别加两行。
   
   3.2、修改/etc/profile
   通过vi /etc/profile修改，在最后加入以下内容
   ulimit -n 65536
   然后重新登录即可生效了。
   说明：
   其实只修改/etc/profile就可以生效了，但我还是建议把/etc/security/limits.conf也修改一下。
   最后强调的是，你如果要使得修改对所有用户都生效，那么现在看来你只能重新编译Linux的内核才行。
   
   
   
4. 安装APR，参考：http://jmchung.github.io/blog/2013/09/06/centos-installing-apache-portable-runtime-apr-for-tomcat/
   
   $ wget http://apache.fayea.com//apr/apr-1.5.1.tar.gz
   $ cd /path/to/tomcat/bin
   $ tar zxvf tomcat-native.tar.gz
   $ cd tomcat-native-x.y.z-src/jni/native
   $ ./configure --with-apr=/usr/local/apr --with-ssl=/usr/lib64/openssl
   $ make install
   
   
5. 修改server.xml
   
   <Connector port="8080" protocol="org.apache.coyote.http11.Http11AprProtocol"
           URIEncoding="UTF-8"  
                 enableLookups="false" 
                 tcpNoDelay="true"
           compression="on" compressionMinSize="2048"
           maxThreads="20000" connectionTimeout="-1"
           compressableMimeType="application/json,text/html,text/xml,text/javascript,text/css,text/plain" redirectPort="8443"/>
   
   

https的也要修改：

<Connector SSLEnabled="true" clientAuth="false"
        port="8443" keystoreFile="/root/java/keystore/server.jks" keystorePass="123456"
        protocol="org.apache.coyote.http11.Http11NioProtocol" scheme="https"
        secure="true" sslProtocol="TLS" 
    URIEncoding="UTF-8"  minSpareThreads="25" maxSpareThreads="75"
           enableLookups="false" disableUploadTimeout="true" connectionTimeout="20000"
    acceptCount="1000"  maxThreads="1000" maxProcessors="1000" minProcessors="5"
    useURIValidationHack="false" tcpNoDelay="true"
    compression="on" compressionMinSize="2048"
    compressableMimeType="application/json,text/html,text/xml,text/javascript,text/css,text/plain" />


6. JVM启动参数
   
   JAVA_OPTS="-server -Xms2048m -Xmx2048m -Xss512k -XX:+AggressiveOpts -XX:+UseBiasedLocking -XX:PermSize=128M -XX:MaxPermSize=256M -XX:+DisableExplicitGC -XX:MaxTenuringThreshold=31 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC  -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:LargePageSizeInBytes=128m  -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -Djava.awt.headless=true "

参考网址：
http://www.cnblogs.com/baibaluo/archive/2011/08/23/2150305.html
http://ifeve.com/tomcat-connector-tuning-2/
http://sndapk.blog.51cto.com/5385144/1306278

posted @ 2015-01-06 17:40 paulwong 阅读(512) | 评论 (0) | 编辑 收藏