2007年02月22日

1.      bufferpool进行监控和调优

select BP_NAME,

(

INT(1 –

(FLOAT(pool_Index_P_Reads + pool_data_P_Reads)) /

(FLOAT(Pool_Index_L_Reads+Pool_data_L_Reads))

)*100

) AS Pool_Hit_Ratio

FROM TABLE

(SNAPSHOT_BP(‘SAMPLE’,-1 ))  #-1仅获取当前partition-2获取所有partition

as SNAPSHOT_BP;

对于bufferpool1-(物理的read次数/逻辑的read次数),就是bufferpool的命中率。这个值大于80%才能说明这个bufferpool是有用的;对于OLTP环境,必须更大(特别是Index的命中率);对于DSS环境,这个值不可能要求很大。

 

2.      监视bufferpool的异步读Ratio

异步读(asynchronous read ratioRatio的计算公式:

ARR = ((Asynch Data Reads + Asynch Index Reads) /

((Data Logical Reads + Index Logical Reads)) * 100%

使用SQL Table funtion

select BP_NAME,

(INT(((FLOAT(pool_Async_data_Reads + pool_async_index_Reads)) /

(FLOAT(Pool_Index_L_Reads + Pool_data_L_Reads))) * 100))

AS Asynch_Read_Ratio

FROM TABLE(SNAPSHOT_BP(‘SAMPLE’,-1 ))

as SNAPSHOT_BP;

得到的结果就是表明prefetch的活动是否频繁。如果得到一个非常小的结果,则可能说明:

1.     事务的类型都是对单行进行读写,因此无法从prefetch中获益

2.     database配置了太少的prefetcher

3.     可能database只有一个container

对于异步读比例高的tablespace,最好是为它们各自配置单独的bufferpool

 

3.      物理读RatePhysical Read Rate

PRR = (Data Physical Reads + Index Physical Reads) /

(Time since monitor switches reset orgraphics/ccc.gif activated)

Timer的计算方法为:Snapshot timestamp – First db connect timestamp

物理读可以识别出哪个tablespace有更多的IO需求。

 

4.      Read 所消耗的Time

对于每个ReadDB2 snapshot中提供了足够的信息计算出每个Read所消耗的时间

ART = (Total Buffer Pool Read Time) / (Data Physical Reads + Index Physical Reads)

SQL Table function算法是:

select BP_NAME,

(INT(((FLOAT(pool_read_time))/

(FLOAT(Pool_Index_p_Reads+Pool_data_p_Reads))) * 100))

AS Avg_Read_Time_in_ms

FROM TABLE(SNAPSHOT_BP(‘SAMPLE’,-1 ))

as SNAPSHOT_BP;

 

5.      Page cleaner每次写入diskpage的平均值

      平均每次写入diskpages过大或者过小都将影响数据库的性能。DB2没有直接的snapshot可以获取这个值,但是可以计算出来:

APPAW =

((Asynchronous pool data page writes + Asynchronous pool index page writes) / graphics/ccc.gif(Dirty page steal cleaner triggers + Dirty page threshold cleaner triggers + LSN Gapgraphics/ccc.gif Cleaner Triggers))

通过连接两个表TABLE(SNAPSHOT_BP())TABLE(SNAPSHOT_DATABSE())可以获得这个值。得到的值(pages需要乘上pagesize)应当比较和bufferpool的比率,如果在大于1%小于5%则是比较合理的值。

1.      Page Cleaning

agent要求DB2disk上读取databufferpool中,而此时bufferpool已满的时候,DB2需要选择出victim page,如果victim page已经dirty,那么DB2首先需要将dirty page写入到disk中,这时agent需要等待。

为了避免agent等待,DB2page被选择位victim之前,就将其asynchronously写入到disk,使用page cleaner来完成任务(异步缓冲区写程序)。

每个bufferpool等维护着一个dirty list。当page cleaner被触发时,它们将list中的dirty page写入到各个对应的表空间。

 

2.      触发Page Cleaner的三种途径

1.     Dirty list threshold

参数CHNGPGS_THRESH所设定的,dirty pagebufferpool总页数的百分比

2.     LGN Gap

DB崩溃之后恢复时,需要从日志中重放数据记录,需要重放的日志量是:最新的日志记录,和日志中记录的对bufferpoolpage所做的最早更改开始的日志。

触发PageCleaner的条件是当需要重放的日志记录大小超过:logfilsiz*softmax时,即触发清理动作。其中,softmax的含义是:如果配置了520,那么值就是logfilsiz*5.2。(windows下默认有13log file

3.     Dirty page steals

DB2为一个agent选择了若干个dirty page达到一定的数量之后,则启动page cleaner进行清清除。这是同步写入到disk,需要agent等待。

三种情况各占的百分比可以用以下SQL Table函数获得:

SELECT DB_NAME,

POOL_LSN_GAP_CLNS,

POOL_DRTY_PG_STEAL_CLNS,

POOL_DRTY_PG_THRSH_CLNS

FROM TABLE(SNAPSHOT_DATABASE(‘SAMPLE’,-1 ))

as SNAPSHOT_DATABASE

在比较好的情况下,第三种情况应当只占总的page cleaner次数的2%以下。

如果发现第2种情况的page cleaner过少,则说明可能是logfilsiz*softmax值过大,分别查看这两个值,可以确定问题的原因。

 

3.      Page Cleaner是如何工作的?

当以上三种条件之一触发了Page Cleaner进程之后,所有的page cleaner都将开始工作。

每个page cleaner获取最多400dirty page,并且将它们一个个写入到disk。然后再查看是否还有更多的dirty page;如果没有则等待再次被触发。

 

4.      如何选择PageCleaner的个数?

过多的Page Cleaner将占用过多的系统资源(因为它们会同时被触发),所以,作为一个直观上的选择,选择与本机器CPU个数相同的Page Cleaner

 

5.      调优CHNGPGS_THRESH参数

该参数决定,当bufferpool中的脏页达到百分之多少时,进行page cleaner工作。对于一个大的bufferpool(如2GB),默认值80%过大,将导致严重的性能问题。应当适当调小。对于OLTP环境,应当进行启动page cleaner;而对于DSS环境,则没有必要。

 

1.      关于Prefetching

      预取由optimizer在生成access plan的时候指定,或者在restart recover的时候自动启用(可以用DB2_AVOID_PREFETCH来避免)。

      DB2在读取一个页时,它预计到需要读取与该页在同一个extent中的其他页时(一般来说是sequential detect),它将启动Prefetch,配置参数SEQDETECT可以不使用该功能。DB2 IO Servers参数也就是DB2 Prefetcher

      Prefetcher的工作时间与bufferpool的大小有关,较小的bufferpool无法容忍过于aggressiveprefetcher

      存在一个Prefetch Queue,由prefetch manager管理(它可以查看是否有预取请求可以合并),采用FIFO算法。队列的最大值为100

 

2.      两种Prefetching

1.     Range Prefetching

在执行sequential表扫描中,如果bufferpool中配置了block area,那么DB2将启动一个big block readvectored read,看OS是否支持;对于raw device,应当是毫无疑问支持的)将数据读入到一个private memory buffer中,再将这个buffer中内容copybufferpool中的block area

2.     List Prefetching

在扫描index的时候,产生了一个RID的结果集,需要将这些RID对应的数据预取到bufferpool中。List Prefetch可能被convertRange Prefetch

      与预取有关的环境变量:DB2_PARALLEL_IO

 

3.      选择Prefetching的大小

      对于一个拥有多个containerDB来说,算法一般如下:

prefetch size = extent size * number of containers

      如果只有一个containerRaid上,预取的大小一般为:

prefetch size = extent size * number of disks in the stripe set

      如果启用了DB2_PARALLEL_IO,那么将启动PrefetchingSize/ExtentSizePrefetcher,如果需要aggressive的能力(如在DSS系统中),扩大此值。如果没有启用DB2_PARALLEL_IO,那么,启动的Prefetcher个数等于container的个数。

 

4.      Prefetcher的其他功能

1.     Drop temporary objecsts

agentSQL请求中,可能需要建立system temporary tables来存储中间或最后结果集,为了加快agent的相应速度,将drop的工作给prefetcher来做。

2.     Add DMS container

Agent为第一个container分配空间,后面container空间由Prefetcher来分配。

3.     Resize DMS container

Add相似。

4.     TRAVERSING INDEX LEAF PAGES

在使用REORG命令的时候,需要Prefetcher来调整INDEX LEAFpages

1.      Create Bufferpools命令

                                     .-IMMEDIATE-.

>>-CREATE BUFFERPOOL– bufferpool-name –+———–+————>

                                       ‘-DEFERRED–’

   .-ALL DBPARTITIONNUMS———————————–.

>–+——————————————————-+—->

   |                           .-,———————–. |

   |                           V                         | |

   ‘-DATABASE PARTITION GROUP—- db-partition-group-name -+-’

>–SIZE– number-of-pages –  4 * ————————————->

>–+————————————+–  4 * ——————–>

   ‘-  1 | except-on-db-partitions-clause | -’

   .-  1 NUMBLOCKPAGES 0 ————————————————.

>–+—————————————————————-+–>

   ‘-  1 NUMBLOCKPAGES –  1  number-of-pages  –+—————————-+-’

                                     ‘-  1 BLOCKSIZE –  1  number-of-pages  -’

      .-PAGESIZE–4096———–.

>–*–+————————–+–*—————————>

      ‘-PAGESIZE– integer –+—+-’

                           ‘-K-’

   .-NOT EXTENDED STORAGE-.

>–+———————-+–*———————————><

   ‘-EXTENDED STORAGE—–’

except-on-db-partitions-clause:

|–EXCEPT ON–+-DBPARTITIONNUM–+——————————->

              ‘-DBPARTITIONNUMS-’

 .-,————————————————————————-.

 V                                                                           |

>–(—- db-partition-number1 –+————————–+–SIZE– number-of-pages -+–)–|

                              ‘-TO– db-partition-number2 -’

 

 

2.      一个DB需要多少个Bufferpool?

1.     Under carefully monitoring and tuning, DB2 can outperform much better than one single bufferpool.

2.     One single bufferpool needs no tuning, DB2 has a highly optimized algorithm for aging pages in bufferpools, like favoring index pages, put pages unlikely to accessed to ‘Hate Stack’.

 

3.      何时需要考虑使用多个Bufferpool?

1.     DBA wants to favor a particular application.

2.     Tables are always scanned seperately.

3.     Certain tables don’t need bufferpools.

4.     Operations like join, sort that needs large temporary tables in temp spaces.

tablespace可以使用指定的bufferpool

4.      Bufferpools带来的开销

      DB2 需要为bufferpool中的每一个page分配100 byte的描述符,占用的dbheap上的空间。也就是说,对于一个1GBbufferpool,需要消耗dbheap25MB的空间。因此,在扩展bufferpool之前,需要先扩大dbheap的大小。

 

5.      32-bit 环境下的DB2内存限制

      32-bit的环境中,每个进程的共享内存大小是有限的。DB2中,有如下参数对应的内存需要在bufferpool中分配:

1.     bufferpools

2.     locklist

3.     pckcachesz

4.     shared sortssort_heap, SHEAPTHRES_SHR

5.     dbheap (logbufsz, catalogcache_sz)

6.     util_heap_sz

AIX中,每个进程的地址空间包括了16个段,每个段256MB。在这16个段中,只有7个能够用于Shared Memory,也就是1.75GB。而在这7个段中,一个用于mapped memory I/O,另外一个用于FCM(fast communication manager, 用于partition之间的通信)

对于仅有很少文件个数的tablespacememory mapped I/O可以避免i-node的竞争。如果file个数多,可将DB2_MMAP_READ, DB2_MMAP_WIRTE设置为NODB2_FORCE_FCM_BP设置为NO可以关闭FCM

 

6.      Block-Based Bufferpool

      配置了NUMBLOCKSZBLOCKSZ两个参数之后,bufferpool中的部分区域是以block(多个连续的page)组织的。其作用在于:

      disk上预取的时候,是以extentNpage)的大小取得数据的,放到bufferpool时,可能分布在不连续的page上。在bufferpool中配置了一定比例的block area之后,预取的extent就可以放到连续的页(block)上了。

      extent的大小大于blocksz的时候,DB2将数据放到block中。当extent的大小小于blocksz的时候,DB2可能将数据放到page-based area中或block-based area中,取决于extentblocksz的差别有多大。

2007年02月08日

世界上第一个合格的程序员

【转载,英文原文参见后面】

多年以前有一个铁路公司,它的一位领导(可能就是商务方面的头儿)有了这样一个
发现,如果只给百分之五十的车厢配备厕所的话,原始投资将会大大地减少。于是,
他们决定就这么做了。

公司执行这项措施之后不久,关于厕所的抱怨就接踵而至。经调查发现,实际情况是
尽管这家公司还很年轻,但它已经存在严重的内部沟通问题,因为上头关于厕所的决
定并没有传达给调度室,所有的车厢都得到了同等的对待,于是有时候一列车中几乎
没有一个厕所。

为了解决这个问题,给每个车厢都加上了一些信息,用于区别这个车厢上是否有厕所,
调度室则需要在列车编组的时候尽量保证两种车厢的数量是相等的。这对调度来说无
疑是个麻烦事,不过问题解决之后,负责调度过程的人们都为此而非常得意。

新的调度过程实施之后,关于厕所的抱怨却依然没有平息。新的调查发现,尽管在一
列车中确实有一半的车厢有厕所,但有时候却把所有的厕所都编组在了列车的一头。
为了对此加以补救,上头又有了新的措施,规定带厕所的车厢和不带厕所的车厢应该
交替编组。这个方法的复杂度对于调度人员来说实在是太恐怖了,不过在最初的一番
唧唧崴崴之后,他们最终还是搞定了。

然而,抱怨仍在继续。调查出来的原因是,对于那些有厕所的车厢来说,厕所都位于
车厢的一头,列车中两个相邻厕所的距离仍然可能会有三个车厢的长度。对于那些有
紧急需要的抱小孩儿的妈咪们――尤其是过道上充塞着行李箱的时候――就会导致灾
难性的后果。结果是,给那些带厕所的车厢又加上了一点信息,将它们变成了带方向
的物体,新的规定是,在每个列车中,所有带厕所的车厢都必须是同向的。这一次,
调度人员收到新的指示的时候就差没疯掉了,因为调车转台的数目刚刚够用,如果要
完全公正地说的话,我们必须得承认,按照任何合情合理的标准,调车转台的数目是
不够用的,调度人员必须发挥极大的创造力才能勉强搞定。

等到所有的厕所都均匀地分布在列车中之后,公司有理由确信所有的事情都OK了,不
过乘客们依然在抱怨:尽管没有乘客离最近的厕所会超过一节车厢,乘客们(尤其是
有紧急需要的)不知道该向过道的那个方向开始他们的冲刺!为了解决这个问题,
写有“TOILET”的箭头被固定在了过道上。这就让另一半的车厢也变成了带方向的物
体,调度过程也必须对它们的方向进行正确地排列。

收到新的指令之后,调度室里充斥着绝望和反抗的情绪:这是不可能的!在这个关键
时刻,有个人站了出来,他的名字已经被遗忘了,而且也无从查证,他做出了以下的
分析。当每节带厕所的车厢都在它的有厕所的一头和另一节没有厕所的车厢配好对之
后,调度室根本无需再为N个两种类型的带方向的车厢而烦恼了,因为他们面对的将
是N/2个同样的单元,不管从哪个方面说,这些单元都可以被认为是对称的。这个分析
搞定了所有的调度问题,不过稍微有点代价,首先是每次只能向列车上加挂偶数个
的车厢――由此而增加的少量车厢可以从商务头目最初省下的那笔钱里面报销!――
其次,假定所有厕所的尺寸都是相同的。不过,谁会在乎那最后的三英尺呢?

尽管在发生这个故事的时候人类还没有计算机,但发现解决方案的那位匿名人物可以
当之无愧地被视为全世界第一个合格的程序员。

(Recently I found the following text in manuscript among old papers of mine. It must have been written in the middle of 1973, but I don’t think that in the intervening three years it has lost anything of its significance. Hence I now incorporate it in the EWD-series.)

A parable.

Years ago a railway company was erected and one of its directors –probably the commercial bloke– discovered that the initial investments could be reduced significantly if only fifty percent of the cars would be equipped with a toilet, and, therefore, so was decided.

Shortly after the company had started its operations, however, complaints about the toilets came pouring in. An investigation was carried out and revealed that the obvious thing had happened: despite its youth the company was already suffering from internal communication problems, for the director’s decision on the toilets had not been transmitted to the shunting yard, where all cars were treated as equivalent, and, as a result, sometimes trains were composed with hardly any toilets at all.

In order to solve the problem, a bit of information was associated with each car, telling whether it was a car with or without a toilet, and the shunting yard was instructed to compose trains with the numbers of cars of both types as equal as possible. It was a complication for the shunting yard, but, once it had been solved, the people responsible for the shunting procedures were quite proud that they could manage it.

When the new shunting procedures had been made effective, however, complaints about the toilets continued. A new investigation was carried out and then it transpired that, although in each train about half the cars had indeed toilets, sometimes trains were composed with nearly all toilets in one half of the train. In order to remedy the situation, new instructions were issued, prescribing that cars with and cars without toilets should alternate. This was a move severe complication for the shunting people, but after some initial graumbling [sic], eventually they managed.

Complaints, however, continued and the reason turned out to be that, as the cars with toilets had their toilet at one of their ends, the distance between two successive toilets in the train could still be nearly three car lengths, and for mothers with children in urgent need –and perhaps even luggage piled up in the corridors– this still could lead to disasters. As a result, the cars with toilets got another bit of information attached to them, making them into directed objects, and the new instructions were, that in each trains [sic] the cars with toilets should have the same orientation. This time, the new instructions for the shunting yard were received with less than enthusiasm, for the number of truntables [sic] was hardly sufficient; to be quite fair to the shunting people we must even admit that according to all reasonable standards, the number of turntables was insufficient, and it was only by virtue of the most cunning ingenuity, that they could just manage.

With all toilets equally spaced along the train the company felt confident that now everything was alright, but passengers continued to complain: although no passenger was more than a car length away from the nearest toilet, passengers (in urgent need) did not know in which direction to start their stumbling itinary [sic] along the corridor! To solve this problem, arrows saying "TOILET" were fixed in all corridors, thereby also making the other half of the cars into directed objects that should be properly oriented by the shunting procedure.

EWD594 – 1

When the new instruction reached the shunting yard, they created an atmosphere ranging from despair to revolt: it just couln’t [sic] be done! At that critical moment a man whose name has been forgotten and shall never be traced, made the following observation. When each car with a toilet was coupled, from now until eternity, at its toileted end with a car without a toilet, from then onwards the shunting yard, instead of dealing with N directed cars of two types, could deal with N/2 identical units that, to all intents and purposes, could be regarded as symmetrical. And this observation solved all shunting problems at the modest price of, firstly sticking to trains with an even number of cars only –the few additional cars needed for that could be paid out of the initial savings effected by the commercial bloke!– and, secondly, slightly cheating with regard to the equal spacing of the toilets. But, after all, who cares about the last three feet?

Although at the time that this story took place, mankind was not blessed yet with automatic computers, our anonymous man who found this solution deserves to be called the world’s first competent programmer.

* * *

I have told the above story to different audiences. Programmers, as a rule, are delighted by it, and managers, invariably, get more and more annoyed as the story progresses; true mathematicians, however, fail to see the point.

Platasnstreat 5                         prof.dr.Edsger W. Dijkstra
NL-4565 NUENEN                          Burroughs Research Fellow
The Netherlands

down了一个6.10的版本,用vmware安装了一下,网络用NAT,感觉不错。

安装系统之前,ubuntu先加载了一个可执行的系统镜像,所以安装时可以上网,呵呵。

我装的是中文语言包,装完了之后,选择系统->首选项->SCIM设置,把不需要的输入法去掉就可以了。

6.10版本的ubuntu如果选择安装中文包的话,默认的更新服务器已经是cn了,不需要修改,把/etc/apt/sources.list中的几个被#注释调的行恢复。

然后修改root密码(习惯了:),方法:
$sudo passwd root
先输入本用户的密码,再输入root新密码。

更新软件包列表:
#apt-get update
#apt-get dist-upgrade

居然gcc编译文件时链接出错,运行:
#apt-get install g++
安装完就修正了,gcc和g++都可用。

安装ssh,xinetd,vsftpd:
#apt-get install ssh
#apt-get install xinetd
#apt-get install vsftpd

刚安装完是不能访问ftp服务的,需要修改/etc/vsftpd.conf文件,把容许匿名登录去掉,把local_enable改为YES,保存退出。
#ps -ef|grep ftp
得到vsftp的pid之后,执行
#kill -HUP pid
之后就可以从外部访问ftp了。(和SuSE linux的管理差不多)

然后,把vsftp也委托给xinetd管理。基本上搞定。

播放器什么的,从ubuntu官方网站上看如何安装就行了。


数据库计算机(Databank machine)
Mel Beckman


一个被大家广泛接受但实际上并不正确的格言是—“每个人都有权利拥有自己的意见”。对于我们中间的任何一个人来说,我们总会在一些事情上没有资格发表自己的意见。例如,我就没有资格对外科颅内视神经微管手术说三道四—虽然我可以在互联网上找到这些术语。

不幸的是,人们在发表自己的意见时常常并不首先具备必要的专家知识,这在技术领域是一个非常常见的现象。基于Unix的数据库系统(特别是基于Linux的数据库系统)就是这样的一个特别容易产生如此怪论的话题。

我在此前的20年中一直在运行Unix和Linux的不同版本,而我总是发现数据库可靠性是这些系统的一个主要问题,它们经常会发生随机和无法解释的系统 崩溃。由于发生致命死机和处理过程被挂起的次数太多,以至于大多数Unix数据库管理员(DBM)为方便起见都将数据库的复位程序放在自己的监视器上。关 于应该如何解决这一问题,数据库开发人员有各种各样的意见,但我担心他们并没有资格在这一领域发表自己的意见。

我并不是说Unix数据库开发人员不够聪明。实际上,他们需要创建如此复杂、如同巴洛克建筑一般的软件“城堡”,并与“会飞的墙壁、魔毯和深坑”进行战 斗。我的意见是Unix数据库的开发人员没有这方面的发言权—他们深深地沉迷于自己周围的环境,对那些定义良好、能够解决Unix数据库可靠性问题的解决 方案视而不见。实现数据库可靠性的正确途径是使核心数据库功能成为底层计算机硬件的一个组成部分。拥有内建的硬件辅助数据库引擎的i系列架构就是使用这种 方法的一个非常好的例子。

i系列的数据库计算机(database machine)架构是一种有很长历史而又十分著名的架构,它最早出现在上世纪70年代的System/38中。通过将单级虚拟内存与抽象的机器指令集美 妙地结合在一起,i系列内建的数据库工具在概念上与最初创建时并没有什么变化。因为基础理念非常好,所以无论其“年纪”如何,i系列的数据库机一直都值得 使用和模仿。

与经常闯祸的Unix数据库不同,i系列数据库几乎不要求(人工)干预,但很少(如果有的话)崩溃。我从未见过一个崩溃的i系列数据库—尽管我认为在理论 上存在着崩溃的可能性。另一方面,我每个月都会因为莫名其妙的原因而需要对一些Unix服务器上的Oracle、Sybase、SQL Server、MySQL或Postgres数据库进行恢复。这些系统拥有广泛的数据库验证和恢复工具(如使人感到胆战心惊的Postgres Vacuum工具),而这一事实恰恰证明了它们内在的不可靠性。

IBM的i系列服务器之所以拥有这样高的可靠性,是因为它将尽可能多的数据库功能放在底层硬件上实现—这些功能以经过长时间检验、高度优化的微代码的形式 实现。例如,i系列有一条名为Create Index(创建索引)的机器指令,该指令的功能是创建一个完整的B-树索引。其它指令可以在这些机器实现的索引中插入或删除一个入口。使用单一存储虚拟 内存的系统使这些机器指令无需考虑磁盘和内存的分级—在它们看来,所有的数据和指令都在内存之中,而且只有一个唯一的地址。

需要指出的是,并非整个数据库都在硬件上实现,实现的只有关键的核心功能。在硬件上实现可以使这些功能更加高效、更加重要和非常可靠。将其封装到硬件之中可使其免受意外变化和数据库软件其它组件崩溃的影响。

在计算机架构中有一个很好的先例可以说明将数据库引擎嵌入到硬件中的必要性。很久以前,计算机曾经有很长一段时间不能执行数学计算,它们只能执行算术计 算。System/3处理器甚至不能执行乘法或除法,您会不会大声惊呼—还有这样的事!那时,当您需要执行真正的数学计算如浮点操作和三角计算时,您需要 购买一个数学功能库。当时有很多相互竞争的库产品,每一个功能库都使用自己专有的计算方法。由此导致的结果是,对于这些运行不同数学库的计算机,在进行故 障诊断时很难得到明确一致的答案。

最终,人们终于认识到解决这一问题需要通过标准。电气和电子工程师学会(IEEE)制订了一个机器表示标准,用于表示数字和执行基本的数学运算。这些标准 和算法被嵌入到数学协处理器之中,并最终直接嵌入到CPU之中。因此,现在的软件开发人员可以开发更加一致和可靠的代码,而且它们的引导速度更快。

现在,其它平台将核心数据库功能嵌入到硬件中的时机已经成熟,而i系列架构就是一个极好的值得效仿的典范。i系列架构的开发人员在选择应该将哪些数据库功能转移到硬件的问题上拥有数十年的经验。在未来应如何继续的问题上,我们完全应该请教他们的意见。


2007年02月06日

闲来无聊,也写一下听了几年歌的心得,说一说我喜欢的单曲,也就不管有的摇滚迷们鄙视我外行了(我曾经和一个重金属迷聊天,他认为,不喜欢重金属的都是伪摇滚迷)。

先给出一个列表,有兴趣再看我的评论:

1. November Rainby Gun’n’Rose

2. Smells like teen spirit, by Nirvana

3. Light my fire, by the Doors

4. Yellow Submarine, by the Beatles

5. Like a rolling stone, by Bob Dylan

6. 一无所有,崔健

7. We will rock you, by the Queen

8. Yesterday, by the Beatles

9. Ode to my family, by the Cranberries

10. God save the Queen, by Sex Pistols

 

1.  November Rain, by Gun’N’Rose

       这是一首以歌词取胜的名曲,但是其中的旋律同样触人心弦。虽然枪炮玫瑰的硬摇滚从来就不是我喜欢的类型,但是我一直对这首歌情有独钟。

歌词很平淡,但是有一种非常的感动,随着一些忧郁和希望。试着在阴冷的雨天抱着女朋友听这首歌。

So never mind the darknessWe still can find a way‘Cause nothin’ lasts foreverEven cold November rain

 

2. Smells like teen spirit, by Nirvana

       Kurt Cobain的愤怒,那个年代的青年的愤怒。

暴躁愤怒的家伙,摇滚王朝最后的统治者,被剥夺抚养权的父亲,深度吸毒者,用他的同样暴躁、狂怒的歌反击这个社会,这首歌是最出色的一支。但是,令他兴奋同时又矛盾的是,这个“社会”居然接受了他的音乐并且狂热地迷恋他的音乐。

       他用一颗子弹作了最后的反击。

 

3.  Light my fire, by The Doors

以我个人的性格,是不应当喜欢这样的歌和Jim Morrison这样的家伙的。但是歌曲中长时间随心所欲的配乐是吸引我的主要原因,其实每个人内心都在呼喊,Come on baby light my fire

 

4. Yellow Submarine

      Beatles的经典,同样是Lennon/McCartny的作品,由Ringo演唱。没心没肺的笑声,海浪声,杂乱的敲击盘子声,每当听起这首歌,就会忘掉一切烦恼,和他们一起哼We all live in the yellow submarine,仿佛自己就住在那Yellow Submarine中。

 

5.      Like a rolling stoneby Bob Dylan

Bob的嗓音难听无比,但是如果他自称写歌词第二,那么第一名肯定是留给了上帝。Like a rolling stone中虽然有他那个年代的一些音乐上的尝试,但是现在并没有什么特色。永垂不朽的是它的歌词。

When you got nothing, you got nothing to lose. 凡事想开点。

 

6.        一无所有,崔健

有人说他是教父,但是我觉得他更像是盘古,因为他开天辟地。这首一无所有,是现在从2050年龄段都有人喜欢的。也许数不清的年轻人吼着这首歌度过了他们的青春,还泡到了他们的MM

再重听这首歌的时候,我在想,为什么现在那些情歌那么多废话,唱完了还不知所谓?

 

7.        We will rock you, by Queen

       没有什么理由,简单地喜欢。还可以听听Queen的其他歌:Show Must Go On, We are the champions, Bohemian Rhapsody

 

8.        Yesterdayby Beatles

没有事情干的时候,回忆昨天是一个的选择。没有歌听的时候,听BeatlesYesterday是唯一的选择。

 

9.        Ode to my family, by Cranberries

在这支以和平为主题的爱尔兰乐队中,我特别喜欢这一首。当然,他们的Zombie是时代的经典。

 

10.    God save the queen, by Sex Pistols

来自英格兰的臭名昭著的乐队,恶毒地修改了国歌,在舞台上拿着啤酒瓶丑陋地扭动着,张大他们喷射着毒药的嘴巴:There is no futurein England’s dreaming

这就是性手枪,一个名字和他们的风格完全相符的乐队。

令人震惊。然后就是发泄。这是摇滚最重要的一部分,不是吗?

级别:低
重要命令:lsattr, lscfg, lsvg

1、  系统配置

可以使用prtconf命令输出完整的报告,包括:

系统型号、机器序列号、处理器类型、处理器数目、处理器时钟速度、cpu 类型、总内存大小、网络信息、文件系统信息、调页空间信息和设备信息。

# prtconf

使用prtconf的选项获取单独的信息,如:

# prtconf –s

获取CPU的时钟速度(MHz)。

也可以使用lsattr来获取系统的硬件信息:

# lsattr –El sys0

 

2、  各种硬件、配置信息

32位还是64位:

# bootinfo –y (硬件的位数)

# bootinfo –K (当前运行的内核的位数)

 

CPU的个数、主频:

# lsdev –Cc processor (个数)

# lscfg | grep proc (个数)

# lsattr –El proc0  (主频)

# prtconf –s (主频)

 

物理内存大小:

# lsattr -El sys0 -a realmem

# lsattr –El mem0 (一般来说,等同于上面的命令)

 

       内置硬盘空间大小(如果没有向rootvg扩充过硬盘):

# lsvg rootvg

 

       网卡个数(IP地址等):

# lsdev -Cc if

# ifconfig –a

 

Paging space信息:

# lsps –a (显示所有paging space

# lsps –s paging space的使用情况)

 

VG/LV信息:

# lsvg  (列出所有的VG)

# lsvg –o (列出活动的VG

# lspv  (列出所有的hdisk,即Raid级别)

# lsvg –l vg_name (列出VG上的所有LV)

# lslv lv_name (列出某个LV的具体信息)

 

文件系统(AIX5.2以上的df才有-g等选项)

# df –g  (-gGB输出,-m按照MB输出,-k按照KB输出,默认512byte输出)

 

3、  操作系统的版本信息

获取操作系统版本,机器名等:

# uname –a

 

       获取操作系统版本及ML版本号:

# oslevel –r

5300-04 (说明操作系统是AIX5.3 with ML 04)

# oslevel –rl 5300-04 (查看ML04缺少哪些文件集更新)

 

       获取所有软件包的版本号:

# lslpp –l

# lslpp –h pakage_name (确认特定软件包的版本号)

 

确认安装的单个APAR号,输入:

# instfix –l (列出安装的所有APAR)

级别:中高


1、  rmss:模拟较小的内存环境

使用rmss命令,可以限制只使用实际物理内存一部分。比如当前的物理内存是8G,如果想测试出程序在4G物理内存下的表现,那么这个命令就非常有用。

 

使用如下命令限制只使用4G的物理内存:

#rmss -c 4096

执行该命令之后,系统会根据当前的内存使用情况进行内存整理,将被限制使用的空间清理出来。这个时候,系统将非常繁忙。

 

需要解除限制,使用-r选项reset

#rmss –r

 

注意事项:这个命令只应当在开发、测试环境使用。必须具备root权限。

 

2、  bindprocessor:将应用程序绑定到指定CPU上运行

这个命令在调试线程死锁时常常用到。

绑定进程ID到指定CPU之后,该进程中的所有线程都将在指定CPU上运行,使用方法:

先查看系统的CPU情况:

#lsdev –Cc processor

或者使用vmstatp5+AIX5.2以上),但是注意如果启用了smtctl(同步多线程)功能,vmstat中输出的CPU个数会是物理CPU个数的两倍。

#bindprocessor process_id cpu_id

绑定后,可以查看下面命令输出的BND列:

#ps -emo THREAD

解除绑定:

#bindprocessor -u process_id

 

3、  tprof:查看程序的CPU使用情况

在做程序的性能调优时,这是个常常被使用的命令。

该命令输出程序的一个报告,当不打开与内核有关的选项时,对于C\C++程序,可以在函数级别对CPU使用率来排序;对于Java程序,-j选项可以在Java类和函数级别进行排序,输出的报告名为:program_name.tprof

用法如下:

#tprof -x program_name arguements

注意:tprof需要使用trace设备(/dev/systrace),因此,在运行tprof时,不能有其他trace在执行。

 

4、  svmon:监控程序的内存使用情况

AIX系统中,一直存在的一个问题是:无法准确获取系统的空闲内存和程序使用的物理内存。这和AIX系统的内存管理策略有关。

使用svmon可以看到系统和程序使用总虚拟内存大小(物理内存+paging space),监控一个程序时:

#svmon -P process_id

       监控系统内存:

#svmon –G

svmon命令还有非常丰富的选项,可以到:

http://study.chyangwa.com/IT/AIX/aixcmds5/svmon.htm

查看具体信息。