linux服务器内网穿透（服务器 内网穿透）〔linuxdeploy 内网穿透〕

　　一、uptime下令 $ uptime 23:51:26 up 21:31, 1 user, load average: 30.02, 26.43, 19.02

　　这个下令 可以快速查察 呆板 的负载环境 。在Linux体系 中，这些数据表现 等待 CPU资源的进程 和壅闭 在不可停止 IO进程 （进程 状态为D）的数量 。这些数据可以让我们对体系 资源利用 有一个宏观的相识 。

　　下令 的输出分别表现 1分钟、5分钟 、15分钟的均匀 负载环境 。通过这三个数据 ，可以相识 服务器负载是在趋于告急 还是 趋于缓解 。假如 1分钟均匀 负载很高，而15分钟均匀 负载很低，阐明 服务器正在下令 高负载环境 ，必要 进一步排查CPU资源都斲丧 在了那边 。反之，假如 15分钟均匀 负载很高，1分钟均匀 负载较低 ，则有大概 是CPU资源告急 时候 已经已往 。

　　上面例子中的输出，可以望见 近来 1分钟的均匀 负载非常高，且远高于近来 15分钟负载 ，因此我们必要 继承 排查当前体系 中有什么进程 斲丧 了大量的资源 。可以通过下文将会先容 的vmstat、mpstat等下令 进一步排查。

　　二、dmesg下令 $ dmesg | tail [1880957.563150] perl invoked oom-killer: gfp_mask=0x280da, order=0, oom_score_adj=0 [...] [1880957.563400] Out of memory: Kill process 18694 (perl) score 246 or sacrifice child [1880957.563408] Killed process 18694 (perl) total-vm:1972392kB, anon-rss:1953348kB, file-rss:0kB [2320864.954447] TCP: Possible SYN flooding on port 7001. Dropping request. Check SNMP counters.

　　该下令 会输出体系 日记 的末了 10行。示例中的输出，可以望见 一次内核的oom kill和一次TCP丢包 。这些日记 可以资助 排查性能题目 。千万 不要忘了这一步。

　　三 、vmstat下令 $ vmstat 1 procs ---------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 34 0 0 200889792 73708 591828 0 0 0 5 6 10 96 1 3 0 0 32 0 0 200889920 73708 591860 0 0 0 592 13284 4282 98 1 1 0 0 32 0 0 200890112 73708 591860 0 0 0 0 9501 2154 99 1 0 0 0 32 0 0 200889568 73712 591856 0 0 0 48 11900 2459 99 0 0 0 0 32 0 0 200890208 73712 591860 0 0 0 0 15898 4840 98 1 1 0 0

　　vmstat(8) 下令 ，每行会输出一些体系 核心 指标 ，这些指标可以让我们更具体 的相识 体系 状态 。背面 跟的参数1，表现 每秒输出一次统计信息，表头提示了每一列的寄义 ，这几先容 一些和性能调优相干 的列：

r：等待 在CPU资源的进程 数。这个数据比均匀 负载更加可以或许 表现 CPU负载环境 ，数据中不包罗 等待 IO的进程 。假如 这个数值大于呆板 CPU核数，那么呆板 的CPU资源已经饱和。

free：体系 可用内存数（以千字节为单位 ），假如 剩余内存不敷 ，也会导致体系 性能题目 。下文先容 到的free下令 ，可以更具体 的相识 体系 内存的利用 环境 。

si，so：互换 区写入和读取的数量 。假如 这个数据不为0 ，阐明 体系 已经在利用 互换 区（swap），呆板 物理内存已经不敷 。

us, sy, id, wa, st：这些都代表了CPU时间的斲丧 ，它们分别表现 用户时间（user）、体系 （内核）时间（sys）、空闲时间（idle） 、IO等待 时间（wait）和被偷走的时间（stolen ，一样平常 被其他假造 机斲丧 ）。

　　上述这些CPU时间，可以让我们很快相识 CPU是否出于繁忙状态。一样平常 环境 下，假如 用户时间和体系 时间相加非常大 ，CPU出于忙于实行 指令 。假如 IO等待 时间很长，那么体系 的瓶颈大概 在磁盘IO。

　　示例下令 的输出可以望见 ，大量CPU时间斲丧 在用户态，也就是用户应用程序斲丧 了CPU时间。这不肯定 是性能题目 ，必要 连合 r队列，一起分析 。

　　四、mpstat下令 $ mpstat -P ALL 1 Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU) 07:38:49 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle 07:38:50 PM all 98.47 0.00 0.75 0.00 0.00 0.00 0.00 0.00 0.00 0.78 07:38:50 PM 0 96.04 0.00 2.97 0.00 0.00 0.00 0.00 0.00 0.00 0.99 07:38:50 PM 1 97.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 2.00 07:38:50 PM 2 98.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 1.00 07:38:50 PM 3 96.97 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 3.03 [...]

　　该下令 可以表现 每个CPU的占用环境 ，假如 有一个CPU占用率特别 高 ，那么有大概 是一个单线程应用程序引起的。

　　五、pidstat下令 $ pidstat 1 Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU) 07:41:02 PM UID PID %usr %system %guest %CPU CPU Command 07:41:03 PM 0 9 0.00 0.94 0.00 0.94 1 rcuos/0 07:41:03 PM 0 4214 5.66 5.66 0.00 11.32 15 mesos-slave 07:41:03 PM 0 4354 0.94 0.94 0.00 1.89 8 java 07:41:03 PM 0 6521 1596.23 1.89 0.00 1598.11 27 java 07:41:03 PM 0 6564 1571.70 7.55 0.00 1579.25 28 java 07:41:03 PM 60004 60154 0.94 4.72 0.00 5.66 9 pidstat 07:41:03 PM UID PID %usr %system %guest %CPU CPU Command 07:41:04 PM 0 4214 6.00 2.00 0.00 8.00 15 mesos-slave 07:41:04 PM 0 6521 1590.00 1.00 0.00 1591.00 27 java07:41:04 PM 0 6564 1573.00 10.00 0.00 1583.00 28 java 07:41:04 PM 108 6718 1.00 0.00 0.00 1.00 0 snmp-pass 07:41:04 PM 60004 60154 1.00 4.00 0.00 5.00 9 pidstat

　　pidstat下令 输出进程 的CPU占用率，该下令 会连续 输出，而且 不会覆盖之前的数据 ，可以方便观察体系 动态。如上的输出，可以望见 两个JAVA进程 占用了将近 1600%的CPU时间，既斲丧 了约莫 16个CPU核心 的运算资源 。

　　六 、iostat下令 $ iostat -xz 1 Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU) avg-cpu: %user %nice %system %iowait %steal %idle 73.96 0.00 3.73 0.03 0.06 22.21 Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util xvda 0.00 0.23 0.21 0.18 4.52 2.08 34.37 0.00 9.98 13.80 5.42 2.44 0.09 xvdb 0.01 0.00 1.02 8.94 127.97 598.53 145.79 0.00 0.43 1.78 0.28 0.25 0.25 xvdc 0.01 0.00 1.02 8.86 127.79 595.94 146.50 0.00 0.45 1.82 0.30 0.27 0.26 dm-0 0.00 0.00 0.69 2.32 10.47 31.69 28.01 0.01 3.23 0.71 3.98 0.13 0.04 dm-1 0.00 0.00 0.00 0.94 0.01 3.78 8.00 0.33 345.84 0.04 346.81 0.01 0.00 dm-2 0.00 0.00 0.09 0.07 1.35 0.36 22.50 0.00 2.55 0.23 5.62 1.78 0.03 [...]

　　iostat下令 重要 用于查察 呆板 磁盘IO环境 。该下令 输出的列 ，重要 寄义 是：

r/s, w/s, rkB/s, wkB/s：分别表现 每秒读写次数和每秒读写数据量（千字节）。读写量过大，大概 会引起性能题目 。

await：IO操纵 的均匀 等待 时间，单位 是毫秒 。这是应用程序在和磁盘交互时 ，必要 斲丧 的时间，包罗 IO等待 和实际 操纵 的耗时。假如 这个数值过大，大概 是硬件装备 碰到 了瓶颈大概 出现故障。

avgqu-sz：向装备 发出的哀求 均匀 数量 。假如 这个数值大于1，大概 是硬件装备 已经饱和（部分 前端硬件装备 支持并行写入）。

%util：装备 利用 率。这个数值表现 装备 的繁忙程度 ，履历 值是假如 高出 60，大概 会影响IO性能（可以参照IO操纵 均匀 等待 时间） 。假如 到达100%，阐明 硬件装备 已经饱和。

　　假如 表现 的是逻辑装备 的数据 ，那么装备 利用 率不代表后端实际 的硬件装备 已经饱和。值得留意 的是，纵然 IO性能不抱负 ，也不肯定 意味这应用程序性能会不好 ，可以利用 诸如预读取、写缓存等战略 提拔 应用性能 。

　　七、free下令 $ free -m total used free shared buffers cached Mem: 245998 24545 221453 83 59 541 -/+ buffers/cache: 23944 222053 Swap: 0 0 0

　　free下令 可以查察 体系 内存的利用 环境 ，-m参数表现 按照兆字节展示。末了 两列分别表现 用于IO缓存的内存数，和用于文件体系 页缓存的内存数。必要 留意 的是 ，第二行-/+ buffers/cache，看上去缓存占用了大量内存空间 。

　　这是Linux体系 的内存利用 战略 ，尽大概 的利用 内存 ，假如 应用程序必要 内存，这部分 内存会立即 被采取 并分配给应用程序。因此，这部分 内存一样平常 也被当成是可用内存。

　　假如 可用内存非常少，体系 大概 会动用互换 区（假如 设置 了的话） ，如许 会增长 IO开销（可以在iostat下令 中提现），低落 体系 性能。

　　八 、sar下令 $ sar -n DEV 1 Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU) 12:16:48 AM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil 12:16:49 AM eth0 18763.00 5032.00 20686.42 478.30 0.00 0.00 0.00 0.00 12:16:49 AM lo 14.00 14.00 1.36 1.36 0.00 0.00 0.00 0.00 12:16:49 AM docker0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 12:16:49 AM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil 12:16:50 AM eth0 19763.00 5101.00 21999.10 482.56 0.00 0.00 0.00 0.00 12:16:50 AM lo 20.00 20.00 3.25 3.25 0.00 0.00 0.00 0.00 12:16:50 AM docker0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

　　sar下令 在这里可以查察 网络装备 的吞吐率 。在排查性能题目 时，可以通过网络装备 的吞吐量 ，判定 网络装备 是否已经饱和。如示例输出中，eth0网卡装备 ，吞吐率大概在22 Mbytes/s ，既176 Mbits/sec，没有到达 1Gbit/sec的硬件上限。

　　sar -n TCP,ETCP 1 $ sar -n TCP,ETCP 1 Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU) 12:17:19 AM active/s passive/s iseg/s oseg/s 12:17:20 AM 1.00 0.00 10233.00 18846.00 12:17:19 AM atmptf/s estres/s retrans/s isegerr/s orsts/s 12:17:20 AM 0.00 0.00 0.00 0.00 0.00 12:17:20 AM active/s passive/s iseg/s oseg/s 12:17:21 AM 1.00 0.00 8359.00 6039.00 12:17:20 AM atmptf/s estres/s retrans/s isegerr/s orsts/s 12:17:21 AM 0.00 0.00 0.00 0.00 0.00

　　sar下令 在这里用于查察 TCP毗连 状态，此中 包罗 ：

active/s：每秒本地 发起的TCP毗连 数 ，既通过connect调用创建的TCP毗连 ；

passive/s：每秒长途 发起的TCP毗连 数，即通过accept调用创建的TCP毗连 ；

retrans/s：每秒TCP重传数量 ；

　　TCP毗连 数可以用来判定 性能题目 是否由于创建 了过多的毗连 ，进一步可以判定 是主动 发起的毗连 ，还是 被动担当 的毗连 。TCP重传大概 是由于 网络环境 恶劣，大概 服务器压

　　九、top下令 $ top top - 00:15:40 up 21:56, 1 user, load average: 31.09, 29.87, 29.92 Tasks: 871 total, 1 running, 868 sleeping, 0 stopped, 2 zombie %Cpu(s): 96.8 us, 0.4 sy, 0.0 ni, 2.7 id, 0.1 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem: 25190241+total, 24921688 used, 22698073+free, 60448 buffers KiB Swap: 0 total, 0 used, 0 free. 554208 cached Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 20248 root 20 0 0.227t 0.012t 18748 S 3090 5.2 29812:58 java 4213 root 20 0 2722544 64640 44232 S 23.5 0.0 233:35.37 mesos-slave 66128 titancl+ 20 0 24344 2332 1172 R 1.0 0.0 0:00.07 top 5235 root 20 0 38.227g 547004 49996 S 0.7 0.2 2:02.74 java 4299 root 20 0 20.015g 2.682g 16836 S 0.3 1.1 33:14.42 java 1 root 20 0 33620 2920 1496 S 0.0 0.0 0:03.82 init 2 root 20 0 0 0 0 S 0.0 0.0 0:00.02 kthreadd 3 root 20 0 0 0 0 S 0.0 0.0 0:05.35 ksoftirqd/0 5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H 6 root 20 0 0 0 0 S 0.0 0.0 0:06.94 kworker/u256:0 8 root 20 0 0 0 0 S 0.0 0.0 2:38.05 rcu_sched

　　top下令 包罗 了前面好几个下令 的查抄 的内容。比如 体系 负载环境 （uptime）、体系 内存利用 环境 （free）、体系 CPU利用 环境 （vmstat）等。因此通过这个下令 ，可以相对全面的查察 体系 负载的泉源 。同时，top下令 支持排序 ，可以按照差别 的列排序，方便查找出诸如内存占用最多的进程 、CPU占用率最高的进程 等。

　　但是，top下令 相对于前面一些下令 ，输出是一个刹时 值，假如 不连续 盯着，大概 会错过一些线索。这时大概 必要 停息 top下令 革新 ，来记录 和比对数据 。

　　号外号外：

　　如今 我们公众号推出参加 奖和互动奖，凡是通过微信与我们参加 讨论互动最多的朋侪 ，将得到 我们送出的秘密 礼品 ，尚有 机遇 得到 Ansible中文官网立刻 将出书 的新书哦！ 我们将不定期的推出嘉奖 筹划 ！ 嘉奖 多多，小搭档 们，一起来吧！

　　以上是本日 为各人 带来的内容 ，假如 有任何题目 ，各人 也可以添加以下QQ群参加 题目 的讨论。

Ansible中文权势巨子 群：372011984(已满）

AWKSED企业实战： 260039357

docker企业架构实践：491533668

Jumpserver交换 群 ：399218702

Ansible中文权势巨子 -2号群：486022616

关于我们：