由hugepage设置导致的数据库事故(r4笔记第28天)
发布日期:2021-06-30 13:30:09 浏览次数:2 分类:技术文章

本文共 1861 字,大约阅读时间需要 6 分钟。

近期客户需要希望提高业务处理能力,在现有的系统中加入几台weblogic服务器,所以需要增加以下连接数的配置,但是同时他们想对现有系统的设置一些变更,发送了一个清单给我们。

Change Processes from 10000 to 18000

Change PGA from 10G to 20G

Change Buffer Cache from 20G to 40G

Change Shared pool from 10G to 20G

HugePage from 60 GB to 120GB 546860k free, 1108k buffers

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 3852 root 20 -5 0 0 0 R 52.2 0.0 22:53.66 [kswapd3] 3849 root 20 -5 0 0 0 R 52.1 0.0 7:12.63 [kswapd0] 3851 root 20 -5 0 0 0 R 52.1 0.0 17:42.67 [kswapd2] 3850 root 20 -5 0 0 0 R 52.1 0.0 8:09.50 [kswapd1]31332 oraccbs1 18 0 63.6g 26m 18m S 23.9 0.0 0:08.28 ora_p171_CUST015207Linux uses kswapd for virtual memory management such that pages that have been recently accessed are kept in memory and less active pages are paged out to disk.这个和虚拟内存管理相关,存在着大量的页面置换。如果验证这一点,可以从vmstat来说明。> vmstat 1 3procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------ r b swpd free buff cache si so bi bo in cs us sy id wa st611 7 10799976 547000 1444 64194804 0 0 351 452 0 0 3 1 96 0 0536 1 10799984 546716 1508 64194876 252 108 614 361 1062 108275 7 93 1 0 0428 2 10800060 548112 1516 64195268 48 204 436 437 1052 111422 9 86 5 0 0swpd的值在之前都是为0,说明存在着大量的置换操作。从业务部门和开发部门的一些同事反馈,数据库已经连不上了。这个时候我赶快发送了一封邮件抄给客户的dba组,让他们赶紧查看一些内存异常的问题,同时我在远程也在看。这样问题就不会很被动,同步一些信息给客户,可能他们已经在关注或者在查了,能避免很多的误解。kswapd3的的原因是由于内存使用紧张导致的,那么300G左右的内存,设置了60G左右的Hugepage,怎么还不够用呢,从Hugepage的情况来看一下。> cat /proc/meminfo | grep -i pageAnonPages: 21223132 kBPageTables: 136301560 kBHugePages_Total: 30000HugePages_Free: 27284HugePages_Rsvd: 566Hugepagesize: 2048 kB这一看确实让人奇怪,设置了那么大的hugepage怎么还剩余这么多呢,基本都没有用到。Huge Pages allocation failed (free: 29431 required: 32457)

Change Processes from 10000 to 18000

Change PGA from 10G to 20G

Change Buffer Cache from 20G to 40G

Change Shared pool from 10G to 20G

HugePage from 60 GB to 120GB 32457个,那么大小就是32457*2M=64914M

转载地址:https://jeanron100.blog.csdn.net/article/details/102506987 如侵犯您的版权,请留言回复原文章的地址,我们会给您删除此文章,给您带来不便请您谅解!

上一篇:一条全表扫描sql语句的分析 (r4笔记第32天)
下一篇:关于地铁让座(r4笔记第27天)

发表评论

最新留言

关注你微信了!
[***.104.42.241]2024年04月29日 21时18分40秒