背景:作为swoole顾问,当然需要对新版本发布作下相关的描述,一直想rango推rpc,此次暂搁置了,底层实现对RPC性能提升没有多大意义,swoole应该专注php的弱点,而不是把所有的东西都封装到底层,成为大杂会。觉得能用PHP实现的不再实现,定位上只是对PHP功能的增强。总之,1.8.0 是一个里程碑的版本。

最好要在PHP版本V5.4以上运行,对各种DB和缓存及服务器客户端的异步支持以高效利用IO:
增加原生异步 MySQL 客户端
增加原生异步 Redis 客户端,基于 Redis 官方提供的 hiredis 库
增加原生异步 Http 客户端
增加原生异步 WebSocket 客户端支持
——————————————————————————————————————————
....各种优化及bug修改相关特性融入内核....
重构底层 swClient,异步 TCP 客户端实现放到 swoole 内核中
增加 swoole_client->reuse 属性,SWOOLE_KEEP 长连接模式下标识是否为复用的连接
修改Bug:重构定时器,修复after、tick定时器偶然出现的core dump的问题
新加特性:异步Redis客户端
预告一下:1.8.1 版本,即将增加 命名空间的类别名
计划搁置:RPC暂时没有开发计划,因为这个东西PHP代码就能实现,没必要底层去支持。
——————————————————————————————————————————
Swoole-1.8.0版本增加了对异步Redis客户端的支持,基于redis官方提供的hiredis库实现。Swoole提供了__call魔术方法,来映射绝大部分Redis指令。

编译安装hiredis

使用Redis客户端,需要安装hiredis库。下载hiredis源码后,执行

make -j
sudo make install
sudo ldconfig
hiredis下载地址:https://github.com/redis/hiredis/releases
启用异步Redis客户端

编译swoole是,在configure指令中加入--enable-async-redis

./configure --enable-async-redis
make clean
make -j
sudo make install

来自:http://wiki.swoole.com/wiki/page/521.html
更多:http://www.oschina.net/news/70266/swoole-1-8-0
背景:阿里上买了一小vps,空间本来就小,居然发现一个大文件,442M    /var/log/cron,于是想把它干掉,以减少占用的磁盘空间。
我的vps是一个文件:
echo "" >  /var/log/cron
du -sh /var/log/cron
而有的那个机器是一个目录,目录怎么办,一样删除,如下:
最近刚好有一个小任务 - 由于产品产生的Log很多,而且增长很快,所以需要用脚本(Bash scripts)删除过期的Log文件 。

使用Linux下的Cron Job可以很好的解决这个问题。

   什么是Cron Job?
   建立Cron Job需要用到命令crontab,维基百科定义: crontab 命令常见于Unix和类Unix的操作系统之中,用于设置周期性被执行的指令 。
查阅了一些资料(发现技术查询还是要用Google)参考后,期间也遇到很多问题,通过摸索和学习,实现步骤如下:

一. 写一个Bash shell script,作用: 检索日志文件夹下的所有log文件,查询每个文件的日期,如果日期过期,则删除这个log文件   


二. 新建一个Cron Job,周期性的执行上面的脚本
命令:


注意:
1. 这里我用的是 sudo crontab -e ,不是crontab -e,这样做是使用root的crontab,可以使用sudo,获取root某些权限。
2. Cron Job的格式如下:


具体可参见http://www.cyberciti.biz/faq/how-do-i-add-jobs-to-cron-under-linux-or-unix-oses/,Cron Job的用法讲解很详细。

3. 如何通过日志查看Cron Job的执行情况?

" >> /home/user/cron_job.log 2>&1 "的作用是可以方便的将Cron Job执行情况的日志记录到自己指定的Log文件中,方便查看Job执行情况。另外还可通过下面这个命令,查看Job执行的一些其他信息,感觉主要还是看自己指定的日志文件,如果执行出错,如Permisson Denied错误,在里面记录的很清楚。


三. 小结

经过以上的步骤,就可以很轻松的在Linux中建立起一个Cron Job,用于周期性的做某些事情,如删Log等。

四. 赔偿是参考资料和摘自:
原文  http://www.cnblogs.com/KevinSong/p/3816981.html
安装Nginx:

wget --no-check-certificate http://ftp.exim.llorien.org/pcre/pcre-8.39.tar.bz2
wget --no-check-certificate http://nginx.org/download/nginx-1.11.6.tar.gz
tar xf pcre-8.39.tar.bz2
tar xf nginx-1.11.6.tar.gz
cd nginx-1.11.6/

vi auto/lib/openssl/conf

# 将下面的内容修改
            CORE_INCS="$CORE_INCS $OPENSSL/.openssl/include"
            CORE_DEPS="$CORE_DEPS $OPENSSL/.openssl/include/openssl/ssl.h"
            CORE_LIBS="$CORE_LIBS $OPENSSL/.openssl/lib/libssl.a"
            CORE_LIBS="$CORE_LIBS $OPENSSL/.openssl/lib/libcrypto.a"
            CORE_LIBS="$CORE_LIBS $NGX_LIBDL"
# 为
            CORE_INCS="$CORE_INCS $OPENSSL/include"
            CORE_DEPS="$CORE_DEPS $OPENSSL/ssl.h"
            CORE_LIBS="$CORE_LIBS /usr/local/lib/libssl.a"
            CORE_LIBS="$CORE_LIBS /usr/local/lib/libcrypto.a"
            CORE_LIBS="$CORE_LIBS $NGX_LIBDL"
pkg install google-perftools
./configure --prefix=/usr/local/nginx --user=www --group=www --with-http_gzip_static_module --with-http_v2_module --with-http_realip_module --with-google_perftools_module --with-http_stub_status_module --with-http_sub_module --with-http_flv_module --with-http_ssl_module --with-openssl=/usr/local/include/openssl --with-pcre=../pcre-8.39 --with-pcre-jit            
gmake -j `sysctl hw.ncpu | wc -w`
gmake install -j `sysctl hw.ncpu | wc -w`

=========================From:https://my.oschina.net/ericliu77/blog/801539=================================




php5.6.17是最后一个php5版本,后来就到php7了。

FreeBSD 10系统编译安装Nginx, PHP, MariaDB环境
可惜的是 FreeBSD 10 用 Clang 替代 gcc 为默认编译器,这让用惯了 gcc 的同学们很不爽:
http://www.php1.cn/article/62718.html

整合freeBSD下nginx+php+mysql安装方案(ports安装):
http://blog.csdn.net/shaobingj126/article/details/5620702

freebsd+nginx+php+mysql+zend+phpmyadmin+系统优化+防止ddos +傻瓜式ports安装法:
http://blog.163.com/023_dns/blog/static/11872736620091029306126/
http://blog.163.com/dyc_888@126/blog/static/100443351201021910057781/

FreeBSD下NGINX 1.8+PHP5.6 +PERL 5.20 +Mysql 5.6+FTP 环境搭建与优化:
http://www.douban.com/note/524153021/


在FreeBSD上配置Apache+SSL:
http://wenku.baidu.com/link?url=Wp51oiSGtk7yQF2x_fqI7g9vDWylT218Rs2q2rRWs-WJJwSbyMepcmclmuKCu9QZ4UVkiXCAkemZfj4CIQNT7OU9L3uvEuQgeNngeqfJ78e


This post will describe how to install and configure Apache, MySQL, PHP and phpMyAdmin on FreeBSD for basic local web development:
https://www.iceflatline.com/2011/11/how-to-install-apache-mysql-php-and-phpmyadmin-on-freebsd/


FreeBSD下Nginx配置ssl-自建CA给网站签发SSL证书 [原创]:
http://www.92csz.com/42/494.html

FreeBSD下防火墙设置:
http://blog.163.com/caizhongyi@126/blog/static/3391683920102594249139/

X3.2针对PHP7的兼容版本-测试ing:
https://github.com/branchzero/discuz-x32-php7/releases


FreeBSD+Rsync文件同步 :
http://blog.chinaunix.net/uid-20496698-id-1664047.html
http://blog.chinaunix.net/uid-20496698-id-1664047.html

How to Install Official PHP 7 release on FreeBSD 10.2:
http://rasyid.net/2015/12/05/install-official-php-7-release-on-freebsd-10-2/
http://rasyid.net/2015/01/23/how-to-install-phpng-aka-php7-on-freebsd-10/

内容管理框架 ThinkCMFX 2.0.0 发布,支持 PHP7:
http://www.oschina.net/news/68813/thinkcmfx-2-0-0
http://demo.thinkcmf.com/
背景:一个队列client的服务器上,有一天运维网络调整后,发现其访问队列状态出现下面的提示:

