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的增长是哪个进程导致。
如果你的本地盘是scsi的话,iops达到8k就算很高了,肯定会导致系统和业务反应慢,san盘iops就算跑满也不会导致系统反应慢,而是业务处理慢,你现在的问题是本地盘慢导致系统反应慢,那就要查查系统盘哪个逻辑卷有大iops的操作,nmon应该可以看到,再用fuser看看是哪个进程。
收起如果是我会从以下方向入手:
1、首先,找触发事件,查进程,查服务具体问题具体分析,重点排查Oracle : 性能是否存在瓶颈? 索引命中率多少? sql 是否最优等等
2、其次,系统层内核参数等等 lvm本地磁盘和san 磁盘有无镜像或者跨本地和san的lvm ? 数据和日志放在同一个lun ? 只是怀疑
3、再次,底层磁盘是否有坏道或者坏盘,raid 重组,掉盘等问题
想到的话再补充
slabinfo - version: 2.1
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天内一切都正常。
两次都是重启解决问题。**