背景:天峰兄弟及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
发牢骚: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
Linux服务器 /var/spool/clientmqueue 目录下产生大量文件的解决办法
Unix/LinuxC技术 jackxiang 2015-12-28 15:21
背景: 磁盘没空间了,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
____________________________________________________________________
今天收到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
在du命令里如何排除其中一个目录
Unix/LinuxC技术 jackxiang 2015-12-28 14:26
背景:对/下的文件大小作统计但想排除一些文件夹。
想计算一下/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
想计算一下/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
百度的 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
方法四是在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
阿里云FreeBSD初始化方法,FreeBSD才是坚如磐石,freebsd被苹果做起来osX和iOS。。
Unix/LinuxC技术 jackxiang 2015-12-23 16:02
背景:前些天在淘宝上的一台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
一个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
linux中远程连接(如SSH)出现someone could be eavesdropping on you right now的解决办法
Unix/LinuxC技术 jackxiang 2015-12-23 15:46
今天用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.
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
日志记录中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
PHP 7内核之HashTable实现,PHP7的hash实现由双向变单向链表。-来自:华仔。
Php/Js/Shell/Go jackxiang 2015-12-22 21:41
Hash贯穿了PHP的数组、对象,总之,这个hash是个很基础重要的东西:
http://blog.csdn.net/heiyeshuwu/article/details/44259865
http://blog.csdn.net/heiyeshuwu/article/details/44259865
[转]shell脚本执行时报"bad interpreter: Text file busy"的解决方法
Php/Js/Shell/Go jackxiang 2015-12-22 21:35
在执行一个shell脚本时,遇到了“-bash: ./killSession.sh: /bin/bash: bad interpreter: Text file busy”错误提示,如下所示:
[oracle@DB-Server bin]$ ./killSession.sh
-bash: ./killSession.sh: /bin/bash: bad interpreter: Text file busy
此时只需要在#!/bin/bash,加一空格#! /bin/bash即可解决问题。
另外一种情况: 当有其它进程访问这个文件,可以通过lsof | grep killSession.sh来查看是否有其它进程正在访问该文件。
此时可以用kill命令杀掉其它进程。解决上面这个问题。
转自:http://www.cnblogs.com/kerrycode/p/4038934.html
[oracle@DB-Server bin]$ ./killSession.sh
-bash: ./killSession.sh: /bin/bash: bad interpreter: Text file busy
此时只需要在#!/bin/bash,加一空格#! /bin/bash即可解决问题。
另外一种情况: 当有其它进程访问这个文件,可以通过lsof | grep killSession.sh来查看是否有其它进程正在访问该文件。
此时可以用kill命令杀掉其它进程。解决上面这个问题。
转自:http://www.cnblogs.com/kerrycode/p/4038934.html
背景:升级了一下mysql到最新版本 5.7.9,博客数据没有动,后导出数据备份时出现Couldn't execute 'SHOW VARIABLES LIKE 'gtid\_mode'',加上 --set-gtid-purged=off出现新错误的问题,总之一堆问题,最后还是终于导出了,特别是升级后一定要重启,啥玩意,艹。
实践如下,出现问题:
[root@iZ25dcp92ckZ backup]# mysqldump -uroot -p -ujustwinit_mysql_database > -ujustwinit_mysql_database.cn.sql
Enter password:
mysqldump: Couldn't execute 'SHOW VARIABLES LIKE 'gtid\_mode'': Table 'performance_schema.session_variables' doesn't exist (1146)
用mysqldump备份时出现下面的出错信息:
mysqldump:Couldn't execute ‘SELECT @@GTID_MODE':Unknown system variable 'GTID_MODE' (1193)
造成此错误的原因是因为5.6引入了Global Transaction Identifiers (GTIDs) 。GTIDs可以让主从结构复制的跟踪和比较变得简单。mysqldump会试图查询这个系统变量,但这个变量在5.6之前的版本中不存在,所以产生错误。解决的方法很简单,在mysqldump后加上–set-gtid-purged=OFF命令
如:
mysqldump -h(主机名或ip) -u(用户名) -p(密码) 数据库名 --set-gtid-purged=off >d:/db.sql
From:http://www.rjkfw.com/s_3139.html
___________________________________________________________________
[root@iZ25dcp92ckZ ~]# mysqldump --set-gtid-purged=off -uroot -p -ujustwinit_mysql_database > -ujustwinit_mysql_database.cn.sql
Enter password:
mysqldump: Couldn't execute 'SHOW VARIABLES LIKE 'ndbinfo\_version'': Table 'performance_schema.session_variables' doesn't exist (1146)
解决办法:
[root@iZ25dcp92ckZ ~]# mysql_upgrade -u root -p --force
Enter password:
Checking server version.
Running queries to upgrade MySQL server.
Checking system database.
mysql.columns_priv OK
mysql.db OK
。。。。。。
sys.sys_config OK
temperature.temperature OK
temperature.tempsetting OK
Upgrade process completed successfully.
Checking if update is needed.
再次导出:
[root@iZ25dcp92ckZ ~]# mysqldump --set-gtid-purged=off -uroot -p -ujustwinit_mysql_database > -ujustwinit_mysql_database.cn.sql
Enter password:
mysqldump: Couldn't execute 'SHOW VARIABLES LIKE 'ndbinfo\_version'': Native table 'performance_schema'.'session_variables' has the wrong structure (1682)
忘记重启了,于是重启下,再次导出,出现新的错:
[root@iZ25dcp92ckZ bin]# mysqldump --set-gtid-purged=off -u-ujustwinit_mysql_database_mysql_database -p -ujustwinit_mysql_database_mysql > -ujustwinit_mysql_database.cn.sql
Enter password:
mysqldump: Got error: 1044: Access denied for user '-ujustwinit_mysql_database_mysql'@'localhost' to database '-ujustwinit_mysql_database_mysql' when using LOCK TABLES
用mysqldump备份数据库时出现when using LOCK TABLES_:
--skip-lock-tables
普通用户备份mysql 数据库报错
mysql 无lock tables权限 报Access denied for user 'dbuser'@'localhost' to database 'db' when using LOCK TABLES
主要原因是该用户无lock tables 该权限,处理办法:
1. 给该普通用户赋予lock tables 权限,建议是删除该用户,重新用mysql命令建
2. 加上--skip-lock-tables即可
mysqldump -udbuser -p dbname --skip-lock-tables > dbname.sql
3. 使用root 备份
MySQL无lock tables权限 报Access denied for user when using LOCK TABLES:
http://www.linuxidc.com/Linux/2012-01/51802.htm
mysqldump --set-gtid-purged=off --skip-lock-tables -u-ujustwinit_mysql_database_mysql_database -p -ujustwinit_mysql_database_mysql > -ujustwinit_mysql_database.cn.sql
成功了:
[root@iZ25dcp92ckZ bin]# mysqldump --set-gtid-purged=off --skip-lock-tables -uroot -p justwinit_mysql_database > jackxiang.com.database.bak.perfected.2015.12.29.sql
Enter password:
来自:http://www.amznz.com/error-native-table-performance_schema/
实践如下,出现问题:
[root@iZ25dcp92ckZ backup]# mysqldump -uroot -p -ujustwinit_mysql_database > -ujustwinit_mysql_database.cn.sql
Enter password:
mysqldump: Couldn't execute 'SHOW VARIABLES LIKE 'gtid\_mode'': Table 'performance_schema.session_variables' doesn't exist (1146)
用mysqldump备份时出现下面的出错信息:
mysqldump:Couldn't execute ‘SELECT @@GTID_MODE':Unknown system variable 'GTID_MODE' (1193)
造成此错误的原因是因为5.6引入了Global Transaction Identifiers (GTIDs) 。GTIDs可以让主从结构复制的跟踪和比较变得简单。mysqldump会试图查询这个系统变量,但这个变量在5.6之前的版本中不存在,所以产生错误。解决的方法很简单,在mysqldump后加上–set-gtid-purged=OFF命令
如:
mysqldump -h(主机名或ip) -u(用户名) -p(密码) 数据库名 --set-gtid-purged=off >d:/db.sql
From:http://www.rjkfw.com/s_3139.html
___________________________________________________________________
[root@iZ25dcp92ckZ ~]# mysqldump --set-gtid-purged=off -uroot -p -ujustwinit_mysql_database > -ujustwinit_mysql_database.cn.sql
Enter password:
mysqldump: Couldn't execute 'SHOW VARIABLES LIKE 'ndbinfo\_version'': Table 'performance_schema.session_variables' doesn't exist (1146)
解决办法:
[root@iZ25dcp92ckZ ~]# mysql_upgrade -u root -p --force
Enter password:
Checking server version.
Running queries to upgrade MySQL server.
Checking system database.
mysql.columns_priv OK
mysql.db OK
。。。。。。
sys.sys_config OK
temperature.temperature OK
temperature.tempsetting OK
Upgrade process completed successfully.
Checking if update is needed.
再次导出:
[root@iZ25dcp92ckZ ~]# mysqldump --set-gtid-purged=off -uroot -p -ujustwinit_mysql_database > -ujustwinit_mysql_database.cn.sql
Enter password:
mysqldump: Couldn't execute 'SHOW VARIABLES LIKE 'ndbinfo\_version'': Native table 'performance_schema'.'session_variables' has the wrong structure (1682)
忘记重启了,于是重启下,再次导出,出现新的错:
[root@iZ25dcp92ckZ bin]# mysqldump --set-gtid-purged=off -u-ujustwinit_mysql_database_mysql_database -p -ujustwinit_mysql_database_mysql > -ujustwinit_mysql_database.cn.sql
Enter password:
mysqldump: Got error: 1044: Access denied for user '-ujustwinit_mysql_database_mysql'@'localhost' to database '-ujustwinit_mysql_database_mysql' when using LOCK TABLES
用mysqldump备份数据库时出现when using LOCK TABLES_:
--skip-lock-tables
普通用户备份mysql 数据库报错
mysql 无lock tables权限 报Access denied for user 'dbuser'@'localhost' to database 'db' when using LOCK TABLES
主要原因是该用户无lock tables 该权限,处理办法:
1. 给该普通用户赋予lock tables 权限,建议是删除该用户,重新用mysql命令建
2. 加上--skip-lock-tables即可
mysqldump -udbuser -p dbname --skip-lock-tables > dbname.sql
3. 使用root 备份
MySQL无lock tables权限 报Access denied for user when using LOCK TABLES:
http://www.linuxidc.com/Linux/2012-01/51802.htm
mysqldump --set-gtid-purged=off --skip-lock-tables -u-ujustwinit_mysql_database_mysql_database -p -ujustwinit_mysql_database_mysql > -ujustwinit_mysql_database.cn.sql
成功了:
[root@iZ25dcp92ckZ bin]# mysqldump --set-gtid-purged=off --skip-lock-tables -uroot -p justwinit_mysql_database > jackxiang.com.database.bak.perfected.2015.12.29.sql
Enter password:
来自:http://www.amznz.com/error-native-table-performance_schema/
PHP filesize() 函数是有缓存的,你需要清除文件状态缓存。
Php/Js/Shell/Go jackxiang 2015-12-17 19:01
背景:有时有做一些H5的websocket做模仿linux下的tail -f,形成一个实时日志查看工具时,会对写入事件前的文件大小和写入事件后的文件大小作一个计算,而在实际调试时发现这个PHP的filessize函数是有缓存的,这个链接的兄弟在问怎么破?(http://segmentfault.com/q/1010000003843245),如下文所示 。
定义和用法
clearstatcache()函数的作用是:清除文件状态缓存。
PHP的缓存数据对更快更好的运行函数是非常有利的。如果一个文件在脚本中测试了多次,你也许会禁止对正确的结果进行缓存。为了实现这点,你可以使用clearstatcache()函数。
语法
clearstatcache()
提示和注意
提示:执行缓存的函数:
stat()
lstat()
file_exists()
is_writable()
is_readable()
is_executable()
is_file()
is_dir()
is_link()
filectime()
fileatime()
filemtime()
fileinode()
filegroup()
fileowner()
filesize()
filetype()
fileperms()
案例
上述代码将输出下面的结果:
事件前文件大小:59635
事件后文件大小:59639
来自:http://www.chinaz.com/program/2010/0302/107501.shtml
定义和用法
clearstatcache()函数的作用是:清除文件状态缓存。
PHP的缓存数据对更快更好的运行函数是非常有利的。如果一个文件在脚本中测试了多次,你也许会禁止对正确的结果进行缓存。为了实现这点,你可以使用clearstatcache()函数。
语法
clearstatcache()
提示和注意
提示:执行缓存的函数:
stat()
lstat()
file_exists()
is_writable()
is_readable()
is_executable()
is_file()
is_dir()
is_link()
filectime()
fileatime()
filemtime()
fileinode()
filegroup()
fileowner()
filesize()
filetype()
fileperms()
案例
上述代码将输出下面的结果:
事件前文件大小:59635
事件后文件大小:59639
来自:http://www.chinaz.com/program/2010/0302/107501.shtml
背景:想测试android的pad浏览器屏幕的显示情况,而测试机没有网络,如果用wifi热点作fiddler2的代理也成,可是不是人人都有代理,最好是修改一下host文件。
最近在做的项目要通过域名调用内网的服务器,因为android模拟器host文件无法修改,导致无法通过域名使用http方法调用内网服务,因此从网上大量转载的一种方法,这种方法:
1. 通过emulator -avd avdName -partition-size 128 启动模拟器
2.通过adb root 和 adb remount 命令获得root权限。
3.通过 adb pull /system/etc/hosts 命令将hosts文件转移到PC上,手动修改hosts,并且通过adb push将hosts文件再推送回去。
这个问题是因为linux中的换行符和window中的回车换行不一致引起的,网上大部分方法是让利用ultraedit等编辑器直接修改,但是我复制到编辑器上依然无法修改。上贴中的malbers回复说,利用echo命令,可以直接通过命令将需要修改的内容添加到hosts文件中,试了一下,果然可行。
首先键入 adb shell 命令(新版本的sdk adb命令被转移到了platform-tools目录中),然后echo 192.168.0.246 www.aaa.com>>/system/etc/hosts,敲入上面这条命令后,再使用 cat /system/etc/hosts查看hosts文件修改情况,发现hosts果然已经被修改,但是问题是依然没有换行,貌似只有换行了以后才能被识别,
因此再次利用echo命令加入了换行符,问题解决。具体操作如下:
前面几个步骤不变,但是不需要将hosts文件pull到电脑上,如果你已经修改了但是无效,可以先pull出来,还原到原始状态,不要有任何换行,并替换掉
模拟器上已经修改的hosts,使它回复到原始状态。即只有127.0.0.1 localhost。
然后进入adb shell , 使用 echo -e \\n >> /system/etc/hosts 为hosts文件加入换行符。
再次使用 echo 192.168.0.246 www.aaa.com >> /system/etc/hosts 。
这样就完整解决了换行问题。再次在浏览器中敲入www.aaa.com,熟悉的页面也出现了。
转自:http://blog.csdn.net/landen11/article/details/7022376
首先请确认你修改的是文件是 /system/etc/hosts ,如果不是,那你即使改了也无效。
其次,如果你是在windows下修改hosts文件,那就必须注意换行符的问题,以及hosts文件格式的问题:
android下的hosts文件必须像以下这样写:
IP 域名
注意:
在IP和域名之间保留一个空格 每行只能有一个域名,不能一个IP后面跟多个域名。
android上的换行符(也就是回车)是LF,也就是\n,而windows上的换行符是CR LF,也就是\r\n
所以在windows下用记事本之类的软件编辑了hosts文件,放到手机上肯定认不出来的!解决的办法就是用NotePad++之类的文本编辑器,再使用“查找替换”,将“\r\n”替换成“\n”(注意要在notepad++里把查找模式设置为扩展模式,才能识别转义字符\r\n)
如果是在windows下编辑hosts,要保证最后一行结尾也是“\n”
终于搞掂!!!
转自:https://plus.google.com/105237252862440264277/posts/CF9F42e4axj
最近在做的项目要通过域名调用内网的服务器,因为android模拟器host文件无法修改,导致无法通过域名使用http方法调用内网服务,因此从网上大量转载的一种方法,这种方法:
1. 通过emulator -avd avdName -partition-size 128 启动模拟器
2.通过adb root 和 adb remount 命令获得root权限。
3.通过 adb pull /system/etc/hosts 命令将hosts文件转移到PC上,手动修改hosts,并且通过adb push将hosts文件再推送回去。
这个问题是因为linux中的换行符和window中的回车换行不一致引起的,网上大部分方法是让利用ultraedit等编辑器直接修改,但是我复制到编辑器上依然无法修改。上贴中的malbers回复说,利用echo命令,可以直接通过命令将需要修改的内容添加到hosts文件中,试了一下,果然可行。
首先键入 adb shell 命令(新版本的sdk adb命令被转移到了platform-tools目录中),然后echo 192.168.0.246 www.aaa.com>>/system/etc/hosts,敲入上面这条命令后,再使用 cat /system/etc/hosts查看hosts文件修改情况,发现hosts果然已经被修改,但是问题是依然没有换行,貌似只有换行了以后才能被识别,
因此再次利用echo命令加入了换行符,问题解决。具体操作如下:
前面几个步骤不变,但是不需要将hosts文件pull到电脑上,如果你已经修改了但是无效,可以先pull出来,还原到原始状态,不要有任何换行,并替换掉
模拟器上已经修改的hosts,使它回复到原始状态。即只有127.0.0.1 localhost。
然后进入adb shell , 使用 echo -e \\n >> /system/etc/hosts 为hosts文件加入换行符。
再次使用 echo 192.168.0.246 www.aaa.com >> /system/etc/hosts 。
这样就完整解决了换行问题。再次在浏览器中敲入www.aaa.com,熟悉的页面也出现了。
转自:http://blog.csdn.net/landen11/article/details/7022376
首先请确认你修改的是文件是 /system/etc/hosts ,如果不是,那你即使改了也无效。
其次,如果你是在windows下修改hosts文件,那就必须注意换行符的问题,以及hosts文件格式的问题:
android下的hosts文件必须像以下这样写:
IP 域名
注意:
在IP和域名之间保留一个空格 每行只能有一个域名,不能一个IP后面跟多个域名。
android上的换行符(也就是回车)是LF,也就是\n,而windows上的换行符是CR LF,也就是\r\n
所以在windows下用记事本之类的软件编辑了hosts文件,放到手机上肯定认不出来的!解决的办法就是用NotePad++之类的文本编辑器,再使用“查找替换”,将“\r\n”替换成“\n”(注意要在notepad++里把查找模式设置为扩展模式,才能识别转义字符\r\n)
如果是在windows下编辑hosts,要保证最后一行结尾也是“\n”
终于搞掂!!!
转自:https://plus.google.com/105237252862440264277/posts/CF9F42e4axj
RocksDB介绍:一个比LevelDB更彪悍的引擎
Php/Js/Shell/Go jackxiang 2015-12-8 17:24
背景:听说要写rocksdb的PHP扩展,推荐到PHP官方去,一看发现这个db很牛,支持key-value的查找,Facebook开源闪存数据库RocksDB。
关于LevelDB的资料网上还是比较丰富的,如果你尚未听说过LevelDB,那请稍微预习一下,因为RocksDB实际上是在LevelDB之上做的改进。本文主要侧重在架构上对RocksDB对LevelDB改进的地方做个简单介绍并添加一些个人的看法,更详细的信息读者可参考其官网:http://rocksdb.org/
RocksDB是在LevelDB原来的代码上进行改进完善的,所以在用法上与LevelDB非常的相似。如下,就是简单的把原来Leveldb信息替换为Rocksdb,从继承的角度看,Rocksdb就像是Leveldb的后辈。
RocksDB:
#include "rocksdb/db.h"
rocksdb::DB* db;
rocksdb::Options options;
options.create_if_missing = true;
rocksdb::Status status = rocksdb::DB::Open(options, "/tmp/testdb", &db);
assert(status.ok());
status = db->Get(rocksdb::ReadOptions(), key1, &value);
status = db->Put(rocksdb::WriteOptions(), key2, value);
status = db->Delete(rocksdb::WriteOptions(), key1);
delete db;
#include "rocksdb/db.h"
rocksdb::DB* db;
rocksdb::Options options;
options.create_if_missing = true;
rocksdb::Status status = rocksdb::DB::Open(options, "/tmp/testdb", &db);
assert(status.ok());
status = db->Get(rocksdb::ReadOptions(), key1, &value);
status = db->Put(rocksdb::WriteOptions(), key2, value);
status = db->Delete(rocksdb::WriteOptions(), key1);
delete db;
LevelDB:
#include "leveldb/db.h"
leveldb::DB *db;
leveldb::Options options;
options.create_if_missing = true;
leveldb::Status status = leveldb::DB::Open(options, "/tmp/testdb", &db);
assert(status.ok());
status = db->Get(leveldb::ReadOptions(), key1, &value);
status = db->Put(leveldb::WriteOptions(), key2, value);
status = db->Delete(leveldb::WriteOptions(), key1);
delete db;
#include "leveldb/db.h"
leveldb::DB *db;
leveldb::Options options;
options.create_if_missing = true;
leveldb::Status status = leveldb::DB::Open(options, "/tmp/testdb", &db);
assert(status.ok());
status = db->Get(leveldb::ReadOptions(), key1, &value);
status = db->Put(leveldb::WriteOptions(), key2, value);
status = db->Delete(leveldb::WriteOptions(), key1);
delete db;
RocksDB虽然在代码层面上是在LevelDB原有的代码上进行开发的,但却借鉴了Apache HBase的一些好的idea。在云计算横行的年代,开口不离Hadoop,RocksDB也开始支持HDFS,允许从HDFS读取数据。而LevelDB则是一个比较单一的存储引擎,有点我就是我,除了我依然只有我的感觉。也是因为LevelDB的单一性,在做具体的应用的时候一般需要对其作进一步扩展。
RocksDB支持一次获取多个K-V,还支持Key范围查找。LevelDB只能获取单个Key
RocksDB除了简单的Put、Delete操作,还提供了一个Merge操作,说是为了对多个Put操作进行合并。站在引擎实现者的角度来看,相比其带来的价值,其实现的成本要昂贵很多。个人觉得有时过于追求完美不见得是好事,据笔者所测(包括测试自己编写的引擎),性能的瓶颈其实主要在合并上,多一次少一次Put对性能的影响并无大碍。
RocksDB提供一些方便的工具,这些工具包含解析sst文件中的K-V记录、解析MANIFEST文件的内容等。有了这些工具,就不用再像使用LevelDB那样,只能在程序中才能知道sst文件K-V的具体信息了。
RocksDB支持多线程合并,而LevelDB是单线程合并的。LSM型的数据结构,最大的性能问题就出现在其合并的时间损耗上,在多CPU的环境下,多线程合并那是LevelDB所无法比拟的。不过据其官网上的介绍,似乎多线程合并还只是针对那些与下一层没有Key重叠的文件,只是简单的rename而已,至于在真正数据上的合并方面是否也有用到多线程,就只能看代码了。
RocksDB增加了合并时过滤器,对一些不再符合条件的K-V进行丢弃,如根据K-V的有效期进行过滤。
压缩方面RocksDB可采用多种压缩算法,除了LevelDB用的snappy,还有zlib、bzip2。LevelDB里面按数据的压缩率(压缩后低于75%)判断是否对数据进行压缩存储,而RocksDB典型的做法是Level 0-2不压缩,最后一层使用zlib,而其它各层采用snappy。
在故障方面,RocksDB支持增量备份和全量备份,允许将已删除的数据备份到指定的目录,供后续恢复。
RocksDB支持在单个进程中启用多个实例,而LevelDB只允许单个实例。
RocksDB支持管道式的Memtable,也就说允许根据需要开辟多个Memtable,以解决Put与Compact速度差异的性能瓶颈问题。在LevelDB里面因为只有一个Memtable,如果Memtable满了却还来不及持久化,这个时候LevelDB将会减缓Put操作,导致整体性能下降。笔者目前写的引擎在这方面竟然跟RocksDB不谋而合,这里偷偷乐一下,呵呵。
看完上面这些介绍,相比LevelDB是不是觉得RocksDB彪悍的不可思议,很多该有的地方都有,该想的都想到了,简直不像在做引擎库,更像是在做产品。不过虽然RocksDB在性能上提升了不少,但在文件存储格式上跟LevelDB还是没什么变化的, 稍微有点更新的只是RocksDB对原来LevelDB中sst文件预留下来的MetaBlock进行了具体利用。
个人觉得RocksDB尚未解决的地方:
依然是完全依赖于MANIFEST,一当该文件丢失,则整个数据库基本废掉。
合并上依然是整个文件载入,一些没用的Value将被多次的读入内存,如果这些Value很大的话,那没必要的内存占用将是一个可观的成本。
关于这两个问题,尤其是后面那个问题,笔者已有相应的解决方案,至于结果如何只等日后实现之后再作解说了。
来自:http://tech.uc.cn/?p=2592
关于LevelDB的资料网上还是比较丰富的,如果你尚未听说过LevelDB,那请稍微预习一下,因为RocksDB实际上是在LevelDB之上做的改进。本文主要侧重在架构上对RocksDB对LevelDB改进的地方做个简单介绍并添加一些个人的看法,更详细的信息读者可参考其官网:http://rocksdb.org/
RocksDB是在LevelDB原来的代码上进行改进完善的,所以在用法上与LevelDB非常的相似。如下,就是简单的把原来Leveldb信息替换为Rocksdb,从继承的角度看,Rocksdb就像是Leveldb的后辈。
RocksDB:
#include "rocksdb/db.h"
rocksdb::DB* db;
rocksdb::Options options;
options.create_if_missing = true;
rocksdb::Status status = rocksdb::DB::Open(options, "/tmp/testdb", &db);
assert(status.ok());
status = db->Get(rocksdb::ReadOptions(), key1, &value);
status = db->Put(rocksdb::WriteOptions(), key2, value);
status = db->Delete(rocksdb::WriteOptions(), key1);
delete db;
#include "rocksdb/db.h"
rocksdb::DB* db;
rocksdb::Options options;
options.create_if_missing = true;
rocksdb::Status status = rocksdb::DB::Open(options, "/tmp/testdb", &db);
assert(status.ok());
status = db->Get(rocksdb::ReadOptions(), key1, &value);
status = db->Put(rocksdb::WriteOptions(), key2, value);
status = db->Delete(rocksdb::WriteOptions(), key1);
delete db;
LevelDB:
#include "leveldb/db.h"
leveldb::DB *db;
leveldb::Options options;
options.create_if_missing = true;
leveldb::Status status = leveldb::DB::Open(options, "/tmp/testdb", &db);
assert(status.ok());
status = db->Get(leveldb::ReadOptions(), key1, &value);
status = db->Put(leveldb::WriteOptions(), key2, value);
status = db->Delete(leveldb::WriteOptions(), key1);
delete db;
#include "leveldb/db.h"
leveldb::DB *db;
leveldb::Options options;
options.create_if_missing = true;
leveldb::Status status = leveldb::DB::Open(options, "/tmp/testdb", &db);
assert(status.ok());
status = db->Get(leveldb::ReadOptions(), key1, &value);
status = db->Put(leveldb::WriteOptions(), key2, value);
status = db->Delete(leveldb::WriteOptions(), key1);
delete db;
RocksDB虽然在代码层面上是在LevelDB原有的代码上进行开发的,但却借鉴了Apache HBase的一些好的idea。在云计算横行的年代,开口不离Hadoop,RocksDB也开始支持HDFS,允许从HDFS读取数据。而LevelDB则是一个比较单一的存储引擎,有点我就是我,除了我依然只有我的感觉。也是因为LevelDB的单一性,在做具体的应用的时候一般需要对其作进一步扩展。
RocksDB支持一次获取多个K-V,还支持Key范围查找。LevelDB只能获取单个Key
RocksDB除了简单的Put、Delete操作,还提供了一个Merge操作,说是为了对多个Put操作进行合并。站在引擎实现者的角度来看,相比其带来的价值,其实现的成本要昂贵很多。个人觉得有时过于追求完美不见得是好事,据笔者所测(包括测试自己编写的引擎),性能的瓶颈其实主要在合并上,多一次少一次Put对性能的影响并无大碍。
RocksDB提供一些方便的工具,这些工具包含解析sst文件中的K-V记录、解析MANIFEST文件的内容等。有了这些工具,就不用再像使用LevelDB那样,只能在程序中才能知道sst文件K-V的具体信息了。
RocksDB支持多线程合并,而LevelDB是单线程合并的。LSM型的数据结构,最大的性能问题就出现在其合并的时间损耗上,在多CPU的环境下,多线程合并那是LevelDB所无法比拟的。不过据其官网上的介绍,似乎多线程合并还只是针对那些与下一层没有Key重叠的文件,只是简单的rename而已,至于在真正数据上的合并方面是否也有用到多线程,就只能看代码了。
RocksDB增加了合并时过滤器,对一些不再符合条件的K-V进行丢弃,如根据K-V的有效期进行过滤。
压缩方面RocksDB可采用多种压缩算法,除了LevelDB用的snappy,还有zlib、bzip2。LevelDB里面按数据的压缩率(压缩后低于75%)判断是否对数据进行压缩存储,而RocksDB典型的做法是Level 0-2不压缩,最后一层使用zlib,而其它各层采用snappy。
在故障方面,RocksDB支持增量备份和全量备份,允许将已删除的数据备份到指定的目录,供后续恢复。
RocksDB支持在单个进程中启用多个实例,而LevelDB只允许单个实例。
RocksDB支持管道式的Memtable,也就说允许根据需要开辟多个Memtable,以解决Put与Compact速度差异的性能瓶颈问题。在LevelDB里面因为只有一个Memtable,如果Memtable满了却还来不及持久化,这个时候LevelDB将会减缓Put操作,导致整体性能下降。笔者目前写的引擎在这方面竟然跟RocksDB不谋而合,这里偷偷乐一下,呵呵。
看完上面这些介绍,相比LevelDB是不是觉得RocksDB彪悍的不可思议,很多该有的地方都有,该想的都想到了,简直不像在做引擎库,更像是在做产品。不过虽然RocksDB在性能上提升了不少,但在文件存储格式上跟LevelDB还是没什么变化的, 稍微有点更新的只是RocksDB对原来LevelDB中sst文件预留下来的MetaBlock进行了具体利用。
个人觉得RocksDB尚未解决的地方:
依然是完全依赖于MANIFEST,一当该文件丢失,则整个数据库基本废掉。
合并上依然是整个文件载入,一些没用的Value将被多次的读入内存,如果这些Value很大的话,那没必要的内存占用将是一个可观的成本。
关于这两个问题,尤其是后面那个问题,笔者已有相应的解决方案,至于结果如何只等日后实现之后再作解说了。
来自:http://tech.uc.cn/?p=2592
[实践OK]创建从0-9的目录结构层次,shell输出a-z,A-Z,0-9的脚本。
Unix/LinuxC技术 jackxiang 2015-12-8 09:41
背景:Nginx的断点上传这块涉及到一个创建散列目录的的情况,这块得从0-9,a-z,A-Z, 搜索了一下网上,用awk比较吃香。
________________________________________________________________________________
参考:http://blog.csdn.net/ghosc/article/details/5721178
awk如何输出A-Z ,网上高手很多:
不用麻烦awk了
这样就行了
那个echo {A..Z}够牛逼的~~
http://bbs.chinaunix.net/thread-1815653-1-1.html
________________________________________________________________________________
参考:http://blog.csdn.net/ghosc/article/details/5721178
awk如何输出A-Z ,网上高手很多:
不用麻烦awk了
这样就行了
那个echo {A..Z}够牛逼的~~
http://bbs.chinaunix.net/thread-1815653-1-1.html
背景:现在H5做上传呢,想有好的用户体验是直接提交ajax上传文件,其实用form跳转也是可以的,不是说用户体验不好嘛,其实我觉得也没啥不好的,只要提示明确就好,非要在一个页面上做所有的操作,这是产品挖空心思想的问题,为什么不能呢,这儿有一个兄弟告诉我们说能的。其主要是设置http的header头符合一些h5的跨域规范就成(像Flash有一个xml文件作验证的,Flash不行了,咱还是H5吧。),这块啥语言都能设置头,包括nginx的conf文件里也能设置(http://www.anrip.com/post/1501 ,http://blog.csdn.net/oyzl68/article/details/18741057(讲到两次请求,这更像是flash的那套作法了,这块服务端配置上可能会不大一样。),html5rocks.com 上面的头返回可参考。),先转下,尽管没有通知作者。
选择了http头来实现跨越的原理概述:
ajax跨域访问是一个老问题了,解决方法很多,比较常用的是JSONP方法,JSONP方法是一种非官方方法,而且这种方法只支持GET方式,不如POST方式安全。
即使使用jquery的jsonp方法,type设为POST,也会自动变为GET。
官方问题说明:
“script”: Evaluates the response as JavaScript and returns it as plain text. Disables caching by appending a query string parameter, “_=[TIMESTAMP]“, to the URL unless the cache option is set to true.Note: This will turn POSTs into GETs for remote-domain requests.
如果跨域使用POST方式,可以使用创建一个隐藏的iframe来实现,与ajax上传图片原理一样,但这样会比较麻烦。
——————————————————————————————————————————————————————————————
ajax跨域访问是一个老问题了,解决方法很多,比较常用的是JSONP方法,JSONP方法是一种非官方方法,而且这种方法只支持GET方式,不如POST方式安全。
即使使用jquery的jsonp方法,type设为POST,也会自动变为GET。
官方问题说明:
“script”: Evaluates the response as JavaScript and returns it as plain text. Disables caching by appending a query string parameter, “_=[TIMESTAMP]“, to the URL unless the cache option is set to true.Note: This will turn POSTs into GETs for remote-domain requests.
如果跨域使用POST方式,可以使用创建一个隐藏的iframe来实现,与ajax上传图片原理一样,但这样会比较麻烦。
因此,通过设置Access-Control-Allow-Origin来实现跨域访问比较简单。
例如:客户端的域名是www.client.com,而请求的域名是www.server.com
如果直接使用ajax访问,会有以下错误
XMLHttpRequest cannot load http://www.server.com/server.php. No 'Access-Control-Allow-Origin' header is present on the requested resource.Origin 'http://www.client.com' is therefore not allowed access.
在被请求的Response header中加入
就可以实现ajax POST跨域访问了。
代码如下:
client.html 路径:http://www.client.com/client.html
server.php 路径:http://www.server.com/server.php
Access-Control-Allow-Origin:* 表示允许任何域名跨域访问
如果需要指定某域名才允许跨域访问,只需把Access-Control-Allow-Origin:*改为Access-Control-Allow-Origin:允许的域名
例如:header('Access-Control-Allow-Origin:http://www.client.com');
如果需要设置多个域名允许访问,这里需要用php处理一下
例如允许 www.client.com 与 www.client2.com 可以跨域访问
server.php 修改为
源码下载地址:http://download.csdn.net/detail/fdipzone/8779657
该文转自:http://blog.csdn.net/fdipzone/article/details/46390573
选择了http头来实现跨越的原理概述:
ajax跨域访问是一个老问题了,解决方法很多,比较常用的是JSONP方法,JSONP方法是一种非官方方法,而且这种方法只支持GET方式,不如POST方式安全。
即使使用jquery的jsonp方法,type设为POST,也会自动变为GET。
官方问题说明:
“script”: Evaluates the response as JavaScript and returns it as plain text. Disables caching by appending a query string parameter, “_=[TIMESTAMP]“, to the URL unless the cache option is set to true.Note: This will turn POSTs into GETs for remote-domain requests.
如果跨域使用POST方式,可以使用创建一个隐藏的iframe来实现,与ajax上传图片原理一样,但这样会比较麻烦。
——————————————————————————————————————————————————————————————
ajax跨域访问是一个老问题了,解决方法很多,比较常用的是JSONP方法,JSONP方法是一种非官方方法,而且这种方法只支持GET方式,不如POST方式安全。
即使使用jquery的jsonp方法,type设为POST,也会自动变为GET。
官方问题说明:
“script”: Evaluates the response as JavaScript and returns it as plain text. Disables caching by appending a query string parameter, “_=[TIMESTAMP]“, to the URL unless the cache option is set to true.Note: This will turn POSTs into GETs for remote-domain requests.
如果跨域使用POST方式,可以使用创建一个隐藏的iframe来实现,与ajax上传图片原理一样,但这样会比较麻烦。
因此,通过设置Access-Control-Allow-Origin来实现跨域访问比较简单。
例如:客户端的域名是www.client.com,而请求的域名是www.server.com
如果直接使用ajax访问,会有以下错误
XMLHttpRequest cannot load http://www.server.com/server.php. No 'Access-Control-Allow-Origin' header is present on the requested resource.Origin 'http://www.client.com' is therefore not allowed access.
在被请求的Response header中加入
就可以实现ajax POST跨域访问了。
代码如下:
client.html 路径:http://www.client.com/client.html
server.php 路径:http://www.server.com/server.php
Access-Control-Allow-Origin:* 表示允许任何域名跨域访问
如果需要指定某域名才允许跨域访问,只需把Access-Control-Allow-Origin:*改为Access-Control-Allow-Origin:允许的域名
例如:header('Access-Control-Allow-Origin:http://www.client.com');
如果需要设置多个域名允许访问,这里需要用php处理一下
例如允许 www.client.com 与 www.client2.com 可以跨域访问
server.php 修改为
源码下载地址:http://download.csdn.net/detail/fdipzone/8779657
该文转自:http://blog.csdn.net/fdipzone/article/details/46390573
linux下的/opt目录是做什么用的?空间不够了可以挪走。
Unix/LinuxC技术 jackxiang 2015-12-4 11:58
/opt 主机额外安装软件所摆放的目录。默认是空的。 一般安装软件的时候,可以自己指定安装到这个目录下,便于查找和管理:
[root@localhost opt]# ls /opt
20120207 mysql-5.6.11
/根空间太小大了,直接挪动到其它盘符(data目录大: 171G 39G 123G 24% /data),做个软链接:
/opt -> /data/backdata/opt
[root@localhost opt]# ls /opt
20120207 mysql-5.6.11
/根空间太小大了,直接挪动到其它盘符(data目录大: 171G 39G 123G 24% /data),做个软链接:
/opt -> /data/backdata/opt