2014年3月8日星期六

[]Oracle数据库如何授权收费(Database Licensing)

本文自动转发自我的博客: http://www.haofengjing.org/2437.html

PS:Oracle Database在几个月前发布12c 最新版本,基于云计算的旗舰产品,称之为"第一个为云而设计的数据库"。有部分项目数据库使用的是Oracle,有时也被同事询问oracle的收费模式,下面把oracle的授权收费模式简要说明一下。

Oracle软件本身是免费的,所以任何人都可以从Oracle官方网站下载并安装Oracle的数据库软件,收费的是License,即软件授权,如果数据库用于商业用途,就需要购买相应Oracle产品的License。

现在Oracle有两种授权方式,按CPU(Process)数和按用户数(Named User Plus)。前一种方式一般用于用户数不确定或者用户数量很大的情况,典型的如互联网环境,而后一种则通常被用于用户数确定或者较少的情况。

按CPU: License数=CPU 数*系数。系数来自Oracle的一个参数表,如IBM Power6的处理器为1,AMD和Intel的处理器为0.5,详细情况见下:

参数 处理器型号
0.25 Sun UltraSPARC T1 处理器
0.50 Sun UltraSPARC T1处理器
0.50 Intel、AMD处理器
0.50 Sun UltraSPARC T2+ 处理器
1.00 IBM POWER6、POWER7 处理器
0.75 其他多核处理器
1.00 单核处理器

则根据公式可以算出,一个SUN UltraSparc T1的4*8核处理器需要4*8*0.25=8个CPU licenses

按用户数:Oracle用户数的官方定义是每一个访问Oracle数据库的用户,无论是自然人还是设备(如工业环境中的传感器之类),都算作一个用户(Named User)。

英文官方定义:Named User Plus: is defined as an individual authorized by you to use the programs which are installed on a single server or multiple servers, regardless of whether the individual is actively using the programs at any given time. A non human operated device will be counted.

按用户数购买则对应相应的产品有对应的License的最低购买量限制,如下:

产品 最低License数
Oracle Database Standard Edition ONE 5 Named User Plus licenses
Oracle Database Standard Edition 5 Named User Plus licenses
Oracle Database Enterprise Edition 25 Named User Plus licenses per CPU
Oracle Application Server Standard Edition ONE 5 Named User Plus licenses
All other Oracle Application Server products 10 Named User Plus licenses per CPU

当然用户应该根据自己的实际用户数订购,且不少于相应版本所要求的最低用户数。

一般情况下,1CPU的费用约等于50user的费用,所以如果用户数>CPU数*系数*50,则按CPU订购反而更为经济。

每个License还有有效期的分类[不论是User License还是CPU License],分别为:1年、2年、3年、4年、5年、永久。当然价格也是依次增加。

当前Oracle 11G的User License无限使用期的价格为人民币3千5左右,按50个User License无限使用期的购买量则价格为17.5万;每个CPU License无限使用期的价格为17万9千,按IBM小机的系数计算,则购买价格为17万9千,和50个User License的价格相近。

关于服务价格:一般地,购买Oracle的License都包含首年的服务费,以后的费用按每年原价的22%计算。

更多的产品价格可以访问 http://shop.oracle.com 查看。

参考资料:

Oracle Licensing:http://www.orafaq.com/wiki/Oracle_Licensing

Oracle Technology Global Price List:http://www.oracle.com/us/corporate/pricing/technology-price-list-070617.pdf

Oracle Price Lists:http://www.oracle.com/us/corporate/pricing/price-lists/index.html

Oracle Support:http://www.orafaq.com/wiki/Oracle_Support


[]服务框架演变过程 -- 系统架构 -- IT技术博客大学习 -- 共学习 共进步!

