向东博客 专注WEB应用 构架之美 --- 构架之美，在于尽态极妍 | 应用之美，在于药到病除|赢在IT，Playin' with IT,Focus on Killer Application,Marketing Meets Technology.

没有啥用对我来说，卸载掉：
[root@iZ25dcp92ckZ var]# rpm -qa|grep mail
mailx-12.5-12.el7_0.x86_64
libreport-plugin-mailx-2.1.11-21.el7.centos.0.5.x86_64
[root@iZ25dcp92ckZ var]# rpm -e mailx-12.5-12.el7_0.x86_64
错误：依赖检测失败：
        mailx 被 (已安裝) smartmontools-1:6.2-4.el7.x86_64 需要
        mailx 被 (已安裝) libreport-plugin-mailx-2.1.11-21.el7.centos.0.5.x86_64 需要
[root@iZ25dcp92ckZ var]# rpm -e smartmontools-1:6.2-4.el7.x86_64
[root@iZ25dcp92ckZ var]# rpm -e libreport-plugin-mailx-2.1.11-21.el7.centos.0.5.x86_64
[root@iZ25dcp92ckZ var]# rpm -e mailx-12.5-12.el7_0.x86_64
阅读全文

微信Web开发者工具发布:
http://news.mydrivers.com/1/465/465752.htm

开发者文档:
http://mp.weixin.qq.com/wiki/10/e5f772f4521da17fa0d7304f68b97d7e.html

背景：想用户登录ssh到linux时发邮件里有top，但发现出现top: failed tty get 错误 。
通过其他程序或脚本在非交互式模式下调用top命令，经常会出现:
   top: failed tty get 错误
解决办法：加个-b 选项皆可
-b : Batch mode operation
   Starts  top  in  Batch mode, which could be useful for sending output from top to other programs or to a file.  In this mode, top will not accept input and runs until the iterations limit youve set with the -n command-line option or until killed.
例如执行：top -bn 1


通过其他程序或脚本在非交互式模式下调用top命令，经常会出现:
   top: failed tty get 错误
解决办法：加个-b 选项皆可
-b : Batch mode operation
   Starts  top  in  Batch mode, which could be useful for sending output from top to other programs or to a file.  In this mode, top will not accept input and runs until the iterations limit youve set with the -n command-line option or until killed.
例如执行：top -bn 1


来自：http://blog.chinaunix.net/uid-9554532-id-2000668.html

Unhandled exceptions 无法捕获的原因以及解决方案：
http://name5566.com/934.html

回忆未来-向东-Jàck(372647693)  16:09:29
是超时了。
我这网不好引起的：
//CURLcode res;  
//res = curl_easy_perform(curl);
curl_easy_perform(curl);
//printf("upload file return res=%s\n",res);

这样写就好了，这个res不要，就不会有问题，兄弟们分析是怎么回事导致的？
胡说九道0531(18678088)  16:10:41
可以设置超时时长
回忆未来-向东-Jàck(372647693)  16:11:53
curl_easy_setopt(curl, CURLOPT_TIMEOUT, timeOut);  有的 120.
我是想让兄弟帮我分析为何我去了res就不崩溃了。
simplesslife<zhenglipeng_59@163.com>  16:12:45
打印太费时间了？
去掉printf试试
胡说九道0531(18678088)  16:13:39
我也加了code=
运行非常稳定
回忆未来-向东-Jàck(372647693)  16:14:03
嗯，我呆会去掉打印看下，我快传完了。

curl的回调是啥个意思，这块兄弟们用它干嘛使的？
simplesslife<zhenglipeng_59@163.com>  16:14:57
http返回的数据
用来处理http返回的数据
胡说九道0531(18678088)  16:16:04
就是接收resp
胡说九道0531(18678088)  16:17:50
对于vc的异常的coredump
你搜一下vc setunhandledexceptionfilter
这个关键字就找到了，很多的，我另外一台机器不方便上网，就2个函数


————————————————————————————————————————————————————————
很多软件通过设置自己的异常捕获函数，捕获未处理的异常，生成报告或者日志（例如生成mini-dump文件），达到Release版本下追踪Bug的目的。但是，到了VS2005（即VC8），Microsoft对CRT（C运行时库）的一些与安全相关的代码做了些改动，典型的，例如增加了对缓冲溢出的检查。新CRT版本在出现错误时强制把异常抛给默认的调试器（如果没有配置的话，默认是Dr.Watson），而不再通知应用程序设置的异常捕获函数，这种行为主要在以下三种情况出现。

（1）       调用abort函数，并且设置了_CALL_REPORTFAULT选项（这个选项在Release版本是默认设置的）。

（2）       启用了运行时安全检查选项，并且在软件运行时检查出安全性错误，例如出现缓存溢出。（安全检查选项 /GS 默认也是打开的）

（3）       遇到_invalid_parameter错误，而应用程序又没有主动调用

_set_invalid_parameter_handler设置错误捕获函数。

所以结论是，使用VS2005（VC8）编译的程序，许多错误都不能在SetUnhandledExceptionFilter捕获到。这是CRT相对于前面版本的一个比较大的改变，但是很遗憾，Microsoft却没有在相应的文档明确指出。

解决方法

之所以应用程序捕获不到那些异常，原因是因为新版本的CRT实现在异常处理中强制删除所有应用程序先前设置的捕获函数，如下所示：

/* Make sure any filter already in place is deleted. */

SetUnhandledExceptionFilter(NULL);

UnhandledExceptionFilter(&ExceptionPointers);

解决方法是拦截CRT调用SetUnhandledExceptionFilter函数，使之无效。在X86平台下，可以使用以下代码。

#ifndef _M_IX86

#error “The following code only works for x86!”

#endif



void DisableSetUnhandledExceptionFilter()

{

void *addr = (void*)GetProcAddress(LoadLibrary(_T(“kernel32.dll”)),

“SetUnhandledExceptionFilter”);

if (addr)

{

unsigned char code[16];

int size = 0;

code[size++] = 0×33;

code[size++] = 0xC0;

code[size++] = 0xC2;

code[size++] = 0×04;

code[size++] = 0×00;



DWORD dwOldFlag, dwTempFlag;

VirtualProtect(addr, size, PAGE_READWRITE, &dwOldFlag);

WriteProcessMemory(GetCurrentProcess(), addr, code, size, NULL);

VirtualProtect(addr, size, dwOldFlag, &dwTempFlag);

}

}

在设置自己的异常处理函数后，调用DisableSetUnhandledExceptionFilter禁止CRT设置即可。

其它讨论

上面通过设置api hook，解决了在VS2005上的异常捕获问题，这种虽然不是那么“干净”的解决方案，确是目前唯一简单有效的方式。

虽然也可以通过_set_abort_behavior(0, _WRITE_ABORT_MSG | _CALL_REPORTFAULT), signal(SIGABRT, …), 和_set_invalid_parameter_handler(…) 解决（1）（3），但是对于（2），设置api hook是唯一的方式。

