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的增长是哪个进程导致。
收起