Building the Coming Soon

关于

Kaijia graduated from the Akademia. He is always proud to be a HFLSer!

SSH Channel“open failed: connect failed: Connection timed out”问题解决

09/07/2015

在Hyper-V的虚拟机里面运行Linux网络性能果真要比KVM差一些,当然此间原因很多:驱动、NAT转换效率等等。这次Kaijia遇到的大量“open failed: connect failed: Connection timed out”问题,最后看来也是连接性能原因。

Kaijia用SSH转Socket连接到不同地区的IP,然后进行检测和数据采集,同时所有连接同时有流量传输,一开始一切正常,但是Socket运行时间久后就会慢慢出现“open failed: connect failed: Connection timed out”错误提示。于是Kaijia开启调试模式分析了一下错误信息,看到了很多类似以下的信息:

debugx: channel x: open confirm rwindow ?? rmax ??
channel x: open failed: connect failed: Connection timed out
debugx: channel x: free: direct-tcpip: listening port xxxxx for xxx.xxx.xxx.xxx port 80, connect from 172.16.1.xxx port xxxxx to 172.16.1.xxx port xxxxx, nchannels x
debugx: channel x: zombie
debugx: channel x: garbage collecting
debugx: channel x: read failed
debugx: channel x: close_read
debugx: channel x: input open -> drain
debugx: channel x: ibuf empty
debugx: channel x: send eof
debugx: channel x: input drain -> closed

结合错误提示,网上搜了一些,很好理解即连接在允许的时间内没有收到任何信息,于是发送了EOF结束,返回了连接超时错误,因此可以说是连接的性能问题。根本上解决问题是比较困难的,涉及到很多方面因素,比较现实的解决方法便是延长等待时间,避免连接超时(Timeout)以增加收到数据包的概率。

阅读更多

MySQL命令行操作限定单个数据库方法

09/06/2015

写这篇文章的原因出自Kaijia一次被Stack Overflow坑的经历,回头看来虽然Stack Exchange的Peer Review机制很好,但是错误照样还是很多的,以及Kaijia提交了Edit被Peer Review拒绝了……

之前某个插件神不知鬼不觉地删除了所有WordPress数据表的主键和自增,导致系统出现异常,如果手动恢复的话要处理近30余张主键规则不同的表非常麻烦,于是Kaijia决定采用数据恢复的方式,即先将现有数据导出并删除表,再导入数据库备份重建表结构,再将现有数据导入。这样一来数据是现有的数据,表结构是损坏前的正确结构完成修复。

按照这个步骤下去,第二步是导入备份,但是Kaijia的数据库备份是全数据库整盘备份,单个SQL文件里面包含了所有数据库的数据,而本次恢复涉及单个数据库,不能影响其他数据库。之前没有类似经验无从下手,于是Kaijia搜索了下找到了此篇Stack Overflow问题《Can I restore a single table from a full mysql mysqldump file?》,高票回答是使用sed命令(完全正确),但是显然没有后面的正面回答(后来证实是坑)方便。后面回答的要旨非常简单:

mysql命令最后加上指定的数据库名便可以了!这不科学!但鉴于此答案有还有人点赞,还有人评论“This is what most people need.”于是Kaijia就尝试了……结果果真其他的数据库都被还原了,当然幸亏操作前Kaijia给服务器快照了一下,直接恢复了。

阅读更多

文件句柄限制造成“accept: Too many open files”问题解决

09/04/2015

由于数据采集需要,而且流量并不大,不需要使用分布式爬虫,Kaijia使用使用一台服务器同时连接近百个SSH并生成Socket处理采集需求,一开始运行的相当流畅,但是大约数小时后终端便开始不停地弹出“accept: Too many open files”报错。

于是便简单地使用lsof命令查看了单个SSH进程使用的文件句柄数量:

结果发现单个SSH比预想中的文件句柄使用率要多很多,连接繁忙(例如并发)的时候可以达到两三百,一般情况下只要Socket有数据传输就可能打开一百个文件句柄。考虑到同时运行的Socket数量较多,同时存在的文件句柄数量可能会超过Linux系统设置的上限,造成“accept: Too many open files”问题。

阅读更多

EDIUS多机位编辑卡顿问题解决

11/19/2014

更新了很多编程相关的内容,作为技术宅也稍微写点其他技术方面的文章。在杭外时,Kaijia笔记本上的EDIUS还是运行得相当流畅的,处理多机位时也不会出现卡顿等问题。但2年多过去了,Kaijia笔记本的性能可以说是“每况愈下”,已经几乎只能拿来编程了。

现在Kaijia有时用EDIUS编辑多机位(尤其是三机位以上)的视频基本上都是一顿一顿得进行的。这个问题基本上可以归因为两种:Windows系统效率降低;视频质量的提升。以前Kaijia使用的素材基本上都在720P以下,码率很少有超过10M的。现在手机都能清楚1080P甚至4K全高清摄像,码率可以高达30M。而Kaijia的笔记本硬件也没有更新,处理器性能自然无法跟上要求。

阅读更多

VestaCP面板PHP-CGI进程过多耗尽内存问题解决

11/18/2014

就像Kaijia在上一篇文章中提到的一样,VestaCP面板对较新发布的系统支持并不理想,到现在对Ubuntu 14.04的支持只能说是勉强能正常运行,还没有得到很好的优化,而对Redhat/CentOS 7的支持则完全还没开始。在Ubuntu 14.04系统中,VestaCP面板的部分设置仍有调整优化的空间,Kaijia这次就遇到的PHP-CGI进程耗尽内存的情况就是由于配置未优化造成的。

Kaijia的VestaCP模块(Package)设置使用的是phpfcgid模板,这样可以通过PHP-CGI模块有效得实现站点间文件访问的阻隔。但这样做的代价是每个Unix用户都会拥有自己的FCGI实例,因此需要支出额外的内存。当配置失当时更会造成虽然服务器访问量低但内存接近耗尽的情况,使用htop等工具查看有如下图:

HTOP显示PHP-CGI大量进程占用内存情况

HTOP显示PHP-CGI大量进程占用内存情况

虽然Kaijia放在VestaCP服务器上的网站P/V很低,但大量的PHP-CGI进程仍然在服务器重启后数小时内基本耗尽了内存,很早之前闲置的PHP-CGI进程没有被杀死,一个进程下面运行了近20个子进程消耗了至少100M的内存。造成这一现象的原因既是VestaCP在Ubuntu的phpfcgid模板中使用了未优化的配置。

阅读更多

Ubuntu系统使用备份恢复已损坏MySQL数据库

11/18/2014

数据库损害的情况经常发生,尤其是OpenVZ VPS,当物理服务器非正常关机,而是断电或者直接崩溃时,MySQL数据库损坏几乎是不可避免的,尤其是数据库量比较大的时候。Kaijia已经遇到过数次数据库损坏的情况,一般情况下MySQL的调试日志里面会直接给出修复提示,比如在my.cnf中增加:

关闭异步I/O操作等,此类操作一般能恢复数据库的正常使用。但这次Kaijia遇到了一次由于物理服务器宕机造成的MySQL数据库损坏,并且错误信息也没有给出任何修复提示,此时应该按照MySQL文档中给出的步骤恢复InnoDB,这个过程相对比较复杂,并且考虑到损害的数据库并不大,也不常用,并且每小时都有备份,于是Kaijia决定直接通过还原备份恢复已损坏MySQL数据库文件。

阅读更多

DigitalOcean恢复模式挂载分区并修改文件方法

11/16/2014

目前Kaijia使用DigitalOcean(有学生优惠~)跑个人网盘和实验项目,DO的网速相对其他线路要快不少方便网盘数据下载上传。由于DO的硬盘有限无法满足网盘的需求,Kaijia将网盘数据文件夹存在另一台大硬盘的服务器上,然后使用SSHFS挂载到DO。

Kaijia在/etc/fstab中设置了自动挂载,但由于不明原因(应该是因为SSH连接比较耗时),系统启动时一直无法自动挂载SSHFS。以前做运维的计算机老师上课常说不要乱抄别人的配置,这次Kaijia还撞上去了。Kaijia搜索了一下直接按照找到的结果在/etc/fstab中加上了“delay_connect”属性,也没有仔细测试,重启之后系统就直接卡死在了启动界面上了。这种情况一般可以在Console中跳过挂载,但这个方法在这里无法实现,Kaijia等待了5分钟还是没有响应,这种情况只能使用DO的恢复模式(Recovery Mode)来修改刚才编辑的文件了。

