解决方法有三种:

1、当CPU数超出终端大小不多时,可以通过ALT + Enter 最大化当前窗口(SecureCRT客户端时);

2、mpstat -P ALL

3、sar -P ALL

方法1一般不会有效果。这里主要说要方法2和方法3。
接下来我要说的是用top命令,按数字1键,查看CPU各个核心使用情况,提示:Sorry, terminal is not big enough。
在此之前的服务器2颗6核CPU,开启超线程24。当我们遇到这个情况的时候,用Alt +Enter最大化终端窗口就Ok了[SecureCRT软件]。
现在的服务器2颗8核,超线程32核,此时,再用Alt +Enter最大化终端窗口[SecureCRT软件],Sorry, terminal is not big enough
没办法了吗?网上说用putty,上次我匆匆试了一下,没有搞定,就另想它法了,linux系统的开源人,为我提供了许多好用的命令,

mpstat命令,结合一些参数,如下:

mpstat命令详解:
http://www.bdkyr.com/view.php?id=73

mpstat -P ALL
#执行结果如图


有人问了,可以看,但是不实时呀。别急,还有呢,再加点参数:

mpstat -P ALL 2 1000

这样就可以搞定了,不信你找一台2路8核的服务器,试试,很有效果的,shell搞的话,可以自己弄个更强大,更人性化的实时查看工具。

来自:http://www.361way.com/terminal-big-enough/4514.html
使用安装包安装的phpstrom无法正常启动,原因是原默认wwwroot是 /data/www,现在系统禁用了对根目录的使用所以只能将dbpath指向到自定义目录,如
将原来的目录迁移到/var/data,在/data下面做软链接即可,原来的升级备份位置在哪儿?
系统升级完成后桌面会出现一个目录 迁移的项目 将这个目录下的/data/db 下的文件拷贝到新的dbpath就可以了。
原文链接:https://blog.csdn.net/StillCity/article/details/102562281


二)如何做软链接?ln -sf /var/data /data
在这次mac升级系统后,我发现我的/data目录消失了,于是我执行了命令:

mkdir /data
结果发现居然提示我Read-Only filesystem,即使加上了sudo也没用

在我查阅相关资料后找到了解决办法(关闭SIP,然后输入sudo mount -uw /,创建文件夹添加权限,最后启用SIP),具体步骤如下:

1、重启mac,按住Command+R,等到系统进入安全模式。

2、选择一个账户,然后点击屏幕上方的工具栏找到命令行工具。

3、执行,命令 csrutil disable

4、重启电脑后,不要进入安全模式,执行命令sudo mount -uw /

5、执行命令sudo mkdir /data

6、执行命令sudo chmod 777 /data

7、重启电脑,进入安全模式,执行命令csrutil enable (开启SIP)
原文链接:https://blog.csdn.net/weiyoushi4001/article/details/102928575

大体运行命令:



背景:我一看这文章就知道是架构平台部的兄弟的操作性更大一些,谁投的稿不清楚,但这个操作能感受到浓浓的鹅厂气息,这些年过去了,系统底层依然没有大变化,估计这些操作还能再用上十年,特梳理总结,以便“后来人”,也包括自己备忘。女程序员少,会写VIM、GDB、Linux命令、正则表达式、Makefile的女程序员妹子简直就是至宝啊,尽管ls –lhS ,中间横写得不对,但这不是重点,正是留言的好机会,请年轻程序员男好生把握,哥也年轻过,别后悔莫及,机会就让给你们了,哈哈。

1)磁盘满了查看/一级目录的报警:
du -h --max-depth=1


2)将当前目录下各文件以从大到小的顺序进行展示:
ls -lhS


3)查看日志最近200行:
history | tail -n 200


4)top cpu内存排序:
top 命令的基本视图中,按数字 1 监控每个逻辑 CPU 的使用情况;按 P 实现按 CPU 降序排列,按 M 按内存降序排列。

5)编写的二进制代码推到后台监听端口9999:
nohup xxx 9999

6)查看程序开启的端口:
netstat -anp | grep -w 9999

7)tcpdump抓自己开发的服务器server并调试,学后面的正则匹配:
tcpdump -s 0 -A 'tcp dst port 80 and (tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x504f5354)'

