eygle.com   eygle.com
eygle.com eygle
eygle.com  
 
Digest Net: 学习资料 Archives

Recently in 学习资料 Category

阮一峰 这个系列文章非常精彩,受益良多,转载几篇于此。

原文网址:http://www.ruanyifeng.com/blog/2012/03/ranking_algorithm_bayesian_average.html
作者: 阮一峰

上一篇介绍了"威尔逊区间",它解决了投票人数过少、导致结果不可信的问题。

举例来说,如果只有2个人投票,"威尔逊区间"的下限值会将赞成票的比例大幅拉低。这样做固然保证了排名的可信性,但也带来了另一个问题:排行榜前列总是那些票数最多的项目,新项目或者冷门的项目,很难有出头机会,排名可能会长期靠后。

IMDB为例,它是世界最大的电影数据库,观众可以对每部电影投票,最低为1分,最高为10分。

系统根据投票结果,计算出每部电影的平均得分。然后,再根据平均得分,排出最受欢迎的前250名的电影。

这里就有一个问题:热门电影与冷门电影的平均得分,是否真的可比?举例来说,一部好莱坞大片有10000个观众投票,一部小成本的文艺片只有100 个观众投票。这两者的投票结果,怎么比较?如果使用"威尔逊区间",后者的得分将被大幅拉低,这样处理是否公平,能不能反映它们真正的质量?

一个合理的思路是,如果要比较两部电影的好坏,至少应该请同样多的观众观看和评分。既然文艺片的观众人数偏少,那么应该设法为它增加一些观众。

排名页面的底部,IMDB给出了它的计算方法。

  

  - WR, 加权得分(weighted rating)。
  - R,该电影的用户投票的平均得分(Rating)。
  - v,该电影的投票人数(votes)。
  - m,排名前250名的电影的最低投票数(现在为3000)。
  - C, 所有电影的平均得分(现在为6.9)。

仔细研究这个公式,你会发现,IMDB为每部电影增加了3000张选票,并且这些选票的评分都为6.9。这样做的原因是,假设所有电影都至少有 3000张选票,那么就都具备了进入前250名的评选条件;然后假设这3000张选票的评分是所有电影的平均得分(即假设这部电影具有平均水准);最后, 用现有的观众投票进行修正,长期来看,v/(v+m)这部分的权重将越来越大,得分将慢慢接近真实情况。

这样做拉近了不同电影之间投票人数的差异,使得投票人数较少的电影也有可能排名前列。

把这个公式写成更一般的形式:

  

  - C,投票人数扩展的规模,是一个自行设定的常数,与整个网站的总体用户人数有关,可以等于每个项目的平均投票数。
  - n,该项目的现有投票人数。
  - x,该项目的每张选票的值。
  - m,总体平均分,即整个网站所有选票的算术平均值。

这种算法被称为"贝叶斯平均"(Bayesian average)。因为某种程度上,它借鉴了"贝叶斯推断"(Bayesian inference)的思想:既然不知道投票结果,那就先估计一个值,然后不断用新的信息修正,使得它越来越接近正确的值。

在这个公式中,m(总体平均分)是"先验概率",每一次新的投票都是一个调整因子,使总体平均分不断向该项目的真实投票结果靠近。投票人数越多,该项目的"贝叶斯平均"就越接近算术平均,对排名的影响就越小。

因此,这种方法可以给一些投票人数较少的项目,以相对公平的排名。

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

"贝叶斯平均"也有缺点,主要问题是它假设用户的投票是正态分布。比如,电影A有10个观众评分,5个为五星,5个为一星;电影B也有10个观众评分,都给了三星。这两部电影的平均得分(无论是算术平均,还是贝叶斯平均)都是三星,但是电影A可能比电影B更值得看。

解决这个问题的思路是,假定每个用户的投票都是独立事件,每次投票只有n个选项可以选择,那么这就服从"多项分布"(Multinomial distribution),就可以结合贝叶斯定理,估计该分布的期望值。由于这涉及复杂的统计学知识,这里就不深入了,感兴趣的朋友可以继续阅读William Morgan的How to rank products based on user input