本文自动转发自我的博客: http://www.haofengjing.org/2415.html

  我们的服务框架已经持续做了三年了,在厂内广泛的使用,目前部署在服务框架上的服务为2k+,每天经过服务框架的服务执行次数为120亿+,摸高到150亿+,三年的发展并非一帆风顺,由于经验的原因,还是摔了不少跤的,在这篇blog中,来给大家分享下,希望能够给要做服务框架或服务化的同学带来一些帮助,少走一些弯路,不一定要一开始就做成完整的服务框架,但至少先做好铺垫,避免在广泛使用后再来挽救。

    我们的服务框架主要由四个部分的功能组成:

    1、标准的服务的交互方式

    2、高性能网络通信

    3、软件负载均衡

    4、服务治理

    这四个部分都经历了一些演变,才形成了最后的结构,尤其是服务治理这块,在各种SOA的文章中,都会说到服务治理这块,但基本都不会说服务治理到底要做什么,我们是在经历过很多后,终于让服务治理这块由一堆实际的功能组成,下面分别来看看以上这四块的演变过程。

    标准的服务的交互方式

    在服务框架的第一个版本中,最早我们希望对应用完全不侵入,做到应用不需要依赖服务框架的任何包,也不需要在应用里面定义服务,因此策略是在应用的外部写一个xml文件,用来描述对外提供的服务,或者要调用的服务,这个版本提供给应用方使用后,发现使用起来非常复杂,因为这个xml文件和应用是不在一起的,一方面不知道该放在代码仓库的什么地方;另一方面对于部署维护而言也是非常的麻烦。

    于是决定改进这块,厂内应用基本都是基于spring的,因此还是决定提供一个类来方便直接在spring bean的xml中发布服务和配置调用服务的代理bean,在这样的机制下发布服务和调用服务的配置大致就如下了:

<bean class="发布服务的类" or class="调用服务的proxy类">

    在改造成这种方式后,应用方使用起来就比较透明和方便了,并且也只是在运行时对服务框架会产生依赖,后来也就基本没变过了,兄弟厂有改造成这样的方式的,用起来更简单一点,不过需要加schema,所以我们这边还是没去这么做。

    在服务的定义上碰到的主要需求是最早我们只支持一种通信协议以及只支持接口级的超时配置,后续随着需求调整了一次服务的定义,增加了方法级超时的配置以及通信协议的配置。

    高性能网络通信

    在第一个版本中,我们选择了基于JBoss Remoting来实现,在最初一个访问量不大的应用中上线时表现挺正常的,可惜的是在后面一个访问量较大的应用上线后出现了问题,最后查证原因主要是出在了超时设置上,当时采用了默认的60秒超时,刚好当时提供服务的应用出现了处理慢的现象,导致前端的web应用被拖的支撑不住,而在当时的JBoss Remoting版本中,其实这个超时设置是有bug的,因此如果要修复就必须直接修改JBoss Remoting的代码。

    另外一个问题是JBoss Remoting的连接池方式,在通过硬件负载设备访问提供服务的集群的情况下,一旦重启,会很容易出现连接严重不均衡的现象。

    鉴于上面的现象,觉得还是自己掌握整个通信过程比较靠谱,于是选择了基于Mina来实现整个网络通信,自行实现异步转同步、超时、连接管理,连接的使用采用了每目标地址单个连接的方式,这样一方面是可以避免连接池造成的连接不均衡的问题,另一方面也避免调用端建立太多连接,导致服务提供者连接会不够用,伸缩性差的问题,另外,由于都是内网的请求,因此采用长连接方式。

    基本上一直以来都没对上面的网络通信机制做过调整,不过单连接在序列化/反序列化对象消耗时间较长时,会影响到其他的请求或响应,这个一方面是由于Mina的实现机制,另一方面是要结合应用场景来做适当的处理。

    在序列化上我们支持了默认的Java和Hessian两种,但杯具的是当时的Hessian版本较老,并且Hessian新版本与旧版本的兼容做的很差,导致后来我们一直很难升级Hessian的版本。

    在网络通信上,我们经历过的教训主要是最早的通信协议上没带版本号,导致升级时的兼容性比较难处理;还有就是在设计之初我们是不考虑用于跨语言场景的,但后面跨语言的场景出现了,于是就很被动了;还有一点是如果发送的对象过大或过多造成内存不够的现象,最早的时候没做限制。

    软件负载均衡

    在最初的几个版本中,我们都是通过硬件负载设备来访问服务提供者集群的,但有一次出现过硬件负载设备出故障的现象,导致应用出现故障,但又没办法修复,只能等待硬件负载设备问题的解决,在这种情况下,我们觉得随着服务越来越多,请求量越来越大,中间的硬件负载设备很容易成为最大的风险,于是决定自己做软件负载均衡。

    我们对于软件负载均衡最重要的一点要求是,当服务调用者调用服务时,是直接和服务提供者交互的,不需要通过任何中间的机器,当时考察了下现有的,觉得只能自己做了,于是我们就基于这个要求实现了自己的软件负载均衡,不过我们实现软件负载均衡的方法随着机器数越来越多,也碰到了不少的挑战,由于这个涉及实现机制,就不在这里细说了。

    最早在选址上我们仅支持随机选择,但由于集群中会出现机器配置相差比较远的现象,因此决定加入权重的支持,以便分配不同的流量。

    一个应用通常会对外提供多种不同功能的服务,这些服务对资源的消耗以及对整体系统的重要性是不一样的,而服务框架对于所有服务的执行都是放在同一线程池中的,因此会出现某些不重要又耗资源或执行慢的服务把线程池占满,导致重要的服务无法执行的现象,对于这种现象,我们提供了两种方案来进行解决:一是分线程池,二是按接口将集群再进行划分。

    分线程池的方法有些时候仍然是不够的,例如耗资源或执行慢的服务有可能同时把共享的资源消耗完了,那这个时候即使分线程池也仍然会导致重要的服务出问题的现象。

    按接口将集群再进行划分的好处就很明显了,在不改变代码结构的基础上,在软件负载均衡上实现按接口的路由即可,于是我们实现了这个机制。

    随着按接口路由实现后,又碰到了一个接口中不同的方法的重要性、执行速度以及消耗资源不同的问题,于是相继我们又支持了按方法以及按参数的路由,这个时候我们的不经过中间节点调用的软件负载均衡机制发挥出了巨大的优势,如果是硬件负载设备,一方面是没办法做到这样的7层路由,另一方面硬件负载设备一旦开启7层路由,性能下降会非常明显,而在我们的软件负载均衡实现机制下,则完全不会有这样的问题。

    服务治理

    最早的时候,我们压根就不知道服务治理到底该做些什么,基本都是随着使用者的增多才逐渐形成的。

    由于在调用服务时,不需要配置调用服务的目标地址,有些时候出错了,连调的是哪台服务器出现的错误都不知道,因此在初期的时候经常有使用者会来问,调的服务到底是哪台机器呢,于是一方面我们是在执行出错的日志里增加了调用的目标地址的说明,另一方面就是做了一个简单的系统,用于查询服务的调用者和提供者在什么机器上。

    当功能需要由调用服务来完成时,排错成为了大问题,在这个问题上我们现在还是支持的不够,现在的查错仍然是人肉较多,并且要判断问题出在哪里会比较复杂,尤其是出现A -> B服务 -> C服务这种时候。

    随着服务越来越多,当服务由于某些原因要废弃方法或做重大改造时,需要通知相关的服务提供者,以便做相应的调整和测试等,但最早服务框架在这方面没提供什么支持,因此服务的提供者只能通过邮件来进行调查,但这样非常容易出现遗漏等,出现过好几次问题,于是开始做服务的依赖关系分析。

    除了上面升级产生的问题外,还有一个问题是依赖的关系越来越复杂,导致系统的稳定性很差,因此需要管理起依赖,也就是最好服务的调用需要授权,这个也是服务框架初期的版本中没有考虑到的,于是只能进行改造来提供支持。

    使用服务框架的应用越来越多,开始出现了使用到的服务框架多个版本的现象,而最开始我们没有办法知道有哪些版本在使用,这种情况的杯具就是当我们发现某个版本出现致命bug时,根本不知道该通知谁升级,另外在解决问题的时候也非常麻烦。

    在软件负载均衡实现上,我们支持了按接口、方法和参数对集群进行划分,这个时候就造成了在加减机器的时候必须明确的知道是要操作哪部分的机器,这块如果支持不够就会造成机器的维护非常麻烦,这还是我们在继续努力的一块。

    在系统出现问题时,有些时候查找和修复需要花费较长的时间,因此如果能够通过路由的调整来隔离故障,那么对于系统的稳定性可以带来很大的帮助,于是我们实现了服务的降级,可以在运行时屏蔽某些调用者对于某些服务的某些方法的调用。

    在这样的情况下,形成了我们目前的服务治理:服务信息查询、依赖分析和管理、服务调用/执行报表、服务框架版本分布、服务路由调整以及服务降级,但即使是这样,也仍然是不够的,还需继续努力。

    从上面四个大方面的演变过程可以看到,大多时候是因为需求的推动发展,并且可以看到有些事情,由于一开始没做,导致了后面花了非常大的精力去挽救,因此如果能再来一次的话,我觉得可以在一开始就设计的更为周到,但不是说一开始要做的多完整,而是要埋好伏笔,避免后面不断的调整系统的设计,也希望上面这些演进过程的分享可以让你至少少走一次弯路,那我就觉得很开心了。

    bonus:

    除了上面围绕这四大块的演变外,在服务框架的整个发展过程中,我们还有一些其他的教训:

    1、服务的上线和下线

     其实很多情况下,我们是希望应用在更新前先下线服务,避免出现一些事务等问题,而在上线时最好是能做到逐步放入流量,这样可以让应用完成热身后再来接受大的请求量,避免出现应用还没进入状态时请求量大造成无法支撑的现象。

    2、外部定制化支持不够

     例如如果应用想介入调用过程或执行过程,做下特殊处理时,我们暂时是不支持的。

    3、日志打爆

     例如当应用出现问题时,我们没有对错误的日志做限制,导致有些时候会把最后一根救命稻草给砍断,后来我们才增加了日志输出时的流量控制。