8)对日志某些列判断性打印:
awk '-F,' '{if ($666==110) print $999}' xxx.log.20191212

9)动态链接没有加载文件:
lsof xxx.so  #进程加载的一个外部 so 动态库对应功能并没有生效
GDB 调试时发现,该 so 并没有导出函数 fffff 。
nm -D xxx.so | grep fffff

10)停掉了测试进程 xxx:
ps aux | grep -w xxx| grep -v grep | awk '{print $2}' | xargs kill -9

11)并没有导出函数 fffff ,证实了该 so 确实没有导出该函数。
nm -D xxx.so | grep fffff

来源自vimer、女程序员说:https://mp.weixin.qq.com/s/WsWFcw-xoRTFOcz1TQqDBw
#ls -i
24229218 go  805308641 -w,

这样删不掉:
#rm -i 805308641
rm: cannot remove ‘805308641’: No such file or directory


这样删才行:
find ./* -inum 805308641 -delete


来自:https://blog.csdn.net/wb736/article/details/79756956
现象:init 0 关闭系统 出现错误提示,阿里专有云的运维兄弟反馈说是没有完全关闭:
再登录下:runlevel  ,说是操作系统bug。
来自:https://developer.aliyun.com/ask/107789?spm=a2c6h.13159736
zabbix  负载高,unreacheable等,都是因 nfs的server端出了问题导致的,其
结论是从阻塞查起,现象是有很多进程hang住,sudo umount -lf /backup是解决CPU高的最有效良药。两篇核心文章:
nfs问题导致df挂起  https://www.jianshu.com/p/6fd207b16a06?utm_campaign=maleskine&utm_content=note&utm_medium=seo_notes&utm_source=recommendation
生产故障之nfs挂载导致系统负载巨高  https://blog.51cto.com/12643266/2377694
链接:
生产故障之nfs挂载导致系统负载巨高
nfs问题导致df挂起

背景:Linux的负载很高,uptime  load average: 457.67, 449.80, 429.24,用sar看一下user、system、iowait、idle,vmstat 2 2看一下,现用netstat -an | wc -l 多么?lsof | wc -l (卡死了,文件打开可能太多了,strace lsof出现Bad file descriptor,ulimit -n,lsof -n | awk '{print($2)}' | sort | uniq -c | sort -nr | more ,其中第一列是打开的句柄数,第二列是进程ID。来自:https://www.cnblogs.com/cloudwind2011/p/6409074.html ),ps -ef | wc -l多么(多达2158个/usr/bin/rsync -avh /backup/, ps -ef|grep rsync|wc -l 1455个进程),看清进程名用 ps -eo"pid,ppid,cmd"|grep rsync,原来是:/usr/bin/rsync -avh /backup/yum.qr.***.net  /data/www >/dev/null 2>&1。

模拟nfs服务端问题导致nfs客户端的进行hand死,具体表现为调用df命令或者涉及访问该目录的命令时界面会hang住,如果大量后台进行调用访问该目录会导致uptime下的负载检查,而实际所有的sar检查都没有发现任何性能问题。
sar -u 观察CPU情况
cpu使用率非常低,大部分为idle,说明没有进程在等待cpu资源。sar -u 1。
sar -d 观察磁盘情况 磁盘dev253-0的tps几乎为0,说明没有什么进程时等待磁盘。sar -d 1。
sar -b 观察IO情况 IO设备的读写tps都几乎为0,瓶颈明显不足IO设备:sar -b 1。
sar -W 观察换页情况 当时几乎没有进行换页操作。 sar -W 1。
sar -q 观察队列情况 队列情况初步指出问题所在,大量队列堆积在任务列表中未执行,继续考虑进程问题。sar -q 1。
根据最明显的问题根源“df操作hang死”,通过strace去分析df命令的系统调用及信号情况,可以明显发现df是在系统调用尝试获取目录/var/nfs的stat信息时挂起,如下: strace df -h /backup   open("/backup", O_RDONLY|O_NOCTTY...。
mount发现 /backup是挂载目录。 mount | column -t |grep backup
umount -lf强制卸载文件系统,df恢复正常,通过killall df将大量的残余df进程中止后系统负载下降。sudo umount -lf /backup
链接:https://www.jianshu.com/p/6fd207b16a06

以下8个大点看CPU:

1)top看IO/CPU
2)sar 看整体
3)vmstat 2 2
4)netstat -an|wc -l 看网络连接数
5)lsof |wc -l 实际使用句柄数, root权限!
6)ps -ef | wc -l 看进程数
7)yum -y install iotop 看写入进程是否太大。
8)dmesg  #能看到一些磁盘和网络啥的信息nfs: server 10.71.15.*8 not responding, still trying

strace lsof出现Bad file descriptor:
access("/etc/selinux/config", F_OK)     = 0
getrlimit(RLIMIT_NOFILE, {rlim_cur=65535, rlim_max=65535}) = 0
close(3)                                = -1 EBADF (Bad file descriptor)

lsof -nPp pid   #会被卡住,说明还是句柄太多了,无法看哪个句柄了,只有重启解决了,https://jackxiang.com/post/9908/,忽然也看到:
cp /data/backup/ldap_backup_19-12-25-22.ldif /backup/ldap.qr.**.net/ 这个是网盘,估计也是网盘引起的:
cat /usr/local/sbin/ldap_backup.sh|grep cp
cp /data/backup/ldap_backup_$DATE.ldif /backup/ldap.qr.*.net/

root     49414 49413  0 19:00 ?        00:00:00 /bin/sh -c /usr/local/sbin/ldap_backup.sh > /dev/null 2>&1
root     49416 49414  0 19:00 ?        00:00:00 /bin/bash /usr/local/sbin/ldap_backup.sh
root     49422 49416  0 19:00 ?        00:00:00 cp /data/backup/ldap_backup_19-12-25-19.ldif /backup/ldap.qr.*.net/

strace -f -p 49422 #卡死
strace: Process 49422 attached
lsof -nPp 49422 #卡住    

开机启动:/etc/rc.local
mount -t nfs -o vers=3,tcp 10.71.15.**:/Vol-01/irdcbackup /backup



原因和步骤:
存储访问不到,你就先把备份暂停吧
卡在这里你只能 kill进程了
load是每core排队任务数,不一定机器就压力大
你这个在排队,因为它们都卡着,也没啥压力


监控报警找到原因了,那几台机器都挂载nas,nas有问题了,就是那个/backup的nas

不光是引起报警,还会引起rsync同步到nas时时进程数太多负载高。
rsync同步时最好加上超时:
timeout:rsync的超时设置,防止客户端的死连接,单位为秒。默认值为0,意味着没有超时定义。
rsync hang增加超时设置如下:rsync -avz --contimeout=60 --timeout=900 --password-file="./rsync.pas" --include="*/" --include="*.nc" --exclude="*" rsync://192.168.100.1/obs_data/hspt/mrt/ /test/hspt/mrt/   ,来自:http://blog.sina.com.cn/s/blog_8d92d7580102xt4i.html