银行账务基本核算方法 之 帐务组织

最近在银行的项目上,学习一下金融知识,这里是摘录的一些 账务组织 内容(原文链)。

一、帐务组织的概念及其内容
1、概念
  帐务组织是指根据凭证对经济业务核算时,从帐簿的设置,记帐程序,直到帐务平衡,编制出会计日报表为止,整个核算过程中各种方法相互配合所形成的核算体系。 银行的帐务组织包括明细核算和综合核算两个系统。
2、明细核算和综合核算的关系
    明细核算的概念:明细核算是按帐户进行的核算,它能反映资金运动的详细情况
    综合核算的概念:综合核算是按科目进行的核算,它能反映资金运动的总括情况
  两者之间的关系:银行经济业务发生后,要遵守双线核算原则,即根据同一凭证,对经济业务既进行明细核算,同时又进行综合核算。明细核算对综合核算起补充说明作用,综合核算对明细核算起统驭作用,二者相互联系,相互制约,共同构成银行严密、科学的帐务组织。

二、明细核算
(一)概述
  1.明细核算的基础:以帐户为基础进行核算。
  2.明细核算的组成内容:由分户帐、登记簿、现金收付日记簿、余额表四部分内容组成。
  3.明细核算的程序:首先,根据传票记载分户账(如为现金收付业务,则还要分别登记现金收入日记簿和现金付出日记簿);其次,对不能入账而又需要记载的重要业务事项,则在登记簿中进行记载;最后,营业终了按分户账各户当日最后余额编制余额表。
(二)分户帐
  分户帐是明细核算的主要形式,应根据传票逐笔连续记载,并结计余额。银行使用的分户帐帐页格式有四种,分别称作
    甲种帐,    乙种帐,    丙种帐,    丁种帐
 1.甲种帐:适用于不计算利息的帐户使用。
 2.乙种帐 适用于计算利息的帐户使用。
 3.丙种帐:适用于借、贷双方反映余额的帐户使用。
 4.丁种帐:适用于逐笔记帐、逐笔销帐的帐户使用。
(三)登记簿
  登记簿是一种辅助帐簿,属备查簿性质,是分户帐的补充。凡分户帐上不能记载而又需查考的业务,均使用登记簿核算,主要是反映表外科目的明细情况,可用来控制重要空白凭证、有价单证和实物。帐页格式无统一规定,视业务需要而定。
(四)现金收付日记簿
  现金收入、付出日记簿是分别逐笔、序时地记录银行现金收入、付出情况的帐簿。
  现金收付日记簿的登记。
  现金收入、付出业务发生后依据现金收入传票和现金付出传票分别逐笔登记现金收入日记簿、现金付出日记簿。每天营业终了,结计出现金收入、付出合计数,再计算出现金结存数,并与实际现金库存数核对相符。
(五)余额表
  余额表是用来填制分户帐余额的表格,其作用是据以核对总帐和分户帐余额,并计算利息。余额表的格式有两种,一种称计息余额表,一种称一般余额表。

eBay,可伸缩性是我们每天奋力抵抗的一大架构压力。我们所做的每一项架构及设计决策,身前身后都能看到它的踪影。当我们面对的是全世界数以亿计的用户,每天的页面浏览量超过10亿,系统中的数据量要用皮字节(1015或250)来计算----可伸缩性是生死交关的问题。


在一个可伸缩的架构中,资源的消耗应该随负载线性(或更佳)上升,负载可由用户流量、数据量等测量。如果说性能衡量的是每一工作单元所需的资源消耗,可伸缩性则是衡量当工作单元的数量或尺寸增加时,资源消耗的变化情况。换句话说,可伸缩性是整个价格-性能曲线的形状,而不是曲线上某一点的取值。