根本原因是队列一直在跑,网络调整时出现有些请求因调整没有及时返回,网络可能路很差了,一堆的timewait导致client机上的fd耗尽引发上面的问题,
可以用netstat看下TIMEWAIT情况,发现一大堆的TIMEWAIT,如下图:阅读全文
背景:阿里去的Centos是到7.0,而内核是3.10.0,而centos7.1.1内核是4.1.1,Linus说是新的内核性能上应该更强一些,实践证明升级后的感觉的确要强一些,新内核真不错。


这个是用阿里云论坛里手工做好的rpm包进行升级:
https://bbs.aliyun.com/read/249016.html?spm=5176.bbsr250035.0.0.ATHIBV

用二进制包升级的下载并成功升级的地址:http://down.7qy.com/Hot-kerne/rpm/hot-centos-kernel-4.x-up-1.2.0.bin
======================================================================
======================================================================
*        热点 CentOS 6/7 内核升级程序  Ver.1.2.0  by blog.7QY.Com       *
*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~*
*              安装完成后需要重新启动系统才能使用新内核                 *
* 按Ctrl+C键退出本安装程序,然后输入shutdown -r now 或 reboot 重启系统  *
*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~*
*                Tips: Select < 1 > to 升级CENTOS 6.X内核               *
*                Tips: Select < 2 > to 升级CENTOS 7.X内核               *
=========================================================================

Please input ( 1 or 2 ) to 热点 CentOs 6/7 内核升级程序
Select: (1) 升级CENTOS 6.X内核 | (2) 升级CENTOS 7.X内核
(1/2): 2

开始升级CENTOS 7.X内核...
准备中...                          ################################# [100%]

......


警告:RPM 数据库已被非 yum 程序修改。
  正在安装    : kernel-ml-4.4.0-1.el7.elrepo.x86_64                                                                      1/2
  正在安装    : kernel-ml-devel-4.4.0-1.el7.elrepo.x86_64                                                              2/2
  验证中      : kernel-ml-devel-4.4.0-1.el7.elrepo.x86_64                                                               1/2
  验证中      : kernel-ml-4.4.0-1.el7.elrepo.x86_64                                                                       2/2

已安装:
  kernel-ml.x86_64 0:4.4.0-1.el7.elrepo                      kernel-ml-devel.x86_64 0:4.4.0-1.el7.elrepo                    

完毕!
会立即重新启动(有可能不是,是挂载新内核,因为后面发现内存还剩下37M,分页的那个进程占用CPU高达95%,后来把PHP-fpm重新调小一点重新启动一下php-fpm就好了,但一会儿CPU又上来了:http://jackxiang.com/post/8438/。),后一会儿就连接上了,发现内核成功升级,数据也正常(我没有挂载,就是阿里云默认的20G),新内核是相当的高效,通过ssh就能感觉得到。
[root@iZ25dcp92ckZ ~]# uname -rasp
Linux iZ25dcp92ckZ 4.4.0-1.el7.elrepo.x86_64 #1 SMP Sun Jan 10 21:17:16 EST 2016 x86_64 x86_64 x86_64 GNU/Linux
http://www.91cto.com.cn/detail/udepnxs/


一)FreeBSD前提是能连上网,配置成功的实践步骤在:https://jackxiang.com/post/8518/
二)后就是安装Lamp架构了,如下pkg,port目前好像用的人较少,先使这个吧,特别是Raspberry这种cpu相对太差,自己编译太麻烦了也更耗时,就别在上面整port了,直接pkg安装即可,也解决了依赖问题:
まず静的リンクしたコマンドでpkg自体をインストール
# fetch http://www.peach.ne.jp/archives/rpi/pkg-static
# chmod 755 pkg-static
# ./pkg-static add http://www.peach.ne.jp/archives/rpi/ports/pkg.txz

デフォルトのパッケージを無効化
# mkdir -p /usr/local/etc/pkg/repos
# echo "FreeBSD: { enabled: no }" > /usr/local/etc/pkg/repos/FreeBSD.conf

独自パッケージリポジトリを追加
# fetch http://www.peach.ne.jp/archives/rpi/rpi.conf
# mv rpi.conf /usr/local/etc/pkg/repos