[]数据挖掘+人工智能,教育定制化下的学霸量产-CSDN.NET

本文自动转发自我的博客: http://www.haofengjing.org/2410.html
摘要:学校从商业发展中得到启示,利用大数据可以改善教学方法,帮助学校聘用更好的老师,帮助政府更有效地使用教育资金。将人工智能应用到学习过程中,将数据挖掘应用到教育改革中,未来的学生会更加成功。

【编者按】大数据将给现在的教育体制带来变革,用数据分析找出教学过程中的问题,完善教学方法,让学生接受自适应学习,培养终生学习的能力。大数据可以用来聘用优秀教师,合理配置教育资源,减少宝贵教育资源的浪费,大数据还可以用来为学生未来的事业发展提供帮助……有大数据,一切皆有可能,作家Gail Dutton为我们带来了精彩分析。


CSDN推荐:欢迎免费订阅《Hadoop与大数据周刊》获取更多Hadoop技术文献、大数据技术分析、企业实战经验,生态圈发展趋势。

以下为译文:

大数据已经应用到课堂上了,比如:创建自适应学习课程,指导学生通过更有效的方式取得成功,而有些应用则针对管理人员和学校,这些数据应用帮助校长和老师有效地提高教学水平、跟踪教学状态的变化趋势,而且大数据应用到大学后,对学生未来事业会有更加直接的帮助。用一句话说就是:大数据给现在的教育体制带来了变革。

自适应学习

这是从小学到大学整个教育体制的再造,McGraw-Hill教育正在开发数字课程,准备相关的课程资料,它从200万学生中收集信息,利用人工智能为每个学生创建自适应的学习体验。当一个学生阅读材料并回答问题时,系统会根据学生对知识的掌握情况给出相关资料。系统知道应该考学生什么问题,什么样的方式学生更容易接受。系统还会在尽可能长的时间内保留学生信息,以便未来能给学生带来更多的帮助。

Stephen Laster是McGraw-Hill教育的首席数字官(CDO,chief digital officer),他说:"我们把学习看作对目标建立映射的过程,学习的方法不会只有一种。"

自适应学习学习的既不是简单的符号或文字,也不是言语或文字陈述的概念或原理,而是chief digital officer一些具体的实例或问题,学习者的任务是通过考察实例和解决问题,从中发现有关的知识和解决问题的技能。在自适应学习的条件下,学习不是一个被动地接受知识的过程,而是在考察实例和解决问题中主动地发现知识的过程。

Laster说:"例如,通过追踪学生的整个学习过程,记下他们在每个任务上花费的时间,我们可以采用最适合他们的学习方法,让他们主动参与到学习过程中,接受各种各样的挑战。"

