TPS不高的情况下Linux IO 100% Busy的问题?

OS: Redhat 6.9
内存:512GB
CPU:8路192核
问题:
某个时点,TPS 8K的情况下,IO BUSY 100%,系统响应缓慢。
重启后,TPS 8K的情况下,IO BUSY  小于 15%,系统恢复正常。

观察到的现象:
1. IO BUSY时系统本地盘和SAN磁盘都busy。
2. 问题发生时,CPU使用率不到3%,内存300+G可用。
3. 重启前,pagetable大小21G,没有基准数据可以比对,不确定这是否是一个正常的大小。另,重启后,有业务压力(5X8)的情况下,age table增长大约750MB/天。
4. 内存主要是被缓存使用,oracle用了40多G,其他全是系统cache和buffer。slabinfo可以看到存在大量dentry堆积,并保持持续增长(和page table情况一样,重启前后都是持续增长)。事发时有273380000个对象,每对象192字节,20个对象一个slab,每个slab一个page。
5.事发时内存使用情况:
MemTotal:       529002072 kB
MemFree:        347646028 kB
Buffers:          743852 kB
Cached:         79231244 kB
SwapCached:         5008 kB
Active:         74411264 kB
Inactive:       21551440 kB
Active(anon):   65223932 kB
Inactive(anon): 16861612 kB
Active(file):    9187332 kB
Inactive(file):  4689828 kB
Unevictable:      370172 kB
Mlocked:          370184 kB
SwapTotal:      67108860 kB
SwapFree:       67097036 kB
Dirty:              4220 kB
Writeback:             0 kB
AnonPages:      16356552 kB
Mapped:         57412988 kB
Shmem:          66027620 kB
Slab:           57206268 kB
SReclaimable:   55351496 kB
SUnreclaim:      1854772 kB
KernelStack:      169408 kB
PageTables:     22858560 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    331609896 kB
Committed_AS:   113216876 kB
VmallocTotal:   34359738367 kB
VmallocUsed:     2123548 kB
VmallocChunk:   33890924616 kB
HardwareCorrupted:     0 kB
AnonHugePages:         0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:       14336 kB
DirectMap2M:     1812480 kB
DirectMap1G:    534773760 kB

问题:
1. 什么情况会导致TPS不高的情况下 IO 100% busy(磁盘阵列卡等硬件层面的问题排查中)。
2. 512G的内存,重启30多天后,page table 21G是不是一个正常的值,如前所述,我们没有基准数据进行历史比较。page table每天增长这么多,是不是存在内存泄漏的问题。page table的大小是不是有个性能临界点,大小超过某个值后,会导致系统整体性能降低。
3. 怎么跟踪page table的增长是哪个进程导致,怎么跟踪dentry的增长是哪个进程导致。

参与28

7同行回答

空  系统工程师 , other
我们也刚遇到类似的问题,没有好的诊断方法,等待高手解答。显示全部

我们也刚遇到类似的问题,没有好的诊断方法,等待高手解答。

收起
IT咨询服务 · 2019-11-25
浏览4274
wnzyjwnzyj  清洁 , cc
如果你的本地盘是scsi的话,iops达到8k就算很高了,肯定会导致系统和业务反应慢,san盘iops就算跑满也不会导致系统反应慢,而是业务处理慢,你现在的问题是本地盘慢导致系统反应慢,那就要查查系统盘哪个逻辑卷有大iops的操作,nmon应该可以看到,再用fuser看看是哪个进程。...显示全部

如果你的本地盘是scsi的话,iops达到8k就算很高了,肯定会导致系统和业务反应慢,san盘iops就算跑满也不会导致系统反应慢,而是业务处理慢,你现在的问题是本地盘慢导致系统反应慢,那就要查查系统盘哪个逻辑卷有大iops的操作,nmon应该可以看到,再用fuser看看是哪个进程。

