开心保网站自建立一年来经历了很多问题和教训，随着访问量的不断提升，如何提升服务器性能、改善用户体验、增强网站稳定性成为了今后我工作的重点，同时我也决定将更多部门和团队管理方面的时间挤出来用于网站性能、稳定性、抗灾性的提升上，并通过自身希望能在web安全、高可用性以及可扩展架构部署方面达到熟练和精通的程度。
开心保网站使用了nginx的反向代理，由于服务器采用的是4核CPU8G内存，如何充分利用这些配置是我一直思考的问题，网站有时候会时不时的卡死，保险产品条款及批量上传有时会特别慢，我一直坚信nginx之所以这么流行，肯定有我不知道的一些隐藏的功能没有被我挖掘出来：
原来nginx设置的work_processes设置的是2，说明4核cpu没有充分使用，于是我把work_processes改成了4，同时为每一个进程分配了一个cpu:worker_cpu_affinity 0001 0100 0010 0001;可以看到加上主进程共有5个进程在运行
root 12318 0.0 0.0 44268 2136 ? Ss Nov22 0:00 nginx: master process /alidata/server/nginx/sbin/nginx
APPuser 23984 0.7 0.0 44712 3092 ? S 15:02 0:05 nginx: worker process
appuser 23985 0.7 0.0 44636 3036 ? S 15:02 0:06 nginx: worker process
appuser 23986 0.7 0.0 44636 3068 ? S 15:02 0:05 nginx: worker process
appuser 23987 0.8 0.0 44944 3324 ? S 15:02 0:06 nginx: worker process
平滑重启nginx服务，测试cpu的使用情况，使用top命令让后按1，看到的生产环境的cpu运行情况如下：可以看到基本每个cup都在工作了，把睡觉的2个都给用了起来，哈哈！
top - 15:11:19 up 19 days, 3:50, 2 users, load average: 0.14, 0.27, 0.30
Tasks: 110 total, 1 running, 108 sleeping, 1 stopped, 0 zombie
Cpu0 : 9.3%us, 0.7%sy, 0.0%ni, 89.0%id, 0.3%wa, 0.0%hi, 0.7%si, 0.0%st
Cpu1 : 0.3%us, 0.0%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu2 : 0.3%us, 0.0%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu3 : 0.3%us, 0.0%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 8185732k total, 7561596k used, 624136k free, 400784k buffers
Swap: 0k total, 0k used, 0k free, 3783972k cached
PID USER PR NI viRT RES SHR S %CPU %MEM TIME+ COMMAND
5859 appuser 22 0 3078m 2.3g 17m S 8.0 29.2 302:14.93 java
23987 appuser 15 0 44712 3088 944 S 1.3 0.0 0:03.85 nginx
4725 appuser 20 0 2805m 611m 15m S 0.7 7.7 7:01.27 java
24132 root 15 0 12748 1120 844 R 0.3 0.0 0:00.42 top
1 root 15 0 10356 632 540 S 0.0 0.0 0:02.14 init
2 root RT -5 0 0 0 S 0.0 0.0 0:02.61 migration/0
3 root 34 19 0 0 0 S 0.0 0.0 0:00.01 ksoftirqd/0
4 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/0
另外还发现一个问题，我用root用户启动nginx服务，但是两个worker进程的属主却一直是www，即使通过chown将属主调整了，呆运行一段时间以后，nginx的很多附属文件夹的权限还会变成www，肯定是在一键安装web环境的时候，nginx被强制更改了配置，这个问题困扰了我很久，今天终于通过一个命令解决：在nginx.conf加上user appuser dba;哈哈，所有的worker进程就都乖乖的归属到appuser名下了，终于摆脱www用户的束缚啦 
开心保网站使用了nginx的反向代理，由于服务器采用的是4核CPU8G内存，如何充分利用这些配置是我一直思考的问题，网站有时候会时不时的卡死，保险产品条款及批量上传有时会特别慢，我一直坚信nginx之所以这么流行，肯定有我不知道的一些隐藏的功能没有被我挖掘出来：
原来nginx设置的work_processes设置的是2，说明4核cpu没有充分使用，于是我把work_processes改成了4，同时为每一个进程分配了一个cpu:worker_cpu_affinity 0001 0100 0010 0001;可以看到加上主进程共有5个进程在运行
root 12318 0.0 0.0 44268 2136 ? Ss Nov22 0:00 nginx: master process /alidata/server/nginx/sbin/nginx
APPuser 23984 0.7 0.0 44712 3092 ? S 15:02 0:05 nginx: worker process
appuser 23985 0.7 0.0 44636 3036 ? S 15:02 0:06 nginx: worker process
appuser 23986 0.7 0.0 44636 3068 ? S 15:02 0:05 nginx: worker process
appuser 23987 0.8 0.0 44944 3324 ? S 15:02 0:06 nginx: worker process
平滑重启nginx服务，测试cpu的使用情况，使用top命令让后按1，看到的生产环境的cpu运行情况如下：可以看到基本每个cup都在工作了，把睡觉的2个都给用了起来，哈哈！
top - 15:11:19 up 19 days, 3:50, 2 users, load average: 0.14, 0.27, 0.30
Tasks: 110 total, 1 running, 108 sleeping, 1 stopped, 0 zombie
Cpu0 : 9.3%us, 0.7%sy, 0.0%ni, 89.0%id, 0.3%wa, 0.0%hi, 0.7%si, 0.0%st
Cpu1 : 0.3%us, 0.0%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu2 : 0.3%us, 0.0%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu3 : 0.3%us, 0.0%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 8185732k total, 7561596k used, 624136k free, 400784k buffers
Swap: 0k total, 0k used, 0k free, 3783972k cached
PID USER PR NI viRT RES SHR S %CPU %MEM TIME+ COMMAND
5859 appuser 22 0 3078m 2.3g 17m S 8.0 29.2 302:14.93 java
23987 appuser 15 0 44712 3088 944 S 1.3 0.0 0:03.85 nginx
4725 appuser 20 0 2805m 611m 15m S 0.7 7.7 7:01.27 java
24132 root 15 0 12748 1120 844 R 0.3 0.0 0:00.42 top
1 root 15 0 10356 632 540 S 0.0 0.0 0:02.14 init
2 root RT -5 0 0 0 S 0.0 0.0 0:02.61 migration/0
3 root 34 19 0 0 0 S 0.0 0.0 0:00.01 ksoftirqd/0
4 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/0
另外还发现一个问题，我用root用户启动nginx服务，但是两个worker进程的属主却一直是www，即使通过chown将属主调整了，呆运行一段时间以后，nginx的很多附属文件夹的权限还会变成www，肯定是在一键安装web环境的时候，nginx被强制更改了配置，这个问题困扰了我很久，今天终于通过一个命令解决：在nginx.conf加上
- 上一篇： 关于不同用户session共享的问题
- 下一篇： 软件开发者的考核应注意的几个问题
评论