1、系统情况：

  操作系统：Redhat AS4

  数据库：mysql 4.1.18

  应用服务器：JBoss 3.2.7

  服务器： 4 x3.00GHz的Intel Xeon CPU

  数据库和应用服务器都部署在同一台服务器上。

  简单跟踪了一下，发现平常内存、io负载都不大，数据库连接数也不多。只是很奇怪的是mysql的cpu负载始终是99.9%,但整个系统的速度还行，开始怀疑是JVM、数据库参数、索引没有优化导致的，因此先着手对java虚拟机参数及数据库参数进行了调整。

2、java虚拟机调优

• 调整虚拟机的参数

  JAVA_OPTS=”$JAVA_OPTS -Xms512m -Xmx1024m -server -XX:MaxPermSize=300m -XX:MaxNewSize=300m”

• 调整jboss的数据库连接池，修改最大连接数及连接回收时间

<min-pool-size>20</min-pool-size>

<max-pool-size>300</max-pool-size>

<idle-timeout-minutes>1</idle-timeout-minutes>

<min-pool-size>20</min-pool-size>

3、数据库调优

• 对所有的表，优化及增加索引。

发现一个好用的mysql工具navicat，感觉比ems 好用，用这东西增加索引方便多了。

• 调整mysql参数

原来是基于my-medium.cnf 修改的参数，由于担心是大数据量查询sort区等不够及程序存在内存泄露问题，因此基于my-huge.cnf进行调整。

[client]
port            = 3306
socket          = /var/lib/mysql/mysql.sock
[mysqld]
port            = 3306
socket          = /var/lib/mysql/mysql.sock
skip-locking
key_buffer = 256M
max_allowed_packet = 1M
table_cache = 256
sort_buffer_size = 2M
read_buffer_size = 2M
read_rnd_buffer_size = 2M
myisam_sort_buffer_size = 64M
thread_cache_size = 8
query_cache_size= 32M
thread_concurrency = 8
max_connections=300

#skip-networking

#log-bin

server-id       = 1

[mysqldump]
quick
max_allowed_packet = 16M

[mysql]
no-auto-rehash
#safe-updates

[isamchk]
key_buffer = 128M
sort_buffer_size = 128M
read_buffer = 2M
write_buffer = 2M

[myisamchk]
key_buffer = 128M
sort_buffer_size = 128M
read_buffer = 2M
write_buffer = 2M

[mysqlhotcopy]
interactive-timeout

调整后，支撑了3天左右，除了mysql的cpu占用始终是99%外，系统整体运行基本正常，忙于其他事情，没有继续跟踪。没想到大年初一接了一堆报警短信，执行查看了系统参数，发现系统竟然没有swap区，欣喜一阵，可能是这原因吧，于是临时建立swap区。

4、增加swap区

• 在/swap下生成1G的文件

     # mkdir /swap

　　# dd if=/dev/zero of=/swap/swapfile bs=500M count=2

• 创建为swap文件

　　#mkswap /swap

• 让swap生效

　　#swapon /swap

• 查看一下swap

　　#swapon -s

• 把新增的swap文件加到fstab文件中让系统引导时自动启动

　　#vi /etc/fstab

　　/swap/swapfile swap swap defaults 0 0

    增加后，重启应用及服务，mysql的cpu占用还是持续性为99.9%，而且运行上一段时间还是出现无法登录的情况。远程登录到系统，发现内存、io、swap区占用都很正常，数据库连接数也很正常，而且在停止mysql和jboss后，直接重启jboss，不能正常启动成功，需要等上一会儿，怀疑是文件句柄及tcp连接尚未正常释放。联系以前遇到的情况，怀疑与操作系统允许的最大句柄数有关。

用ulimit -a|grep open 命令查看了结果为：

open files                      (-n) 1024

用cat /proc/sys/fs/file-max查看结果为：

379816

由于数据库和jboss同时部署在同一台服务器上，在负荷较小的情况下用lsof -u root |wc -l查看root用户的句柄数仍然为700多，因此在负荷较高的情况下，用户的最大句柄数1024是有点小。

5、修改操作系统句柄数

5.1、修改操作系统的最大限制数

• 修改 /etc/sysctl.conf

    增加fs.file-max = 8061540

• 在/etc/pam.d/login 中添加  

    session     required      /lib/security/pam_limits.so

• 在/etc/security/limits.conf 中添加
  root              -        nofile           1006154

  修改root用户的句柄数（包括hard和soft）限制为1006154

• 修改 /etc/rc.local   添加
  echo 8061540 > /proc/sys/fs/file-max

5.2、修改用户最大限制数

考虑到重启服务器的风险，先暂时修改一下启动jboss的root用户的/root/.bash_profile，增加如下内容：

ulimit -n 65535

重启jboss和mysql。

连续观察了几天，发现cpu始终占用99.9%的情况解决掉了，继续观察中。

6、参考文档

http://www.bea.com.cn/support_pattern/Too_Many_Open_Files_Pattern.html

http://kbase.redhat.com/faq/FAQ_80_1540.shtm

© chuanliang for 出家如初，成佛有余, 2008. | Permalink | One comment

Add to del.icio.us

Search blogs linking this post with Technorati

Want more on these topics ? Browse the archive of posts filed under 技术相关.