发表于 |

tc

tc 网络状况

  1. 增加延迟100ms ± 10ms
    tc qdisc change dev eth0 root netem delay 100ms 10ms

  2. 增加延迟100ms ± 10ms, 下一个随机数25%依赖于上一个
    tc qdisc change dev eth0 root netem delay 100ms 10ms 25%

  3. 随机丢包0.1%
    tc qdisc change dev eth0 root netem loss 0.1%

发表于 |

netstat

netstat 用于列出所有tcp，udp连接

  1. 显示当前所有活动的网络连接
    ~ » netstat -an | head -n 10 wazi@eli
    Active Internet connections (including servers)
    Proto Recv-Q Send-Q Local Address Foreign Address (state)
    tcp4 0 0 172.16.13.172.54304 180.149.131.55.8843 SYN_SENT
    tcp4 0 0 172.16.13.172.54303 45.32.41.155.44005 ESTABLISHED
    tcp4 0 0 127.0.0.1.60409 127.0.0.1.54302 ESTABLISHED
    tcp4 0 0 127.0.0.1.54302 127.0.0.1.60409 ESTABLISHED
    tcp4 0 0 172.16.13.172.54300 45.32.41.155.44005 ESTABLISHED
    tcp4 0 0 127.0.0.1.60409 127.0.0.1.54299 ESTABLISHED
    tcp4 0 0 127.0.0.1.54299 127.0.0.1.60409 ESTABLISHED
    tcp4 0 0 172.16.13.172.54296 111.203.187.167.3306 ESTABLISHED

    连接状态：
    LISTEN：侦听来自远方的TCP端口的连接请求
    SYN-SENT：再发送连接请求后等待匹配的连接请求
    SYN-RECEIVED：再收到和发送一个连接请求后等待对方对连接请求的确认
    ESTABLISHED：代表一个打开的连接
    FIN-WAIT-1：等待远程TCP连接中断请求，或先前的连接中断请求的确认
    FIN-WAIT-2：从远程TCP等待连接中断请求
    CLOSE-WAIT：等待从本地用户发来的连接中断请求
    CLOSING：等待远程TCP对连接中断的确认
    LAST-ACK：等待原来的发向远程TCP的连接中断请求的确认
    TIME-WAIT：等待足够的时间以确保远程TCP接收到连接中断请求的确认
    CLOSED：没有任何连接状态

  2. 显示所有连接ip
    netstat -n -p | grep ES | awk ‘{print $5}’ | awk -F: ‘{print $1}’

  3. 显示数量
    netstat -anp |grep ‘tcp|udp’ | awk ‘{print $5}’ | cut -d: -f1 | sort | uniq -d

发表于 | 分类于 |

CPU

iostat
avg-cpu: %user %nice %system %iowait %steal %idle
1.95 0.06 0.41 0.03 0.00 97.56
cpu属性值说明：
%user：CPU处在用户模式下的时间百分比。
%nice：CPU处在带NICE值的用户模式下的时间百分比。
%system：CPU处在系统模式下的时间百分比。
%iowait：CPU等待输入输出完成时间的百分比。
%steal：管理程序维护另一个虚拟处理器时，虚拟CPU的无意识等待时间百分比。
%idle：CPU空闲时间百分比。

注：

  1. 如果%iowait的值过高，表示硬盘存在 I/O瓶颈，
  2. %idle值高，表示CPU较空闲，如果%idle值高但系统响应慢时，有可能是CPU等待分配内存，
    此时应加大内存容量。
  3. %idle值如果持续低于10，那么系统的CPU处理能力相对较低，表明系统中最需要解决的资源是CPU。

Disk