可伸缩性有很多侧面----事务的方面、运营的方面、还有开发的方面。我们在改善一个Web系统的事务吞吐量的过程中学到了很多经验,本文总结了其中若 干关键的最佳实践。可能很多最佳实践你会觉得似曾相识,也可能有素未谋面的。这些都是开发和运营eBay网站的众人的集体经验结晶。

最佳实践 #1:按功能分割

相关的功能部分应该合在一起,不相关的功能部分应该分割开来----不管你把它叫做SOA、功能分解还是工程秘诀。而且,不相关的功能之间耦合程度越松散,就越能灵活地独立伸缩其中的一部分。

在编码层次,我们无时不刻都在运用这条原则。JAR文件、包、Bundle等等,都是用来隔离和抽象功能的机制。

在应用层次,eBay将不同的功能划分成几个应用程序池。销售功能由一组应用服务器运行,投标功能由另一组负责,搜索又是另外一组服务器。我们把总 共约16,000台应用服务器分成220个池。这样就可以根据某项功能的资源消耗,单独地伸缩其中一个池。我们也因此得以进一步隔离及合理化资源依赖关系 ----比如销售池只需要访问后台资源的一个相对较小的子集。

在数据库层次,我们也采取同样的做法。eBay没有无所不包的单一数据库,相反我们有一组数据库主机存放用户数据、一组存放商品数据、一组存放购买数据......总共1000个逻辑数据库分布在400台物理主机上。同样,这种做法让我们得以单独为某一类数据伸缩其数据库设施。

最佳实践 #2:水平切分

按功能分割对我们的帮助很大,但单凭它还不足以得到完全可伸缩的架构。即使将功能一一解耦,单项功能的资源需求随着时间增长,仍然有可能超出单一系 统的能力。我们常常提醒自己,"没有分割就没有伸缩"。在单项功能内部,我们需要能把工作负载分解成许多我们有能力驾驭的小单元,让每个单元都能维持良好 的性能价格比。这就是水平分割出场的时候了。

在应用层次,由于eBay将各种交互都设计成无状态的,所以水平分割是轻而易举之事。用标准的负载均衡服务器来路由进入的流量。所有应用服务器都是 均等的,而且任何服务器都不会维持事务性的状态,因此负载均衡可以任意选择应用服务器。如果需要更多处理能力,只需要简单地增加新的应用服务器。

数据库层次的问题比较有挑战性,原因是数据天生就是有状态的。我们会按照主要的访问路径对数据作水平分割(或称为"sharding")。例如用户 数据目前被分割到20台主机上,每台主机存放1/20的用户。随着用户数量的增长,以及每个用户的数据量增长,我们会增加更多的主机,将用户分散到更多的 机器上去。商品数据、购买数据、帐户数据等等也都用同样的方式处理。用例不同,我们分割数据的方案也不同:有些是对主键简单取模(ID尾数为1的放到第一 台主机,尾数为二的放到下一台,以此类推),有些是按照ID的区间分割(1-1M、1-2M等等),有些用一个查找表,还有些是综合以上的策略。不过具体 的分割方案如何,总的思想是支持数据分割及重分割的基础设施在可伸缩性上远比不支持的优越。

最佳实践 #3:避免分布式事务

看到这里,你可能在疑惑按功能划分数据和水平划分数据的实践如何满足事务要求。毕竟,几乎任何有意义的操作都要更新一个以上的实体----立即就可以举 出用户和商品的例子。正统的广为人知的答案是:建立跨资源的分布式事务,用两段式提交来保证要么所有资源全都更新,要么全都不更新。很不幸,这种悲观方案 的成本很可观。伸缩、性能和响应延迟都受到协调成本的反面影响,随着依赖的资源数量和客户数量的上升,这些指标都会以几何级数恶化。可用性亦受到限制,因 为所有依赖的资源都必须就位。实用主义的答案是,对于不相关的系统,放宽对它们的跨系统事务的保证。