mount超时设置和测试:
hard-mount:客户端加载不成功时,会一直重试,直到NFS服务器有响应,于是出现了高负载。系统缺省值就是一直重试,最好同时选intr,允许中断系统调用请求,避免引起系统挂起。
INTR——中断请求信号,高电平有效
INTE ——中断允许信号,高电平有效
  用于控制中断允许或中断屏蔽
  8255A输出的信号,可用于向CPU提出中断请求,要求CPU读取外设数据
当客户端挂载的时候采用soft模式,我们可以配置timeo和retry参数,配置超时时间,服务器端出现异常,客户端也会向服务器端发请求,当超过我们配置的时间,则会返回错误,不会一直阻塞。
hard模式挂载:
mount -t nfs -o rw 192.168.1.2:/home/nfs /mnt local_path
soft模式挂载
mount -t nfs -o rw,soft,timeo=30,retry=3 192.168.1.2:/home/nfs /mnt
timeo的单位是0.1秒,配置为30就是隔3秒客户端向服务器端请求。

断网命令:iptables -A OUTPUT -d 172.16.18.0/24 -j DROP
恢复命令:iptables -F
查看报错:
dmesg | tail -n 40
来自:https://blog.csdn.net/lindao99/article/details/80000002

进程多不是负载高的原因,核心还是mount的服务器端给停掉了引发一系列的rsync没有超时的进程越来越多,文章:https://blog.51cto.com/12643266/2377694

