ITPUB论坛-中国最专业的IT技术社区

 找回密码
 注册
查看: 4999|回复: 33

数据库服务器环境这样配置,存在什么问题?

[复制链接]
论坛徽章:
304
奥迪
日期:2013-07-29 13:45:59红旗
日期:2014-02-07 10:47:20路虎
日期:2014-02-13 10:34:03保时捷
日期:2014-02-14 09:46:462014年新春福章
日期:2014-02-18 16:41:11马上有车
日期:2014-02-18 16:41:11马上有车
日期:2014-02-19 11:55:14马上有房
日期:2014-02-19 11:55:14马上有钱
日期:2014-02-19 11:55:14马上有对象
日期:2014-02-19 11:55:14
发表于 2017-5-2 14:10 | 显示全部楼层 |阅读模式
1  OS: CENTOS7.3,物理内存:128G, SWAP=4G

#uname -a
Linux cloudrac2 3.10.0-514.el7.x86_64 #1 SMP Tue Nov 22 16:42:41 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
[cloudrac2@root ~]
#

2  ORACLE 11204, RAC 双节点

3  数据库参数:MEMORY_TARGET=100G,SGA_MAX_SIZE=70G,JOB_QUEUE_PROCESSES=500,OPEN_CURSOR=900,PROCESSES=900,其他参数默认,非归档模式,
    这样设置,是基于 ORACLE 此前的推荐, 80%给数据库,剩下20%给操作系统,也就是28G给系统使用,100G给数据库使用。
   
现象:28号上午,第一次应用系统测试,正常结束,耗时1小时,

      下午,上述设置未做任何改动,再次测试:进行了大概30分钟左右,
       1  两个节点都报下面的错误:
      
Fri Apr 28 16:18:18 2017
Process J000 died, see its trace file
kkjcre1p: unable to spawn jobq slave process
Errors in file /home/app/11.2.4/diag/rdbms/k3db/k3db2/trace/k3db2_cjq0_28326.trc:
Process J000 died, see its trace file
kkjcre1p: unable to spawn jobq slave process
Errors in file /home/app/11.2.4/diag/rdbms/k3db/k3db2/trace/k3db2_cjq0_28326.trc:
Process J000 died, see its trace file
kkjcre1p: unable to spawn jobq slave process
Errors in file /home/app/11.2.4/diag/rdbms/k3db/k3db2/trace/k3db2_cjq0_28326.trc:
Process J000 died, see its trace file
kkjcre1p: unable to spawn jobq slave process
Errors in file /home/app/11.2.4/diag/rdbms/k3db/k3db2/trace/k3db2_cjq0_28326.trc:
Process J000 died, see its trace file
kkjcre1p: unable to spawn jobq slave process
Errors in file /home/app/11.2.4/diag/rdbms/k3db/k3db2/trace/k3db2_cjq0_28326.trc:
Fri Apr 28 16:18:28 2017
Process J000 died, see its trace file
kkjcre1p: unable to spawn jobq slave process
Errors in file /home/app/11.2.4/diag/rdbms/k3db/k3db2/trace/k3db2_cjq0_28326.trc:
Process J000 died, see its trace file
kkjcre1p: unable to spawn jobq slave process
Errors in file /home/app/11.2.4/diag/rdbms/k3db/k3db2/trace/k3db2_cjq0_28326.trc:
Process J000 died, see its trace file
kkjcre1p: unable to spawn jobq slave process
Errors in file /home/app/11.2.4/diag/rdbms/k3db/k3db2/trace/k3db2_cjq0_28326.trc:
Process J001 died, see its trace file
kkjcre1p: unable to spawn jobq slave process
Errors in file /home/app/11.2.4/diag/rdbms/k3db/k3db2/trace/k3db2_cjq0_28326.trc:
Fri Apr 28 16:18:36 2017
Process PZ99 died, see its trace file
Process J001 died, see its trace file
kkjcre1p: unable to spawn jobq slave process
Errors in file /home/app/11.2.4/diag/rdbms/k3db/k3db2/trace/k3db2_cjq0_28326.trc:


而该文件里的信息为: /home/app/11.2.4/diag/rdbms/k3db/k3db2/trace/k3db2_cjq0_28326.trc

*** 2017-04-28 16:18:10.655
Process J000 is dead (pid=15003 req_ver=388 cur_ver=388 state=KSOSP_SPAWNED).

*** 2017-04-28 16:18:12.655
Process J000 is dead (pid=15012 req_ver=389 cur_ver=389 state=KSOSP_SPAWNED).

*** 2017-04-28 16:18:14.655
Process J000 is dead (pid=15014 req_ver=390 cur_ver=390 state=KSOSP_SPAWNED).

*** 2017-04-28 16:18:16.655
Process J000 is dead (pid=15016 req_ver=391 cur_ver=391 state=KSOSP_SPAWNED).