左右逢源是办不到的。保证跨多个系统或分区之间的即时的一致性,通常既无必要,也不现实。Inktomi的Eric Brewer十年前提出的CAP公理是这样说的:分布式系统的三项重要指标----一致性(Consistency)、可用性(Availability)和 分区耐受性(Partition-tolerance)----在任意时刻,只有两项能同时成立。对于高流量的网站来说,我们必须选择分区耐受性,因为它是实 现可伸缩的根本。对于24x7运行的网站,选择可用性也是理所当然的。于是只好放弃即时一致性(immediate consistency)。

在eBay,我们绝对不允许任何形式的客户端或者分布式事务----因此绝不需要两段式提交。在某些经过仔细定义的情形下,我们会将作用于同一个数据库 的若干语句捆绑成单个事务性的操作。而对于绝大部分操作,单条语句是自动提交的。虽然我们故意放宽正统的ACID属性,以致不能在所有地方保证即时一致 性,但现实的结果是大部分系统在绝大部分时间都是可用的。当然我们也采用了一些技术来帮助系统达到最终的一致性(eventual consistency):周密调整数据库操作的次序、异步恢复事件,以及数据核对(reconciliation)或者集中决算(settlement batches)。具体选择哪种技术要根据特定用例对一致性的需求来决定。

对于架构师和系统的设计者来说,关键是要明白一致性并非"有"和"没有"的单选题。现实中大多数的用例都不要求即时一致性。正如我们经常根据成本和其他压力因素来权衡可用性的高低,一致性也同样可以量体裁衣,根据特定操作的需要而保证适当程度的一致性。 

最佳实践 #4:用异步策略解耦程序

提高可伸缩性的另一项关键措施是积极地采取异步策略。如果组件A同步调用组件B,那么A和B就是紧密耦合的,而紧耦合的系统其可伸缩性特征是各部分 必须共同进退----要伸缩A必须同时伸缩B。同步调用的组件在可用性方面也面临着同样的问题。我们回到最基本的逻辑:如果A推出B,那么非B推出非A。也就 是说,若B不可用,则A也不可用。如果反过来A和B的联系是异步的,不管是通过队列、多播消息、批处理还是什么其他手段,它们就可以分别地伸缩。而且,此 时A和B的可用性特征是相互独立的----即使B受困或者死掉,A仍然能够继续前进。

整个基础设施从上到下都应该贯彻这项原则。即使在单个组件内部也可通过SEDA(分阶段的事件驱动架构,Staged Event-Driven Architecture)等技术实现异步性,同时保持一个易于理解的编程模型。组件之间也遵守同样的原则----尽可能避免同步带来的耦合。在多数情况下, 两个组件在任何事件中都不会有直接的业务联系。在所有的层次,把过程分解为阶段(stages or phases),然后将它们异步地连接起来,这是伸缩的关键。

最佳实践 #5:将过程转变为异步的流

用异步的原则解耦程序,尽可能将过程变为异步的。对于要求快速响应的系统,这样做可以从根本上减少请求者所经历的响应延迟。对于网站或者交易系统, 牺牲数据或执行的延迟时间(完成全部工作的实践)来换取用户的延迟时间(用户得到响应的时间)是值得的。活动跟踪、单据开付、决算和报表等处理过程显然都 应该属于后台活动。主要用例过程中常常有很多步骤可以进一部分解成异步运行。任何可以晚点再做的事情都应该晚点再做。

还有一个同等重要的方面认识到的人不多:异步性可以从根本上降低基础设施的成本。同步地执行操作迫使你必须按照负载的峰值来配备基础设施----即使在 任务最重的那一天里任务最重的那一秒,设施也必须有能力立即完成处理。而将昂贵的处理过程转变为异步的流,基础设施就不需要按照峰值来配备,只需要满足平 均负载。而且也不需要立即处理所有的请求,异步队列可以将处理任务分摊到较长的时间里,因而起到削峰的作用。系统的负载变化越大,曲线越多尖峰,就越能从 异步处理中得益。