ps -ef|grep rsync|grep -v grep |grep yum|awk '{print "kill -9 " $2}'|sh   #Processor load is too high on 下一了。杀掉同步阻塞进程,负载下来了,Zabbix的Too many processes on也好了。

umount  /backup/ -f   #强制卸载,umount.nfs: /backup: device is busy,fuser -m /backup ,按tab都无法补齐,直接卡死了,只好reboot,如果reboot 还不行得init 1为重启上了 来自:https://jackxiang.com/post/5100/,怎么办?sudo umount -lf /backup 得到解决,加上l:
-l     Add the labels in the mount output. Mount must have permission to read the disk device (e.g. be suid root) for this to work.  One can set  such  a
              label for ext2, ext3 or ext4 using the e2label(8) utility, or for XFS using xfs_admin(8), or for reiserfs using reiserfstune(8)

=====================================================================================
sar(System Activity Reporter系统活动情况报告)是目前 Linux 上最为全面的系统性能分析工具之一,可以从多方面对系统的活动进行报告,包括:文件的读写情况、系统调用的使用情况、磁盘I/O、CPU效率、内存使用状况、进程活动及IPC有关的活动等。本文主要以CentOS 6.3 x64系统为例,介绍sar命令。

sar命令常用格式
sar [options] [-A] [-o file] t [n]

其中:

t为采样间隔,n为采样次数,默认值是1;

-o file表示将命令结果以二进制格式存放在文件中,file 是文件名。

options 为命令行选项,sar命令常用选项如下:



-A:所有报告的总和

-u:输出CPU使用情况的统计信息

-v:输出inode、文件和其他内核表的统计信息

-d:输出每一个块设备的活动信息

-r:输出内存和交换空间的统计信息

-b:显示I/O和传送速率的统计信息

-a:文件读写情况

-c:输出进程统计信息,每秒创建的进程数

-R:输出内存页面的统计信息

-y:终端设备活动情况

-w:输出系统交换活动信息

1. CPU资源监控
例如,每10秒采样一次,连续采样3次,观察CPU 的使用情况,并将采样结果以二进制形式存入当前目录下的文件test中,需键入如下命令:

sar -u -o test 10 3

From:http://lovesoo.org/linux-sar-command-detailed.html?rylyjc=tohvi3
macOS 升级到 Catalina之后,使用SecureCRT报如下错误

The permissions on the "/cores" directory need to be changed to
include write permission for "other".

Please execute (or ask an admin to execute) the following from a
terminal window:

sudo chmod go+w /cores

If you would prefer not to change the permissions on the /cores
folder, you can turn off the Global option "Create core file when
application crashes".



应该是macOS的权限控制严格了,导致CRT没有权限访问/cores文件夹,这里关掉CRT崩溃时创建core转储文件即可(实践发现:这个项是没有 checked的,还是老老实实的执行sudo chmod o+w /cores命令后重启后secureCRT就好了。)

Option --> Global Options 取消 Create core file when application crashes 前面的复选框选择即可

来自:https://blog.90.vc/archives/93.html
想对指针类型里装的地址改动,在函数参数里需要两个**表明它是一个指向指针的指针(也就是传的是指针q的地址) ,ptr_copy(char ** d,char *s){ *d = s;} ,赋值里注意一下是*d =s(*d就是传指针地址的址,不再是值,也就是不会被在函数完成销毁后,外面值不会变,因为传的是指针q的地址。),也就是d里存指针地址*d表示,*d=s,s就是一个地址刚好能赋值。
更多说明帮助理解传参部分:
c语言菜鸟指针传递 问题 void func(char **p) {} int main(void) { char *q=null; func(&q); } p被赋值了神马 为什么俩星号?
p被赋值的是char* p的地址!你把char* 理解为一个变量就好理解了,就好比char a;char是变量类型,a是变量。既然是变量它就有地址,所以p也有地址,char **p,可以看成是 char* (*p)所以char** 被传的值是存放地址的变量的地址!

