项目中因为追求执行速度和高效管理，采用了sqlite3文本数据库作为系统的数据库，几百次压力测试中出现“打不开数据库文件”错误，导致后期对数据库操作均报错，系统瘫痪。出现该问题，定位方法：
1）首先sqlite登入数据库，查看数据库内容是否正确，是否是替换了数据库文件但进程未重新加载导致。经检查，排除该可能性。
2）其次查看sqlite3源码执行过程中返回的错误，文件打开失败，open一个文件时失败。出现该错误，一般由于进程的文件描述符耗尽导致，找到了怀疑点
3）查看操作数据库的进程已占用的文件描述符，一般一个进程最大文件描述符为1023个，假设该进程PID为223，则cd /proc/223/fd; ls -l，可以看到该进程占有所有的文件描述，已达到1023个，资源耗尽，导致再次获取文件描述符失败。一般是由于socket创建后未关闭导致泄漏资源。
也可以通过lsof（list open files）命令查看进程已占用了多少文件描述符，对系统的监测和排错有很大的帮助。
lsof | grep xxx(进程名)/PID（进程号）查看已占用的文件描述符
4）执行netstat -a 查看所有的连接，发现大量redis数据库连接connected状态，基本锁定连接redis时出现资源泄漏。
5）分析测试场景和相关代码，发现的确存在大量的资源泄漏问题。
附：
1. 系统最大打开文件描述符数：/proc/sys/fs/file-max
a. 查看
$ cat /proc/sys/fs/file-max
186405
2. 设置
a. 临时性
# echo 1000000 > /proc/sys/fs/file-max
2. 永久性：在/etc/sysctl.conf中设置
fs.file-max = 1000000
2. 进程最大打开文件描述符数：user limit中nofile的soft limit
a. 查看
$ ulimit -n
1700000
2. 设置
a. 临时性：通过ulimit -Sn设置最大打开文件描述符数的soft limit，注意soft limit不能大于hard limit（ulimit -Hn可查看hard limit），另外ulimit -n默认查看的是soft limit，但是ulimit -n 1800000则是同时设置soft limit和hard limit。对于非root用户只能设置比原来小的hard limit。
查看hard limit：
$ ulimit -Hn
1700000
设置soft limit，必须小于hard limit：
$ ulimit -Sn 1600000
2. 永久性：上面的方法只是临时性的，注销重新登录就失效了，而且不能增大hard limit，只能在hard limit范围内修改soft limit。若要使修改永久有效，则需要在/etc/security/limits.conf中进行设置（需要root权限），可添加如下两行，表示用户chanon最大打开文件描述符数的soft limit为1800000，hard limit为2000000。以下设置需要注销之后重新登录才能生效：
chanon soft nofile 1800000
chanon hard nofile 2000000
设置nofile的hard limit还有一点要注意的就是hard limit不能大于/proc/sys/fs/nr_open，假如hard limit大于nr_open，注销后无法正常登录。可以修改nr_open的值：
# echo 2000000 > /proc/sys/fs/nr_open
3. 查看当前系统使用的打开文件描述符数
[root@localhost bin]# cat /proc/sys/fs/file-nr
5664 0 186405
其中第一个数表示当前系统已分配使用的打开文件描述符数，第二个数为分配后已释放的（目前已不再使用），第三个数等于file-max。
4. 总结：
a. 所有进程打开的文件描述符数不能超过/proc/sys/fs/file-max
b. 单个进程打开的文件描述符数不能超过user limit中nofile的soft limit
c. nofile的soft limit不能超过其hard limit
d. nofile的hard limit不能超过/proc/sys/fs/nr_open