最佳实践 #6:虚拟化所有层次

虚拟化和抽象化无所不在,计算机科学里有一句老话:所有问题都可以通过增加一个间接层次来解决。操作系统是对硬件的抽象,而许多现代语言所用的虚拟 机又是对操作系统的抽象。对象-关系映射层抽象了数据库。负载均衡器和虚拟IP抽象了网络终端。当我们通过分割数据和程序来提高基础设施的可伸缩性,为各 种分割增加额外的虚拟层次就成为重中之重。

在eBay,我们虚拟化了数据库。应用与逻辑数据库交互,逻辑数据库再按照配置映射到某个特定的物理机器和数据库实例。应用也抽象于执行数据分割的 路由逻辑,路由逻辑会把特定的记录(如用户XYZ)分配到指定的分区。这两类抽象都是在我们自己开发的O/R层上实现的。这样虚拟化之后,我们的运营团队 可以按需要在物理主机群上重新分配逻辑主机----分离、合并、移动----而完全不需要接触应用程序代码。

搜索引擎同样是虚拟化的。为了得到搜索结果,一个聚合器组件会在多个分区上执行并行的查询,但这个高度分割的搜索网格在客户看来只是单一的逻辑索引。

以上种种措施并不只是为了程序员的方便,运营上的灵活性也是一大动机。硬件和软件系统都会故障,请求需要重新路由。组件、机器、分区都会不时增减、 移动。明智地运用虚拟化,可使高层的设施对以上变化难得糊涂,你也就有了腾挪的余地。虚拟化使基础设施的伸缩成为可能,因为它使伸缩变成可管理的。

最佳实践 #7:适当地使用缓存

最后要适当地使用缓存。这里给出的建议不一定普遍适用,因为缓存是否高效极大地依赖于用例的细节。说到底,要在存储约束、对可用性的需求、对陈旧数 据的容忍程度等条件下最大化缓存的命中率,这才是一个高效的缓存系统的最终目标。经验证明,要平衡众多因素是极其困难的,即使暂时达到目标,情况也极可能 随着时间而改变。

最适合缓存的是很少改变、以读为主的数据----比如元数据、配置信息和静态数据。在eBay,我们积极地缓存这种类型的数据,并且结合使用"推"和" 拉"两种方法保持系统在一定程度上的更新同步。减少对相同数据的重复请求能达到非常显著的效果。频繁变更、读写兼有的数据很难有效地缓存。在eBay,我 们大多有意识地回避这样的难题。我们一直不对请求间短暂存在的会话数据作任何缓存。也不在应用层缓存共享的业务对象,比如商品和用户数据。我们有意地牺牲 缓存这些数据的潜在利益,换取可用性和正确性。在此必须指出,其他网站采取了不同的途径,作了不同的取舍,也同样取得了成功。

好东西也会过犹不及。为缓存分配的内存越多,能用来服务单个请求的内存就越少。应用层常常有内存不足的压力,因此这是非常现实的权衡。更重要的一 点,当你开始依赖于缓存,那么主要系统就只需要满足缓存未命中时的处理要求,自然而然你就会想到可以削减主要系统。但当你这样做之后,系统就完全离不开缓 存了。现在主要系统没办法直接应付全部流量,也就是说网站的可用性取决于缓存能否100%正常运行----潜在的危局。哪怕是例行的操作,比如重新配置缓存资 源、把缓存移动到别的机器、冷启动缓存服务器,都有可能引发严重的问题。

做得好,缓存系统能让可伸缩性的曲线向下弯曲,也就是比线性增长还要好----后续请求从缓存中取数据比从主存储取数据成本低廉。反过来,缓存做得不好 会引入相当多额外的经常耗费,也会妨碍到可用性。我还没见过哪个系统没机会让缓存大展拳脚的,关键是要根据具体情况找到适当缓存策略。

总结

