MySQL服务器的线程数需要在一个合理的范围之内，这样才能保证MySQL服务器健康平稳地运行。Threads_created表示创建过的线程数，通过查看Threads_created就可以查看MySQL服务器的进程状态。

1. mysql> show global status like 'Thread%';  
2. +-------------------+-------+  
3. | Variable_name | Value |  
4. +-------------------+-------+  
5. | Threads_cached | 46 |  
6. | Threads_connected | 2 |  
7. | Threads_created | 570 |  
8. | Threads_running | 1 |  
9. +-------------------+-------+ 

如果我们在MySQL服务器配置文件中设置了thread_cache_size，当客户端断开之后，服务器处理此客户的线程将会缓存起来以响应下一个客户而不是销毁(前提是缓存数未达上限)。

Threads_created表示创建过的线程数，如果发现Threads_created值过大的话，表明MySQL服务器一直在创建线程，这也是比较耗资源，可以适当增加配置文件中thread_cache_size值，服务器
thread_cache_size配置：

1. > show variables like 'thread_cache_size';  
2. +-------------------+-------+  
3. | Variable_name | Value |  
4. +-------------------+-------+  
5. | thread_cache_size | 64 |  
6. +-------------------+-------+ 

最近线上遇到一个问题，接口日志发现有很多超时报错，根据日志定位到数据库实例之后发现一切正常，一般来说接口出现超时排查顺序如下：

　　慢查询 -》连接数 -》 服务器负载 -》网卡流量，但是这次从QPS、连接数、服务器负载、IO消耗、响应时间及慢查询上都非常正常并没有什么异常发生，只有如下这个图有变化。

　　在排除了前端服务器没有出现异常后，看来问题就出现在这个链接数变化上面了。为了看懂上面的图我们先说一下状态值的含义。

1、Max Connections和Max Used Connection

这两个就不细说了，分别是最大链接数限制和每个用户最大链接数限制。

2、Aborted Clients：

The number of connections that were aborted because the client died without closing the connection properly.

当ablort clients增大的时候意味着有客户端成功建立连接，但是很快就断开连接或者被终止了，这种情况一般发生在网络不稳定的环境中。主要的可能性有

　　a）客户端没有主动关闭mysql连接mysql_close()。

　　b）wait_timeout设置很短被mysql干掉了。

　　c）客户端由于某些原因被干掉了。

3、Aborted Connection：

The number of failed attempts to connect to the MySQL server.

当有大量的链接连接不上mysql的时候，这个数值就会激增。主要的可能有：

　　a）没有授权或者密码不对。一般错误日志中会有如下报错（Access denied for ‘user’@‘host’）

　　b）连接数满了。一般报错包含（too many connections）

　　c）超过链接时间限制，主要有这个参数控制connect_timeout（mysql默认是10s，基本除非网络环境极端不好，一般不会超时。）

4、Threads Connected：

The number of currently open connections.

也就是我们经常使用show processlist看见那个数值。

5、Connections

The number of connection attempts (successful or not) to the MySQL server.

所有尝试连接到mysql server的连接数，关键时不管成功还是失败。所以这个数值的增量并不等于show processlist的数值，这点需要注意。

了解以上参数之后，就可以分析这个图了，首先第一反应时连接数有增加，我们可以看到connections和thread connected都增加了，但是没有达到max connections的限制。

在仔细看图下的数据，我们发现abort connection和connections的max值和avg值基本一样，在仔细看图，可以发现蓝线和绿线基本重合了。

从上述参数含义看，在问题时间段所有尝试建立的链接都失败了，导致connections和abort connection同步增加完全重叠。

但是究竟是什么导致链接数上升，前端开始重建链接，由于当时的前端日志没有及时分析出来，故我们就不得而知了。但是有3个怀疑点：

1、由于mysql版本是5.5.12，所以可能遇到了max_connections的bug，可以见这个blog（http://www.cnblogs.com/billyxp/p/3408335.html），这种情况下，前端日志应该有非常多的too many connection是的报错。

2、短时间内有大量的大包传输，导致超过max_allow_packet的限制，导致断开连接。这个设置在server和client上都有，需要同步配置。同时前端应该报Got a packet bigger than ‘max_allowed__packet’ bytes这个报错。

3、超过max_connect_error的限制，导致某一个ip出现问题，不停的重试。（这个可能是最不可能，首先默认数值非常大，其次单个ip不应该出现这么大的影响。max_connect_error代表某一个ip连续失败超过n之后，server会拒绝这个ip的请求，只有flush host cache才可以解封。）

      现在各种国产软件已经牢牢占据了国内市场，无论是在浏览器、下载软件、压缩软件还是视频播放器等领域，都可以看到国产软件活跃的身影。诚然，国产软件在很多方面体验都不错，但之所以它们这么强，很大程度上是因为在核心技术方面，借用了相当多来自开源软件的技术。大家对国产软件都相当了解，但对于国产软件背后的开源软件，又知道多少？今天，就一起来谈谈国产软件背后的开源软件吧。

　　养活了国产浏览器的Chromium

　　国内有很多“极速浏览器”，所使用的是Chrome同样的引擎，这点大家都相当了解。不过，对于Chome背后的开源项目Chromium，大家了解的细节未必就这么多了。Chromium源于Webkit，而Webkit则源于DE开源项目，兴盛于苹果公司的Safari项目，所以说起来Chromium和苹果还是有一些渊源的。但是，Chromium又不仅仅是Webkit，Chrome只是继承了Webkit的WebCore部分，在JS引擎上使用了Google引以为豪的“V8”，还在Webkit上封装了一层Webkit Glue。可以说，Chromium对Webkit进行了相当程度的魔改。

Chromium是一堆国产极速浏览器赖以生存的基本

　　不仅如此，Chromium也已经转用了Blink内核，和Webkit的渊源就更加远了。国内浏览器使用了Chromium的源码，因此现在不少也换用了Blink内核。但是，国产浏览器继承的往往只是Chromium的内核和JS引擎，对其拓展支持部分，却大大被阉割。相较于Chrome，国产浏览器对各种扩展插件的支持都相当弱，往往只能安装修改后的扩展，这也许是出于商业上的原因。虽然国产软件对比Chrome默认多了很多功能，但扩展支持较弱这点，还是令可玩性大减。

　　国产播放器的大奶妈：FFmpeg

　　大家都喜欢用国产播放器看小电影，毕竟国产播放器的功能体验用起来真的不错，能够搜字幕，能够云播，最重要的还是支持格式比较全。但是，很多人并不知道，支持格式全这点，其实和国外的开源项目FFmpeg是息息相关的。

FFmpeg的解码器造就了无数万能播放器

　　FFmpeg是一个和视频处理相关的开源项目，包含了丰富的多媒体解码库。国内的播放器之所以如此万能，很大程度上就是因为使用了FFmpeg的解码库。但是，FFmpeg是基于LGPL/GPL开源的，这意味着如果某软件使用了FFmpeg的代码，那么这个软件涉及这些代码的部分，也必须开源。但是国内的风气嘛，你懂的，白拿了你的东西才不要守规矩。因此，国内的一些“XX影音”被钉在了FFmpeg的耻辱柱上。

　　被占了便宜还被踢出门的7-Zip

　　国内有很多免费的压缩软件，这些压缩软件的功能都挺不错，速度也可以，但内核往往也并非来自自己。国内压缩软件往往使用了7-Zip这款开源软件的内核，来实现众多压缩文件的支持。

　　7-Zip这款开源软件的影响还是非常大的，首先它的效率很高。使用7-Zip编码的话，能够比WinZip和WinRAR提供更高的压缩率。另外它对各种压缩文件支持也非常好，主流的压缩文件基本都给予支持，当然一些商业的压缩格式例如rar，就只能解压不能压缩。由于7-Zip是开源的，所以它的内核被很多其他压缩软件所使用，国产压缩软件通常就是7-Zip的忠实拥簇。

7-Zip在国内不流行的一大原因可能是界面太简陋，但就是这样的风格，社会你7哥，人狠话不多

　　然而，7-Zip也是一款使用了LGPL协议的开源软件，使用了7-Zip的源码，按理来说也必须开源。但国内的“X压”等软件非但没有开源，还在压缩文件的文件头中故意加入无助于压缩的私货，让其他压缩软件无法解压。用了人家的代码还故意制造不兼容，对于这种行为，只想说一句，“我从未见过如此厚颜无耻之人”！

　　为老司机铺开康庄大道的eMule

　　如果你是有些年头的老司机，应该会知道VeryCD和电驴。VeryCD这个站点提供了大量eD2k链接，通过旗下的“电驴”软件，就可以下载到各种资源。虽然现在VeryCD已经转型，但各大下载软件依然对eD2k链接有着良好的支持，各种eD2k资源，也是老司机们飙车时绕不开的路。

　　不过电驴和eD2k背后的eMule“电骡”，大家或许就知之甚少了。其实eD2k协议最早起源于商业公司开发的eDonkey（这才是正牌电驴）分享软件，有个德国人不满这软件，就自己开发了开源的客户端eMule电骡，也支持eD2k协议。国内的VeryCD把eMule电骡的开源代码魔改后，制造出了大家熟知的“VeryCD电驴”。