リポジトリカタログを最新状態に更新
pkg update
pkg install screen
freebsd-update fetch
freebsd-update install
pkg install php56 mod_php56 php56-mysql php56-mysqli
如何在 FreeBSD 10.2 上安装 Nginx 作为 Apache 的反向代理:http://www.linuxidc.com/Linux/2016-01/127139.htm
FreeBSD 10 + Nginx 1.4.4 + PHP 5.5.9 + MySQL 5.6.15:     http://my.oschina.net/neochen/blog/198979

三) FreeBSD的pkg使用方法 :
http://blog.chinaunix.net/uid-20332519-id-4063284.html
====================================================================
在 FreeBSD 10.0 上安装和配置 Nginx+PHP+APC+MySQL:
http://www.vpsee.com/2014/04/install-nginx-php-apc-mysql-on-freebsd-10-0/
安装软件:
pkg search php

FreeBSD 11-CURRENT on Raspberry Pi Apache 2.4/MySQL 5.6/PHP 5.6:
http://www.bigsea.com.cn/archives/1393/

如何在树莓派 2B 上安装 FreeBSD:
http://www.linuxidc.com/Linux/2015-12/126724.htm

FreeBSD 网络配置:
https://wiki.freebsdchina.org/faq/networking


修改raspberry pi上安装的freebsd可用内存大小:
http://blog.sina.com.cn/s/blog_a0aacb430101mj69.html
背景:试着把libcurl进行post到服务器102k分片时,发现返回:100 continue怎么办?
PHP修改:
CURLOPT_HTTPHEADER => array("Content-Type: application/binary","Expect:")
curl_setopt($ch, CURLOPT_HTTPHEADER, array('Expect:'));
               // Disable Expect: header (lighttpd does not support it)

libcurl修改为:



      使用HTTP/1.1协议的curl,发送一个请求,在post数据量超过1K的时候,接口会返回:

  HTTP/1.1 100 Continue

  HTTP/1.1 200 OK
  Date: Sat, 07 Dec 2013 10:09:11 GMT
  Server: Apache/2.2.24 (Unix) PHP/5.3.25
  X-Powered-By: PHP/5.3.25
  Content-Length: 43
  Content-Type: text/html

  从表面上看,100 Continue表明请求一次没发送完,需要继续发送;搜索后看到现在新浪微博PHP架构师的一片博文,介绍了100的信息;详见在使用curl做POST的时候, 当要POST的数据大于1024字节的时候, curl并不会直接就发起POST请求, 而是会分为俩步,;

  流程如下:
  1. 发送一个请求, 包含一个Expect:100-continue, 询问Server使用愿意接受数据
  2. 接收到Server返回的100-continue应答以后, 才把数据POST给Server

  使用libcurl的时候会碰到这样的问题;
  在w3c的官网介绍看到如下一段话:

  8.2.3 Use of the 100 (Continue) Status
  The purpose of the 100 (Continue) status (see section 10.1.1) is to allow a client that is sending a request message with a request body to determine if the origin server is willing to accept the request (based on the request headers) before the client sends the request body. In some cases, it might either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without looking at the body.
  Requirements for HTTP/1.1 clients:
  – If a client will wait for a 100 (Continue) response before
  sending the request body, it MUST send an Expect request-header
  field (section 14.20) with the “100-continue” expectation.
  – A client MUST NOT send an Expect request-header field (section
  14.20) with the “100-continue” expectation if it does not intend
  to send a request body.

  简单翻译一下:
  使用100(不中断,继续)状态码的目的是为了在客户端发出请求体之前,让服务器根据客户端发出的请求信息(根据请求的头信息)来决定是否愿意接受来自客户端的包含了请求内容的请求;在某些情况下,在有些情况下,如果服务器拒绝查看消息主体,这时客户端发送消息主体是不合适的或会降低效率

  对HTTP/1.1客户端的要求:
  -如果客户端在发送请求体之前,想等待服务器返回100状态码,那么客户端必须要发送一个Expect请求头信息,即:”100-continue”请求头信息;

  -如果一个客户端不打算发送请求体的时候,一定不要使用“100-continue”发送Expect的请求头信息;