void func(char **p) {} //函数参数是指向指针的指针
int main(void)
{
char *q=null; //q定义为指针类型
func(&q); //&q,是取q的地址,q是一个指针类型,所以&q就是指针q的地址,即向指针的指针
}

来自:https://zhidao.baidu.com/question/686311732439253092.html


问:运行的以下clang代码,我希望输出ptr3=123与var相同ptr2的结果,但是结果是ptr3=(null)。如何修改我想要的结果代码?

gcc a.c -o a
./a
ptr2=123
ptr3=1PTI

让我们来看看您的“复制”功能:

void ptr_copy(char* d, char* s)
{
    d = s;
}
在函数中,变量d是局部变量。一旦函数返回并d超出范围并终止其生命,对它的分配将丢失。

这使您ptr3在main函数中留下未初始化的变量,使用它会导致未定义的行为 -

如果要复制指针,则需要通过将指针传递给指针本身来模拟按引用传递:

void ptr_copy(char** d, char* s)
{
    *d = s;
}
并称其为

ptr_copy(&ptr3, ptr)

需要的是一个不同的ptr_copy功能,如下所示:

void ptr_copy(char** dst, char* src) {
    (*dst) = src;
}

ptr_copy(&ptr3, ptr);
这个想法是您将内容填充ptr到ptr3存储的位置(因此&ptr3,不是ptr3)。

当您将指针传递给函数时,该指针的值将被传递(即给定指针指向的地址)。因此,d内部ptr_copy的指针不同于(与该指针具有相同的值,但它位于内存的另一部分中)不同的指针。这就是为什么分配,更改地址指向的原因,但是对却没有任何作用。

确实考虑一个功能

void value_copy(int d, int s) {
    d = s;
}
int i1 = 3;
int i3 = 2;
value_copy(i3, i1);
您不希望i3在调用后等于3 value_copy(),对吗?

正确调用如下:




#make a.c
cc     a.c   -o a

#./a
ptr2=123
ptr3=123


来自:https://stackoverflow.com/questions/59084119/copy-string-to-pointer-failed-in-function-in-clang



经GDB调试一下,发现其经过char ** d传参数进入函数后,实现了对传入的指针传址的d进行了修改,返回时也是作了修改,所以能正确指向123,GDB在打印时print ptr就是地址和值,如下:
(gdb) l
8       int main(){
9           char *ptr = "123";
10          char* ptr2;
11          char* ptr3;
12
13          ptr2 = ptr;
14          printf("ptr=%p\n", ptr);
15          printf("ptr2=%p\n", ptr2);
16          ptr_copy(&ptr3, ptr);
17          printf("ptr3=%p\n", ptr3);
(gdb) p ptr
$1 = 0x400670 "123"
(gdb) n
14          printf("ptr=%p\n", ptr);
(gdb) s
ptr=0x400670
15          printf("ptr2=%p\n", ptr2);

(gdb) p ptr
$3 = 0x400670 "123"
(gdb) s
ptr2=0x400670
16          ptr_copy(&ptr3, ptr);
(gdb) s
ptr_copy (d=0x7fffffffe498, s=0x400670 "123") at a.c:5
5           *d = s;
(gdb) p d
$4 = (char **) 0x7fffffffe498
(gdb) s
6       }

(gdb) s
main () at a.c:17
17          printf("ptr3=%p\n", ptr3);
(gdb) p ptr3
$6 = 0x400670 "123"

经过函数的运作,这个ptr,ptr2,ptr3都指向了0x400670,也就是123。
问题,之前以为是redis占用太多内存,后来发现是操作系统有问题:
free -m
             total       used       free     shared    buffers     cached
Mem:          7865       6138       1726          0        326       5110
-/+ buffers/cache:        701       7163

echo 1 > /proc/sys/vm/drop_caches

free -m
             total       used       free     shared    buffers     cached
Mem:          7865        530       7335          0          0         19

===============================================
Linux cached过高问题,手动释放cached

To free pagecache:  echo 1 > /proc/sys/vm/drop_caches

To free dentries and inodes:  echo 2 > /proc/sys/vm/drop_caches

To free pagecache, dentries and inodes:  echo 3 > /proc/sys/vm/drop_caches

