背景：

kubernetes集羣中部署應用，對應用進行壓力測試。jmeter進行壓力測試大概是每秒300個左右的請求（每分鐘elasticsearch中採集的請求有18000個）。查看日誌有nginx的erro log:
​

但是我的cpu 內存資源也都沒有打滿。通過搜索引擎搜索發現與下面博客的環境基本相似，php-fpm也是走的socket：

​

參見：http://www.bubuko.com/infodetail-3600189.html

解決問題：

修改net.core.somaxconn

進入自己的nginx-php容器查看：

bash-5.0# cat /proc/sys/net/core/somaxconn
128

隨機找了一個work節點查看主機的somaxconn:

root@ap-shanghai-k8s-node-1:~# cat /proc/sys/net/core/somaxconn
32768

注：這是一個tke集羣。參數都是默認的。未進行修改
下面修改一下應用的配置文件：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: paper-miniprogram
spec:
  replicas: 1
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  selector:
    matchLabels:
      app: paper-miniprogram
  template:
    metadata:
      labels:
        app: paper-miniprogram
    spec:
      containers:
        - name: paper-miniprogram
          image: ccr.ccs.tencentyun.com/xxxx/paper-miniprogram:{data}
          ports:
            - containerPort: 80
          resources:
            requests:
              memory: "1024M"
              cpu: "1000m"
            limits:
              memory: "1024M"
              cpu: "1000m" 
      imagePullSecrets:                                              
        - name: tencent
---

apiVersion: v1
kind: Service
metadata:
  name: paper-miniprogram
  labels:
    app: paper-miniprogram
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: paper-miniprogram

修改如下：
增加initContainers配置

apiVersion: apps/v1
kind: Deployment
metadata:
  name: paper-miniprogram
spec:
  replicas: 1
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  selector:
    matchLabels:
      app: paper-miniprogram
  template:
    metadata:
      labels:
        app: paper-miniprogram
    spec:
      containers:
        - name: paper-miniprogram
          image: ccr.ccs.tencentyun.com/xxxx/paper-miniprogram:{data}
          ports:
            - containerPort: 80
          resources:
            requests:
              memory: "1024M"
              cpu: "1000m"
            limits:
              memory: "1024M"
              cpu: "1000m" 
      initContainers:
      - image: busybox
        command:
        - sh
        - -c
        - echo 1000 > /proc/sys/net/core/somaxconn
        imagePullPolicy: Always
        name: setsysctl
        securityContext:
          privileged: true
      imagePullSecrets:                                              
        - name: tencent
---

apiVersion: v1
kind: Service
metadata:
  name: paper-miniprogram
  labels:
    app: paper-miniprogram
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: paper-miniprogram

php-fpm listen.backlog參數修改

先看一下系統變量net.ipv4.tcp_max_syn_backlog的參數值

cat /proc/sys/net/core/netdev_max_backlog
#OR
sysctl -a|grep backlog

然後查看一下php中listen。backlog的配置：

511就先511吧不先修改了 如果修改這個值也要特權模式修改一下啊容器中net.ipv4.tcp_max_syn_backlog的值?
​

官方關於sysctl

kubernetes官方有syscl的用法説明的：https://kubernetes.io/zh/docs/tasks/administer-cluster/sysctl-cluster/

然後這樣做的後遺症：

個人覺得特權模式會帶來的安全等問題,還是不喜歡pod啓用特權模式。

個人覺得比較好的方式：

1. 通過grafana看板發現pod的資源利用率還是沒有那麼高。合理調整資源limits參數。

2. 啓用hpa 水平自動伸縮。
3. 綜上所述我還想想保持默認的net.core.somaxconn=128。而依靠更多的副本數去滿足高負載。這也是符合使用容器的思想的思路。

4. 關鍵是很多人認為擴大資源就可以提高併發負載量的思想是不對的.更應該去調優參數。

   關於php-fpm unix socket and tcp

   

參見知乎：https://zhuanlan.zhihu.com/p/83958307

​

一些配置的可供參考：

https://github.com/gaoxt/blog/issues/9
https://blog.csdn.net/pcyph/article/details/46513521
​