升级完网站系统之后,在网站的程序文件夹下这样的权限是极端不靠谱的:
drwxrwxrwx 20 www www 1.0K Jun 6 02:27 www/
可以先执行以下操作:
chown -R www:www /www;chmod u-w,u-r,g-w,g-r /www
find /www -typ...
升级完网站系统之后,在网站的程序文件夹下这样的权限是极端不靠谱的:
drwxrwxrwx 20 www www 1.0K Jun 6 02:27 www/
可以先执行以下操作:
chown -R www:www /www;chmod u-w,u-r,g-w,g-r /www
find /www -typ...
五一的时候yycrazy本来准备对服务器上的应用进行一次分离操作,但是由于极差的网络性能铩羽而归。自从五一过后服务器一直处于极度不稳定状态:系统不定期并且毫无征兆的所有phpcgi进程突然卡死导致CPU负载飙升并导致全站所有动态内容访问很慢且最终全线奔溃。
一开始找了很多资料尝试了很多方法都没有明显的好转,因为没有任何一定的触发条件,并且所有等级的日志和监控都无法记录任何蛛丝马迹,所以一时很难做出准确判断。无意之中在网上看到有TX反应Discuz X 1.5在nginx+php-cgi环境下使用manyou应用的时候很容易导致php-cgi进程高负载运作大量消耗CPU资源,于是尝试将开启的Discuz X1.5的manyou应用关闭,发现问题有很大的缓解,本来以为已经解决了,但是第二天凌晨时再度出现毫无征兆的所有phpcgi进程突然卡死让我无奈地之后从更底层的角度去考录解决的办法。
经过漫长的排查与测试最终发现问题出在/boot/loader.conf中的设置上,一开始安装FreeBSD的时候顺手copy了之前的一份优化过的loader.conf配置的一部分,里面有一个参数 kern.ipc.nmbclusters="0" ,本来只是将nmbclusters设置成无限制,但是问题就出在只copy了一部分:因为kern.ipc.nmbclusters被设置成 0 的情況下,net.inet.tcp.reass.maxsegments 参数也跟着一同被设置成 0 了。net.inet.tcp.reass.maxsegments被设置成0之后在有大量 TCP out-of-order 封包的网络情况下,FreeBSD的性能将会变得极差而且整个系统会非常的脆弱,在出现问题的时候用netstat查看连接信息可以发现packets discarded due to memory problems的计数相当之多而 TCP out-of-order的计数永远为0。
Automysqlbackup是一个非常不错的轻量级Mysql自动备份脚本,你可以在http://sourceforge.net/projects/automysqlbackup/files/AutoMySQLBackup/下载到最新的版本,经过简单的配置之后添加到系统的周期执行列表中去即可简单实现mysql自动备份的功能。但是这么一个简洁而强大的工具在FreeBSD下使用的时候会提示如下的错误...
很好用的工具 diskinfo -tv da0
da0是磁盘名
手机上一直收到来自服务器的负载过高报警短信,上服务器检查后发现被同一内网IP的机器DoS了,找出问题所在之后在ipf中添加上了禁止DoS主机的源IP,整个系统的负载瞬间就下来了,php-cgi进程也都空闲了。同一网段的IP还不知道是谁么,机房里就那么几台服务器,不是被入侵的话那就是有人搞鬼了…… 不知道哪位TX这么有闲情做这么些无聊之事,如果相当有闲情的话不妨联系一下我。
顺便记录一下FreeBSD下常用的统计当前系统网络连接状态的一些命令:
摘 要:本文依托cnfug开发的Floppy Firewall为平台,以嗅探器抓包分析结合相应的路由转发规分析IPFilter对数据报进行转发和NAT的机理,最终针对实际案例的需求提出解决方案。
关键词:NAT FreeBSD 嗅探器 TCP/IP