来自:http://zhidao.baidu.com/question/1495713785713961379.html?fr=iks&word=HTTP%2F1.1+100+Continue&ie=gbk
参考:http://www.laruence.com/2011/01/20/1840.html
背景:如果FreeBSD安装在vmware里,想上网,那么Vmware8及nat模式想上网,那么dhcp分配IP是难免的。在笔记本用wifi上网那个网卡共享给Vmware8后,vmware8会有一个IP 192.168.137.1  ,经过上面配置后FreeBSD获得IP是 192.168.137.129,没有curl,用ping一个就能获取到IP说明初步成功,但能否上外网和dns有关。

1、运行命令ifconfig查看当前网卡列表,确定名称,如果不在列表内,可能是驱动没装好

% ifconfig
dc0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 192.168.1.3 netmask 0xffffff00 broadcast 192.168.1.255
ether 00:a0:cc:da:da:da
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
dc1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255
ether 00:a0:cc:da:da:db
media: Ethernet 10baseT/UTP
status: no carrier
lp0: flags=8810<POINTOPOINT,SIMPLEX,MULTICAST> mtu 1500
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet 127.0.0.1 netmask 0xff000000
tun0: flags=8010<POINTOPOINT,MULTICAST> mtu 1500
2、vi /etc/rc.conf 添加
ifconfig_dc0="DHCP"
dhcp_program="/sbin/dhclient"
dhcp_flags=""
3、reboot后,应该就可以用了