*** 2017-04-28 16:18:18.655
Process J000 is dead (pid=15043 req_ver=392 cur_ver=392 state=KSOSP_SPAWNED).

*** 2017-04-28 16:18:20.655
Process J000 is dead (pid=15049 req_ver=393 cur_ver=393 state=KSOSP_SPAWNED).

*** 2017-04-28 16:18:22.655
Process J000 is dead (pid=15058 req_ver=394 cur_ver=394 state=KSOSP_SPAWNED).

*** 2017-04-28 16:18:24.655
Process J000 is dead (pid=15061 req_ver=395 cur_ver=395 state=KSOSP_SPAWNED).

*** 2017-04-28 16:18:26.655
Process J000 is dead (pid=15063 req_ver=396 cur_ver=396 state=KSOSP_SPAWNED).

*** 2017-04-28 16:18:28.655
Process J000 is dead (pid=15135 req_ver=168 cur_ver=168 state=KSOSP_SPAWNED).

*** 2017-04-28 16:18:30.655
Process J000 is dead (pid=15142 req_ver=169 cur_ver=169 state=KSOSP_SPAWNED).

此外,再没找到任何与这个错误相关的数据信息,
      

此外,此时, 两节点看到的 FREE -M 信息:
      
#free -m
              total        used        free      shared  buff/cache   available
Mem:         128650        4303       74421       49195       49925       66738
Swap:          4095           0        4095
[cloudrac1@root ~]
#      
      
      2  同时,节点2实例似乎宕机,报:
     
$sqlplus / as sysdba

SQL*Plus: Release 11.2.0.4.0 Production on Fri Apr 28 13:57:52 2017

Copyright (c) 1982, 2013, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
Data Mining and Real Application Testing options

SYS@k3db2>select * from gv$resource_limit where resource_name='processes' order by 2,1;    这是正常情况,

   INST_ID RESOURCE_NAME             CURRENT_UTILIZATION MAX_UTILIZATION INITIAL_ALLOCATION                    LIMIT_VALUE
---------- ------------------------------ ------------------- --------------- ---------------------------------------- ----------------------------------------
          1 processes                                             84             101               900                                         900
          2 processes                                             81              99       900                                         900

Elapsed: 00:00:00.01
SYS@k3db2>/

   INST_ID RESOURCE_NAME             CURRENT_UTILIZATION MAX_UTILIZATION INITIAL_ALLOCATION                    LIMIT_VALUE
---------- ------------------------------ ------------------- --------------- ---------------------------------------- ----------------------------------------
          2 processes                                             50             106               900                                         900  

Elapsed: 00:00:02.20
SYS@k3db2>/
select * from gv$resource_limit where resource_name='processes' order by 2,1   -- 出故障后,
*
ERROR at line 1:
ORA-12850: Could not allocate slaves on all specified instances: 2 needed, 1 allocated


Elapsed: 00:00:06.45
SYS@k3db2>/
select * from gv$resource_limit where resource_name='processes' order by 2,1
*
ERROR at line 1:
ORA-12850: Could not allocate slaves on all specified instances: 2 needed, 1 allocated


Elapsed: 00:00:07.54
SYS@k3db2>


[cloudrac2@oracle ~]
$sqlplus / as sysdba

SQL*Plus: Release 11.2.0.4.0 Production on Fri Apr 28 16:53:14 2017

Copyright (c) 1982, 2013, Oracle.  All rights reserved.

Connected to an idle instance.   -实例2宕机了,

SYS@k3db2>exit
Disconnected
[cloudrac2@oracle ~]
$srvctl status database -d k3db
Instance k3db1 is running on node cloudrac1
Instance k3db2 is running on node cloudrac2  --这里显示实例2是正常的,
[cloudrac2@oracle ~]
$sqlplus / as sysdba

SQL*Plus: Release 11.2.0.4.0 Production on Fri Apr 28 16:53:38 2017

Copyright (c) 1982, 2013, Oracle.  All rights reserved.

Connected to an idle instance.

SYS@k3db2>select * from gv$resource_limit where resource_name='processes' order by 2,1;
select * from gv$resource_limit where resource_name='processes' order by 2,1
*
ERROR at line 1:
ORA-01034: ORACLE not available    -- 节点2的实例挂掉了,
Process ID: 0
Session ID: 0 Serial number: 0


Elapsed: 00:00:00.00
SYS@k3db2>exit
Disconnected
[cloudrac2@oracle ~]
$srvctl status database -d k3db
Instance k3db1 is running on node cloudrac1  
Instance k3db2 is running on node cloudrac2    -- 似乎实例2是好的,
[cloudrac2@oracle ~]



3  启动实例2时,报:无法分配内存,应该是 FREE -M 中  BUFFER/CACHE 占用了49G 内存后,启动时无法达成 MEMORY_TARGET=100G,而报的错误,

4  后,几次用 crsctl stop crs 无法停止集群,最后好像是用 crsctl stop cluster 反复执行才关闭的集群,

5  我怀疑是 MEMORY_TARGET=100G,占用了太多的物理内存,数据库在开辟新进程时,没有物理内存导致,但没有证据证明这个观点,且新进程为何不使用 PGA ?

论坛徽章:
115
现任管理团队成员
日期:2011-05-07 01:45:08
发表于 2017-5-2 17:33 | 显示全部楼层
不应该~ 如果没有启用大页内存的话,启动数据库不会直接使用sga_max_size的内存,仅仅是划分内存地址,并不填充内存也~
你使用了memory_target所以肯定不是大页内存~

但是!你应该看看/dev/shm的大小,因为memory_target的内存(pga+sga)其实是在这个虚拟文件系统中分配的!

如果 /dev/shm 比100GB小,很有可能出现这个问题~

使用道具 举报

回复
论坛徽章:
115
现任管理团队成员
日期:2011-05-07 01:45:08
发表于 2017-5-2 17:39 | 显示全部楼层
我不知道 Redhat 7,但是Redhat6上,默认只有50%的内存被划分到 /dev/shm中,你的机器只有128GB内存,所以默认/dev/shm只有64GB,所以如果你不修改这个文件系统大小,直接使用memory_target=100GB,那么当/dev/shm 64GB被用光后,肯定会出先内存不足,无法spanwd进程的错误~

如果进程是关键进程,很有可能报错ORA-600导致实例crash

使用道具 举报

回复
论坛徽章:
115
现任管理团队成员
日期:2011-05-07 01:45:08
发表于 2017-5-2 17:40 | 显示全部楼层
将 /dev/shm调大不会浪费内存,因为这个文件系统是动态使用内存的,就算你设置为128GB,里面没有产生文件(pga和sga对应的一大堆文件),也不会真正使用内存页的~

使用道具 举报

回复
论坛徽章:
304
奥迪
日期:2013-07-29 13:45:59红旗
日期:2014-02-07 10:47:20路虎
日期:2014-02-13 10:34:03保时捷
日期:2014-02-14 09:46:462014年新春福章
日期:2014-02-18 16:41:11马上有车
日期:2014-02-18 16:41:11马上有车
日期:2014-02-19 11:55:14马上有房
日期:2014-02-19 11:55:14马上有钱
日期:2014-02-19 11:55:14马上有对象
日期:2014-02-19 11:55:14
 楼主| 发表于 2017-5-2 18:00 | 显示全部楼层
zergduan 发表于 2017-5-2 17:33
不应该~ 如果没有启用大页内存的话,启动数据库不会直接使用sga_max_size的内存,仅仅是划分内存地址,并不 ...

这个值 /DEV/SHM 是128G,

[cloudrac1@root ~]
#df -h
Filesystem                     Size  Used Avail Use% Mounted on
/dev/mapper/cl_cloudrac1-root   50G  6.1G   44G  13% /
devtmpfs                        63G     0   63G   0% /dev
tmpfs                          128G  332M  128G   1% /dev/shm
tmpfs                           63G   26M   63G   1% /run
tmpfs                           63G     0   63G   0% /sys/fs/cgroup
/dev/sda2                     1014M  165M  850M  17% /boot
/dev/sda1                      200M  9.5M  191M   5% /boot/efi
/dev/mapper/cl_cloudrac1-home  503G   42G  462G   9% /home
tmpfs                           13G   16K   13G   1% /run/user/42
tmpfs                           13G     0   13G   0% /run/user/0
[cloudrac1@root ~]
#

使用道具 举报

回复
论坛徽章:
179
红宝石
日期:2014-05-09 08:24:37萤石
日期:2014-01-03 10:25:39马上有车
日期:2014-02-18 16:41:11马上有钱
日期:2014-11-24 15:17:08马上有钱
日期:2014-11-12 09:33:24马上有房
日期:2014-11-07 08:46:05马上有钱
日期:2014-10-27 09:26:57马上有对象
日期:2014-10-28 10:28:08itpub13周年纪念徽章
日期:2014-10-10 10:38:25马上有对象
日期:2015-01-14 17:33:15
发表于 2017-5-3 11:37 | 显示全部楼层
改成hupages就ok了,这样大内存,分配页面表消耗巨大.

你会话能达到多少,每个使用页面表5M, 800*5=4G.应用每个5M/(也许更多)又是4G.而且你好像许多以job来运行.
cat /proc/meminfo看看.PageTables:占多少.

使用道具 举报

回复
论坛徽章:
115
现任管理团队成员
日期:2011-05-07 01:45:08
发表于 2017-5-3 13:38 | 显示全部楼层
ZALBB 发表于 2017-5-2 18:00
这个值 /DEV/SHM 是128G,

[cloudrac1@root ~]

晕~

使用道具 举报

回复
论坛徽章:
115
现任管理团队成员
日期:2011-05-07 01:45:08
发表于 2017-5-3 13:41 | 显示全部楼层
lfree 发表于 2017-5-3 11:37
改成hupages就ok了,这样大内存,分配页面表消耗巨大.

你会话能达到多少,每个使用页面表5M, 800*5=4G.应用 ...

他使用了memory_target 没法用大页内存,并且他提到了:
3  启动实例2时,报:无法分配内存
理论上来说,实例启动时并不会有大量进程,此时pagetables应该不会很大的呀?

另外有一个问题,swap=4gb是不是太小了,按照oracle官方文档的内容,这么大的内存swap空间应该设置为32GB,当然这个配置问题未必和现在的现象有关~

使用道具 举报

回复
论坛徽章:
304
奥迪
日期:2013-07-29 13:45:59红旗
日期:2014-02-07 10:47:20路虎
日期:2014-02-13 10:34:03保时捷
日期:2014-02-14 09:46:462014年新春福章
日期:2014-02-18 16:41:11马上有车
日期:2014-02-18 16:41:11马上有车
日期:2014-02-19 11:55:14马上有房
日期:2014-02-19 11:55:14马上有钱
日期:2014-02-19 11:55:14马上有对象
日期:2014-02-19 11:55:14
 楼主| 发表于 2017-5-3 13:52 | 显示全部楼层
lfree 发表于 2017-5-3 11:37
改成hupages就ok了,这样大内存,分配页面表消耗巨大.

你会话能达到多少,每个使用页面表5M, 800*5=4G.应用 ...

我也怀疑是这个原因,但看了下,不启用hugepages 时的,128G的物理内存,页面表的消耗,最多也就1.5G,而测试启动的进程数,大概也就120个不到,感觉不应该是这个原因,

最大的疑点,第二次测试报错后,发现:buffer/cache = 49g,,,我登录数据库时,看到连接上去的是空实例,想启动实例,报无法分配内存,,,但实际 srvctl status database -d xxx 报两实例正在运行,并没关闭,

使用道具 举报

回复
论坛徽章:
304
奥迪
日期:2013-07-29 13:45:59红旗
日期:2014-02-07 10:47:20路虎
日期:2014-02-13 10:34:03保时捷
日期:2014-02-14 09:46:462014年新春福章
日期:2014-02-18 16:41:11马上有车
日期:2014-02-18 16:41:11马上有车
日期:2014-02-19 11:55:14马上有房
日期:2014-02-19 11:55:14马上有钱
日期:2014-02-19 11:55:14马上有对象
日期:2014-02-19 11:55:14
 楼主| 发表于 2017-5-3 13:54 | 显示全部楼层
lfree 发表于 2017-5-3 11:37
改成hupages就ok了,这样大内存,分配页面表消耗巨大.

你会话能达到多少,每个使用页面表5M, 800*5=4G.应用 ...

现在改成 HUGEPAGES,已经测试了4遍,都很正常,但得找到出,使用 memory_target 时为何会出错?

使用道具 举报

回复

您需要登录后才可以回帖 登录 | 注册

本版积分规则

SACC2017购票7.8折优惠进行时

2017中国系统架构师大会(SACC2017)将于10月19-21日在北京新云南皇冠假日酒店震撼来袭。今年,大会以“云智未来”为主题,云集国内外顶级专家,围绕云计算、人工智能、大数据、移动互联网、产业应用等热点领域展开技术探讨与交流。本届大会共设置2大主会场,18个技术专场;邀请来自互联网、金融、制造业、电商等多个领域,100余位技术专家及行业领袖来分享他们的经验;并将吸引4000+人次的系统运维、架构师及IT决策人士参会,为他们提供最具价值的交流平台。
----------------------------------------
优惠时间:2017年8月30日前

活动链接>>
TOP技术积分榜 社区积分榜 徽章 电子杂志 团队 统计 虎吧 老博客 知识索引树 读书频道 积分竞拍 文本模式 帮助
  ITPUB首页 | ITPUB论坛 | 数据库技术 | 企业信息化 | 开发技术 | 微软技术 | 软件工程与项目管理 | IBM技术园地 | 行业纵向讨论 | IT招聘 | IT文档 | IT博客
  ChinaUnix | ChinaUnix博客 | ChinaUnix论坛 | SAP ERP系统
CopyRight 1999-2011 itpub.net All Right Reserved. 北京皓辰网域网络信息技术有限公司版权所有 联系我们 网站律师 隐私政策 知识产权声明
京ICP证:060528号 北京市公安局海淀分局网监中心备案编号:1101082001 广播电视节目制作经营许可证:编号(京)字第1149号
  
快速回复 返回顶部 返回列表