来自:https://www.cnblogs.com/yanwei-wang/p/8133888.html
ss -lnt
LISTEN     0      128                                                     *:57840                                                  *:*

sudo lsof -i tcp:57840  
rpc.statd 1453 rpcuser    9u  IPv4  13387      0t0  TCP *:57840 (LISTEN)

ps -ef|grep 1453          
rpcuser   1453     1  0  2018 ?        00:00:00 rpc.statd

rpm -qf /sbin/rpc.statd
nfs-utils-1.2.3-39.el6.x86_64

ls /etc/init.d/nfs*

/etc/init.d/nfslock status

vi /etc/services
nfs             2049/tcp        nfsd shilp      # Network File System
nfs             2049/udp        nfsd shilp      # Network File System
nfs             2049/sctp       nfsd shilp      # Network File System

找到里面的 nfs ,在前面加 # 注释掉,重启,我直接停掉服务。
/etc/init.d/nfslock stop
Stopping NFS statd:                                        [  OK  ]

来自:https://blog.csdn.net/maxuearn/article/details/79879607
https://jackxiang.com/post/10343/,出现磁盘等待wait较高,如下:
iostat -x 2 5  # %util 出现100,设备是挂载的dm-0
Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
dm-0              0.00     0.00    0.00    0.00     0.00     0.00     0.00     2.00    0.00   0.00 100.00



#dm-0的%utilized 是100.00%,这个很好的说明了有进程正在写入到dm-0磁盘中。
dm是device mapper(设备映射)的意思:
dm-0是个块设备,就是个分区,他被挂载在不同的目录,但是不同目录里的文件却不一样。


实践如何不用重启直接生效/etc/fstab的方法:
修改过/etc/fstab后mount -a 即可生效

      -a, --all
              Mount all filesystems (of the given types) mentioned in fstab.



二)查找iostat与df -h,挂载磁盘dm-0的对应关系。
cd /dev/mapper/
ll
ddf1_4c5349202020202010000055000000004711471100001450p1 -> ../dm-1

dmsetup ls|grep ddf1_4c5349202020202010000055000000004711471100001450p1
ddf1_4c5349202020202010000055000000004711471100001450p1 (253:1)

df -Plh|grep 'ddf1_4c5349202020202010000055000000004711471100001450p1'
/dev/mapper/ddf1_4c5349202020202010000055000000004711471100001450p1  194M   34M  151M  19% /boot

双出现:dm-3              0.00     0.00    0.00    0.00     0.00     0.00     0.00     2.00    0.00   0.00 100.00
df -Plh|grep 'ddf1_4c5349202020202010000055000000004711471100001450p3'
/dev/mapper/ddf1_4c5349202020202010000055000000004711471100001450p3  119G  2.4G  110G   3% /

指向boot目录。
反证:以为是卸载了所有的mount目录iowait就好,实践发现并没有好,负载依然高:




ddf1_4c5349202020202010000055000000004711471100001450p1 通过下面命令也能看:


来自:https://www.iteye.com/blog/andnnl-2236548
磁盘有问题:
sudo badblocks -s -v -o sdbbadblocks.log /dev/sda  #出现一堆的坏块编号

dmesg |less -i     #jbd2,当有硬盘坏道时,通常在dmesg输出的信息中会有 Buffer I/O Error,所以经常检查dmesg的输出可以及时发现是否存在硬盘问题。
NFO: task jbd2/dm-3-8:526 blocked for more than 120 seconds.
      Not tainted 2.6.32-431.el6.x86_64 #1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
jbd2/dm-3-8   D 0000000000000002     0   526      2 0x00000000


查看第2个CPU上的程序定位到jbd2:

ps -eo 'pid,psr,cmd' |sort -nk 2|awk '{if($2==2)print }'|grep -v '\['
ps -eo 'pid,psr,cmd' |sort -nk 2|awk '{if($2==2)print }'|grep  '\['

ls -l /dev/dm-3
brw-rw---- 1 root disk 253, 3 Nov 11 14:59 /dev/dm-3

ps -LF -p 526   #看它的主进程
UID        PID  PPID   LWP  C NLWP    SZ   RSS PSR STIME TTY          TIME CMD
root       526     2   526  0    1     0     0   2 Nov11 ?        00:00:00 [jbd2/dm-3-8]

