更新了很多编程相关的内容，作为技术宅也稍微写点其他技术方面的文章。在杭外时，Kaijia笔记本上的EDIUS还是运行得相当流畅的，处理多机位时也不会出现卡顿等问题。但2年多过去了，Kaijia笔记本的性能可以说是“每况愈下”，已经几乎只能拿来编程了。
现在Kaijia有时用EDIUS编辑多机位（尤其是三机位以上）的视频基本上都是一顿一顿得进行的。这个问题基本上可以归因为两种：Windows系统效率降低；视频质量的提升。以前Kaijia使用的素材基本上都在720P以下，码率很少有超过10M的。现在手机都能清楚1080P甚至4K全高清摄像，码率可以高达30M。而Kaijia的笔记本硬件也没有更新，处理器性能自然无法跟上要求。
就像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大量进程占用内存情况
虽然Kaijia放在VestaCP服务器上的网站P/V很低，但大量的PHP-CGI进程仍然在服务器重启后数小时内基本耗尽了内存，很早之前闲置的PHP-CGI进程没有被杀死，一个进程下面运行了近20个子进程消耗了至少100M的内存。造成这一现象的原因既是VestaCP在Ubuntu的phpfcgid模板中使用了未优化的配置。
数据库损害的情况经常发生，尤其是OpenVZ VPS，当物理服务器非正常关机，而是断电或者直接崩溃时，MySQL数据库损坏几乎是不可避免的，尤其是数据库量比较大的时候。Kaijia已经遇到过数次数据库损坏的情况，一般情况下MySQL的调试日志里面会直接给出修复提示，比如在my.cnf中增加：
|
1 |
innodb_use_native_aio = 0 |
关闭异步I/O操作等，此类操作一般能恢复数据库的正常使用。但这次Kaijia遇到了一次由于物理服务器宕机造成的MySQL数据库损坏，并且错误信息也没有给出任何修复提示，此时应该按照MySQL文档中给出的步骤恢复InnoDB，这个过程相对比较复杂，并且考虑到损害的数据库并不大，也不常用，并且每小时都有备份，于是Kaijia决定直接通过还原备份恢复已损坏MySQL数据库文件。
目前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决定将这个过程分享给大家。
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初始设计是大型公司用于监控服务器集群的，但日常中也用于监控VPS或云主机。后者情况下Zabbix的很多配置和属性就没有经过优化，取决于监控的对象和用途，经常需要对一些Zabbix配置进行调整。Kaijia主要使用Zabbix监控一些云主机和VPS，也会经常遇到一些问题，比如之前遇到的“Lack of free swap space”问题，今天写下来和大家分享。
Kaijia使用的部分云主机（例如DigitalOcean）和VPS（一代OpenVZ）都没有设置交换分区/虚拟内存，使用free -m命令将会显示SWAP三项都为0。
free -m命令显示系统无交换空间
这种情况下，如果开启Zabbix监控，Zabbix将会报告系统缺少交换分区空间（“Lack of free swap space”）。这完全可以理解，因为按照正常的逻辑，一台物理服务器不可能不设置交换分区。显然，这样的设计没有考虑到云主机用户，但需要适当调整监控文件配置即可解决问题。
之前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中的默认站点。
好久没有更新了，最近Kaijia做科研项目计算又租用了一台支持IPv6的服务器。按照往常Kaijia会在架设完服务器之后设置好Zabbix Agent，后期就使用Zabbix服务监控服务器的稳定性，一般情况下设置完成后服务器就能稳定运行了，Kaijia也很少收到服务器宕机的通知。
但是这次Kaijia遇到了一个奇怪的情况，Zabbix监控间断发出“Zabbix agent on * is unreachable for 5 minutes”提醒，基本上一小时内能有四五次。一开始Kaijia认为此问题是网络连接不稳定造成的（毕竟新的服务器与Zabbix所在的监控服务器物理距离挺远的），于是观察了网络，也没有发现异常。保险起见Kaijia还利用附近一台Zabbix监控一直非常稳定的节点架设了Zabbix Proxy，但仍然没有有效问题。
之前Kaijia在升级一台全新安装Ubuntu 12.04的OpenVZ系统到Ubuntu 14.04时遇到了升级脚本无法启动的问题，在这里也做记录。Ubuntu的LTS版本间的升级一般都是建议重装，但有的时候必须通过升级完成，比如没有提供Ubuntu 14.04模板的OpenVZ系统，此时就需要通过运行：
|
1 |
do-release-upgrade -d |
升级。Kaijia升级其他机子时都没有遇到问题，唯独在这台OpenVZ上一运行do-release-upgrade直接出现了以下错误提示：
|
1 2 3 4 5 6 7 |
Error in sys.excepthook: Traceback (most recent call last): File "/tmp/update-manager-A4Uzdw/DistUpgrade/DistUpgradeViewText.py", line 108, in _handleException "\n".join(lines)) File "/tmp/update-manager-A4Uzdw/DistUpgrade/DistUpgradeViewText.py", line 142, in error print(twrap(summary)) UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-5: ordinal not in range(128) |
自从在Zabbix中开启了FTP（Template App FTP Service）监控之后，Kaijia发现了有一台Virtualmin服务器的ProFTPD服务经常掉。虽然每次重启之后都能解决问题但Kaijia还是留意了一下日志，因为流量小所以日志非常简单很快就找到了与问题关联的内容：
2014-08-15 00:41:13,737 kaijia proftpd[1020] kaijia.me: ProFTPD killed (signal 15)
2014-08-15 00:41:13,815 kaijia proftpd[1020] kaijia.me: ProFTPD 1.3.5rc3 standalone mode SHUTDOWN
看起来这又像是一个仅有两行日志的无头案了。不过由于日志明确给出了退出信号“killed (signal 15)”，因此Google的话还是比较简单找到答案的，最后Kaijia在一篇Stack Overflow中找到了解决方案。
- 已经载入全部文章 -
近期评论