可伸缩性有时候被叫做"非功能性需求",言下之意是它与功能无关,也就比较不重要。这么说简直错到了极点。我的观点是,可伸缩性是功能的先决条件----优先级为0的需求,比一切需求的优先级都高。

希望以上最佳实践能对你有用,希望能帮助你从新的角度审视你的系统,无论其规模如何。

参考

关于作者

Randy Shoup是eBay的杰出架构师。从2004年起担任eBay搜索基础设施的主要架构师。在加入eBay之前,他是Tumbleweed Communications公司的总架构师,也曾在Oracle和Informatica担任多个软件开发和架构的职位。

他经常在业界的会议上讲授可伸缩性和架构模式。

阅读英文原文:Scalability Best Practices: Lessons from eBay

转引自:http://www.infoq.com/cn/articles/ebay-scalability-best-practices


vim全局替换命令参考

| 1 Comment
语法为 :[addr]s/源字符串/目的字符串/[option]
全局替换命令为::%s/源字符串/目的字符串/g
[addr] 表示检索范围,省略时表示当前行。
如:"1,20" :表示从第1行到20行;
"%" :表示整个文件,同"1,$";
". ,$" :从当前行到文件尾;
s : 表示替换操作
[option] : 表示操作类型
如:g 表示全局替换; 
c 表示进行确认
p 表示替代结果逐行显示(Ctrl + L恢复屏幕);
省略option时仅对每行第一个匹配串进行替换;
如果在源字符串和目的字符串中出现特殊字符,需要用"\"转义
下面是一些例子:
#将That or this 换成 This or that
:%s/\(That\) or \(this\)/\u\2 or \l\1/
--- 
#将句尾的child换成children
:%s/child\([ ,.;!:?]\)/children\1/g
---
#将mgi/r/abox换成mgi/r/asquare
:g/mg\([ira]\)box/s//mg//my\1square/g    <=>  :g/mg[ira]box/s/box/square/g
---
#将多个空格换成一个空格
:%s/  */ /g
---
#使用空格替换句号或者冒号后面的一个或者多个空格
:%s/\([:.]\)  */\1 /g
---
#删除所有空行
:g/^$/d
---
#删除所有的空白行和空行
:g/^[  ][  ]*$/d
---
#在每行的开始插入两个空白
:%s/^/>  /
---
#在接下来的6行末尾加入.
:.,5/$/./
---
#颠倒文件的行序
:g/.*/m0O  <=> :g/^/m0O
---
#寻找不是数字的开始行,并将其移到文件尾部
:g!/^[0-9]/m$ <=> g/^[^0-9]/m$
---
#将文件的第12到17行内容复制10词放到当前文件的尾部
:1,10g/^/12,17t$
~~~~重复次数的作用
---
#将chapter开始行下面的第二行的内容写道begin文件中
:g/^chapter/.+2w>>begin
---
:/^part2/,/^part3/g/^chapter/.+2w>>begin
---
:/^part2/,/^part3/g/^chapter/.+2w>>begin|+t$


IBM AIX svmon 简介之一

原文链接: http://www-01.ibm.com/support/docview.wss?uid=csc1ef3e1dda91b04aa248256da4004c60fb

