Linux 实例常用内核网络参数介绍与常见问题处理

Linux 实例常用内核网络参数介绍与常见问题处理

KB: 41334

 ·

更新时间:2018-11-16 20:26:51

   

本文总结了常见的 Linux 内核参数及相关问题。修改内核参数前,您需要:

  • 从实际需要出发,最好有相关数据的支撑,不建议随意调整内核参数。
  • 了解参数的具体作用,且注意同类型或版本环境的内核参数可能有所不同。
  • 备份 ECS 实例中的重要数据。参阅文档创建快照

查看和修改 Linux 实例内核参数

方法一、通过 /proc/sys/ 目录

查看内核参数:使用 cat 查看对应文件的内容,例如执行命令 cat /proc/sys/net/ipv4/tcp_tw_recycle 查看 

                

发现大量的mysql TIME_WAIT解决办法

今天早上一上班,有同事就反映公司好几个网站都打不开,登陆数据库
服务器(windows),发现很卡,于是重启了下服务器,进入系统后,没过一会问题依旧,查看了下系统进程,发现mysql占用率达到99%,可以肯定的是mysql连接出现问题:
netstat -an
192.168.12.13:3306      192.168.12.12:30443      TIME_WAIT
192.168.12.13:3306      192.168.12.12:30444      TIME_WAIT
192.168.12.13:3306      192.168.12.12:30445      TIME_WAIT
192.168.12.13:3306      192.168.12.12:30446      TIME_WAIT
192.168.12.13:3306      192.168.12.12:30447      TIME_WAIT
192.168.12.13:3306      192.168.12.12:30448      TIME_WAIT
192.168.12.13:3306      192.168.12.12:30449      TIME_WAIT
192.168.12.13:3306      192.168.12.12:30450      TIME_WAIT
192.168.12.13:3306      192.168.12.12:30451      TIME_WAIT
192.168.12.13:3306      192.168.12.12:30452      TIME_WAIT…
                

MySQL 数据库优化,看这篇就够了

 

前言

 

数据库优化一方面是找出系统的瓶颈,提高MySQL数据库的整体性能,而另一方面需要合理的结构设计和参数调整,以提高用户的相应速度,同时还要尽可能的节约系统资源,以便让系统提供更大的负荷.

 

1、优化一览图

 

MySQL 数据库优化,看这篇就够了

 

2、优化

 

笔者将优化分为了两大类,软优化和硬优化,软优化一般是操作数据库即可,而硬优化则是操作服务器硬件及参数设置.

 

2.1 软优化

 

2.1.1 查询语句优化

 

1、首先我们可以用EXPLAIN或DESCRIBE(简写:DESC)命令分析一条查询语句的执行信息.

 

2.例:

 

DESC SELECT * FROM `user`

 

显示:

 

MySQL 数据库优化,看这篇就够了

 

其中会显示索引和查询数据读取数据条数等信息.

 

2.1.2 优化子查询

 

在MySQL中,尽量使用JOIN来代替子查询.因为子查询需要嵌套查询,嵌套查询时会建立一张临时表,临时表的建立和删除都会有较大的系统开销,而连接查询不会创建临时表,因此效率比嵌套子查询高.

 

2.1.3 使用索引

 

索引是提高数据库查询速度最重要的方法之一,关于索引可以参高笔者<MySQL数据库索引>一文,介绍比较详细,此处记录使用索引的三大注意事项:

 

1、LIKE关键字匹配'%'开头的字符串,不会使用索引.

 

2、OR关键字的两个字段必须都是用了索引,该查询才会使用索引.

 

3、使用多列索引必须满足最左匹配.

 

2.1.4 分解表

 

对于字段较多的表,如果某些字段使用频率较低,此时应当,将其分离出来从而形成新的表,

 

2.1.5 中间表

 

对于将大量连接查询的表可以创建中间表,从而减少在查询时造成的连接耗时.

 

2.1.6 增加冗余字段

 

类似于创建中间表,增加冗余也是为了减少连接查询.

 

2.1.7 分析表,检查表,优化表

 

分析表主要是分析表中关键字的分布,检查表主要是检查表中是否存在错误,优化表主要是消除删除或更新造成的表空间浪费.

 

1、分析表:
    

浏览器缓存看这一篇就够了

浏览器缓存作为性能优化的重要一环,对于前端而言,重要性不言而喻。以前总是一知半解的,所以这次好好整理总结了一下。

1、缓存机制

首先我们来总体感知一下它的匹配流程,如下:

  1. 浏览器发送请求前,根据请求头的expires和cache-control判断是否命中(包括是否过期)强缓存策略,如果命中,直接从缓存获取资源,并不会发送请求。如果没有命中,则进入下一步。
  2. 没有命中强缓存规则,浏览器会发送请求,根据请求头的last-modified和etag判断是否命中协商缓存,如果命中,直接从缓存获取资源。如果没有命中,则进入下一步。
  3. 如果前两步都没有命中,则直接从服务端获取资源。