收起
银行 · 2019-11-26
浏览4284
  • 不好意思,8K这里是指8KB/S的throughput,不是iops。提问题的时候满脑子想着tps,把throughput写成了tps。
    2019-11-26
  • [此评论已删除]
    2019-11-26
  • 如果你的磁盘busy,那么一定iops高
    2019-11-26
kamiarkamiar  软件开发工程师 , 北京中亦安图科技股份有限公司
1.建议重点排查一下存储和交换机,交换机的链路躁音和存储的微码BUG或者存储前端口瓶颈都会导致此种情况发生。显示全部

1.建议重点排查一下存储和交换机,交换机的链路躁音和存储的微码BUG或者存储前端口瓶颈都会导致此种情况发生。

收起
互联网服务 · 2019-11-26
浏览4019
king8823king8823  系统工程师 , IT
如果是我会从以下方向入手:1、首先,找触发事件,查进程,查服务具体问题具体分析,重点排查Oracle : 性能是否存在瓶颈? 索引命中率多少? sql 是否最优等等2、其次,系统层内核参数等等   lvm本地磁盘和san 磁盘有无镜像或者跨本地和san的lvm ? 数据和日志放在同一个lun ?  ...显示全部

如果是我会从以下方向入手:
1、首先,找触发事件,查进程,查服务具体问题具体分析,重点排查Oracle : 性能是否存在瓶颈? 索引命中率多少? sql 是否最优等等
2、其次,系统层内核参数等等   lvm本地磁盘和san 磁盘有无镜像或者跨本地和san的lvm ? 数据和日志放在同一个lun ?  只是怀疑
3、再次,底层磁盘是否有坏道或者坏盘,raid 重组,掉盘等问题
想到的话再补充

收起
系统集成 · 2019-11-26
浏览4003
liukangliukang  系统分析师 , 日志易
应该是内存问题导致的,出现问题时候可以看看内存的缺页状况显示全部

应该是内存问题导致的,出现问题时候可以看看内存的缺页状况

收起
互联网服务 · 2019-12-14
浏览3874
kobe24shoukobe24shou  数据库开发工程师 , ls
内存512G,配置大页啊,PageTables 都21G了,PageTables 大于1G,大概率oracle 要出问题。配置完大页。问题解决。显示全部

内存512G,配置大页啊,PageTables 都21G了,PageTables 大于1G,大概率oracle 要出问题。配置完大页。问题解决。

收起
软件开发 · 2019-12-06
浏览3885
shiwei123shiwei123  数据库管理员 , 某证券
补充事发时slabinfo片段slabinfo - version: 2.1name : tunables : slabdatafuse_request 0 0 424 9 1 : tunables 54 27 8 : slabdata 0 0 0fuse_inode 1 5 768 5 1 : tunables 54 27 8 : slabdata 1 1 0。。。。。inode_cache 41888 42216 592 6 1 : tunables ...显示全部



补充事发时slabinfo片段

slabinfo - version: 2.1

name : tunables : slabdata

fuse_request 0 0 424 9 1 : tunables 54 27 8 : slabdata 0 0 0

fuse_inode 1 5 768 5 1 : tunables 54 27 8 : slabdata 1 1 0

。。。。。

inode_cache 41888 42216 592 6 1 : tunables 54 27 8 : slabdata 7035 7036 0

dentry 273378954 273380000 192 20 1 : tunables 120 60 8 : slabdata 13669000 13669000 53

names_cache 259 259 4096 1 1 : tunables 24 12 8 : slabdata 259 259 0

avc_node 0 0 64 59 1 : tunables 120 60 8 : slabdata 0 0 0
。。。

**再补充:
这个问题是第二次发生,距离第一次发生38天,这38天内一切都正常。
两次都是重启解决问题。**

收起
证券 · 2019-11-25
浏览4481

提问者

shiwei123
数据库管理员某证券

相关问题

相关资料

相关文章

问题状态

  • 发布时间:2019-11-25
  • 关注会员:8 人
  • 问题浏览:9831
  • 最近回答:2019-12-14
  • X社区推广