来自：http://www.tiansin.com/thread-645.html

背景：本文作者主要是讲linux下的nginx处理高效是依赖内核驱动事件处理，但是一个一个的事件处理都是建立在一个消息处理队列循环，而这个一个个的循环的一个（一个事件循环）是得一个一个的处理，而OS系统的瓶颈是磁盘IO，而作者认为linux提供的相关磁盘IO异步操作不如FreeBSD的稳健，没有纳入Linux内核而FreeBSD对这块有优势，再就是nginx从应用层上加入了线程池，避免了这个循环被卡住，这两条的解决，真正提升了应用的效率，总之，Nginx对瞬间就处理完的事件上目前还是不错的，而非瞬间就处理完的操作则目前linux和在上面安装低版本的没有线程池支持的nginx来讲，性能并没有得到最大发挥，而这个新版本的nginx（加入了线程池）如果在FreeBSD上，则性能会最优，最后，作者所说的对于不是一瞬间就处理完的业务理论和实践上的确存在，也就是为何对于一些PHP耗时的处理，大多数是安装在apache上，而不是nginx，这也是有这个原因在里面的，很多人一说nginx牛了，就全用nginx，也是没有认真思考，为何大公司都是nginx和apache2同时使用的根源。

step1：
作者显然是有FreeBSD的立场如下：
要命的是，操作系统可能永远没有这个功能。第一次尝试是 2010 年 linux 中引入 fincore() 系统调用方法，没有成功。接着做了一系列尝试，例如引入新的带有 RWF_NONBLOCK 标记的 preadv2() 系统调用方法。所有的这些补丁前景依旧不明朗。比较悲剧的是，因为 持续的口水战 ，导致这些补丁一直没有被内核接受。
另一个原因是，FreeBSD用户根本不会关心这个。因为 FreeBSD 已经有一个非常高效的异步文件读取接口，完全可以不用线程池。

step2：
发文件这块是nginx的软肋，于是用了aio threads来补充：
Nginx从1.7.11开始为AIO(Asynchronous I/O)引入了线程池支持,能够使用多线程读取和发送文件,不会阻塞工人进程.
http://nginx.org/en/docs/http/ngx_http_core_module.html#aio
location /video/ {
sendfile on;
aio threads;
}
要启用多线程支持,configure时需要显式加入--with-threads选项.

step3：php发文件也交给了nginx，提高了效率减轻了sapi的等待时间，也就减少了nginx事件消息处理队列循环等待时间：
比如对于一些需要经过PHP认证身份的附件,可以通过X-Accel-Redirect告诉Nginx文件的路径,让Nginx利用它的线程池读取文件并发送给浏览器,免得阻塞PHP进程.
<?php
auth(); //用户身份认证
header('Content-type: application/octet-stream');
header('Content-Disposition: attachment; filename="'.basename($filePath).'"');
//PHP通过X-Accel-Redirect告诉Nginx文件的路径,Nginx读取文件并发送给浏览器.
header("X-Accel-Redirect: $filePath");
//对比下面直接通过PHP输出文件
//readfile($filePath); //或者echo file_get_contents($filePath);

step4：有人因老外的这篇文章写了评论，http://xiaorui.cc/2015/06/25/%E5%AF%B9%E4%BA%8Enginx%E7%BA%BF%E7%A8%8B%E6%B1%A0thread-pool%E6%8F%90%E9%AB%98%E6%80%A7%E8%83%BD%E7%9A%84%E7%96%91%E6%83%91/

step4涉及到FreeBSD的kqueque，功能角度来盾kqueue比epoll灵活得多。在写kqueue的时候，内核帮你考虑好了不少东西。但是从效率来看，从我作的压力测试来看epoll比kqueue强。估计是学院派自由派的一个哲学问题:
http://jarit.iteye.com/blog/935283
使用 kqueue 在 FreeBSD 上开发高性能应用服务器：
http://blog.csdn.net/xnn2s/article/details/6047038
____________________________________________________________________________
问题
一般情况下，nginx 是一个事件处理器，一个从内核获取连接事件并告诉系统如何处理的控制器。实际上，在操作系统做读写数据调度的时候，nginx是协同系统工作的，所以nginx能越快响应越好。

nginx处理的事件可以是 超时通知、socket可读写的通知 或 错误通知。nginx 接收到这些消息后，会逐一进行处理。但是所有处理过程都是在一个简单的线程循环中完成的。nginx 从消息队列中取出一条event后执行，例如 读写socket的event。在大多数情况下这很快，Nginx瞬间就处理完了。

如果有耗时长的操作发生怎么办？整个消息处理的循环都必须等待这个耗时长的操作完成，才能继续处理其他消息。所以，我们说的“阻塞操作”其实意思是长时间占用消息循环的操作。操作系统可能被各种各样的原因阻塞，或者等待资源的访问，例如硬盘、互斥锁、数据库同步操作等。

例如，当nginx 想要读取没有缓存在内存中的文件时，则要从磁盘读取。但磁盘是比较缓慢的，即使是其他后续的事件不需要访问磁盘，他们也得等待本次事件的访问磁盘结束。结果就是延迟增加和系统资源没有被充分利用。

有些操作系统提供了异步读写文件接口，在nginx中可以使用这些接口（http://nginx.org/en/docs/http/ngx_http_core_module.html?&&&_ga=1.197764335.1343221768.1436170723#aio）。例如FreeBSD就是一个较好的例子，但不幸的是，linux提供的一系列异步读文件接口有不少缺陷。其中一个问题是：文件访问和缓冲需要队列，但是Nginx已经很好解决了。但是还有一个更严重的问题：使用异步接口需要对文件描述符设置O_DIRECT标识，这意味着任何对这个文件的访问会跳过缓存直接访问磁盘上的文件。在大多数情况下，这不是访问文件的最佳方法。


                              ..............


英文原文：Thread Pools in NGINX Boost Performance 9x!
中文翻译：http://www.infoq.com/cn/articles/thread-pools-boost-performance-9x?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global

背景：直接访问ip没有问题，经过cdn后有问题（穿透当dns用，实现故障自动转移，为何不用GSLB[GSLB 是英文Global Server Load Balance的缩写，意思是全局负载均衡。]的dns和类似腾讯的TGW系统，因为没有自己的dns系统...），此时出现http的400错误。
检测办法：在nginx日志的access log中记录post请求的参数值，http://jackxiang.com/post/7728/ 。
发现：这个post的值根本没有取到。而直接绑定IP的就取到了，说明经过了cdn的数据均被干掉了。

而网上常常说是因为header太大引起：
nginx 400 Bad request是request header过大所引起，request过大，通常是由于cookie中写入了较大的值所引起。
每个请求头的长度也不能超过一块缓冲的容量，否则nginx返回错误400 (Bad Request)到客户端。

来自：http://www.linuxidc.com/Linux/2014-06/103685.htm