为了强化学习的效果,McGraw-Hill和技术合作伙伴Time to Know共同开发了数字化教学平台,提供四到七年级的数学和英语课程,这个平台可以为教师提供实时反馈,比如,当一个学生遇到数学问题时,老师会立即知道,并对学生进行针对性的辅导。也就是说,课堂教学会更加有效。

定制化学习,终身学习

大数据有可能会将教育从同一模式的"批量化生产"变为Laster所说的"科学管理下的定制化学习过程,帮助学生培养更好的学习技能,"让学生了解如何利用时间、应对挑战、成为终身学习的人",有了大数据,这些目标将逐渐被实现。

教育捐助与教育投资

DonorsChoose.org,这个组织会根据教师的需求建立特定的项目筹集资金,该组织在两个层次上利用了大数据。首先,该公司通过使用电子邮件和社交网络向超过100万注册捐助者发送学校的请求(大约80%的请求会得到捐助)。该公司可以跟踪和分析捐助者的捐助形式(购买教科书、实地考察、贡献技术、资金支持)。2000年以来,DonorsChoose.org已为美国一半以上的学校筹集了超过1400万美元,报告显示在过去的一年期间这个数据又增涨了50%。

2月,DonorsChoose向公众公布了捐赠的历史数据和趋势报告。DonorsChoose.org的数据科学家Vlad Dubovskiy说:"校长和管理人员可以对这些数据进行挖掘,及时了解学校教师的请求。"他们也可以将本学校的需求和其他学校比较,按区域、贫困程度、民族比例或其他标准分类。

这些信息能够促使政策改变,Dubrovskiy说:"现在有数百万美元的融资机会,如果捐助者可以让管理人员了解他们需要什么、钱花在什么地方,这会有助于对教育财政作预算,有助于教育资金的合理分配。"

联合国教科文组织发布的最新一份《全民教育全球监测报告》显示,全世界用于教育的宝贵经费正在被低质量教育所浪费,其损失金额高达每年1290亿美元。报告就此呼吁各国政府在投资教育时,要注重教师的数量与质量,确保把最好的老师配备给最需要的学生。

预测教学质量

Chula Vista、Calif.、Winston-Salem、N.C.以及其他城市的学校都在使用大数据工具,用于帮助学校聘请教师。该学区计划开展一个预测分析软件项目,来自Hanover研究所的Paragon K-12用大量历史数据研究教师个人能力以及学生成就,既有单个项目的研究,也有对两者关系的研究。Joel Sackett是Paragon K-12的管理者,他说公司与学校的合作使教师招聘过程得到优化,在聘请教师时,分析教师的信息来预测教师能否在教育事业上取得成功,哪一位教师是最优秀的。

例如,Sackett说:"系统考虑到教师的学位和专长,以及信仰、人生观、态度、经验开放性等因素。这并不会决定老师是否被聘用,但从中得出的数据会对聘用过程有一定的影响。"

Sackett强调,在招聘过程中,基于预测分析的得分不应该作为唯一标准,"我们是想为面试提供一个更加客观的决策依据",在美国有好几个学校已经建立了研究试点。

数据分析完善教育体系

Tod R. Massa是弗吉尼亚州高等教育委员会政策研究和数据仓库的负责人,他告诉我们:当大数据应用到教育领域时,"一切皆有可能",作为弗吉尼亚州纵向数据系统(Longitudinal Data System)的一部分,委员会目前正在挖掘所有公共和非营利大学的学生数据,追踪学生表现情况。

最初委员会用数据分析是为了做预算,或者是为招生、财政援助和学位奖励做报告。Massa说:"过去十年中,我们已开始着手完善教育体系,帮助学生取得成功。"

例如,2008年,委员会将获得佩尔助学金(Pell grant)以及其他形式财政援助学生的成功率与所有学生的成功率进行了比较。

没有太大差别,但如果我们没有进行这样的比较,我们就不会知道如何改进它。在接下来几个星期,我们还会调查一些其他因素对学生的影响,如家庭收入。

