A. 如何查看linux下进程的IO活动状况 00 Hey，Linux
前段时间，几台测试服务器的Web应用响应速度非常慢，系统负载也比较高，> 10， 但CPU和内存却很闲，于是怀疑是磁盘的性能瓶颈,通过vmstat和iostat看到IO的读写量非常大，尤其是用iostat -x 1命令可以很直观的看到IO的使用率一直在100%。
但究竟是什么进程导致的高IO呢，由于每台服务器上都有JBoss和MySQL的存在，JBoss会不停的产生很多小的数据文件和生成文本数据库的数据，而MySQL则会不停的从Master同步新的数据。因此我们怀疑是这两个进程导致的高IO，通过停止了JBoss和MySQL之后，IO立刻降为0%. 但我们还是不能确定谁是主因，于是寻找可以查看特定进程IO的方法。
最后，找到了两个方法可以查看进程IO的活动状况。
1. 第一个方法是通过一个python脚本来实现。
方法是将以下内容另存为一个叫io.py的脚本中，然后直接以root身份执行脚本，就可以看到如下图所示的信息（由于我们已经通过升级到SSD硬盘解决了MySQL的IO问题，所以不能提供关于MySQL的截图了），其中出现次数最多，数据最大的进程，就是导致高IO的主因。不过比较遗憾的是这个脚本并不能显示进程在每一秒的准确的IO读写。
# vim io.py
# chmod +x io.py
# ./io.py
#!/usr/bin/python
# Monitoring per-process disk I/O activity
# written by http://www.vpsee.com
import sys, os, time, signal, re
class DiskIO:
def __init__(self, pname=None, pid=None, reads=0, writes=0):
self.pname = pname
self.pid = pid
self.reads = 0
self.writes = 0
def main():
argc = len(sys.argv)
if argc != 1:
print "usage: ./iotop"
sys.exit(0)
if os.getuid() != 0:
print "must be run as root"
sys.exit(0)
signal.signal(signal.SIGINT, signal_handler)
os.system('echo 1 > /proc/sys/vm/block_mp')
print "TASK PID READ WRITE"
while True:
os.system('dmesg -c > /tmp/diskio.log')
l = []
f = open('/tmp/diskio.log', 'r')
line = f.readline()
while line:
m = re.match(\
'^(\S+)\((\d+)\): (READ|WRITE) block (\d+) on (\S+)', line)
if m != None:
if not l:
l.append(DiskIO(m.group(1), m.group(2)))
line = f.readline()
continue
found = False
for item in l:
if item.pid == m.group(2):
found = True
if m.group(3) == "READ":
item.reads = item.reads + 1
elif m.group(3) == "WRITE":
item.writes = item.writes + 1
if not found:
l.append(DiskIO(m.group(1), m.group(2)))
line = f.readline()
time.sleep(1)
for item in l:
print "%-10s %10s %10d %10d" % \
(item.pname, item.pid, item.reads, item.writes)
def signal_handler(signal, frame):
os.system('echo 0 > /proc/sys/vm/block_mp')
sys.exit(0)
if __name__=="__main__":
main()
2. 另一个方法是将Linux的内核升级到 >=2.6.20，然后安装一个iotop软件来实现。
不过这种改动并不适用于生产环境，因为在RHEL5.6和5.7上，内核都在 2.6.20以下。但是它所显示的结果是非常准确的，所以对于新上线的机器以及测试环境，非常值得一试，具体方法如下：
下载和升级新内核（>=2.6.20），编译时打开 TASK_DELAY_ACCT 和 TASK_IO_ACCOUNTING 选项。
解压内核后进入配置界面：
# wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.39.tar.gz
# tar jxvf linux-2.6.39.tar.gz
# mv linux-2.6.39 /usr/src/
# cd /usr/src/linux-2.6.39
# make oldconfig //使用make oldconfig可以继承老的kernel的配置，为自己的配置省去很多麻烦。
# make menuconfig
把General setup - Enable per-task storage I/O accounting这个选项选上。
# vim .config
将#CONFIG_SYSFS_DEPRECATED_V2 is not set的注释去掉的，将其改为y，即修改为CONFIG_SYSFS_DEPRECATED_V2=y。
保存内核后编译内核：
# make
# make moles
# make moles_install
# make install
修改默认以新的内核启动：
# vi /boot/grub/grub.conf
default=0
将新的内核配置文件复制到/boot目录：
# cp /usr/src/linux-2.6.39/.config /boot/config-2.6.39
重启服务器：
# reboot
# uname –r
2.6.39
重启完成后确认内核版本是否正确。
源码安装iotop所需的Python 2.7.2（>= 2.5）：
# wget http://www.python.org/ftp/python/2.7.2/Python-2.7.2.tgz
# tar xzvf Python-2.7.2.tgz
# cd Python-2.7.2
# ./configure
# make; make install
下载并安装iotop：
# wget http://guichaz.free.fr/iotop/files/iotop-0.4.4.tar.bz2
# tar -xjvf iotop-0.4.4.tar.bz2
# cd iotop-0.4.4
# python setup.py build
# python setup.py install
然后就可以使用iotop看到如下图所示的信息：
B. linux和k8s和数据库笔记
有关linux：
1、卸载某一个特定的挂在点。
umount /dev/datavg01 /data01
2、移掉lvm。
vgremove /dev/datavg01
3、拷贝数据。
scp -r /home/gaoge.txt [email protected]:/opt 或rsync -av /root/rpmpkgs /tmp/backups/
4、显示系统盘符并以树状格式展开。
lsblk。
5、扫描新增设备。
echo "---" >/sys/class/scsi-host/hosto/scan
6、强行杀死mysql
kill -9 $(ps -ef | grep mysql)
7、将文件内容以每一行5个的形式展示出来。
cat test2.txt | xargs -n 5
8、用cut去实现awk切割列的效果
cat/etc/passwd | cut -d : -f 2
9、sed、grsp、awk。之前已经说过了、具体看 从linux三剑客说起 这篇。
10、增加一个oracle用户让其属于oinstall组同时也隶属于dba组。useradd oracle -g oinstall -G dba
11、新建立一个组groupnew并将组id修改为255。
groupadd -g 255 groupnew
12、将本地/dev/hdb整盘中的数据备份到/dev/hdd上。
dd if=/dev/hdb of=/dev/hdd
13、查看服务器cpu个数。
cat /proc/cpuinfo | grep "physical id" | wc -l
14、查看服务器io状况并以每间隔1秒的速度输出5次。
iostat 1 5
15、查看服务器内存使用情况并以每间隔2秒的速度输出10次。
vmstat 2 10
16、将gaoge.txt中的第一列db2找到并将db两个字符用ab替换。
cat gaoge.txt |grep db2 | awk -F 2 '{print $1}' | tr db ab
17、将包名解压到指定目录。
tar -cxvf 包名 -C 指定的目录
18、linux中前后台任务切换。
ctrl+z 切换到后台、jobs显示id、fg + id 切换至前台。
19、杀掉top下stopped的进程。
ps -A -ostat,ppid,pid,cmd |grep -e '^[T]'
然后在进行kill
20、监控cpu状态。
mpstat
21、查看虚拟内存使用了多少。
swapon
22、每月1到10号4:45重启nginx。
crontab -u root -l 显示root当前的计划任务。
crontab -u root -e 后输入以下内容并保存退出。
45 4 1,10 ** systemctl start nginx
23、awk打印df -h 的第一列、第三列、最后一列。
df -h | awk '{print $1 " " $3 " " $NF}'
24、批量拉、打标签、推docker镜像的shell脚本。
#！/bin/bash
for image in 'docker images | grep 10.171.10.1：10000 | awk ' { print $1 ":" $2 }
do
version = 'echo $image | awk -F / ' { print $2 } '
docker tag $image 192.168.10.1/$version
docker push 192.168.10.1/$version
done
25、正则表达式匹配电话号码。
(?0d{2}[) -]?d{8}
26、编译安装三步骤。
./configure --prefix=安装目录
make
make install
有关kubernetes：
将kubernetes中pod的数据拷贝到物理宿主机上。
kubectl cp gyl-run/gyl-mysql-01020304: /opt/docker.sh /opt
将kubernetes中物理宿主机上的数据拷贝到pod中。
kubectl cp /opt/docker.sh gyl-run/gyl-mysql-01020304: /opt
检查当前用户有没有权限在k8s中创建资源权限。
kubectl auth can-i '*' '*'
检查当前用户有没有权限在k8s集群中创建namespace权限。
kubectl auth can-i create pods --all-namespaces
查看集群是否 健康 。
kubectl get cs
有关数据库：
查看 mysql 二进制日志格式。
show variables like ‘%binlog_format%’
查看所有二进制日志文件
show master logs
查看正在写入的二进制日志
show master status
格式化二进制显示为sql格式
mysqlbinlog --base64 --output=decode-rows -v --start-date="2019-01-25 00:00:00" --stop-date=“2019-01-26 17:30” master-bin.000006
利用bin-log去还原数据
/usr/bin/mysqlbinlog --no-default /var/lib/mysql/mysql-bin.00001 | usr/bin/mysql -u root -p pwd test
连接 postgresql
psql -U 用户名 -d 数据
数据库名 -h 主机地址 -p端口（默认端口为5432）
l 显示数据库列表
d 显示所有表
d 表名称 显示表结构
显示所有数据库用户
c 数据库名 连接数据库
q 退出pg窗口
pg备份：
pg_mp -U kong -d kong -f /opt/2019-01-26-pg.sql
pg还原：
psql -d kong -U kong -f /opt/2019-01-26-pg.sql
mongo 批量更新数据：把age大于20的class name修改为，设置multi为true
C. Linux里面uptime命令作用是什么
[root@oldboy ~]# uptime
11:45:25 up 5 days, 13:20, 3 users, load average: 0.00, 0.01, 0.05
uptime内容显示的内容一次是系统时间，开机到现在的天数，用户登录数，以及平均负载。
核心是平均负载，其实就是【单位时间内的活跃进程数】。
2颗，单颗4核CPU为例：
1分钟：10.00 #CPU处理进程1分钟的繁忙程度，忙碌1分钟。
5分钟：8.01 #CPU处理进程5分钟的繁忙程度，忙碌了5分钟
15分钟：5.05 #CPU处理进程15分钟的繁忙程度，忙碌持续15分钟，15分钟内平均值5.
uptime:故障恢复了。
1分钟：1.00 #CPU处理进程1分钟的繁忙程度，忙碌1分钟。
5分钟：8.01 #CPU处理进程5分钟的繁忙程度，忙碌了5分钟
15分钟：5.05 #CPU处理进程15分钟的繁忙程度，忙碌持续15分钟，15分钟内平均值5.
==============================================
总结：15分钟负载值12，是高是低呢
负载数值/总的核心数=1 #开始慢的临界点，实际上1*70%==关注的临界点。
12/8=1.2 大于1就说明有问题。
负载不要超过5，是临界点。
2颗单颗4核CPU，共8核，负载就是8*70%=5左右。
需要关注负载的值：总的核心数*70%=关注的点
==================要掌握的============================
1.平均负载是运行队列中活跃的进程数。
2.平均负载，1,5,15分钟内的负载。
3.需要关注负载的值：总的核心数*70%=关注的点
4.辅助top,ps,uptime,sar,mpstat,pidstat,iostat，排查问题。
5.strace跟踪进程系统调用。
6.记住几个案例（面试讲故事）。
面试官问：
你在工作中遇到过哪些生产故障，是怎么解决的？
最好和数据库相关（负载高），和web相关（PHP进程100%,JAVA内存泄漏）
==================要掌握的============================
***6.平均负载案例分析实战\***
下面，我们以三个示例分别来看这三种情况，并用 stress、mpstat、pidstat 等工具，找出平均负载升高的根源。
stress 是 Linux 系统压力测试工具，这里我们用作异常进程模拟平均负载升高的场景。
mpstat 是多核 CPU 性能分析工具，用来实时查看每个 CPU 的性能指标，以及所有 CPU 的平均指标。
pidstat 是一个常用的进程性能分析工具，用来实时查看进程的 CPU、内存、I/O 以及上下文切换等性能指标。
#如果出现无法使用mpstat、pidstat命令查看%wait指标建议更新下软件包
yum install sysstats -y
yum install stress -y
stress --cpu 8 --io 4 --vm 2 --vm-bytes 128M --timeout 10s
***场景一：CPU 密集型进程\***
1.首先，我们在第一个终端运行 stress 命令，模拟一个 CPU 使用率 100% 的场景：
[root@oldboy ~]# stress --cpu 1 --timeout 600
2.接着，在第二个终端运行 uptime 查看平均负载的变化情况
# 使用watch -d 参数表示高亮显示变化的区域(注意负载会持续升高)
[root@oldboy ~]# watch -d uptime
*3.最后，在第三个终端运行 mpstat 查看 CPU 使用率的变化情况*
# -P ALL 表示监控所有CPU，后面数字5 表示间隔5秒后输出一组数据
[root@oldboy ~]# mpstat -P ALL 5
#单核CPU,所以只有一个all和0
4.从终端二中可以看到，1 分钟的平均负载会慢慢增加到 1.00，而从终端三中还可以看到，正好有一个 CPU 的使用率为 100%，但它的 iowait 只有 0。这说明，平均负载的升高正是由于 CPU 使用率为 100% 。那么，到底是哪个进程导致了 CPU 使用率为 100% 呢？可以使用 pidstat 来查询
# 间隔5秒输出一组数据
[root@oldboy ~]# pidstat -u 5 1
#从这里可以明显看到，stress进程的CPU使用率为100%。
- 模拟cpu负载高 `stress --cpu 1 --timeout 100`
- 通过uptime或w 查看 `watch -d uptime`
- 查看整体状态mpstat -P ALL 1 查看每个cpu核心使用率
- 精确到进程： pidstat 1
****场景二：I/O 密集型进程\****
1.首先还是运行 stress 命令，但这次模拟 I/O 压力，即不停地执行 sync
[root@oldboy ~]# stress --io 1 --timeout 600s #利用sync()
stress --hdd 8 --hdd-bytes 1g # hd harkdisk 创建进程去进程写
*2.然后在第二个终端运行 uptime 查看平均负载的变化情况：*
[root@oldboy ~]# watch -d uptime
18:43:51 up 2 days, 4:27, 3 users, load average: 1.12, 0.65, 0.00
*3.最后第三个终端运行 mpstat 查看 CPU 使用率的变化情况：*
# 显示所有 CPU 的指标，并在间隔 5 秒输出一组数据
[root@oldboy ~]# mpstat -P ALL 5
#会发现cpu的与内核打交道的sys占用非常高
*4.那么到底是哪个进程，导致 iowait 这么高呢？我们还是用 pidstat 来查询*
# 间隔5秒后输出一组数据，-u 表示CPU指标
[root@oldboy ~]# pidstat -u 5 1
#可以发现，还是 stress 进程导致的。
- 通过stress 模拟大量进程读写 `stress --hdd 4 `
- 通过w/uptime查看系统负载信息 `watch -d uptime`
- 通过top/mpstat 排查 `mpstat -P ALL 1 或 top 按1`
- 确定是iowati `iostat 1查看整体磁盘读写情况 或iotop -o 查看具体哪个进程读写`
- 根据对应的进程,进行相关处理.
***场景三：大量进程的场景 高并发场景 \***
*当系统中运行进程超出 CPU 运行能力时，就会出现等待 CPU 的进程。*
*1.首先，我们还是使用 stress，但这次模拟的是 4 个进程*
[root@oldboy ~]# stress -c 4 --timeout 600
*2.由于系统只有 1 个 CPU，明显比 4 个进程要少得多，因而，系统的 CPU 处于严重过载状态*
*3.然后，再运行 pidstat 来看一下进程的情况：*
# 间隔5秒后输出一组数据
[root@oldboy ~]# pidstat -u 5 1
*可以看出，4 个进程在争抢 1 个 CPU，每个进程等待 CPU 的时间（也就是代码块中的 %wait 列）高达 75%。这些超出 CPU 计算能力的进程，最终导致 CPU 过载。*
****分析完这三个案例，我再来归纳一下平均负载与CPU\****
***平均负载提供了一个快速查看系统整体性能的手段，反映了整体的负载情况。但只看平均负载本身，我们并不能直接发现，到底是哪里出现了瓶颈。所以，在理解平均负载时，也要注意：
平均负载高有可能是 CPU 密集型进程导致的；
平均负载高并不一定代表 CPU 使用率高，还有可能是 I/O 更繁忙了；
当发现负载高的时候，你可以使用 mpstat、pidstat 等工具，辅助分析负载的来源****
**系统负载的计算和意义**
进程以及子进程和线程产生的计算指令都会让cpu执行,产生请求的这些进程组成"运行队列",等待cpu执行,这个队列就是系统负载, 系统负载是所有cpu的运行队列的总和.
[root@oldboye ~]# w
20:25:48 up 95 days, 9:06, 1 user, load average: 2.92, 0.00, 0.00
//假设当前计算机有4个核心的cpu,当前的负载是2.92
cpu1 cpu2 cpu3 cpu4
2.94/4(个cpu核心) = 73%的cpu资源被使用,剩下27%的cpu计算资源是空想的
//假设当前的计算有2个核心的cpu,当前的负载是2.92
2.92/2 = 146% 已经验证超过了cpu的处理能力
7. 日常故障排查流程(含日志)
- w/uptime, 查看负载
- ps aux/top 看看 cpu百分比, io wait或者是内存占用的高? (三高 cpu,io,内存)
- top检查具体是哪个进程,找出可疑进程
- 追踪这个进程使用情况,做什么的?
- 看看对应**日志**是否有异常
- 系统日志: /var/log/messages(系统通用日志) /var/log/secure(用户登录情况)
- 服务软件的日志
***3.那平均负载为多少时合理\***
*最理想的状态是每个 CPU核心 上都刚好运行着一个进程，这样每个 CPU 都得到了充分利用。所以在评判平均负载时，首先你要知道系统有几个 CPU核心，这可以通过 top 命令获取，或`grep 'model name' /proc/cpuinfo`*
系统平均负载被定义为在特定时间间隔内运行队列中的平均进程数。如果一个进程满足以下条件则其就会位于运行队列中：
- 它没有在等待I/O操作的结果
- 它没有主动进入等待状态(也就是没有调用'wait')
- 没有被停止(例如：等待终止)
《内容来自老男孩老师的课堂笔记》
D. 哪些因素影响了数据库性能
以MySQL为例：
影响数据库性能的主要因素总结如下：
1、sql查询速度
2、网卡流量
3、服务器硬件内
4、磁盘IO
以上因素并不容是时时刻刻都会影响数据库性能，而就像木桶效应一样。如果其中一个因素严重影响性能，那么整个数据库性能就会严重受阻。另外，这些影响因素都是相对的。
例如：当数据量并没有达到百万千万这样的级别，那么sql查询速度也许就不是个重要因素，换句话说，你的sql语句效率适当低下可能并不影响整个效率多少，反之，这种情况，无论如何怎么优化sql语句，可能都没有太明显的效果。