这个哥们的博客奇怪：
ail -f /opt/nginx/logs/access.log
    116.236.228.180 - - [15/Dec/2010:11:00:15 +0800] "-" 400 0 "-" "-"
    116.236.228.180 - - [15/Dec/2010:11:00:15 +0800] "-" 400 0 "-" "-"

网上大把的文章说是HTTP头/Cookie过大引起的,可以修改nginx.conf中两参数来修正.
代码如下:

    client_header_buffer_size 16k;
          large_client_header_buffers 4 32k;

修改后
代码如下:

    client_header_buffer_size 64k;
         large_client_header_buffers 4 64k;

没有效果,就算我把nginx0.7.62升到最新的0.8.54也没能解决.
在官方论坛中nginx作者提到空主机头不会返回自定义的状态码,是返回400错误.
http://forum.nginx.org/read.php?2,9695,11560
最后修正如下
改为原先的值
代码如下:

    client_header_buffer_size 16k;
         large_client_header_buffers 4 32k;

关闭默认主机的日志记录就可以解决问题
代码如下:

    server {
    listen *:80 default;
    server_name _;
    return 444;
    access_log   off;
    }



说是header过大，关掉日志解决问题，这种乐观主义我是见识到了，呵呵：
http://www.blogjava.net/xiaomage234/archive/2012/07/17/383329.html


Header长度太长，咱能不能打一下nginx的header？
在Nginx里面取这个HEAD用到的是$http_head参数，Nginx里面需要小写：
http://gunner.me/archives/363

1）CURL实现探测：能够找到Content-Range则表明服务器支持断点续传，有些服务器还会返回Accept-Ranges:
[root@iZ25dcp92ckZ src]# curl -i --range 0-9  http://jackxiang.com/template/trielegant/images/bridge-banner-twelve.jpg HTTP/1.1 206 Partial Content Server: nginx Date: Wed, 06 Jan 2016 03:53:12 GMT Content-Type: image/jpeg Content-Length: 10 Last-Modified: Thu, 07 May 2015 03:06:51 GMT Connection: keep-alive ETag: "554ad6cb-a532" Expires: Fri, 05 Feb 2016 03:53:12 GMT Cache-Control: max-age=2592000 Content-Range: bytes 0-9/42290


2)用wget实现分片下载的探测：
[root@iZ25dcp92ckZ src]# wget -S http://jackxiang.com/template/trielegant/images/bridge-banner-twelve.jpg 2>&1 | grep 'Accept-Ranges'   Accept-Ranges: bytes
————————————————————————————————————————————————————————————————
curl -i --range 0-9 http://www.baidu.com/img/bdlogo.gif
HTTP/1.1 206 Partial Content
Date: Thu, 13 Mar 2014 00:20:10 GMT
Server: Apache
P3P: CP=" OTI DSP COR IVA OUR IND COM "
Set-Cookie: BAIDUID=AC9512E1E6932D67A05F4F090DE836FC:FG=1; expires=Fri, 13-Mar-15 00:20:10 GMT;

max-age=31536000; path=/; domain=.baidu.com; version=1
Last-Modified: Fri, 22 Feb 2013 03:45:02 GMT
ETag: "627-4d648041f6b80"
Accept-Ranges: bytes
Content-Length: 10
Cache-Control: max-age=315360000
Expires: Sun, 10 Mar 2024 00:20:10 GMT
Content-Range: bytes 0-9/1575
Connection: Keep-Alive
Content-Type: image/gif
上面是curl获取到的响应头信息，其中如果能够找到Content-Range则表明服务器支持断点续传，有些服务器还会返回Accept-Ranges。

Accept-Ranges：表明服务器是否支持指定范围请求及哪种类型的分段请求

Content-Range：在整个返回体中本部分的字节位置，因为我们请求的是图片的前10个字节，所以Content-Range的值是bytes 0-9/1575，后面的1575是图片总的字节数。

另一种方法
wget -S http://www.baidu.com/img/bdlogo.gif 2>&1 | grep 'Accept-Ranges'
如果能看到输出Accept-Ranges，则表明服务器支持断点续传，否则不支持。

Nginx服务器默认支持断点续传的，无线做任何额外配置。

来自：http://www.letuknowit.com/post/45.html

背景：看一个nginx的404里有<!-- a padding to disable MSIE and Chrome friendly error page -->。
配置：upload_cleanup 400 404 499 500-505;
源码：在nginx源码里有配置位置和定义如下：
./src/http/ngx_http_special_response.c:"<!-- a padding to disable MSIE and Chrome friendly error page -->" CRLF
static u_char ngx_http_msie_padding[] =
"<!-- a padding to disable MSIE and Chrome friendly error page -->" CRLF
"<!-- a padding to disable MSIE and Chrome friendly error page -->" CRLF
"<!-- a padding to disable MSIE and Chrome friendly error page -->" CRLF
"<!-- a padding to disable MSIE and Chrome friendly error page -->" CRLF
"<!-- a padding to disable MSIE and Chrome friendly error page -->" CRLF
"<!-- a padding to disable MSIE and Chrome friendly error page -->" CRLF
;
输出：
<html>
<head><title>413 Request Entity Too Large</title></head>
<body bgcolor="white">
<center><h1>413 Request Entity Too Large</h1></center>
<hr><center>nginx</center>
</body>
</html>
<!-- a padding to disable MSIE and Chrome friendly error page -->
<!-- a padding to disable MSIE and Chrome friendly error page -->
<!-- a padding to disable MSIE and Chrome friendly error page -->
<!-- a padding to disable MSIE and Chrome friendly error page -->
<!-- a padding to disable MSIE and Chrome friendly error page -->
<!-- a padding to disable MSIE and Chrome friendly error page -->
————————————————————————————————————————————————————————
nginx自定义页面非常简单，两条指令就可以搞定
1. 在http{}段加入红色指令，如下
http {
...
        fastcgi_intercept_errors on;        
        error_page  404              /404.html;
...
}

2. 把404页面放到根目录(root指令定义的目录下)，默认是安装目录的html目录下。

3.测试配置是否正确
/usr/local/nginx/nginx -t

4.重新载入配置
kill -HUP `cat /usr/local/nginx/nginx.pid`

注：
自定义的404.html的内容必须大于512字节，否则ie下会显示默认404错误页面，不能显示自定义的404页面。
如果你的404内容小于512字节，可以再404.html的<html>标签后面加入一下内容，可以屏蔽浏览器默认错误提示。
<!-- a padding to disable MSIE and Chrome friendly error page -->
<!-- a padding to disable MSIE and Chrome friendly error page -->
<!-- a padding to disable MSIE and Chrome friendly error page -->
<!-- a padding to disable MSIE and Chrome friendly error page -->
<!-- a padding to disable MSIE and Chrome friendly error page -->
<!-- a padding to disable MSIE and Chrome friendly error page -->