iostat -d -x -k 1 1

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
vda 0.00 7.38 0.04 4.60 0.73 63.26 27.59 0.06 12.58 19.94 12.53 6.63 3.07
vdb 0.00 6.97 0.21 6.14 6.30 180.95 58.99 0.07 11.59 4.15 11.85 0.61 0.39
rrqm/s: 每秒进行 merge 的读操作数目。即 rmerge/s
wrqm/s: 每秒进行 merge 的写操作数目。即 wmerge/s
r/s: 每秒完成的读 I/O 设备次数。即 rio/s
w/s: 每秒完成的写 I/O 设备次数。即 wio/s
rsec/s: 每秒读扇区数。即 rsect/s
wsec/s: 每秒写扇区数。即 wsect/s
rkB/s: 每秒读K字节数。是 rsect/s 的一半，因为每扇区大小为512字节。
wkB/s: 每秒写K字节数。是 wsect/s 的一半。
avgrq-sz: 平均每次设备I/O操作的数据大小 (扇区)。
avgqu-sz: 平均I/O队列长度。
await: 平均每次设备I/O操作的等待时间 (毫秒)。
svctm: 平均每次设备I/O操作的服务时间 (毫秒)。
%util: 一秒中有百分之多少的时间用于 I/O 操作，即被io消耗的cpu百分比

备注：如果 %util 接近 100%，说明产生的I/O请求太多，I/O系统已经满负荷，该磁盘可能存在瓶颈。
如果 svctm 比较接近 await，说明 I/O 几乎没有等待时间；如果 await 远大于 svctm，说明I/O 队列太长，
io响应太慢，则需要进行必要优化。如果avgqu-sz比较大，也表示有当量io在等待。
如果 %util 接近 100%，说明产生的I/O请求太多，I/O系统已经满负荷，该磁盘可能存在瓶颈。 idle小于70% IO压力就较大了，一般读取速度有较多的wait。 同时可以结合vmstat 查看查看b参数(等待资源的进程数)和wa参数(IO等待所占用的CPU时间的百分比，高过30%时IO压力高)。

另外 await 的参数也要多和 svctm 来参考。差的过高就一定有 IO 的问题。

avgqu-sz 也是个做 IO 调优时需要注意的地方，这个就是直接每次操作的数据的大小，如果次数多，但数据拿的小的话，其实 IO 也会很小。如果数据拿的大，才IO 的数据会高。也可以通过 avgqu-sz × ( r/s or w/s ) = rsec/s or wsec/s。也就是讲，读定速度是这个来决定的。

svctm 一般要小于 await (因为同时等待的请求的等待时间被重复计算了)，svctm 的大小一般和磁盘性能有关，CPU/内存的负荷也会对其有影响，请求过多也会间接导致 svctm 的增加。await 的大小一般取决于服务时间(svctm) 以及 I/O 队列的长度和 I/O 请求的发出模式。如果 svctm 比较接近 await，说明 I/O 几乎没有等待时间；如果 await 远大于 svctm，说明 I/O 队列太长，应用得到的响应时间变慢，如果响应时间超过了用户可以容许的范围，这时可以考虑更换更快的磁盘，调整内核 elevator 算法，优化应用，或者升级 CPU。

队列长度(avgqu-sz)也可作为衡量系统 I/O 负荷的指标，但由于 avgqu-sz 是按照单位时间的平均值，所以不能反映瞬间的 I/O 洪水。

形象的比喻：
r/s+w/s 类似于交款人的总数
平均队列长度(avgqu-sz)类似于单位时间里平均排队人的个数
平均服务时间(svctm)类似于收银员的收款速度
平均等待时间(await)类似于平均每人的等待时间
平均I/O数据(avgrq-sz)类似于平均每人所买的东西多少
I/O 操作率 (%util)类似于收款台前有人排队的时间比例
设备IO操作:总IO(io)/s = r/s(读) +w/s(写)

平均等待时间=单个I/O服务器时间*(1+2+…+请求总数-1)/请求总数

每秒发出的I/0请求很多,但是平均队列就4,表示这些请求比较均匀,大部分处理还是比较及时。

发表于 |
top 命令
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
top -c
top - 17:48:50 up 151 days,  3:31,  1 user,  load average: 0.07, 0.12, 0.09
Tasks: 132 total,   1 running, 131 sleeping,   0 stopped,   0 zombie
Cpu(s):  1.0%us,  0.5%sy,  0.2%ni, 98.3%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   4194304k total,  4179548k used,    14756k free,        0k buffers
Swap:  2097152k total,   782360k used,  1314792k free,  1977088k cached
PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
1033 mysql     20   0 1158m 7988 1620 S  0.3  0.2  30:16.67 /usr/libexec/mysqld --basedi
7134 tyhall    20   0 1605m 167m  15m S  0.3  4.1   0:29.42 pypy run.py UT001 192.168.10
7136 tyhall    20   0  347m 166m  17m S  0.3  4.1   0:24.37 pypy run.py GT21-001-998-1 1
17:48:50 ： 系统当前时间
151 days, 3:31 ： 系统开机到现在经过了多少时间
1 users ： 当前2用户在线
load average: 0.07, 0.12, 0.09： 系统1分钟、5分钟、15分钟的CPU负载信息
Tasks：任务;
132 total：当前有132个进程。
1 running：1个进程正在运行
131 sleeping：131个进程睡眠
0 stopped：停止的进程数
0 zombie：僵死的进程数
Cpu(s)：表示这一行显示CPU总体信息
1.0%us：用户态进程占用CPU时间百分比，不包含renice值为负的任务占用的CPU的时间。
0.5%sy：内核占用CPU时间百分比
0.2%ni：改变过优先级的进程占用CPU的百分比
98.3%id：空闲CPU时间百分比
0.0%wa：等待I/O的CPU时间百分比
0.0%hi：CPU硬中断时间百分比
0.0%si：CPU软中断时间百分比
注：这里显示数据是所有cpu的平均值，如果想看每一个cpu的处理情况，按1即可；折叠，再次按1；(centos)
Mem：内存
4194304k total：物理内存总量
4179548k used：使用的物理内存量
14756k free：空闲的物理内存量
0k buffers：用作内核缓存的物理内存量
Swap：交换空间
2097152k total：交换区总量
782360k used：使用的交换区量
1314792k free：空闲的交换区量
1977088k cached：缓冲交换区总量
PID：进程的ID
USER：进程所有者
PR：进程的优先级别，越小越优先被执行
NI：值Nice Value 如果为负值，则有较高优先级；如果为正值则为较低优先级；如果为0，则无优先级调整
VIRT：进程占用的虚拟内存
RES：进程占用的物理内存
SHR：进程使用的共享内存
S：进程的状态。S表示休眠，R表示正在运行，Z表示僵死状态，N表示该进程优先值为负数
%CPU：进程占用CPU的使用率
%MEM：进程使用的物理内存和总内存的百分比
TIME+：该进程启动后占用的总的CPU时间，即占用CPU使用时间的累加值。
COMMAND：进程启动命令名称
q：退出top命令
<Space>：立即刷新
s：设置刷新时间间隔
c：显示命令完全模式
t: 显示或隐藏进程和CPU状态信息
m：显示或隐藏内存状态信息
l：显示或隐藏uptime信息
f：增加或减少进程显示标志
S：累计模式，会把已完成或退出的子进程占用的CPU时间累计到父进程的MITE+
P：按%CPU使用率排行
T：按MITE+排行
M：按%MEM排行
u：指定显示用户进程
r：修改进程renice值
k: kill进程
i：只显示正在运行的进程
W：保存对top的设置到文件^/.toprc，下次启动将自动调用toprc文件的设置。
h：帮助命令。
q：退出
如果只需要查看内存：可用free命令。只查看uptime信息（第一行），可用uptime命令；

发表于 |
free 命令
1
2
3
4
5
6
7
8
9
10
11
free -h 
             total       used       free     shared    buffers     cached
Mem:          4.0G       2.6G       1.4G       5.0M         0B       426M
-/+ buffers/cache:       2.2G       1.8G
Swap:         2.0G       766M       1.3G
buffer：将要写到磁盘上的内容
cached: 缓存到内存，供以后使用的数据
2.2G: used(2.6G) - buffer(0B) - cached(426M) 
1.8G: used(1.4G) + buffer(0B) + cached(426M)

vmstat 命令

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
shell: vmstat -S m  1 3
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  0      0    314    323  14996    0    0     1    25    1    5  1  1 98  0  0
 0  0      0    314    323  14996    0    0     0   164 1236 2243  3  1 95  1  0
 0  0      0    312    323  14996    0    0     0    72 1233 2324  3  1 95  0  0
Procs（进程）:
r: 运行队列中进程数量
b: 等待IO的进程数量
Memory（内存）:
swpd: 使用虚拟内存大小
free: 可用内存大小
buff: 用作缓冲的内存大小
cache: 用作缓存的内存大小
Swap:
si: 每秒从交换区写到内存的大小
so: 每秒写入交换区的内存大小
IO：（现在的Linux版本块的大小为1024bytes）
bi: 每秒读取的块数
bo: 每秒写入的块数
system：
in: 每秒中断数，包括时钟中断
cs: 每秒上下文切换数
CPU（以百分比表示）
us: 用户进程执行时间(user time)
sy: 系统进程执行时间(system time)
id: 空闲时间(包括IO等待时间)
wa: 等待IO时间

发表于 |
ps 命令
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
# 显示所有进程
ps -ef
ps aux
#u,f 表示显示详细信息
#显示某用户进程 -u
ps -f -u username
#根据进程id显示进程信息
ps -f  -p 3150,7298,6544
# 显示树型进程, --forest
ps -f --forest -C pypy
# -C 进程名称
# 显示子进程
ps -o pid,uname,comm -C apache2
#选择显示列 -o

发表于 |
文件操作
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
# 查看当前目录下文件个数
find ./ | wc -l
# 查找目标文件夹中是否有obj文件:
$find ./ -name '*.o'
# 查找并删除.svn
find . -name ".svn" | xargs rm -Rf
# ls按照时间排序
ls -lrt
# 拆分文件 split
split -l 100 myfile prefix #按行拆分
split -b 100k myfile prefix #按大小拆分
##### 文件浏览
# 倒序输出 tac
tac myfile
# 显示文件前几行
head -10 filename
# 显示文件后几行
tail -10 filename
#### 文件与目录权限
# 改变文件的拥有者
chown user:user file
# 递归子目录修改 
chown -R user source/
# 改变文件读，写，执行等属性
chmod 600 id_rsa
# 增加脚本可执行权限
chmod a+x myscript
##### tar压缩与解压缩
#  .tar
tar -cvf tecmint-14-09-12.tar /home/tecmint/
tar -xvf tecmint-14-09-12.tar /home/tecmint/
# .tar.gz
tar cvzf MyImages-14-09-12.tar.gz /home/MyImages
tar xvzf MyImages-14-09-12.tar.gz /home/MyImages
# .tar.bz2
tar cvjf MyImages-14-09-12.tar.gz /home/MyImages
tar xvjf MyImages-14-09-12.tar.gz /home/MyImages

发表于 |

原文链接：http://www.yusufaytas.com/who-needs-architect/

架构师？根据维基百科，架构师指的是计划，设计和监督建筑的构造。因此，很明显我们可以看出架构师这个角色取自土木工程。对应的，我们得到了软件架构。软件架构指的是软件系统的高层结构。正如你可能猜到的，我不认为我们需要一个正式的架构师角色，而是需要软件架构。在开始另一次争吵之前，让我们先看一下矩阵架构场景。

很酷吧？这对于每一个构建软件的人来说都是应得的。就是这样。我认为任何工作的软件都有一种架构。哇，那每个人都是架构师了？其实，也对也不对。对的方面是，一个架构需要架构师（们）。不对的地方是，我不认为没有必要定义一个正式的角色，把每个人都叫做架构师。

回到土木工程。一个架构师设计一个建筑，考虑的是美观，艺术性和构造的外形。一个土木工程师则专注于设计的每个元素，是架构的实践者。就这样，没有更多的定义。正如你所看到的，这些是定义明确的角色，它们有一种分层的感觉。当开发软件时，你认为我们有或应该有这种分层吗？不。当然一个有经验的工程师与一个刚毕业的有不同的观点。然而这两种工程师同样地影响着软件系统和架构。如果把一个叫做架构师而另外一个不是，你认为这样公平吗？不！因此，一个正式的架构师职位并不适合软件开发领域。

如果你认为我们只需要软件“软件架构”这个职称来强调其资历水平，我不同意。大多数大公司有着很好的开发路径。差不多是软件工程师1->软件工程师2->资深软件工程师->核心工程师。让我强调一下，他们不需要一个架构师。

一些问题和解答：

如果把核心工程师当作架构师。我们需要总工程师来评价我们构建的每个软件吗？简单的讲不。因为他们在构建自己的项目。

在客户和团队之间，我们真的需要一个代理吗？为什么我们不能都与客户坐在一起，来共同做决定？我认为应该整个团队一起来理解繁乱的需求并从中提出具体任务。当然，有时需要一些有经验的人，领导其他成员。但是我们不必叫他们架构师。他们只是经验丰富的开发人员。

在一个没有架构师的团队里，人们就不能写整洁，高质量的代码了吗？系统设计的阶段就可以去掉？我认为一个好的团队应该先做设计审查，然后代码审查，来分享知识，提高代码质量，倾听不同的意见。如果能很好的沟通交流，开发人员根据能力水平分配任务，那么就可以交付高质量的软件，即使没有一个正式的架构师角色。

我们真的需要一个架构师来领导和制定策略吗？难道不是项目经理来领导团队并决定策略？我认为由于这两个方面的原因，才有了项目经理这个职位。那么技术领导呢？由于软件开发像手工艺，工匠（高级工程师）应该分享如何开发高水平的软件。因此，我们不需要一个正式的架构师角色。

总的来说，我不认为我们需要为设计架构分离出一个专门的角色。我认为团队中的每个成员都应该参与架构讨论，由团队共同完成整个设计。而且，架构师并不需要对应于开发经验水平。最后，再见架构师，让我们专心于架构本身。

发表于 |
文件操作
1
2
3
# 拆分文件 split
split -l 100 myfile prefix #按行拆分
split -b 100k myfile prefix #按大小拆分
文件浏览
1
2
# 倒序输出 tac
tac myfile
tar压缩与解压缩
1
2
3
4
5
6
7
8
9
#  .tar
tar -cvf tecmint-14-09-12.tar /home/tecmint/
tar -xvf tecmint-14-09-12.tar /home/tecmint/
# .tar.gz
tar cvzf MyImages-14-09-12.tar.gz /home/MyImages
tar xvzf MyImages-14-09-12.tar.gz /home/MyImages
# .tar.bz2
tar cvjf MyImages-14-09-12.tar.gz /home/MyImages
tar xvjf MyImages-14-09-12.tar.gz /home/MyImages

查找不包含的文件

1
find . ! -name "*.2017_04_24" -type f

docker attach第一个container

1
sudo docker attach `sudo docker ps |grep "day" | cut -d" " -f1`

去重复uniq

1
2
3
4
5
# uniq
# 121.43.187.116:8000
# 121.43.187.116:8000
# 121.43.187.116:8000
cut -d : -f 1 | uniq

cut

1
2
3
4
5
6
主要参数
-b ：以字节为单位进行分割。这些字节位置将忽略多字节字符边界，除非也指定了 -n 标志。
-c ：以字符为单位进行分割。
-d ：自定义分隔符，默认为制表符。
-f  ：与-d一起使用，指定显示哪个区域。
-n ：取消分割多字节字符。仅和 -b 标志一起使用。如果字符的最后一个字节落在由 -b 标志的 List 参数指示的<br />范围之内，该字符将被写出；否则，该字符将被排除。

发表于 | 分类于 |

简介