如果你没用过eMule，你可能不是真正的老司机

　　和eMule电骡这个开源软件相比，其实VeryCD电驴阉割了相当多的东西。例如，不能直接在KAD网络上进行无限制的搜索，这意味着不能无限制地上各种车——现在流行的各种“种子搜索神器”，也只是阉割过的KAD搜索器罢了。现在VeryCD已经衰败，但eD2k仍长存于各大下载软件中，希望大家在开车的同时，也记得背后的eMule这位铺路人。

　　智能路由器的力量之源：OpenWRT

　　现在国内智能路由器可谓是如火如荼，智能路由器对比传统的路由器，功能的确强大很多。例如，可以外接硬盘当NAS用，还可以安装很多第三方插件，实现更强劲的功能。但是，智能路由器所依仗的OpenWRT，却鲜为人知。

没有OpenWRT，就没有一众智能路由器

　　OpenWRT是一款开源的路由器固件，扩展性强是OpenWRT最大的卖点——这也是智能路由器们的最大卖点。OpenWRT源于Linux，其强大的拓展性很大程度上也是得益于Linux。不过和Linux一样，OpenWRT的使用门槛也比较高，原版需要命令行操纵，没有一定的Linux和网络知识还真是无法驾驭。国内的路由器厂商把OpenWRT改造成界面更友好的固件，可以算是OpenWRT的改版。

　　不过，国内的智能路由器固件虽然上手容易，但对比OpenWRT，还是有一些方面例如性能和可玩性方面，是有所不如的。对比OpenWRT，智能路由器固件的性能和稳定性都要偏弱。特别是高流量时候的吞吐性能，差距会显得更加明显；而在扩展方面，由于技术和商业上的原因，可玩性也不如OpenWRT。而且，国内智能路由器厂商使用了OpenWRT，往往也不根据GPL协议继续开源，这些都是很值得批判一番的。

　　总结

　　在这个广告铺天盖地的商业社会，大家很少会听见开源软件的种种消息。闭源的商业软件搭造起了软件世界琳琅满目的繁华，但开源软件也未曾离开过栋梁的位置。诚然，国产软件的很多功能都相当容易上手，但在使用这些商业软件的时候，大家也应该记住背后默默奉献的开源项目，信息时代少了它们，也会失去很多光彩！

     评论：开源软件为中国快速提高软件水平，发展软件实力提供了机会。但是，从开源软件得到了好处，就不应该不按照开源的规则行事。不这样做，软件的水平和实力无法得到提高。开源软件是共产主义思想的果实。

　找到Web站点对应的应用程序池，“应用程序池” → 找到对应的“应用程序池” → 右键“高级设置...”

一、一般优化方案

　　1、基本设置

　　[1] 队列长度： 默认值1000，将原来的队列长度改为 65535。

　　[2] 启动32位应用程序：默认值False，改为True， 否则安装一些32的组建或32位的php都会出错。

　　[3] 托管管道模式：Integrated 或 Classsic。 

　　2、高级设置

　　[1] 闲置超时（分钟）：默认20分钟，修改设长。

　　[2] 快速故障防护 → 已启用 ：默认True，改为False。 

　　3、解决PEP第一次打开PEP速度慢

　　回收间隔时间

　　使用windows server 2008 r2解决回收假死的问题

　　打开应用程序池 -> 高级设置 ->在“禁止重叠回收”里选择“true”，这样就有效避免了应用程序池回收假死问题。

二、支持同时10万个请求

　　通过对IIS7的配置进行优化，调整IIS7应用池的队列长度，请求数限制，TCPIP连接数等方面，从而使WEB服务器的性能得以提升，保证WEB访问的访问流畅。

　　站点碰到如下问题：

　　Error Summary:

　　HTTP Error 503.2 - Service Unavailable
　　The serverRuntime@appConcurrentRequestLimit setting is being exceeded.

　　Detailed Error Information:

　　Module IIS Web Core
　　Notification BeginRequest
　　Handler StaticFile

　　Error Code 0x00000000

　　由于之前使用的是默认配置，服务器最多只能处理5000个同时请求，今天下午由于某种情况造成同时请求超过5000，从而出现了上面的错误。

　　为了避免这样的错误，我们根据相关文档调整了设置，让服务器从设置上支持10万个并发请求。

　　具体设置如下：

　　1. 调整IIS 7应用程序池队列长度