svmon命令是虚存的的监视命令,svmon可用于确定某个程序、用户、内存段使用实存或虚存的情况。它事实上调用的是svmon_back命令,在使用svmon命令之前,必须确定svmon_back命令可用,该命令位置为 /usr/lib/perf/svmon_back
svmon运行于前台,就象一个普通的用户进程一样,因为它在运行过程中可被中断,所以,它无法完全真正地成为内存使用情况的快照。所以,在非常繁忙的系 统中,svmon收集的数据和真实的数据有所差距,在svmon进程搜集的过程中,VMM(虚存管理器)可能已经发生改动了。
因为svmon使用的全是VMM中的数据,而VMM对内存的视图是基于内存段的,所以,理解svmon的输出,必须先理解段的概念。
段(segment)是一组页的合集,每个段为256M,而每页为4KB字节的虚存,每帧为4KB字节的实存,每个段可同时被多个进程使用,每个段属于以下五种类型其中的一种:
persistent:存放JFS文件或目录
working:进程数据区域和共享内存段
client:用于实现虚拟文件系统如NFS,CD-ROM文件系统和JFS2
mapping:用于实现文件和内存之间的映射关系
real memory mapping:用于对I/O空间的访问
注意,在段的描述中,如果paging space使用的节中如果有一横(-),表明该段未使用交换区,work段可能使用交换区,但persistent段和client段不会使用交换区。
下面举例说明使用命令可做的一些工作:
1、# svmon -uP -t 3|grep -p Pid|grep '^.*[0-9] '
可将使用实存最多的三个进程标出
5428 X 4681 1584 2656 9156 N N
16274 bin 4594 1588 2273 8824 N Y
6458 dtgreet 4660 1580 2144 8712 N N
输出的格式顺序为 Pid Command Inuse Pin Pgsp Virtual 64-bit Mthrd
可以计算出X程序所使用的实存为4681×4096=18763776,约为18MB

2、# svmon -gP -t 3|grep -p Pid|grep '^.*[0-9] '
可将使用交换区最多的三个进程标出,
5428 X 4681 1584 2656 9156 N N
16274 bin 4594 1588 2273 8824 N Y
6458 dtgreet 4660 1580 2144 8712 N N
第一个程序X所使用的交换区大小约为 2566×4096 =10510336 字节,大约为10MB空间

3、# svmon -S -t 3 -i 3
每隔三秒显示使用最多的段
Vsid Esid Type Description Inuse Pin Pgsp Virtual
4f08 -    clnt 37505 0 - -
11e1 -    clnt 33623 0 - -
8811 -    work kernel pinned heap 12637 6547 8091 19397
可见,Vsid为4f08的段使用最多

4、svmon -pP 22674
看PID为22674的进程所使用的为那些文件
Pid Command nuse Pin Pgsp Virtual 64-bit Mthrd
22674 java 29333 1611 2756 32404 N Y

Vsid Esid Type Description Inuse Pin Pgsp Virtual
0 0 work kernel seg 2979 1593 1659 4561
a056 - work 43 16  3   46
1e03 2 work process private 77 2   17  93
1080 - pers /dev/hd2:69742 1 0   -   -
f8bd f work shared library data 84 0   11  99
60ee 8 work shmat/mmap 0 0   0   0
70ec - pers /dev/hd2:69836 1 0   -   -
再利用ncheck命令,用户可自己建立脚本将device:inode信息抽取出来,如从上述的信息中,我们可通过ncheck得到输出:
/usr/java130/jre/lib/rt.jar
/usr/java130/jre/lib/fonts/LucidaSansRegular.ttf
/usr/java130/jre/lib/ext/indicim.jar
/usr/java130/jre/lib/ext/ibmjcaprovider.jar
/usr/java130/jre/lib/fonts/LucidaSansDemiBold.ttf
/usr/java130/jre/bin/java
脚本示例如下:
# expand -4 files.sh|nl
1 grep -p Vsid $1|
2 awk 'NR>1&&$0!~/^$/&&$4~/\/dev/{
3 l=substr($4,1,index($4,":")-1)
4 i=substr($4,index($4,":")+1)
5 if (l~/^\//)
6 print l,i
7 else {
8 print substr(l,index(l,",")+1),i
9 }
10 }'|
11 while read lv inode;do
12 fs=$(lsfs -c $lv 2>/dev/null|awk -F: 'NR>1{print $1}')
13 ncheck -i $inode $lv|awk '!/:$/{print lv $2}' lv=$fs
14 done


Pages

Powered by Movable Type 6.3.2

About this Archive

This page is an archive of recent entries in the 学习资料 category.

孕产婴儿 is the previous category.

开心幽默 is the next category.

回到 首页 查看最近文章或者查看所有归档文章.