SSH全称secure shell，是管理远程服务器最常用的方法。通过使用一系列的
加密技术，SSH 提供了这样一个机制：建立安全加密连接，互相授权，发送命令和返回输出结果。
在其他文章中，我们讨论过了如何配置ssh访问，如何使用ssh连接，和一些ssh建议和技巧。
在本文，我们将介绍SSH的底层加密技术和建立加密连接的方法。这对于理解多个加密层以及建立连接，相互授权的步骤是非常有用的。

对称加密，非对称加密和哈希

为了安全的传输信息，SSH在传输过程中的不同阶段，采用不同类型的控制技术。这些技术包括对称加密，非对称加密和哈希。

  1. 对称加密

加密和解密组件的关系决定了一个加密技术是对称的还是非对称的。

对称加密指的是一个密钥既可以用来加密消息，也可以用来解密消息。这意味着通信双方都持有相同的密钥，既可以加密又可以解密。这种加密方式又叫做“共享加密”或“密钥加密”。典型的是只有一个密钥或者一对关系紧密的密钥（获得另一个密钥并不重要）。

在SSH中，对称加密用于加密整个连接。与一些用户猜想的不同，公／私非对称密钥只用来授权。对称加密也用于密码授权。

客户端和服务器一起生成密钥，生成的密钥不会被第三方知道。密钥是通过一个叫做密钥交换算法生成的。交换的结果是服务器和客户端双方获得相同的密钥。这个流程将在后面详细介绍。

对称加密密钥的生成是基于session的，并建立了实际传输数据的加密。一旦密钥建立所有数据必须通过共享密钥加密。这是在授权客户端之前完成的。

SSH可配置使用多种不同的对称加密系统，包括AES，Blowfish，3DES，CAST128，和Arcfour。客户端和服务器都有一个算法列表，根据优先级来决定使用哪种加密算法。客户端列表中的第一选择，如果服务器也支持，这个算法将被采用。

在Ubuntu 14.04，客户端和服务器的默认算法列表均为:aes128-ctr, aes192-ctr, aes256-ctr, arcfour256, arcfour128, aes128-gcm@openssh.com, aes256-gcm@openssh.com, chacha20-poly1305@openssh.com, aes128-cbc, blowfish-cbc, cast128-cbc, aes192-cbc, aes256-cbc, arcfour。 这就是说，如果两个Ubuntu14.04机器建立连接，（如果没有通过修改配置文件，修改默认算法列表），它们将采用aes128-ctr算法来加密连接。

  1. 非对称加密

非对称加密中，需要两个密钥：一个叫公钥，另一个叫私钥。公钥可以被放到任何地方。私钥应该保密，不能与其他方共享。私钥不能靠公钥计算获得。公钥和私钥的关系是：公钥加密的数据只能靠私钥解密。这个操作是单向的，也就是说，公钥没有办法解密自己加密的数据。

SSH在很多地方使用了非对称加密。比如，在建立对称加密时,交换密钥的过程中，双方产生临时密钥对，用来交换共享密钥（对称加密，用于加密整个session）。

非对称加密在SSH中最被人熟知的用途是基于密钥的授权。客户端生成密钥对，然后将公钥上传到访问服务器，放到~/.ssh/authorized_keys 文件中。

在服务器与客户端的对称加密建立以后，客户端需要被授权访问。服务器使用公钥加密一条消息并发送给客户端。如果客户端能解密这条消息，说明拥有私钥，于是授权成功。

  1. 哈希

SSH还用了一种数据处理叫做哈希加密。哈希加密用来生成数字签名。哈希加密的主要特点是不能反向解密。生成的数字签名不可预测，而且是唯一的。

使用相同的哈希算法加密消息产生的hash值是不变的。修改消息的任何部分将产生完全不同的哈希值。用户不能通过hash值获得原始的消息，但是可以根据能判断一个消息是否对应给定的hash值。

基于以上特性，哈希值一般用于数据完整性验证和消息可靠性检查。
SSH中哈希主要用于HMAC（hash-based message authentication code基于hash的消息授权检查）,用来保证收到的消息是完整的，未修改的。

SSH是如何工作的

<未完待续…>