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