免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
123下一页
最近访问板块 发新帖
查看: 18721 | 回复: 23

[系统管理] CPU load多少是一个合适的范围? [复制链接]

论坛徽章:
0
发表于 2013-11-29 13:45 |显示全部楼层
各位大神好,

小弟碰到一棘手的问题。

我们到产品环境,是一个集群20台blade机器,用的是Sun Grid Engine (也称 OGE)。目前每天晚上有很多任务在每一个blade上运行。每台blade上是24个逻辑cpu。其中一个信息如下:
analyzing CPU 23:
  driver: pcc-cpufreq
  CPUs which need to switch frequency at the same time: 23
  hardware limits: 1.60 GHz - 2.80 GHz
  available cpufreq governors: conservative, userspace, powersave, ondemand, pee
  current policy: frequency should be within 1.60 GHz and 2.80 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 2.80 GHz.

我们到应用在blade上,同时需要访问local的MySQL。MySQL里存的是一些binary压缩数据,每次访问后,均需要解压。发现CPU load高的时候,解压花很长时间。平时大约1秒钟到活,可能要花3分钟左右。

过去都一直很好,最近每天早上6点后突然变得很慢。1分钟平均 Load达到 15-22 之多。此时大约只有10个到14个我们的应用程序在运行。

查过OS的patch最近没有变化,网络部分没有变化,似乎OS的其他问题也都正常。

各位大侠有什么方向指导一下吗?简直现在没有一点方向了,压力山大啊!

叩谢!!!

Edge

论坛徽章:
48
15-16赛季CBA联赛之青岛
日期:2021-01-07 13:41:2315-16赛季CBA联赛之上海
日期:2020-12-01 18:02:0720周年集字徽章-20	
日期:2020-10-28 14:14:2620周年集字徽章-20	
日期:2020-10-28 14:04:3015-16赛季CBA联赛之天津
日期:2020-10-18 22:51:412016猴年福章徽章
日期:2016-02-18 15:30:3415-16赛季CBA联赛之北控
日期:2015-12-22 13:30:48操作系统版块每日发帖之星
日期:2015-12-07 06:20:00操作系统版块每日发帖之星
日期:2015-09-04 06:20:002015亚冠之德黑兰石油
日期:2015-08-05 18:46:082015年亚洲杯之巴勒斯坦
日期:2015-04-19 10:42:502015年亚洲杯之巴林
日期:2015-04-09 08:03:23
发表于 2013-11-29 13:59 |显示全部楼层
看看是否解压的数量增加了?从你的描述来看,就是说访问是否比以前增加了?一般来说,解压占用的CPU资源比较多~

论坛徽章:
15
2015年辞旧岁徽章
日期:2015-03-03 16:54:15双鱼座
日期:2015-01-15 17:29:44午马
日期:2015-01-06 17:06:51子鼠
日期:2014-11-24 10:11:13寅虎
日期:2014-08-18 07:10:55酉鸡
日期:2014-04-02 12:24:51双子座
日期:2014-04-02 12:19:44天秤座
日期:2014-03-17 11:43:36亥猪
日期:2014-03-13 08:13:51未羊
日期:2014-03-11 12:42:03白羊座
日期:2013-11-20 10:15:18CU大牛徽章
日期:2013-04-17 11:48:45
发表于 2013-11-29 14:47 |显示全部楼层
本帖最后由 rdcwayx 于 2013-11-29 14:49 编辑

CPU load和CPU 数有关。 比如一个CPU, 那么1 就正好,超过2 就说明有队列在等候。你的刀片服务器有24个虚拟CPU, 那么不超过24 都还可以的。

论坛徽章:
33
荣誉会员
日期:2011-11-23 16:44:17天秤座
日期:2014-08-26 16:18:20天秤座
日期:2014-08-29 10:12:18丑牛
日期:2014-08-29 16:06:45丑牛
日期:2014-09-03 10:28:58射手座
日期:2014-09-03 16:01:17寅虎
日期:2014-09-11 14:24:21天蝎座
日期:2014-09-17 08:33:55IT运维版块每日发帖之星
日期:2016-04-17 06:23:27操作系统版块每日发帖之星
日期:2016-04-18 06:20:00IT运维版块每日发帖之星
日期:2016-04-24 06:20:0015-16赛季CBA联赛之天津
日期:2016-05-06 12:46:59
发表于 2013-11-29 16:01 |显示全部楼层
楼主的问题要分开来看.

单从 load 来说, 上面的兄弟的建议就可以了. load值跟CPU相当就好.

但其实, load不是真正的问题所在. 如果你所有的进程都是在等IO, 那再高的laod, 也不一定影响到一个只进行计算的进程/线程.

个人以为, 你的问题不是 load值到底有多高. 而在于为啥要把 binfile 存进mysql, 而且还是压缩的. 我觉得这是个非常不科学的做法.