来自：http://www.2cto.com/os/201212/176562.html

背景：天峰兄弟及Swoole的出现解决了长连接问题，但对mysql的线程池还需要进一步解决成一个体系，这块web直接连， 那么连接池也就是多余的 ，RPC形成一个过程也就让性能消耗最小，非常直接且跨平台，再谈一点这块的一个背景：也包括在PHP出现前的WEB1.0阶段，如，在新浪企业邮箱就有基于Sun Solaris 系统上面用c++写Mysql的长连接实现邮箱用户验证登录，那时候的长连接是基于Solaris 下的RPC实现（那时硬件也是sun提供的），对mysql那一端形成一个远程过程的调用，通过XDR数据结构进行解析mysql传来的数据项（RPC也为sun最新提出并后来在linux上默认支持），也就是说像用户登录验证这一块用Mysql的长连接来实现，提高其效率运行相当稳定，后面这个系统迁移到了FreeBSD后，出现了mysql长连接的服务经常出现假死，也就是说进程还在，但是已经连接不上mysql了，重新启动这个RPC服务又好了，原因未知，当时我对c++不了解（现在也不太了解，只听说要看是否形成coredump啥的），当年我还写过一个判断死了就杀死，重启动，判断的程序也老半天回不来，于是我又改成了一个多线程，如果超时没有回来，就干掉那个进程，重启Rpc服务，再后来，这套C++的cgi被替换成了php，再后来基于FreeBSD的系统迁移到了Linux，也就是现在一直在linux上，linux也就强大了起来，回想起来，当年一个登录服务如此极致，现在都变成了直接查询mysql了，这个长连接技术有还有用吗？我只能说对有上千台上万台的服务器可能有用，能节省一定的机器成本罢。但是，追求技术永无止境，需要有这样的一些东西来繁荣我们这个PHP的市场，长连接这个话题不再是Java做成了连接池，像c++也能做成连接池，像腾讯广平就有c++团队还有写cgi实现长连接Mysql服务，据说前二年吧更多关注了H5，像实时技术，比如Tail技术在web上的实现，有转向nodejs的趋势（node试想通过在google这颗大树下提供出来的V8引擎让前端程序员为排头兵统一后端服务及接口），而此时的PHP拿不出这样的技术，是很危险的，有了swoole起到填补作用，我更多的是觉得官方应该重视这个技术，而不是形成一个扩展，像H5的来到，像websocket的进入，这些东西对于Node来讲，从前端向后端的统一，而PHp呢？没有谁来解决，那么从用户角度来讲，开发者用户的流失或迁移，对PHP本身也是一个损失，但我还是说PHP是最好的语言没有之一，期望其能伴随潮流，与时俱进，更好满足当前web端新的需求。

发牢骚：port其实是通过源码编译的，所以不好。FreeBSD这不是都提供了嘛，还要怎么的，有点像人们的皮带，一天不系，你觉得不舒服，要勒紧吗？现代这帮人典型的吃现成的，导致了FreeBSD的没落。
源码包自然有必要提供, 但是你不能要求每个用户用一个软件都编译半天吧，源码的好处是只要你微调得当，性能是最大化的
，然并卵，现在机器性能都挺好，还有8M的嵌入式没法支持，什么不支持，我是发现还有比我懒的人了，听说有交叉编译也不会是在8M上编译啊。

前企业邮箱杀rpc的shell，都快忘记了，做个备份： http://jackxiang.com/post/1273/   2008-9-23 18:31 八年前的事情了。
从Solaris 到FreeBSD再到linux（Centos），其最后居然是linux 居上，而像sun的java被收购，最后FreeBSD的开源太底层（基于系统OS开源），BSD 的代码不是被控制在任何一个人手里，而 Linux的内核基本上被 Linus Torvalds ( Linux创始人)所控制，BSD 并没有单一的人来说什么可以或什么不可以进入代码。但BSD太自由了难度反而大了，人少了是根本原因，再就是商业化的需求没有满足到，被linux干下坡路了，但是，Debian Linux操作系统创始人去世 年仅42岁 ....，我想这个事件会给linux带来不可估量的损失，为什么，debian linux向FreeBSD学习port技术后，发展出的ubutu系统..不说了，反上这个哥们算是能善于学习，他死了...linux社区未来不太好说，但会有波澜是肯定的了。
————————————————————————————————————————————————————————————————
PHP的数据库连接池一直以来都是一个难题，很多从PHP语言转向Java的项目，大多数原因都是因为Java有更好的连接池实现。PHP的MySQL扩展提供了长连接的API，但在PHP机器数量较多，规模较大的情况下，mysql_pconnect非但不能节约MySQL资源，反而会加剧数据库的负荷。

假设有100台PHP的应用服务器，每个机器需要启动100个apache或fpm工作进程，那每个进程都会产生一个长连接到MySQL。这一共会产生1万个My SQL连接。大家都知道MySQL是每个连接会占用1个线程。那MYSQL就需要创建1万个线程，这样大量的系统资源被浪费在线程间上下文切换上。而你的业务代码中并不是所有地方都在做数据库操作，所以这个就是浪费的。

连接池就不同了，100个worker进程，公用10个数据库连接即可，当操作完数据库后，立即释放资源给其他worker进程。这样就算有100台PHP的服务器，那也只会创建1000个MySQL的连接，完全可以接受的。

首先，环境约定如下：
说一下测试环境吧：OS CentOS 7.1 x86；PHP 5.4.44；Mysql 5.7.9-log；swoole-1.7.22。

一）开始编译，网上好多都是编译过了，但是出现某些函数找不到运行时会警告，特别标名一下原因：
以前确实没有好的办法来解决此问题的，现在有了swoole扩展，利用swoole提供的task功能可以很方便做出一个连接池来。
编译时要注意一下：
[root@iZ25dcp92ckZ swoole-src-swoole-1.7.22-stable]# phpize [root@iZ25dcp92ckZ swoole-src-swoole-1.7.22-stable]#./configure --enable-sockets --with-php-config=/usr/local/php/bin/php-config --enable-swoole-debug -enable-async-mysql --enable-ringbuffer --enable-async-mysql=/usr/local/mysql/ [root@iZ25dcp92ckZ swoole-src-swoole-1.7.22-stable]# make && make install
还是出现：[2015-06-29 18:58:24 *9092.0] WARN zm_deactivate_swoole: Fatal error: Call to undefined function swoole_get_mysqli_sock()
因为参数：编译swoole时需要加enable-async-mysql参数来开启 swoole_get_mysqli_sock

php -r "print_r(get_defined_functions());"|grep swoole_get_mysqli_sock 并没发现有这个函数~可能新版本移掉了吧。
实践发现，这块swoole的官方对这块的编译参数并不太提及，不是没有这个函数，这个swoole_get_mysqli_sock函数通过源码里发现是有的。
是因为configure里出现了问题，出现在这儿，对比一下编译且运行Ok的./configure选项就知道了，正确的如下：
[root@iZ25dcp92ckZ swoole-src-swoole-1.7.22-stable]# ./configure --enable-sockets --with-php-config=/usr/local/php/bin/php-config --enable-swoole-debug -enable-async-mysql --enable-ringbuffer --enable-async-mysql
一些博文里的：--enable-async-mysql 后面有路径，这块在swoole-src-swoole-1.7.22-stable里是没有这个路径反而编译正确了。
————————————————————服务端的代码贴在这儿—————————————————————————————
代码如下：
<?php class DBServer {     protected $pool_size = 20;     protected $idle_pool = array(); //空闲连接     protected $busy_pool = array(); //工作连接     protected $wait_queue = array(); //等待的请求     protected $wait_queue_max = 100; //等待队列的最大长度，超过后将拒绝新的请求     /**      * @var swoole_server      */     protected $serv;     function run()     {         $serv = new swoole_server("127.0.0.1", 9508);         $serv->set(array(             'worker_num' => 1,         ));         $serv->on('WorkerStart', array($this, 'onStart'));         //$serv->on('Connect', array($this, 'onConnect'));         $serv->on('Receive', array($this, 'onReceive'));         //$serv->on('Close', array($this, 'onClose'));         $serv->start();     }     function onStart($serv)     {         $this->serv = $serv;         for ($i = 0; $i < $this->pool_size; $i++) {             $db = new mysqli;             $db->connect('localhost', 'root', '**PWD**', '*DbName***');             $db_sock = swoole_get_mysqli_sock($db);             swoole_event_add($db_sock, array($this, 'onSQLReady'));             $this->idle_pool[] = array(                 'mysqli' => $db,                 'db_sock' => $db_sock,                 'fd' => 0,             );         }         echo "Server: start.Swoole version is [" . SWOOLE_VERSION . "]\n";     }     function onSQLReady($db_sock)     {         $db_res = $this->busy_pool[$db_sock];         $mysqli = $db_res['mysqli'];         $fd = $db_res['fd'];         echo __METHOD__ . ": client_sock=$fd|db_sock=$db_sock\n";         if ($result = $mysqli->reap_async_query()) {             $ret = var_export($result->fetch_all(MYSQLI_ASSOC), true) . "\n";             $this->serv->send($fd, $ret);             if (is_object($result)) {                 mysqli_free_result($result);             }         } else {             $this->serv->send($fd, sprintf("MySQLi Error: %s\n", mysqli_error($mysqli)));         }         //release mysqli object         $this->idle_pool[] = $db_res;         unset($this->busy_pool[$db_sock]);         //这里可以取出一个等待请求         if (count($this->wait_queue) > 0) {             $idle_n = count($this->idle_pool);             for ($i = 0; $i < $idle_n; $i++) {                 $req = array_shift($this->wait_queue);                 $this->doQuery($req['fd'], $req['sql']);             }         }     }     function onReceive($serv, $fd, $from_id, $data)     {         //没有空闲的数据库连接         if (count($this->idle_pool) == 0) {             //等待队列未满             if (count($this->wait_queue) < $this->wait_queue_max) {                 $this->wait_queue[] = array(                     'fd' => $fd,                     'sql' => $data,                 );             } else {                 $this->serv->send($fd, "request too many, Please try again later.");             }         } else {             $this->doQuery($fd, $data);         }     }     function doQuery($fd, $sql)     {         //从空闲池中移除         $db = array_pop($this->idle_pool);         /**          * @var mysqli          */         $mysqli = $db['mysqli'];         for ($i = 0; $i < 2; $i++) {             $result = $mysqli->query($sql, MYSQLI_ASYNC);             if ($result === false) {                 if ($mysqli->errno == 2013 or $mysqli->errno == 2006) {                     $mysqli->close();                     $r = $mysqli->connect();                     if ($r === true) continue;                 }             }             break;         }         $db['fd'] = $fd;         //加入工作池中         $this->busy_pool[$db['db_sock']] = $db;     } } $server = new DBServer(); $server->run();

rango有一个更详细的连接池服务端的代码放这儿了：
http://rango.swoole.com/archives/288

二）客户端代码如下：
<?php function dbcp_query($sql){     $link=new swoole_client(SWOOLE_SOCK_TCP,SWOOLE_SOCK_SYNC);//TCP方式、同步     $link->connect('127.0.0.1',9509);//连接     $link->send($sql);//执行查询     die(var_dump($link->recv()));     return unserialize($link->recv()); //这行会报错，注释掉了：PHP Notice:  unserialize(): Error at offset 0 of 292 bytes in /data/htdocs/mysql.swoole.com/mysqlSwooleCli.php on line 6     //swoole_client类析构时会自动关闭连接 } $sql="SELECT * FROM `boblog_links` limit 1"; $dbRetArr = dbcp_query($sql); var_dump($dbRetArr);

三）运行一下看有没有返回：
[root@iZ25dcp92ckZ mysql.swoole.com]# php  mysqlSwooleCli.php
string(292) "array (
  0 =>
  array (
    'linkid' => '3',
    'linkname' => '猪头党乐园',
    'linkurl' => 'http://www.gipsky.com/',
    'linklogo' => '',
    'linkdesc' => '',
    'linkgptoid' => '19',
    'linkorder' => '3',
    'isdisplay' => '1',
    'empty1' => '',
    'empty2' => '',
  ),
)
"

最后，这个到底是不是真长连接在mysql这儿了呢？我们验证一下，连接mysql看下：
mysql> show processlist; +------+------+-----------+-----------------+---------+------+----------+------------------+ | Id   | User | Host      | db              | Command | Time | State    | Info             | +------+------+-----------+-----------------+---------+------+----------+------------------+ | 8047 | root | localhost | jack'sDbName | Sleep   |  616 |          | NULL             | | 8048 | root | localhost | jack'sDbName | Sleep   |  616 |          | NULL             | | 8049 | root | localhost | jack'sDbName | Sleep   |  616 |          | NULL             | | 8050 | root | localhost | jack'sDbName | Sleep   |  616 |          | NULL             | | 8051 | root | localhost | jack'sDbName | Sleep   |  616 |          | NULL             | | 8052 | root | localhost | jack'sDbName | Sleep   |  616 |          | NULL             | | 8053 | root | localhost | jack'sDbName | Sleep   |  616 |          | NULL             | | 8054 | root | localhost | jack'sDbName | Sleep   |  616 |          | NULL             | | 8055 | root | localhost | jack'sDbName | Sleep   |  616 |          | NULL             | | 8056 | root | localhost | jack'sDbName | Sleep   |  616 |          | NULL             | | 8057 | root | localhost | jack'sDbName | Sleep   |  616 |          | NULL             | | 8058 | root | localhost | jack'sDbName | Sleep   |  616 |          | NULL             | | 8059 | root | localhost | jack'sDbName | Sleep   |  616 |          | NULL             | | 8060 | root | localhost | jack'sDbName | Sleep   |  616 |          | NULL             | | 8061 | root | localhost | jack'sDbName | Sleep   |  616 |          | NULL             | | 8062 | root | localhost | jack'sDbName | Sleep   |  616 |          | NULL             | | 8063 | root | localhost | jack'sDbName | Sleep   |  616 |          | NULL             | | 8064 | root | localhost | jack'sDbName | Sleep   |  616 |          | NULL             | | 8065 | root | localhost | jack'sDbName | Sleep   |  616 |          | NULL             | | 8066 | root | localhost | jack'sDbName | Sleep   |  160 |          | NULL             | | 8144 | root | localhost | NULL            | Query   |    0 | starting | show processlist | +------+------+-----------+-----------------+---------+------+----------+------------------+

还有问题？优化如下，我提出我为何要坚持引入RPC的原因：
摘录来自：http://bokjan.com/prog/php-db-conn-pool-with-swoole.html  现在没了。
现在可以运行了，本次实验是成功的。但是如果使用dbcp_query()这个函数，每次调用都要发起一次TCP连接，执行的语句多了，肯定出问题。这个时候我们就可以把它封装成一个类了，单纯实现这个会比较的简单，但是打出来要点时间，这里就不写了。

我的看法：对于这位兄弟提到的每次调用都要发起一次TCP连接，而这个问题在RPC里直接供给前端WEB会得到很好的解决，为什么呢？
目前这种搞法是：一个web请求来到服务器后，这个服务器再生成一个连接swoole的连接池的端口，这儿是：9508端口它再去长连接Mysql的3306端口。
那么，如果每次来一个用户这个9508就会再进去一个连接，再到Mysql的3306接口，这块这个9508取到数据完后，销毁这个socket的fd句柄，来得越多，
这个是不是就会出现很多句柄在这儿生生死列，也就是上面这个兄弟讲的每次调用都要发起一次TCP连接，执行的语句多了，肯定出问题。不是封装的事，
而这种架构在我看来本来就有问题，为此，我提出我的一个引入RPC的看法，以解决每次都生生死死的效率问题，思路如下：
这块RPC引入带来了额外的XDR兼容跨平台的数据接口的打包、解包、返回同样需要打包，再到客户端揭包的一个客外的socket数据流量，不是RPC最大8K性能问题所在。
架构如下：在每台服务器上的RPC服务器上启动一次性多个RPC，每个RPC连接一个Mysql的长链接，而rpc的client直接放到Apache/nginx的cgi目录下，这样从
Web端传过来的请求，直接通过WEB传到RPC服务器器直达Mysql，而这个RPC服务服务这块并不需要重新销毁重新生成请求，有更多连接过来只是再多起几个RPC的server（同时Mysql的长连接也多了几个），也就是说通过RPC的Client与RPC的Server长连接类似KeepAlive，直接打通了Mysql数据库，这样提高了效率，因为这个连接池不管怎么样，都需要给web端来访问，当前解决的就是web端用户一下就来了很多人的一个问题，还形成了可扩展的一个Client和Server模型。
总之的总之，Rpc调用远程就像调用一个函数一样，避免了重新销毁重新生成请求的一个消耗，也避免了下面的serialize和unserialize的一个性能问题，也就真正实现了最大化性能和架构可扩展的解决方案，也就是为何我建议加一个RPC功能，把底层做到极致，通过简单配置就能打通Mysql的各个表结构。

最后：今天做的是数据库连接池的实现。从上面的代码我们可以看见，程序与连接池之间的数据交换是使用php序列进行的。这里会有两次的serialize、unserialize，绝对也是一个开销。Rango的文章里面有说到“MySQL是每个连接会占用1个线程……大量的系统资源被浪费在线程间上下文切换上……不是所有地方都在做数据库操作，所以这个就是浪费的。”再看看他那篇文章的假设：“假设有100台PHP的应用服务器，每个机器需要启动100个apache或fpm工作进程。”这肯定不是一个小项目，确实就适合用连接池了。写的东西是用来练手或者解闷儿的？常规方法已经可以了。不要忘了一点：程序与连接池的交互我们应该还是用Swoole实现的，Swoole可是一个TCP/UDP扩展。而Swoole只能运行在Linux平台上面，但是Linux平台上的MySQL是可以用UNIX Socket通讯的。

来自：http://rango.swoole.com/archives/265
http://bokjan.com/prog/php-db-conn-pool-with-swoole.html

背景： 磁盘没空间了，du -sh ./var/spool/clientmqueue   2.8G    ./var/spool/clientmqueue
____________________________________________________________________
今天收到nagios报警邮件，其中一台server中的磁盘分区空间超过95%，登录到服务器查看

[root@hadoop-node-29 ~]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda5              19G   16G  2.8G  95% /var

到目录/var查看哪个目录中的文件最大

[root@hadoop-node-29 var]# du -sh *

找到是/var/spool目录占了很大空间，进入spool目录继续查看 找到是clientmqueue目录中的文件很多占了大部分空间。

删除所有文件
[root@hadoop-node-29 clientmqueue]# rm -rf *
结果返回-bash: /bin/rm: Argument list too long

换用命令find . -print|xargs rm  过了一段时间终于删除了所有文件

不过这种方法只是治标不治本的方法。

为什么var/spool/clientmqueue会产生大量的文件呢，查资料是因为cron执行时会将相关结果以mail方式发送到执行用户的帐号，可是当sendmail 沒有启动 那么所有信件就会暂存在这个目录中，此时就会出现这种情况。

治本的方法是在cron 任务中的后面加上 > /dev/null 2>&1

例如

* * * * * /etc/init.d/snmp_cron.sh > /dev/null 2>&1

参考http://blog.xuite.net/david.welltake/home/45865306-%2Fvar%2Fspool%2Fclientmqueue+%E4%BD%94%E7%94%A8%E7%A3%81%E7%A2%9F%E7%A9%BA%E9%96%93%E7%9A%84%E5%95%8F%E9%A1%8C+linux

背景：对/下的文件大小作统计但想排除一些文件夹。
想计算一下/tmp的总空间,但想排除/tmp//tmp/ssh-sdgAM28929
du -h /tmp --exclude=/tmp/ssh-sdgAM28929

看起来--exclude=/tmp/ssh-sdgAM28929并没有工作
--exclude=PATTERN 不是一个路径，我觉得你可以--exclude="ssh-sdgAM28929"


[root@localhost ~]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda6              15G   14G     0 100% /
/dev/sda7             743G   67G  639G  10% /data
/dev/sda3              19G  5.2G   13G  29% /usr
/dev/sda2              19G  4.4G   14G  25% /var
/dev/sda1             494M   22M  447M   5% /boot
tmpfs                 7.9G  125M  7.8G   2% /dev/shm
10.70.32.53:/upload   796G   38G  717G   6% /upload

du -sh /* --exclude=/data --exclude=/usr --exclude=/var --exclude=/boot --exclude=/upload
7.0M    /bin
8.0K    /convert
125M    /dev
139M    /etc
244M    /home
196M    /lib
20M     /lib64
4.0K    /logs
16K     /lost+found
8.0K    /media
8.0K    /misc
12K     /mnt
8.0K    /net
0       /opt
4.0K    /playRecord.php
0       /proc
428M    /root
31M     /sbin
8.0K    /selinux
8.0K    /srv
4.0K    /sync
0       /sys
15M     /tmp

背景：那个gcc被锁定有点好玩，看来这里面问题还是有很多。
百度的 GCC 被三体人锁定在 3.4.5 版本是什么典故？
著作权归作者所有。
商业转载请联系作者获得授权，非商业转载请注明出处。
作者：布丁
链接：https://www.zhihu.com/question/21042367/answer/71690766
来源：知乎

佩服百度人民坚守传统的精神。百度的 gcc 还曾经有很长一段时间被锁定在了 gcc 2.96, 当年升级到 gcc 3 的时候那个喜大普奔。记得之前有人质疑我说百度在很长时间禁止大部分 C++ feature 的真实性, 你在这版本上玩 C++ 试试……我没写错，是 2.96，你在 GNU 的主页上查不到 gcc 2.96 这个版本的，这是一个 RedHat 的私家 branch... http://www.redhat.com/advice/speaks_gcc.html 这酸爽。我不了解现在百度的情况，以下讲述的是 6 年前还被锁定在 2.96 时代的事，当故事听就好。其实就是软件管理没做好，这在创业阶段不算个事，但是到发展壮大了还没跟上只能怪自己。一堆无人维护却躲不开的库，很多库是二进制发布把源码像什么似的供着直接造成编译器和glibc版本依赖锁定（当年有幸看过一眼源码，那代码质量简直了），有的甚至干脆找不到可靠的源码（没有可靠源码是指，你手上的源码是编译不出跟生产环境一样的binary的，生产环境上的有可能是某次紧急改bug上线的遗迹，连代码提交都没留下来）。基本没有 unittest 鬼知道刷个版本会发生什么事，还有好多上古传奇人物留下的谜之代码，不乏 /* 别删这行删了会挂虽然我也不知为啥 */ 的注释，又没人有这个闲功夫重写，都被当成 taboo 一样留在那了呗。对了，百度有很长时间把模块线上 core dump 数目作为软件质量评价指标，计入 KPI 的，而不是去改进  fault tolerence 机制让有缺陷的程序相对健康地跑着。这种激励机制，谁吃饱了撑着去升级版本做重构拼 core dump 嘛。

来自：https://www.zhihu.com/question/21042367

实践发现：需要对某些目录不提交，如android开发里的bin gen 文件夹不需要提交，这儿大多介绍了在eclipse下怎么样忽略目录，对svn客户端只有方法四，
方法四是在svn客户端里设置可以的，但是要像方法三的目录忽略（方法三里试了下右键后没有那个忽略的选项：Add to ignore list，下面会单独说这个），方法二中如果没有装eclipse（在 Eclipse 中）其右键好像没有这个功能。

如果我们更新的时候能让SVN不更新这部分资源就好了，可惜的是TortoiseSVN就有这功能。
将资源排除在SVN控制之内：
右键单击文件夹 -> TortoiseSVN -> Unversion and add to ignore list -> 文件夹名称

将资源重新纳入至SVN控制：
如果你要重新纳入的文件已经在本地不存在，那么你可以从SVN上重新Checkout一份. 但重新Checkout下来的文件夹仍然没有纳入到SVN控制中。
右键单击该文件夹 -> TortoiseSVN -> Clean up -> 在弹出的对话中统统都打勾 -> 再次Update


设置SVN忽略文件和目录（文件夹）:
http://blog.csdn.net/hemingwang0902/article/details/6904205
TortoiseSVN (一) - 疑难操作：
http://blog.sina.com.cn/s/blog_74c22b210101cy3s.html

背景：前些天在淘宝上的一台vps出现了宕机，转载如下：【阿里云】尊敬的XXX@qq.com：您的云服务器（120.206.54.108）出现宕机，阿里云正在进行宕机保护性迁移，恢复时会第一时间通知您，谢谢。您好，您的ECS本地磁盘实例i-258cfosv4发生了宕机迁移，请您注意尽快恢复数据恢复业务。【阿里云】
一个Linux服务是基于centos7的，居然宕机了，这种情况要么是阿里云水平不行，要不就是linux不稳定导致，不管那么多，但从坚如磐石来讲，还得是FreeBSD，像之前的像邮件服务器啥的磁盘管理来讲都是用FreeBSD，后因为FreeBSD人越来越少（到现在FreeBSD连筹集个项目都只筹集到一半的钱，发动不起来。）推广问题等，像基于linux人相对多一些，大家都跑linux上了（Linux更符合Web的端的webserver和DB性能的需求变化），回想当我刚毕业时接受的就是FreeBSD，于是搜索了一下FreeBSD，发现阿里云也卖FreeBSD，不求其高性能，求其稳定如磐石即可，是我现在的一个新的需求。
——————————————————————————————————————————————————————————————————————————

     阿里云貌似最近推出了FreeBSD镜像，这是我最喜欢的操作系统，个人看法比Linux好太多了。但是阿里云方面文档没有跟上，无任何挂载硬盘相关的操作说明，所以记录一下在阿里云FreeBSD镜像环境下挂载云磁盘的操作过程。

用dmesg查看云硬盘在/dev的设备号，在xen环境的linux里是xvdb1，FreeBSD下通常是xbd1，由于xbd1未按照freebsd标准分区格式化，所以，如直接mount /dev/xbd1 /opt会报错，Invalid augument什么的。
分区格式化，先初始化磁盘
dd if=/dev/zero of=/dev/xbd1 bs=1k count=1
fdisk -BI /dev/xbd1 (完事会出来xbd1s1)
disklabel -B -w -r /dev/xbd1s1 auto
newfs /dev/xbd1s1
mount /dev/xbd1s1 /opt
echo "/dev/xbd1s1     /opt            ufs     rw      1       1" >> /etc/fstab，中间用tab分割

完成
--------20150806修订--------
FreeBSD 10取消pkg_add的等命令，用pkg代替，pkg安装在GFW环境下比较靠谱，中间曾发现rrdtool被GFW屏蔽，无法通过ports编译安装。

转载自：http://slaytanic.blog.51cto.com/2057708/1679151

很久很久以前，一个叫AT&T贝尔实验室的家族生下了一个叫Unix的婴儿。随着Unix的成长，大家都对Unix特别喜爱。贝尔实验室非常骄傲的到处拿Unix摆显。一个叫Berkeley的少女被贝尔吸引，一夜风流过后，Berkeley怀了孕，生下了BSD。
Unix和BSD都逐渐长大。AT&T发现Unix非常能挣钱，但是BSD却专门帮助人们而仅仅收取点感谢费。这样BSD名声渐大，严重影响了Unix的业务。于是AT&T找到Berkeley说BSD不是你一个人的，我是BSD的父亲，BSD不能这么给人办事不收费用。
而Berkeley却不领AT&T的情，说BSD在自己的家里长大，完全是自己的孩子。AT&T翻脸了，把Berkeley告到法庭要取得部分监护权。
官司一打就是十年。BSD就是被折磨了十年。人生能有几个十年？十年中，社会发生了巨大的变革，互联网风靡世界，PC机逐渐成了人们的日常工具，人们开始使用一种叫手机的东西通信。中国开始改革开放。苏联开始崩溃。而BSD只能呆在校园里望着校外的世界潮涨潮落，云卷云舒。
随着AT&T把自己的亲生孩子卖给了Novell。Novell决定迅速结束这场官司。于是最终官司庭外和解。Berkeley退还了一些当年贝尔送给自己的礼物。BSD的兄弟Unix改名System V，此后几经转手，最终社会的风霜将他雕刻成一个高冷的人。如今你会在少数高档场所见到他冷俊的面孔。
自由了的BSD被Berkeley重新打扮一番后，把他叫到面前说：如今你已经长大，不能在妈妈的家里闲着了，该到社会上闯荡了。
BSD满含着热泪离开了Berkeley。开始了他的社会生活。
BSD遇到了一个叫Sun的富家小姐，BSD秉承了他爹的基因，跟Sun一夜风流后，Sun生下了Solaris。
BSD在PC上建立了一个家，并把自己改名自由BSD（FreeBSD）。来纪念自己如同蹲监狱的十年屈辱时光。
有人想把他请到各种场所做客，那些场合他被叫做NetBSD。以及人们从NetBSD装扮出来的OpenBSD。
FreeBSD经过发展，名声渐大，在一次宴会中遇到了淫荡公主（Slut Princess）苹果。他们一见生情，几经来往后，Apple生下了OS X。OS X出现在苹果的各种社交场所。后来OS X又生下了iOS。iOS这个女人秉承了她奶奶的美丽与淫荡。各种装逼耍酷的场所，她都会出现。
FreeBSD跟Apple交往后，变得越发淫荡风流。跟原来的穷小子不一样了，穿着时尚，装逼耍酷样样都行。吸引了社会上的一些大姑娘小媳妇跃跃欲试。从此过上了没羞没臊的幸福生活。

这是个故事 与事实不符的地方：
AT&T 之所以给别人源代码是因为司法部的垄断协议，其不准经营电脑业务。
官司打了四年而非十年，不过这四年正是个人电脑疯狂发展的时机。
AT&T的unix命名为system v是在官司之前，而非之后。因为它被起诉垄断拆解成八个公司，当然这时它又可以经营电脑业务了。
Sun根据bsd做出的系统开始叫SunOS。远在官司之前。后来，他与at&t合作用System iv做出Solaris 2.0。并把以前的sunOS命名为Solaris 1.0
at&t固执的维护unix版权使其丧失开发活力。system v几经转手停止开发。其它厂商根据它开发了自己的系统比如Sun的Solaris，HP的HP-UX，IBM的AIX

来自：tieba.baidu.com/p/3653259841

今天用SSH连接我的远程主机，出现了以下错误：
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

Someone could be eavesdropping on you right now (man-in-the-middle attack)!

网上查了一下，用

rm -rf .ssh/known_hosts

删除主机列表就行了。

删除的是连接方的主机即可：
mv /root/.ssh/known_hosts /root/.ssh/known_hosts.bak

来自：http://blog.csdn.net/westsource/article/details/6636096



@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
b5:ea:d8:91:4e:98:b8:c7:af:55:c0:e4:68:ff:00:d3.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending key in /root/.ssh/known_hosts:104
RSA host key for 10.71.182.7* has changed and you have requested strict checking.
Host key verification failed.

背景：Nginx代理PHP9000端口的接口里发现一些499........[23/Dec/2015:10:21:59 +0800] "POST /videoupload.php HTTP/1.1" 499 0 "-" "Mozilla/5.0 (compatible; KoPHP v3.0 +http://kophp.com/)" - "5.005"
日志记录中HTTP状态码出现499错误有多种情况，我遇到的一种情况是nginx反代到一个永远打不开的后端，就这样了，日志状态记录是499、发送字节数是0。

    老是有用户反映网站系统时好时坏，因为线上的产品很长时间没有修改，所以前端程序的问题基本上可以排除，于是就想着是Get方式调用的接口不稳定，问了相关人员，说没有问题，为了拿到确切证据，于是我问相关人员要了nginx服务器的日志文件（awstats日志），分析后发现日志中很多错误码为499的错误，约占整个日志文件的1%，而它只占全部报错的70%左右（全部报错见下图），那么所有报错加起来就要超过1%了，这个量还是特别大的。

    499错误是什么？让我们看看NGINX的源码中的定义：

ngx_string(ngx_http_error_495_page), /* 495, https certificate error */
ngx_string(ngx_http_error_496_page), /* 496, https no certificate */
ngx_string(ngx_http_error_497_page), /* 497, http to https */
ngx_string(ngx_http_error_404_page), /* 498, canceled */
ngx_null_string,                    /* 499, client has closed connection */

    可以看到，499对应的是 “client has closed connection”。这很有可能是因为服务器端处理的时间过长，客户端“不耐烦”了。

    Nginx 499错误的原因及解决方法
    打开Nginx的access.log发现在最后一次的提交是出现了HTTP1.1 499 0 -这样的错误，在百度搜索nginx 499错误，结果都是说客户端主动断开了连接。
    但经过我的测试这显然不是客户端的问题，因为使用端口+IP直接访问后端服务器不存在此问题，后来测试nginx发现如果两次提交post过快就会出现499的情况，看来是nginx认为是不安全的连接，主动拒绝了客户端的连接.

    但搜索相关问题一直找不到解决方法，最后终于在google上搜索到一英文论坛上有关于此错误的解决方法：
proxy_ignore_client_abort on;
Don’t know if this is safe.
    就是说要配置参数 proxy_ignore_client_abort on;
    表示代理服务端不要主要主动关闭客户端连接。

    以此配置重启nginx,问题果然得到解决。只是安全方面稍有欠缺，但比总是出现找不到服务器好多了。

    还有一种原因是 我后来测试发现 确实是客户端关闭了连接,或者说连接超时 ,无论你设置多少超时时间多没用 原来是php进程不够用了 改善一下php进程数 问题解决 默认测试环境才开5个子进程。

来自：http://wmcxy.iteye.com/blog/2026835?&from=androidqq

Hash贯穿了PHP的数组、对象，总之，这个hash是个很基础重要的东西：
http://blog.csdn.net/heiyeshuwu/article/details/44259865