## 1. 帶寬占用過高，導致服務器奔潰： 解決方案：降低響應的數據大小，采用gzip處理，對游戲用戶配置數據進行了壓縮處理 ## 2. nginx 工作連接數不夠： 解決方案： 1. 設置`worker_processes`工作進程數 ``` 設置規則：設置為 CPU 的總核數（CPU總核數 = 物理CPU個數 \*? 每顆物理CPU的核數 ） ``` ``` # 查看物理 CPU 個數 cat /proc/cpuinfo| grep "physical id"| sort| uniq| wc -l # 查看每個物理 CPU 的核數 cat /proc/cpuinfo| grep "cpu cores"| uniq # 查看邏輯 CPU 的個數 cat /proc/cpuinfo| grep "processor"| wc -l # 查看 CPU 的信息 cat /proc/cpuinfo | grep name | cut -f2 -d: | uniq -c # 查看內存信息 cat /proc/meminfo 設置 worker_connections 工作連接數 ``` 2. 該參數表示每個進程允許的最多連接數，默認值為 10240 。 ``` 理論上每臺 Nginx 服務器的最大連接數為 worker_process * worker_connections 即（CPU總核數 * 10240） ``` 3. 設置 worker_limit_nofile 打開文件最大句柄數 ``` 該參數表示 Nginx 一個進程打開的最多文件數目，理論值為：ulimit -n / worker_processes 但是 Nginx 分配請求并不是那么均勻，所以一般與 ulimit -n 的值保持一致 ``` ## 3. java運行cpu過高：（啟動java配置參數過低） 解決方案： ``` nohup java -jar -Xms4096m -Xmx4096m -Xss4096k xm-client-1.0.0.jar > /dev/null 2>&1 & ``` ## 4. 硬盤空間不足（java保存了運行日志） 解決方案： ``` nohup java -jar -Xms4096m -Xmx4096m -Xss4096k xm-client-1.0.0.jar > /dev/null 2>&1 & ``` ## 5. 請求過多，進行優化 解決方案： ``` 1. 對于預估大量請求，通過ngnix awk命令去分析，進行削峰處理，進行負載均衡 2. 可以把業務服務器數據庫和日志服務器數據庫拆分，進行分流 ```