lsof -nPp 526
COMMAND   PID USER   FD      TYPE DEVICE SIZE/OFF NODE NAME
jbd2/dm-3 526 root  cwd       DIR  253,3     4096    2 /
jbd2/dm-3 526 root  rtd       DIR  253,3     4096    2 /
jbd2/dm-3 526 root  txt   unknown                      /proc/526/exe


dmraid -r  #man dmraid
/dev/sda: ddf1, ".ddf1_disks", GROUP, ok, 285155328 sectors, data@ 0
/dev/sdb: ddf1, ".ddf1_disks", GROUP, ok, 285155328 sectors, data@ 0


lsblk -f   #RAID1:数据安全性高,即同样的数据在另一块盘上备份一份,硬盘的容量也就减少一半。
NAME                                                               FSTYPE          LABEL UUID                                 MOUNTPOINT
sdb                                                                ddf_raid_member       LSI     \x10                        
└─ddf1_4c5349202020202010000055000000004711471100001450 (dm-0)                                                                
  ├─ddf1_4c5349202020202010000055000000004711471100001450p1 (dm-1) ext4                  bef5de45-511b-41c2-b487-6cf98faf978a /boot
  ├─ddf1_4c5349202020202010000055000000004711471100001450p2 (dm-2) swap                  861a3dbd-ca4b-4c97-b2b8-51504ee45949 [SWAP]
  └─ddf1_4c5349202020202010000055000000004711471100001450p3 (dm-3) ext4                  410be0c5-9b55-490e-b924-606d46182ea2 /
sda                                                                ddf_raid_member       LSI     \x10                        
└─ddf1_4c5349202020202010000055000000004711471100001450 (dm-0)                                                                
  ├─ddf1_4c5349202020202010000055000000004711471100001450p1 (dm-1) ext4                  bef5de45-511b-41c2-b487-6cf98faf978a /boot
  ├─ddf1_4c5349202020202010000055000000004711471100001450p2 (dm-2) swap                  861a3dbd-ca4b-4c97-b2b8-51504ee45949 [SWAP]
  └─ddf1_4c5349202020202010000055000000004711471100001450p3 (dm-3) ext4                  410be0c5-9b55-490e-b924-606d46182ea2 /

dmraid -s
*** Group superset .ddf1_disks
--> Active Subset
name   : ddf1_4c5349202020202010000055000000004711471100001450
size   : 285155328
stride : 128
type   : mirror
status : ok
subsets: 0
devs   : 2
spares : 0


步骤一) top命令显示后 按1
             Cpu2  :  0.0%us,  0.0%sy,  0.0%ni,  0.0%id,100.0%wa,  0.0%hi,  0.0%si,  0.0%st
             wa -- iowait  AmountoftimetheCPUhasbeenwaitingfor I/O to complete.

步骤二)iostat -x 2 5  #定位各个磁盘读写哪个高一些,iostat 会每2秒更新一次,一共打印5次信息, -x 的选项是打印出扩展信息,实际使用得需要扩展信息-x得到svctm一项,反应了磁盘的负载情况,如果该项大于15ms,并且util%接近100%,那就说明,磁盘现在是整个系统性能的瓶颈了。
svctm:          平均每次设备I/O操作的服务时间 (毫秒)。即 delta(use)/delta(rio+wio)
%util:          一秒中有百分之多少的时间用于 I/O 操作,或者说一秒中有多少时间 I/O 队列是非空的。即 delta(use)/s/1000 (因为use的单位为毫秒)
              如果 %util 接近 100%,说明产生的I/O请求太多,I/O系统已经满负荷,该磁盘可能存在瓶颈。
avgqu-sz:     平均I/O队列长度。即 delta(aveq)/s/1000 (因为aveq的单位为毫秒)。

浅显易懂的解释:
平均服务时间(svctm)类似于收银员的收款速度
平均等待时间(await)类似于平均每人的等待时间
I/O 操作率 (%util)类似于收款台前有人排队的时间比例。