Massa告诉我们委员会正在做毕业生工资情况的统计报告,包括了过去20年的毕业生情况。通过和失业率与工资记录相关联,还可以预测毕业生未来的工资情况,"帮助学生了解毕业后收入和学生贷款的变动,使他们了解教育决策对经济的影响。"

数据可帮助教育部门负责人和决策者了解资金政策的影响,"我们的目标是创造一种环境——一切基于事实,而不是猜想或直觉。"

"让我们用数据推动教育体制的变革吧。"

原文链接: Big Data Goes To School(编译/毛梦琪 审校/魏伟)


[]centos防火墙无法启动,初始化设置方法

本文自动转发自我的博客: http://www.haofengjing.org/2404.html
第1步:使用ssh或直接在本机使用root最高权限用户登录到centos系统,执行"iptables -F"并确定。  
  电脑互助网注:此方法命令确定之后不会出现任何成功的提示。 第2步:再次执行"service iptables save"命令并确定,当提示"iptables: Saving firewall rules to /etc/sysconfig/iptables:[ OK ]"就说明成功了。  
  电脑互助网注:这一步就是把本文第一步中的iptables -F命令执行,但是命令是执行成功了,但是还没有生效,所以我们需要重启防火墙。 尊重原创转载留网址http://www.pc811.com/6/7/26003.html 第3步:执行"service iptables restart"命令并确定,当提示有四个OK时就说明防火墙初始化,并重启动完毕。  
  第4步:执行"/etc/init.d/iptables status"命令可查看centos当前防火墙的相关信息,初始化之后,默认是只有两三个防火墙规则的。  
 

[]linux 查看登录日志及登录失败用户的ip

本文自动转发自我的博客: http://www.haofengjing.org/2385.html
查看登录成功的用户信息
命令: last
最新的登录记录在最前面,所以可以用 一下命令来查看。
last | less
查看登录失败的用户信息
命令: lastb
查看登录日志
命令:  tail /var/log/secure

[]理解Linux系统负荷 - 转自阮一峰的网络日志

本文自动转发自我的博客: http://www.haofengjing.org/2384.html

一、查看系统负荷

如果你的电脑很慢,你或许想查看一下,它的工作量是否太大了。

在Linux系统中,我们一般使用uptime命令查看(w命令和top命令也行)。(另外,它们在苹果公司的Mac电脑上也适用。)

你在终端窗口键入uptime,系统会返回一行信息。

这行信息的后半部分,显示"load average",它的意思是"系统的平均负荷",里面有三个数字,我们可以从中判断系统负荷是大还是小。

为什么会有三个数字呢?你从手册中查到,它们的意思分别是1分钟、5分钟、15分钟内系统的平均负荷。

如果你继续看手册,它还会告诉你,当CPU完全空闲的时候,平均负荷为0;当CPU工作量饱和的时候,平均负荷为1。

那么很显然,"load average"的值越低,比如等于0.2或0.3,就说明电脑的工作量越小,系统负荷比较轻。

但是,什么时候能看出系统负荷比较重呢?等于1的时候,还是等于0.5或等于1.5的时候?如果1分钟、5分钟、15分钟三个值不一样,怎么办?

二、一个类比

判断系统负荷是否过重,必须理解load average的真正含义。下面,我根据"Understanding Linux CPU Load "这篇文章,尝试用最通俗的语言,解释这个问题。

首先,假设最简单的情况,你的电脑只有一个CPU,所有的运算都必须由这个CPU来完成。

那么,我们不妨把这个CPU想象成一座大桥,桥上只有一根车道,所有车辆都必须从这根车道上通过。(很显然,这座桥只能单向通行。)

系统负荷为0,意味着大桥上一辆车也没有。

系统负荷为0.5,意味着大桥一半的路段有车。

系统负荷为1.0,意味着大桥的所有路段都有车,也就是说大桥已经"满"了。但是必须注意的是,直到此时大桥还是能顺畅通行的。

系统负荷为1.7,意味着车辆太多了,大桥已经被占满了(100%),后面等着上桥的车辆为桥面车辆的70%。以此类推,系统负荷2.0,意味着等待上桥的车辆与桥面的车辆一样多;系统负荷3.0,意味着等待上桥的车辆是桥面车辆的2倍。总之,当系统负荷大于1,后面的车辆就必须等待了;系统负荷越大,过桥就必须等得越久。