搜索了一下DigitalOcean的知识库发现DO并没有提供恢复模式相关的文章,唯一的一篇是“How To Recover from File System Corruption Using Fsck and a Recovery ISO”介绍如何在恢复模式下使用Fsck(虽然云环境下一般用不着),并且也没有中文文档,所以Kaijia决定将这个过程分享给大家。

阅读更多

Ubuntu 14.04系统VestaCP面板MySQL无法正常运行问题解决

11/14/2014

VestaCP是一款新兴的虚拟主机面板,它以LAMP为核心(也支持Python程序),使用Nginx做前端,同时还支持FTP、邮件和DNS服务器功能,整体功能非常简洁强大,更重要的是,它的界面设计符合潮流。

Kaijia最近也开始学习使用VestaCP并将一台运行Virtualmin的服务器搬到了VestaCP平台下,在这一过程中Kaijia遇到了很多问题。由于VestaCP一开始设计只考虑了RedHat/CentOS,Debian/Ubuntu的支持相对比较欠缺,尤其是Ubuntu 14.04相较其他几个版本变化很大(PHP 5.5和Apache 2.4了,而VestaCP支持的其他发行版基本都在PHP 5.3和Apache 2.2,另外还有upstart/systemd等问题),相应单一发行版的Bug也特别多。在今后的文章中Kaijia将会不定期分享在Ubuntu 14.04系统下使用VestaCP面板遇到的问题和解决经验。

比如这次遇到的问题经过分析也应该是Ubuntu 14.04系统特有的。Kaijia一开始完成VestaCP安装后系统可以正常运行并没有发现任何错误,但是重启服务器之后却出现了MySQL无法使用的问题,无法通过VestaCP面板创建数据库,同时站点也无法连接到数据库。查看MySQL的错误日志可以看到提示InnoDB文件已被锁定:

InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.

阅读更多

Zabbix报告无交换内存主机“Lack of free swap space”问题解决

11/13/2014

Zabbix初始设计是大型公司用于监控服务器集群的,但日常中也用于监控VPS或云主机。后者情况下Zabbix的很多配置和属性就没有经过优化,取决于监控的对象和用途,经常需要对一些Zabbix配置进行调整。Kaijia主要使用Zabbix监控一些云主机和VPS,也会经常遇到一些问题,比如之前遇到的“Lack of free swap space”问题,今天写下来和大家分享。

Kaijia使用的部分云主机(例如DigitalOcean)和VPS(一代OpenVZ)都没有设置交换分区/虚拟内存,使用free -m命令将会显示SWAP三项都为0。

free -m命令显示系统无交换空间

free -m命令显示系统无交换空间

这种情况下,如果开启Zabbix监控,Zabbix将会报告系统缺少交换分区空间(“Lack of free swap space”)。这完全可以理解,因为按照正常的逻辑,一台物理服务器不可能不设置交换分区。显然,这样的设计没有考虑到云主机用户,但需要适当调整监控文件配置即可解决问题。

阅读更多

Ubuntu系统Apache无法解析与FQDN同名虚拟主机问题解决

11/12/2014

之前Kaijia配置Apache服务器时遇到了这样问题,现在把当时的处理记录一下。一般情况下单台Apache服务器倾向于运行单个站点,此时只需要将代码目录放置到/var/www/html文件夹中即可。但当单台Apache服务器需要运行多个站点时我们就会用到Apache服务器的VirtualHost技术。Kaijia的博客服务器一开始将短地址服务设置为默认的主机,这样所有通过错误域名访问或直接扫描IP的请求就会跳转到Kaijia的博客(增加博客访问量。。),但经过一段时间后Kaijia发现这类访问多但转化率极低而且基本上都是机器人,只会影响服务器性能,因此现在Kaijia考虑将默认的站点留空,这样看到的就是Ubuntu的默认静态页面,可以起到降低负载的作用。

于是Kaijia将/etc/apache2/sites-available/000-default.conf文件中的ServerName改回了localhost,然后又新建了一个ServerName为kaijia.me(运行短地址程序)的VirtualHost。重新载入配置后Kaijia却发现Apache无法正常解析kaijia.me的VirtualHost。于是Kaijia做了一些调试,发现无论将ServerName改成任何域名,VirtualHost都能被正常解析,只有ServerName使用kaijia.me时,网站才无法正常打开,而会直接使用000-default.conf中的默认站点。

阅读更多

较新文章
较旧文章