实践发现dm-0 / dm-3 卡住了,产生的I/O请求太多,I/O系统已经满负荷,该磁盘可能存在瓶颈,也可能是坏了,
第一个iostat 报告会打印出系统最后一次启动后的统计信息,这也就是说,在多数情况下,第一个打印出来的信息应该被忽略,剩下的报告,都是基于上一次间隔的时间。举例子来说,这个命令会打印5次,第二次的报告是从第一次报告出来一个后的统计信息,第三次是基于第二次 ,依次类推:
iostat -x 2 5  # %util 出现100,设备是挂载的dm-0
Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
dm-0              0.00     0.00    0.00    0.00     0.00     0.00     0.00     2.00    0.00   0.00 100.00


#dm-0的%utilized 是100.00%,这个很好的说明了有进程正在写入到dm-0磁盘中。
dm是device mapper(设备映射)的意思:
dm-0是个块设备,就是个分区,他被挂载在不同的目录,但是不同目录里的文件却不一样。


svctm 一般要小于 await (因为同时等待的请求的等待时间被重复计算了),如果 svctm 比较接近 await,说明 I/O 几乎没有等待时间;如果 await 远大于 svctm,说明 I/O 队列太长,应用得到的响应时间变慢,如果响应时间超过了用户可以容许的范围,这时可以考虑更换更快的磁盘......。



步骤三)查找引起高I/O wait 对应的进程 ,iotop    #查找I/O wait 对应的进程


步骤四)查找哪个文件引起的I/Owait:
lsof 命令可以展示一个进程打开的所有文件,或者打开一个文件的所有进程。从这个列表中,我们可以找到具体是什么文件被写入,根据文件的大小和/proc中io文件的具体数据

我们可以使用-p <pid>的方式来减少输出,pid是具体的进程
lsof -p 1028

步骤四)更深入的确认这些文件被频繁的读写,我们可以通过如下命令来查看

[root@localhost ~]# df /tmp
文件系统               1K-块    已用     可用 已用% 挂载点
/dev/mapper/cl-root 17811456 3981928 13829528   23% /
  从上面的命令结果来看,我们可以确定/tmp 是我们环境的逻辑磁盘的根目录

复制代码
复制代码
[root@localhost ~]# pvdisplay
  --- Physical volume ---
  PV Name               /dev/sda2
  VG Name               cl
  PV Size               19.00 GiB / not usable 3.00 MiB
  Allocatable           yes (but full)
  PE Size               4.00 MiB
  Total PE              4863
  Free PE               0
  Allocated PE          4863
  PV UUID               4QfaOy-DNSO-niK1-ayn2-K6AY-WZMy-9Nd2It
复制代码
复制代码
  过pvdisplay我们能看到/dev/sda2其实就是我们用来创建逻辑磁盘的具体磁盘。通过以上的信息我们可以放心的说lsof的结果就是我们要查找的文件

cat /proc/18987/io
rchar: 58891582418
wchar: 58891579778
syscr: 46556085
syscw: 46556077
read_bytes: 212992
write_bytes: 59580235776
cancelled_write_bytes: 0

同时可以结合vmstat 查看查看b参数(等待资源的进程数),b有一个等待:
vmstat
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
0  1      0 11119256 238876 205460    0    0     0     0    2    3  0  0 99  1  0


来自:https://www.cnblogs.com/happy-king/p/9234122.html
cat test.txt


sh test.txt
. test.txt


run:
sh test.txt
hello world


. test.txt  
hello world

即便test.txt没有可执行权限,也能够正常运行。

想一个自己的printf程序到底执行的是哪一个呢?
type -a printf
printf is a shell builtin
printf is /bin/printf
printf is /usr/bin/printf


更多来自:https://mp.weixin.qq.com/s/LdHHVsK9UsQ1mNLgA1pdSw
原理:应该是默认路由出口IP,它也就是能上网的default路由,发起公网请求的clientIP也就是要获取的服务器IP地址。



10.71.10.40


more:
echo $(python -c "
import socket;s=socket.socket(socket.AF_INET,socket.SOCK_DGRAM);s.connect(('i.api.weibo.com',0));print(s.getsockname())  
")
('10.71.10.40', 45847)


换成别的IP也一样能行:
分页: 1/38 第一页 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 下页 最后页 [ 显示模式: 摘要 | 列表 ]