binfile, 一般都是不可检索的. 所以, 存进mysql和存在本地硬盘上, 在本质上没有区别是. 而且, 直接存在硬盘上, 可能 io次数还少些.
都已经用到了 SGE 了, 我想数据量一定不小, 这时候还用数据库, 未必是个明智的做法.

论坛徽章:
0
发表于 2013-11-29 21:56 |显示全部楼层
谢谢大家的建议。

很有些奇怪的是:我做过一次测试,但执行12个任务的时候,似乎速度还可以,load大概是2左右,一旦多于12个任务,load一下就涨到15以上,而且所有的任务都变得很慢。但奇怪的是,这个有时不能完全重现。

的确,我们的数据量不小,所有数据计算处理大约需要6-8小时。为什么把binary存入数据库,这是一个以往的design。那些binary数据大多是一些前面任务处理生成的object或一些binary供后面的程序共用的。压缩只是因为空间有限,就是这样了,每天整个数据库大约有200G的数据。

目前,速度慢,直接严重影响了报表的及时生成,其他相关部门抱怨很多。但自己无从下手,压力很大。

论坛徽章:
15
2015年辞旧岁徽章
日期:2015-03-03 16:54:15双鱼座
日期:2015-01-15 17:29:44午马
日期:2015-01-06 17:06:51子鼠
日期:2014-11-24 10:11:13寅虎
日期:2014-08-18 07:10:55酉鸡
日期:2014-04-02 12:24:51双子座
日期:2014-04-02 12:19:44天秤座
日期:2014-03-17 11:43:36亥猪
日期:2014-03-13 08:13:51未羊
日期:2014-03-11 12:42:03白羊座
日期:2013-11-20 10:15:18CU大牛徽章
日期:2013-04-17 11:48:45
发表于 2013-12-02 09:47 |显示全部楼层
如果每天早上六点的话,该不会是定时的备份任务吧。

你自己再查一下,有什么程序是每天6点这个时候运行的。

论坛徽章:
223
2022北京冬奥会纪念版徽章
日期:2015-08-10 16:30:32操作系统版块每日发帖之星
日期:2016-05-10 19:22:58操作系统版块每日发帖之星
日期:2016-02-18 06:20:00操作系统版块每日发帖之星
日期:2016-03-01 06:20:00操作系统版块每日发帖之星
日期:2016-03-02 06:20:0015-16赛季CBA联赛之上海
日期:2019-09-20 12:29:3219周年集字徽章-周
日期:2019-10-01 20:47:4815-16赛季CBA联赛之八一
日期:2020-10-23 18:30:5320周年集字徽章-20	
日期:2020-10-28 14:14:2615-16赛季CBA联赛之广夏
日期:2023-02-25 16:26:26CU十四周年纪念徽章
日期:2023-04-13 12:23:10操作系统版块每日发帖之星
日期:2016-05-10 19:22:58
发表于 2013-12-02 09:51 |显示全部楼层
这个cpu load是怎么看的啊???

论坛徽章:
15
2015年辞旧岁徽章
日期:2015-03-03 16:54:15双鱼座
日期:2015-01-15 17:29:44午马
日期:2015-01-06 17:06:51子鼠
日期:2014-11-24 10:11:13寅虎
日期:2014-08-18 07:10:55酉鸡
日期:2014-04-02 12:24:51双子座
日期:2014-04-02 12:19:44天秤座
日期:2014-03-17 11:43:36亥猪
日期:2014-03-13 08:13:51未羊
日期:2014-03-11 12:42:03白羊座
日期:2013-11-20 10:15:18CU大牛徽章
日期:2013-04-17 11:48:45
发表于 2013-12-02 10:35 |显示全部楼层
最简单的是用top。

论坛徽章:
16
IT运维版块每日发帖之星
日期:2015-10-02 06:20:00IT运维版块每月发帖之星
日期:2015-09-11 19:30:52IT运维版块每周发帖之星
日期:2015-09-11 19:20:31IT运维版块每日发帖之星
日期:2015-08-26 06:20:00每日论坛发贴之星
日期:2015-08-20 06:20:00IT运维版块每日发帖之星
日期:2015-08-20 06:20:002015年辞旧岁徽章
日期:2015-03-03 16:54:15金牛座
日期:2014-05-04 16:58:09双子座
日期:2013-12-17 16:44:37辰龙
日期:2013-11-22 15:20:59狮子座
日期:2013-11-18 22:55:08射手座
日期:2013-11-12 10:54:26
发表于 2013-12-03 06:41 |显示全部楼层
uptime,w也可以

论坛徽章:
0
发表于 2013-12-04 10:23 |显示全部楼层
确定只是我们自己的应用程序。其他备份大约发生在半夜12点左右。

因为实在没有办法了,昨晚重启了几台blade,今天似乎工作正常。至少没有发生这个问题。所有的机器有450天左右没有重启了。难道是操作系统的问题???那为什么其他job不慢?而且每天出现在不同的blade呢???

不过现在不能十分确定,重启是解决问题的方法。

回复 6# rdcwayx


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

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP