2019年6月

河边

一个人的河边,经常能看见钓鱼大叔,基本很少见年轻人钓鱼;
美人蕉,菊花,香彩雀,风车草,绿化做的挺好;


---阅读剩余部分---

Linux中FIN_WAIT2链接过多的解决方法

在对erp老的架构进行改造中,对外前端使用了Nginx,部署在CentOS中,通过查看当前系统链接发现有不少FIN_WAIT2链接:

[root@hd_my_n1 /]# netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
SYN_RECV 30
ESTABLISHED 968
FIN_WAIT2 301
TIME_WAIT 145

服务端由于某种原因关闭连接,如KEEPALIVE的超时,这样,作为主动关闭的服务端一方就会进入 FIN_WAIT2状态,但TCP/IP协议栈有个问题,FIN_WAIT2状态是没有超时的(不象TIME_WAIT状态),所以如果CLIENT不关闭,这个FIN_WAIT_2状态将保持到系统重新启动,越来越多的FIN_WAIT_2状态会致使内核crash。
解决方法如下:
修改内核配置vim /etc/sysctl.conf ,加入以下内容:

net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_max_syn_backlog = 8192

然后执行

/sbin/sysctl -p

让参数生效。
参数说明:

net.ipv4.tcp_syncookies = 1 表示开启SYN Cookies。当出现SYN等待队列溢出时,启用cookies来处理,可防范少量SYN攻击,默认为0,表示关闭;
net.ipv4.tcp_tw_reuse = 1 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接,默认为0,表示关闭;
net.ipv4.tcp_tw_recycle = 1  表示开启TCP连接中TIME-WAIT sockets的快速回收,默认为0,表示关闭。
net.ipv4.tcp_fin_timeout  修改系統默认的 TIMEOUT 时间
net.ipv4.tcp_max_syn_backlog = 8192  表示SYN队列的长度,默认为1024,加大队列长度为8192,可以容纳更多等待连接的网络连接数。

参考:CentOS下TIME_WAIT过多-问题处理方法

nginx warn an upstream response is buffered to a temporary file /usr/local/nginx/proxy_temp/3/47/0003311473 while reading upstream报错解决方法

今天发现nginx的log里面有报错,log如下

2019/06/10 19:01:46 [warn] 8294#0: *231715335 an upstream response is buffered to a temporary file /usr/local/nginx/proxy_temp/3/47/0003311473 while reading upstream, client: 144.123.15.66, server: oa.xxx.com.cn, request: "GET /sys/attachment/sys_att_main/sysAttMain.do?method=readDownload&fdId=16b406e3861578ee83d15344deb88105&open=1 HTTP/1.1", upstream: "http://10.254.2.16:80/sys/attachment/sys_att_main/sysAttMain.do?method=readDownload&fdId=16b406e3861578ee83d15344deb88105&open=1", host: "oa.xxx.com.cn", referrer: "http://oa.xxx.com.cn/km/review/km_review_main/kmReviewMain.do?method=view&fdId=16b4063ca15ddfca4ed8e3747d09968f"
2019/06/10 19:01:52 [warn] 8292#0: *231712177 an upstream response is buffered to a temporary file /usr/local/nginx/proxy_temp/4/47/0003311474 while reading upstream, client: 115.173.28.199, server: aqhcrm.xxx.com.cn, request: "GET /weixinfile/bonuspic/ebd192724baf49e782eb89a9f1b78e3f.png HTTP/1.1", upstream: "http://10.254.2.21:80/weixinfile/bonuspic/ebd192724baf49e782eb89a9f1b78e3f.png", host: "aqhcrm.xxx.com.cn", referrer: "http://aqhcrm.xxx.com.cn/modules/weixin/bonusSelf.html"

从error日志来看是nginx某一块的buffer设置的太小,(包含response header和response body)导致response结果不得不临时写到文件中,解决办法:
在nginx的http段,或location段增加如下参数,参数值根据实际应用需求调整,

proxy_buffering on;
client_max_body_size 500M;
client_body_buffer_size 500M;
proxy_buffer_size 5120k;
proxy_buffers 2560 5120k;
proxy_busy_buffers_size 5120k;
proxy_temp_file_write_size 5120k;

最后重启nginx报错日志消失;

炎炎夏日

夏天到了,看天气预报咸阳的温度比上海还热,不过北方的天气是早晚温差大,中午很热,但是早晚还好;

人是一个惰性动物,冬天怕冷,夏天怕热;

行动比想法更难,做比想难,坚持!行动起来。

---阅读剩余部分---

Flask使用pymysql后出现Warning:1366的解决办法

Flask项目中,运行python models.py时报错如下:

C:\Users\ice\.virtualenvs\blog-edDN3LWE\lib\site-packages\pymysql\cursors.py:170: Warning: (1366, "Incorrect string value: '\\xD6\\xD0\\xB9\\xFA\\xB1\\xEA...' for column 'VARIABLE_VALU
E' at row 485")
  result = self._query(query)

原因是MySQL5.7数据库使用的是utf8mb4编码,使用pymysql会报1366警告,但是数据还是能执行操作,解决方法更换为mysql-connector-python

pip install mysql-connector

models.py里面使用:

import mysql.connector
app.config["SQLALCHEMY_DATABASE_URI"] = "mysql+mysqlconnector://账号:密码@localhost/appname"

然后执行就不会报错了^o^

博客更换域名

以前的域名是unixso.com 目前已更换为unixso.com 更短,mhl这个只是名字里面第一个字母,比较好记,这次会一直使用下去;

看山不是山

很多时候,在看一些事情的时候,表面上看起来貌似很简单,实际上很深入的了解后,确实不简单;特别是在技术方面和项目方面;

越深入越发现自己无知,很多东西不了解;

可能你的了解的只是冰山一角;

iceberg.jpg

最新

分类

归档

评论

其它