CPU的系统负荷,基本上等同于上面的类比。大桥的通行能力,就是CPU的最大工作量;桥梁上的车辆,就是一个个等待CPU处理的进程(process)。

如果CPU每分钟最多处理100个进程,那么系统负荷0.2,意味着CPU在这1分钟里只处理20个进程;系统负荷1.0,意味着CPU在这1分钟里正好处理100个进程;系统负荷1.7,意味着除了CPU正在处理的100个进程以外,还有70个进程正排队等着CPU处理。

为了电脑顺畅运行,系统负荷最好不要超过1.0,这样就没有进程需要等待了,所有进程都能第一时间得到处理。很显然,1.0是一个关键值,超过这个值,系统就不在最佳状态了,你要动手干预了。

三、系统负荷的经验法则

1.0是系统负荷的理想值吗?

不一定,系统管理员往往会留一点余地,当这个值达到0.7,就应当引起注意了。经验法则是这样的:

当系统负荷持续大于0.7,你必须开始调查了,问题出在哪里,防止情况恶化。

当系统负荷持续大于1.0,你必须动手寻找解决办法,把这个值降下来。

当系统负荷达到5.0,就表明你的系统有很严重的问题,长时间没有响应,或者接近死机了。你不应该让系统达到这个值。

四、多处理器

上面,我们假设你的电脑只有1个CPU。如果你的电脑装了2个CPU,会发生什么情况呢?

2个CPU,意味着电脑的处理能力翻了一倍,能够同时处理的进程数量也翻了一倍。

还是用大桥来类比,两个CPU就意味着大桥有两根车道了,通车能力翻倍了。

所以,2个CPU表明系统负荷可以达到2.0,此时每个CPU都达到100%的工作量。推广开来,n个CPU的电脑,可接受的系统负荷最大为n.0。

五、多核处理器

芯片厂商往往在一个CPU内部,包含多个CPU核心,这被称为多核CPU。

在系统负荷方面,多核CPU与多CPU效果类似,所以考虑系统负荷的时候,必须考虑这台电脑有几个CPU、每个CPU有几个核心。然后,把系统负荷除以总的核心数,只要每个核心的负荷不超过1.0,就表明电脑正常运行。

怎么知道电脑有多少个CPU核心呢?

"cat /proc/cpuinfo"命令,可以查看CPU信息。"grep -c 'model name' /proc/cpuinfo"命令,直接返回CPU的总核心数。

六、最佳观察时长

最后一个问题,"load average"一共返回三个平均值----1分钟系统负荷、5分钟系统负荷,15分钟系统负荷,----应该参考哪个值?

如果只有1分钟的系统负荷大于1.0,其他两个时间段都小于1.0,这表明只是暂时现象,问题不大。

如果15分钟内,平均系统负荷大于1.0(调整CPU核心数之后),表明问题持续存在,不是暂时现象。所以,你应该主要观察"15分钟系统负荷",将它作为电脑正常运行的指标。

==========================================

[参考文献]

1. Understanding Linux CPU Load

2. Wikipedia - Load (computing)

(完)


[]人生体验

本文自动转发自我的博客: http://www.haofengjing.org/2383.html
每个人年轻的时候,都想离开自己的父母,离的越远越好,不知不觉真就走出很远,与他们相隔千山万水,有一天猛一回头你会发现,无论走多远,总有一根线连着你和他们,那时候父母已经变老,腿脚不再利索,于是你又折回头重回他们身边,和以前不一样的是,你变成了大人,他们变成了孩子。

[]海淘是电商的最后一块蛋糕?前阿里员工离职创业“CN海淘”,瞄准小白用户海淘市场 | 36氪

本文自动转发自我的博客: http://www.haofengjing.org/2380.html

"跨境电商可能是电商领域的最后一块蛋糕",CN海淘iSO/Android)创始人谢文斌如此向我介绍。谢文斌曾在天猫无线团队负责产品,看到海淘、代购行业正在酝酿中的机遇,去年果断和小伙伴们离职创业,并且顺利拿到了蔡文胜、汪东风的数百万人民币天使。