2、强缓存

强缓存:不会向服务器发送请求,直接从缓存中读取资源。

2.1 强缓存原理

强制缓存就是向浏览器缓存查找该请求结果,并根据该结果的缓存规则来决定是否使用该缓存结果的过程,强制缓存的情况主要有三种(暂不分析协商缓存过程),如下:

  • 第一次请求,不存在缓存结果和缓存标识,直接向服务器发送请求

  • 存在缓存标识和缓存结果,但是已经失效,强制缓存是啊比,则使用协商缓存(暂不分析)

  • 存在该缓存结果和缓存标识,且该结果尚未失效,强制缓存生效,直接返回该结果

那么强制缓存的缓存规则是什么?
当浏览器向服务器发起请求时,服务器会将缓存规则放入HTTP响应报文的HTTP头中和请求结果一起返回给浏览器,控制强制缓存的字段分别是ExpiresCache-Control,其中Cache-Control优先级比Expires高。

2.1.1、 Expires

缓存过期时间,用来指定资源到期的时间,是服务器端的具体的时间点。也就是说,Expires=max-age + 请求时间,需要和Last-modified结合使用。Expires是Web服务器响应消息头字段,在响应http请求时告诉浏览器在过期时间前浏览器可以直接从浏览器缓存取数据,而无需再次请求。

Expires 是 HTTP/1 的产物,受限于本地时间,如果修改了本地时间,可能会造成缓存失效。

2.1.2、

你猜一个 TCP 连接上面能发多少个 HTTP 请求

一道经典的面试题是从 URL 在浏览器被被输入到页面展现的过程中发生了什么,大多数回答都是说请求响应之后 DOM 怎么被构建,被绘制出来。但是你有没有想过,收到的 HTML 如果包含几十个图片标签,这些图片是以什么方式、什么顺序、建立了多少连接、使用什么协议被下载下来的呢?

要搞懂这个问题,我们需要先解决下面五个问题:

  1. 现代浏览器在与服务器建立了一个 TCP 连接后是否会在一个 HTTP 请求完成后断开?什么情况下会断开?
  2. 一个 TCP 连接可以对应几个 HTTP 请求?
  3. 一个 TCP 连接中 HTTP 请求发送可以一起发送么(比如一起发三个请求,再三个响应一起接收)?
  4. 为什么有的时候刷新页面不需要重新建立 SSL 连接?
  5. 浏览器对同一 Host 建立 TCP 连接到数量有没有限制?

先来谈谈第一个问题:现代浏览器在与服务器建立了一个 TCP 连接后是否会在一个 HTTP 请求完成后断开?什么情况下会断开?

在 HTTP/1.0 中,一个服务器在发送完一个 HTTP

            

说说压力测试工具

系统写好了,能不能顺利上线?一般来说我们需要做一些压力测试来判断。比如系统预计每天一百万的接口访问量,并且访问时段主要集中在早八点到晚八点,那么平均下来 RPS 大约是 22 次左右,不过用户的访问量通常不会很平均,假设峰值流量是平均流量的 3 到 5 倍的话,那么我们可以推断出项目要想顺利上线,RPS 至少应该达到 66+ 次,110+ 次更好。由此可见上线前用压力测试工具测试 RPS 是一个很重要的环节。

既然压力测试工具如此重要,那么我们不妨挑几个来说说:

首先说说 ab:

ab 无疑是目前最常见的压力测试工具。其典型用法如下:

shell> ab -k -c 100 -t 10 http://domain/path

其中,参数「c」表示的是并发,参数「t」表示的是整个测试持续的时间。一个很容易被忽视的参数是「k」,它会增加请求头 Connection: Keep-Alive,相当于开启了 HTTP 长连接,这样做一方面可以降低测试服务器动态端口被耗尽的风险,另一方面也有助于给目标服务器更大的压力,测试出更接近极限的结果。

再来说说 wrk:

wrk 相对于 ab 来说最大的优点是它支持多线程,这样更容易发挥多核 CPU

可能是最被误用的 HTTP 响应头之一 Cache-Control: must-revalidate

在 HTTP 客户端(浏览器或者缓存服务器)上,如果某个 URL 对应的缓存过期了,客户端会再次向该 URL 发送一个条件请求(带有If-Modified-Since/If-None-Match请求头),如果服务端(缓存服务器或者源站)返回的状态码是 304(没有响应体),则客户端会根据该304响应所包含的一些响应头(DateLast-ModifiedCache-Control等)重新计算出这条缓存的过期时间,比如:

HTTP/2 304
Cache-Control: max-age=86400

这样的 304响应,就能让这条缓存重新续命一天;如果返回的状态码是 200,则整条缓存会被新返回的响应体替换掉。无论是哪种情况,这条缓存都重新变的有效了,HTTP 规范里把这一“让过期的缓存重新变的有效”过程,叫做 revalidate,英语翻译过来应该是“使重新生效”。…