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

OS: Redhat 6.9内存:512GBCPU:8路192核问题:某个时点,TPS 8K的情况下,IO BUSY 100%,系统响应缓慢。重启后,TPS 8K的情况下,IO BUSY  小于 15%,系统恢复正常。观察到的现象:1. IO BUSY时系统本地盘和SAN磁盘都busy。2. 问题发生时,CPU使用率不到3%,内存300+G可用。3. 重...显示全部

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

查看其它 6 个回答kamiar的回答

kamiarkamiar  软件开发工程师 , 北京中亦安图科技股份有限公司

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

互联网服务 · 2019-11-26
浏览4022

回答者

kamiar
软件开发工程师北京中亦安图科技股份有限公司
擅长领域: 服务器AIXUnix

kamiar 最近回答过的问题

回答状态

  • 发布时间:2019-11-26
  • 关注会员:8 人
  • 回答浏览:4022
  • X社区推广