来自:http://www.jb51.net/article/15810.htm
没有啥用对我来说,卸载掉:
[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
阅读全文
背景:一个状态文件只有一行,这一行的数值改变,于是想用tail -f,但发现不行,看不到它变化,怎么办?想起前两天和rango搞了下websocket下的tail,有一个watch的命令可以搞定。
命令如下,1秒种cat一次,就能看到变化了:
watch -n 1 "cat /data/upload/upload_state/*.state"

Every 1.0s: cat /data/upload/upload_state/*.state                                                                                    Fri Jan 15 11:01:25 2016
0-316669951/5864975953

可能1秒后是这样:
Every 1.0s: cat /data/upload/upload_state/*.state                                                                                    Fri Jan 15 11:02:36 2016
0-400752639/5864975953

参考来源:https://github.com/matyhtf/websocket_tail
微信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:



2)用wget实现分片下载的探测:

————————————————————————————————————————————————————————————————
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

背景:《天下第一针》在央视6套电影频道首映。前几天看到里面有皇帝的一段话,觉得有点意思:又以古经训诂至精,学者封执多失,传心岂如会目,著辞不若案形;...
白话文:传心即指用心去领悟,不如用眼睛直观去看.著辞指用言辞(理论)去解释,不如直接作一个形体去看.
————————————————————————————————————————————————
[原文]
上又以古经训诂至精,学者封执多失,传心岂如会目,著辞不若案形,复令创铸铜人为式。内为腑臓,旁注溪谷,井荥所会,孔穴所安,窍而达中,刻题於侧。使观者烂然而有第,疑者涣然而冰释。在昔未臻,惟帝时宪,乃命侍臣为之序引,名曰《新铸铜人腧穴针灸图经》。肇颁四方,景式万代,将使多瘠咸诏,巨刺靡差。案说蠲痾,若对谈于涪水;披图洞视,如旧饮于上池。保我黎烝,介乎寿考。昔夏后叙六极以辨疾,帝炎问百药以惠人,固当让德今辰,归功圣域者矣。
时天圣四年岁次析木秋八月丙申谨上。

[译文]
我听说圣明的君王能拥有天下,是因为有高明的医生分析国君的病情而推及到国情,根据诊断国君的症候而推知到政事。如果君王的德政不能广泛传播,那么邪恶就会从下面产生,所以就要辨别善恶而制定治国的方案;人体的正气不充盛,那么疾病就要在体内发作,所以医生就要慎用医术来疗救百姓的疾病。从前,我们的圣祖黄帝与其大臣岐伯等人讨问医学问题,认为善于谈论天道的,一定回在人事上得到验证。自然界一年的月数十二个,人体有十二经脉与它相对应;一年有三百六十五天,人体有三百六十五个穴位与它相对应。人体气血的上下运行就像天地运行一样是有其法则规律的,经络的左右循行是有其轨迹的,就像天地一样四方是有其象征的。经脉之间有交会之处,腧穴、合穴必有一定的数目。彻底探究了血脉微妙的道理,验证了阴阳变化的规律,才命人详尽地写出了那些针灸方面的理论,珍藏在金兰之室。等到雷公请教这些理论时,黄帝就坐在明堂之上把这些理论传授给了他。所以后世医家称针灸学为明堂学就是根据这个原因。从此艾灸、针刺的理论与技术就完备了,望闻问切的诊病方法就产生了。像秦越人使虢太子死而复生,华佗治愈跛足病人,王纂驱除病人身边的邪魔,徐秋夫治疗死鬼的腰疼病,不是有什么神灵相助,而都是运用了针灸之法啊。
离开先圣黄帝的时代渐渐久远了,针灸这门学问就难以精通了。虽然把它列在医经的妙法要诀之中,把它绘成针灸经络图象,但图象容易混杂不清,文字在传抄中也产生很多错误。如果误用艾灸就会损伤肝脏,错用针刺就会损伤胃气。百姓受到伤害却不知补救,庸医承袭错误而不思悔改。如果不是圣明之人,谁能拯救这些病患?只有我们皇上深情怜悯万民的痛苦,继承轩辕黄帝遗留下来的医学事业,敬奉圣祖黄帝慈祥的教诲,诏命众官员制定政令,并命令名医严谨慎重地整理医学著作。深思针灸这种医术,从前列为百官中的一种职守,是关系到人民性命的大事,是日常所用的特别急需的治病之法,因而就想要改正针灸学著作在流传中出现的谬误,以便永远救治百姓之疾患。殿中省尚药奉御王唯一平素传授医药秘方,尤其擅长针灸技术。他尽心遵奉皇帝的命令,精心参验针灸的神妙之理。在人体图形的前后和两侧标定经络循行的路线,确定每个腧穴的位置和深浅,增补古今医家的验方验案,订正针灸术的时间禁忌方面的漏洞,总汇各家学说,编成专著三篇。
皇上又认为对古代医学经典的训释解说特别精深难懂,学者往往固执己见多有失误,因此,对针灸取穴的深奥内容,与其靠口传心授,倒不如利用模型作直接观看了解;把针灸学的内容写在书本上,还不如制成模型让学医者在针灸模型上直接查找穴位。于是皇上又下令创制铸造铜人作为教学模型。铜人体内分有脏腑,旁边注明针灸穴位,穴位所在之处,凿成孔窍,使它直接达到体内,在孔穴的旁边刻写出穴位的名称。使观看它的人感到形象鲜明而穴位有次序,有疑惑的人心中的疑惑立刻像冰块融化一样涣然消失。针灸的教学在过去从来没有达到如此完善过,只有到当今皇帝才应时确定了针灸的教令,于是皇上命令我为这部书写序文,书名叫《新铸铜人腧穴针灸图经》,开始颁发到全国各地,为后世万代做出最好的楷模。将使多病的人全都受教诲,针灸医生不会出现差错。按照《图经》上的论述去除治疾病,就像郭玉在涪水边跟涪翁学针法一样;打开图仔细彻底地察视,如同扁鹊久饮了上池之水,而能尽见体内疾病。保佑我们的人民大众,帮助他们达到健康长寿的境域。从前夏禹王阐述六种凶恶的事用来辨证治病,神农氏询问百药而施恩惠于人民,(当今皇上重视医术,)必定会像夏禹,神农一样给后世带来福德利益,其功劳可归入圣人的行列。
时间是天圣四年,正值岁星运行到析木星,丙申日敬慎地写作上面这篇序文。

摘自:http://baike.baidu.com/link?url=w9yuPElsf6RwCyHh9yQEGTPE3_Ng7CJcZiAKW-4pCXNOku410kn_pkUTCwfPgphkYQkxaizumUFmVlHpnPxz5K
背景:天峰兄弟及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功能可以很方便做出一个连接池来。
编译时要注意一下:

还是出现:[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选项就知道了,正确的如下:

一些博文里的:--enable-async-mysql 后面有路径,这块在swoole-src-swoole-1.7.22-stable里是没有这个路径反而编译正确了。
————————————————————服务端的代码贴在这儿—————————————————————————————
代码如下:


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

二)客户端代码如下:


三)运行一下看有没有返回:
[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看下:


还有问题?优化如下,我提出我为何要坚持引入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

分页: 20/248 第一页 上页 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 下页 最后页 [ 显示模式: 摘要 | 列表 ]