"CN 海淘"项目开始于去年 10 月份,5 个月的时间说长不长,说短也不短。期间既需要做产品和技术开发(自己写的爬虫),还要搭建海外的编辑、运营团队,并整合供应链、第三方物流等外部资源。虽然模式看起来很轻(目前只有 10 名全职员工),但所做工作的繁琐程度恐怕比一个 B2C 也不遑多让。

说起进军海淘的机遇,谢文斌向我们介绍了两点:

一、国内外商品的价格和品类差距过大,加上人民币购买力的提升,海淘、代购行业正以可见的速度崛起。根据中国电子商务研究中心的统计,从 2010 年到 2013 年,中国海外代购交易额一路从 120 亿增长到 700 多亿,今年有望冲击千亿规模。而 2012 年数据显示,仅以支付宝支付的海淘交易就比上一年增长了 117%,远高于国内网购 64.7% 的增长速度,这还没将信用卡支付的部分计算在内。

二、虽然市场体量庞大,但消费者一端的海淘体验并不理想。眼下最常见的方式是,用户自己上境外电商网站选购,自己下单并联系转运公司。这需要用户自己懂外语、持有双币信用卡、熟悉转运流程,而且多少都要在海淘论坛混一段时间,以防掉进"坑"里。

由以上前提出发,解决方式就显而易见了。"CN 海淘"核心思考主要是两点:一是如何将前端流程简化,将影响体验的环节尽可能地放在后台处理。二是如何将国外电商本土化,降低小白用户的使用门槛

目前,"CN 海淘"已经上线了 50 多家国外电商的 10000 多件商品。所有商品的名称、品牌介绍、描述、分类都经过编辑团队的编译和整理,下单、跨境支付、物流等流程都交由后台解决。加上一系列细节优化,比如价格透明化、服务条款标准化、支持国内比价和物流查询等功能,让用户可以像在本地电商一样购买国外商品,而且确保正品行货。目前除了物流周期稍长以外(主要由于货运、清关等不可抗力),"CN 海淘"在各方面体验上几乎与一个本地 B2C 没差。

就思路而言,"CN 海淘"并不算是个案。近半年上线的一些海淘产品,比如"海淘城"、"跨境通"等都在设法降低小白用户的参与门槛。而 09 年上线的"洋码头"(旗下产品"海外扫货神器"曾被我们介绍),除了自建物流这一点外,其基于海外零售商的 C2C 的模式很容易让人联想到淘宝。还有上个月正式上线的"天猫国际",看起来名副其实就是天猫的海淘翻版。

其实淘宝早在 07 年就推出了代购频道,在此之后,京东、苏宁、顺丰、申通等电商和物流巨头都纷纷试水。去年 9 月豆瓣上线的商品分享平台"东西",现在也建立了海淘社区。与这些资源丰富的大小巨头相比,创业公司的机会是什么?在阿里出身谢文斌看来,"更灵活、模式更单一"可能是他们的生存逻辑:

"模式这个事情,天猫国际已经定性了,拥有国外商品销售能力的都接入。但是天猫商家太多,接入成本高,还要接受高额的广告资源,所有这些都会体现在价格上,而天猫国际对此是无法掌控的。那对于我们来说很可能不需要你接入,我直接把供应链、物流链统一解决,海外商家只要给我保税仓供货。我以更低的价格出售,帮助商家来售卖,模式更单一,有点类似海淘版唯品会的概念。"

对此我的个人理解是,这可能就像导购业态在海淘领域的复制。如果天猫国际自己的入口、规则、生态无法服务更细分的用户和商家,就会给众多小而美公司以生存空间(包括"CN 海淘"在内,不少海淘平台都走了精品、特卖路线)。而且在海淘商品一端很难出现一家独大的局面,国内外信息不对称又会长期存在,创业窗口期或许会更长。再加上去年底以来一系列公共基础设施的完善,比如顺丰提供的跨境物流能力,上海自贸区的跨境人民币结算,以及各地蜂起的保税区运动——目前海淘行业或许已是黄金进入时机?

当然以上只是我的推想,也是我们乐见其成的期望。在创业机会越来越少的当下,难得还有跨境电商这个值得一搏的大趋势存在。

[36氪原创文章,作者: 沈超]