背景:一外包说是svn没权限,一截图根据里面的提示,感觉是svn client版本太新。

因为SVN客户端版本为1.8以上,太新,跟服务器端不匹配。请卸载,安装1.7版,并重启。
请在新的目录中重新checkout代码,原workspace目录请废弃,不要在其中再执行SVN操作。


来自:http://blog.sina.com.cn/s/blog_4c81e6230101e18a.html
背景:Nginx代理到tomcat时出现504 Gateway Time-out。

如果是设置IP直接proxy则设置在nginx的http{ 里面即可,不用设置在server里。

摘自:http://www.ha97.com/5194.html

超时有问题不光是超时,更有可能是被反向代理的出现了500的内部服务器错误:
背景:对于java和tomcat结合的程序,其实还是一个服务器,可能会有各种线程啥的如上传分片文件时会合并,这种对于PHP来讲是个问题,但是对于java来讲是能实现的边上传边合并的,也是非常好的,但是呢,这种办法如果写得不够好,很可能出现一些问题,假死、僵死,还不如用PHP写个上传,后台用那个守护进程进行合并来得更稳定。
阅读全文
背景:在一个Java分片上传时发现其CPU idle为98.5,以为值越高越危险,于是查了下,表明"System Idle Process" 中的 idle 是“空闲”得很。

cpu ide 是 cpu 的一个命令,cpu 见到这个命令,就停止工作一个指令。变相的可以降低功耗和休息一下。
对于系统来说,如果调度程序没有可以让 cpu 执行的任务,那么就自动发送 ide 命令让 cpu 休眠一个指令。
估计你的程度运行出现了冲突,导致大部分时间都在等待。

在CPU空闲的时候,发出一个IDLE命令,使CPU挂起(暂时停止工作),可有效的降低CPU内核的温度,在操作系统服务里面,都没有禁止它的选项;默认它是占用除了当前应用程序所分配的处理器(CPU)百分比之外的所有占用率;一旦应用程序发出请求,处理器会立刻响应的。在这个进程里出现的CPU占用数值并不是真正的占用而是体现的CPU的空闲率,也就说这个数值越大CPU的空闲率就越高,反之就是CPU的占用率越高。


当“System Idle Process”进程占用资源为2%时,说明机器目前只有2%的资源是空闲的,即机器可能感染了病毒或被其他程序占用了98%的资源。换句话说,“System Idle Process”进程占用资源占用资源越大则系统可用资源越多,其字面意思是“系统空闲进程”。


用sar进行CPU利用率的分析
[root@wh-appserver413 its]# sar -u 2 10
Linux 2.6.18-92.el5 (wh-appserver413)   01/29/2016

10:53:17 AM       CPU     %user     %nice   %system   %iowait    %steal     %idle
10:53:19 AM       all      0.06      0.00      1.00      0.00      0.00     98.94
10:53:21 AM       all      0.56      0.00      0.56      0.25      0.00     98.62
10:53:23 AM       all      0.00      0.00      0.06      0.62      0.00     99.31
10:53:25 AM       all      0.06      0.00      0.25      2.87      0.00     96.81      

我的个人博客:
Linux 4.4.0-1.el7.elrepo.x86_64 (iZ25dcp92ckZ)  2016年01月29日  _x86_64_        (1 CPU)
10时54分45秒     CPU     %user     %nice   %system   %iowait    %steal     %idle
10时54分47秒     all      0.00      0.00      0.00      0.00      0.00    100.00
10时54分49秒     all      0.00      0.00      0.00      0.50      0.50     99.00
10时54分51秒     all      0.50      0.00      0.00      0.00      0.00     99.50
平均时间:     all      0.17      0.00      0.00      0.17      0.17     99.50

%idle:CPU空闲时间百分比。
        在所有的显示中,我们应主要注意%iowait和%idle,%iowait的值过高,表示硬盘存在I/O瓶颈,%idle值高,表示CPU较空闲,如果%idle值高但系统响应慢时,有可能是CPU等待分配内存,此时应加大内存容量。%idle值如果持续低于10,那么系统的CPU处理能力相对较低,表明系统中最需要解决的资源是CPU。

参考:http://blog.itpub.net/8554499/viewspace-580300/
背景:作为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
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

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