　　将原来的队列长度由默认值 1000 改为 65535。当然这里的队列长度你可以根据自己的 访问用户*1.5 来设置，例如：有2000用户，此处就可以设置为3000(3000=2000用户数*1.5）。

　　2.  调整IIS 7的appConcurrentRequestLimit设置

　　由原来的默认5000改为100000。

　　[1] 在cmd中执行：

　　c:\windows\system32\inetsrv\appcmd.exe set config /section:serverRuntime /appConcurrentRequestLimit:100000

　　[2] 在%systemroot%\System32\inetsrv\config\applicationHost.config中可以查看到该设置：

　　<serverRuntime appConcurrentRequestLimit="100000" />

　　3. 调整machine.config中的processModel>requestQueueLimit的设置

　　[1] 单击“开始”，然后单击“运行”，或者 windows + R。

　　[2] 在“运行”对话框中，键入 notepad %systemroot%\Microsoft.Net\Framework64\v4.0.30319\CONFIG\machine.config，然后单击“确定”。(不同的.NET版本路径不一样，可以选择你自己当前想设置的.NET版本的config)

　　[3] 找到如下所示的 processModel 元素：<processModel autoConfig="true" />

　　[4] 将 processModel 元素替换为以下值：<processModel enable="true" requestQueueLimit="15000" />

　　[5] 保存并关闭 Machine.config 文件。
　　由原来的默认5000改为100000。

<configuration>
    <system.web>
        <processModel enable="true" requestQueueLimit="100000"/>

　　参考文章：http://technet.microsoft.com/en-us/library/dd425294(office.13).aspx

　　4. 修改注册表，调整IIS 7支持的同时TCPIP连接数

　　由原来的默认5000改为100000。在cmd中执行：

　　reg add HKLM\System\CurrentControlSet\Services\HTTP\Parameters /v MaxConnections /t REG_DWORD /d 100000

　　可在注册表中查看

　　5. 运行命令使用设置生效

　　net stop http  & net start  http & iisreset

　　完成上述5个设置，就可以支持10万个并发请求，博客园博客服务器已经启用上述设置。

　　为了方法大家与自己使用，我把上面能用bat操作简单放到一个bat文件里面了。将下面的内容保存为do.bat文件运行就可以了，需要手工的自己操作

三、支持高并发的IIS Web服务器常用设置 　　

　　适用的IIS版本：IIS 7.0, IIS 7.5, IIS 8.0

　　适用的Windows Server版本：Windows Server 2008, Windows Server 2008 R2, Windows Server 2012

　　1、应用程序池（Application Pool）的设置：

　　[1] General->Queue Length设置为65535（队列长度所支持的最大值）
　　[2] Process Model->Idle Time-out设置为0（不让应用程序池因为没有请求而回收）
　　[3] Recycling->Regular Time Interval设置为0（禁用应用程序池定期自动回收）

　　2、.Net Framework相关设置

　　[1] 在machine.config中将
　　< processModel autoConfig="true" />

　　改为

　　<processModel enable="true" requestQueueLimit="100000"/>

　　（保存后该设置立即生效）

　　[2] 打开C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\Browsers\Default.browser，找到<defaultBrowser id="Wml" parentID="Default" >，注释<capabilities>部分，然后在命令行中运行aspnet_regbrowsers -i。以解决text/vnd.wap.wml问题。

　　设置命令：

　　c:\windows\system32\inetsrv\appcmd.exe set config /section:serverRuntime /appConcurrentRequestLimit:100000
　　设置结果：
　　< serverRuntime appConcurrentRequestLimit="100000" />

　　（保存后该设置立即生效）

　　4、http.sys的设置

　　注册表设置命令1（将最大连接数设置为10万）：
　　reg add HKLM\System\CurrentControlSet\Services\HTTP\Parameters /v MaxConnections /t REG_DWORD /d 100000

　　注册表设置命令2（解决Bad Request - Request Too Long问题）：

　　reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\HTTP\Parameters /v MaxFieldLength /t REG_DWORD /d 32768
　　reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\HTTP\Parameters /v MaxRequestBytes /t REG_DWORD /d 32768

　　(需要在命令行运行 net stop http  & net start http & iisreset 使设置生效)

　　5、针对负载均衡场景的设置

　　在Url Rewrite Module中增加如下的规则：

　　注意事项：添加该URL重写规则会造成IIS内核模式缓存不工作，详见微软的坑：Url重写竟然会引起IIS内核模式缓存不工作。

　　6、 设置Cache-Control为public

　　在web.config中添加如下配置：

<configuration>
 <system.webServer>
  <staticContent>
   <clientCache cacheControlCustom="public" />
  </staticContent>
 </system.webServer>
</configuration>

　　在machine.config的<processModel>中添加如下设置：

< processModel enable="true" maxWorkerThreads="100" maxIoThreads="100" minWorkerThreads="50" minIoThreads="50"/>