123
 123

2008-04-09 Wed

21:50 Oracle Wait Event:Data file init write (4168 Bytes) » Oracle Life

©作者:eygle 发布在 eygle.com

在一次周末的课程试验中,频繁的看到 Data file init write 等待事件。
在这里做一点记录说明,以下是来自跟踪文件的记录信息:
WAIT #2: nam='Data file init write' ela= 13031 count=1 intr=256 timeout=-1 obj#=51706 tim=6068271611
WAIT #2: nam='Data file init write' ela= 118163 count=1 intr=256 timeout=-1 obj#=51706 tim=6068392491
WAIT #2: nam='Data file init write' ela= 94036 count=1 intr=256 timeout=-1 obj#=51706 tim=6068490286
WAIT #2: nam='Data file init write' ela= 52412 count=1 intr=256 timeout=-1 obj#=51706 tim=6068545333
WAIT #2: nam='Data file init write' ela= 4 count=0 intr=32 timeout=2147483647 obj#=51706 tim=6068545596
WAIT #2: nam='Data file init write' ela= 26 count=1 intr=32 timeout=2147483647 obj#=51706 tim=6068545641
WAIT #2: nam='Data file init write' ela= 101743 count=1 intr=256 timeout=-1 obj#=51706 tim=6068648487
WAIT #2: nam='Data file init write' ela= 44854 count=1 intr=256 timeout=-1 obj#=51706 tim=6068694281
WAIT #2: nam='Data file init write' ela= 52841 count=1 intr=256 timeout=-1 obj#=51706 tim=6068748054
WAIT #2: nam='Data file init write' ela= 48984 count=1 intr=256 timeout=-1 obj#=51706 tim=6068798310
WAIT #2: nam='Data file init write' ela= 3 count=0 intr=32 timeout=2147483647 obj#=51706 tim=6068798365
WAIT #2: nam='Data file init write' ela= 26 count=1 intr=32 timeout=2147483647 obj#=51706 tim=6068798409
WAIT #2: nam='Data file init write' ela= 101899 count=1 intr=256 timeout=-1 obj#=51706 tim=6068900931
WAIT #2: nam='Data file init write' ela= 21 count=-1 intr=32 timeout=2147483647 obj#=51706 tim=6068901053

测试数据库是Oracle10g 10.2.0.3,实际上这个等待事件也是从Oracle 10g开始引入的,用来标识表空间或数据文件扩展时的等待。
Oracle 需要将系统块格式化为Oracle数据块,然后才能提供数据库使用。

在这个流程处理中,Oracle经过如下三个步骤:
1.扩展数据文件
select file# from file$ where ts#=:1
2.更新用户空间限额
update tsq$ set blocks=:3,maxblocks=:4,grantor#=:5,priv1=:6,priv2=:7,priv3=:8 where ts#=:1 and user#=:2
3.扩展数据段
update seg$ set type#=:4,blocks=:5,extents=:6,minexts=:7,maxexts=:8,extsize=:9,extpct=:10,user#=:11,iniexts=:12,lists=decode(:13, 65535, NULL, :13),groups=decode(:14, 65535, NULL, :14), cachehint=:15, hwmincr=:16, spare1=DECODE(:17,0,NULL,:17),scanhint=:18 where ts#=:1 and file#=:2 and block#=:3

这就是Oracle10g中空间扩展时内部流程。

-The End-

相关文章|Related Articles

评论数量(0)|Add Comments

本文网址:

19:51 Fast_provisioning (304 Bytes) » Uploads from dbanotes

dbanotes posted a photo:

Fast_provisioning

19:48 RAC最大支持100个NODE (235 Bytes) » Alibaba DBA Team

今天在看11G文档,文档中说:

 Oracle Clusterware supports up to 100 nodes in a cluster on configurations running Oracle Database 10g Release 2 and later releases.

不知道,有没有人真的用过?

19:37 建立人脉的原则及如何建立人脉?? (5288 Bytes) » 生活帮-LifeBang

俞敏洪老师讲过的一句话:你要想知道你今天究竟值多少钱,你就找出身边最要好的3个朋友,他们收入的平均值,就是你应该获得的收入

建立人脉的原则:

互惠

人和人之间都是相互的,所谓赠人玫瑰空手余香就是这个道理,如果我们只想拥有而不想给予,那将是一个自私的人,而自私的人是不会拥有真正的朋友的。

主动的去帮助对方,并且不要拒绝朋友的帮助,人是越帮忙越近,越不好意思越远~

互赖

互赖包括:互相依赖、互相信赖。“人”字本身就是一撇、一捺互相依靠,互相扶持

分享

分享是一种最好的建立人脉网的方式,你分享的越多,你得到的就越多。世界上有两种东西是越分享越多的:①智慧、知识;②力量。

两大好处:①你分享的东西对别人是有用有帮助的,别人会感谢你;②你愿意向别人分享,有一种愿意付出的心态,别人会觉得你是一个正直、诚恳的人,别人愿意与你做朋友

如何建立人脉?

第一、建立你的价值

在盘点人脉关系前,冷静问问自己:你对别人有用吗?你无法被人利用,就说明你不具有价值(比如说,职业规划无非是提升你的“被雇佣价值”),你越有用,你就越容易建立坚强的人脉关系

身边一位30岁的未婚青年这样对我说:“我的另一半应该在天平的另一边,我有多重,她就会有多重,我有多少价值,她就有多少价值,所以我要先提高自己的价值,这样我才能找到一个同样价值的老婆,我对老婆的要求就是我对自己的要求。”

当你用wp架好了一个空的blog,会立即去做宣传吗?我想不会有人这么做的,因为建立人脉并不是搞慈善活动。

第二、向他人传递你的价值

世界第一的推销员乔·杰拉德在台湾演讲时他把他的西装打开来,至少撒出了三千张名片在现场。他说:“各位,这就是我成为世界第一名推销员的秘诀,演讲结束。”然后他就下场了。

一个老好人,固然有趣但毫无用处,但一个总不愿被人利用的精明人,也难以建立真正的人脉关系。在人际交往中,要善于向别人传递你的“可利用价值”,从而促成交往机会,彼此更深入地了解和信任对方

在日常社交中,有两种心态不太可取:1是自我封闭,傲慢。2是愤青心态,以超脱自居

第三、向他人传递他人的价值,成为人脉关系的一个hub

你很有价值,你身边也有很多朋友各有自己的价值,那么为什么不把他们联系起来,彼此传递更多的价值呢?如果你只是接受或发出信息的一个终点,那么人脉关系产生的价值是有限的;但是,如果你成为信息和价值交换的一个枢纽中心(hub),那么别的朋友也更乐意与你交往,你也能促成更多的机会,从而巩固和扩大自己的人脉关系。
所以,寻找并且建立自己的价值,然后把自己的价值传递给身边的朋友,并且促成更多信息和价值的交流,这就是建立强有力的人脉关系的基本逻辑。

参考文章:http://www.brandmarketing.com.cn/article.asp?id=248

http://book.ce.cn/read/sell/xzpyhzsy/01/200707/20/t20070720_12247611.shtml

标签:,

相关内容

17:36 婴儿般的睡眠 (594 Bytes) » OracleDBA Blog---请享受无法回避的痛苦!

最近居然有了婴儿般的睡眠,是不是该恭喜偶了.

 

婴儿般的睡眠,不知道的人可以去google下那个笑话,俺除了睡醒没那个啥之外,其他的症状都非常相似呀,嗯,看来还是得整点药吃下.

 

PS:发现日子过的有点浑浑噩噩了,早上起来还想,今天周末了,明天可以一个人去西湖走走了,很久没去走过了,结果在工单系统给兄弟派单的时候才发现今天才周四呀.唉,这么算起来,今天才是我这个星期第二天上班而已,靠,这日子过的.

17:01 ORA-7445(qkabxo)错误 (550 Bytes) » yangtingkun
在10203 for Linux X86-64上又碰到一个ORA-7445错误。 错误日志中的信息为:Errors in file /data/oracle/admin/shandong/udump/shandong_ora_3202.trc:ORA-07445: exception encountered: core dump [qkabxo()+15] [SIGSEGV] [Address not mapped to object] [0x000000000] [] []由于错误SQL比较复杂,将问题SQL尽量的简化,得到最终错误SQL如下:SQL> EXPLAIN PLAN FOR 2 SELECT /*+ FIRST_ROWS */ * 3 FROM 4 ( 5 SELECT ROWNUM ROW_NUM, A.* 6 FROM 7 ( 8 SELECT 9 SALER.ORG_NAME SALER_NAME 10 FROM INF_SALER SALER , 11 INF_ENTER...
17:01 ORA-7445(qkabxo)错误 (550 Bytes) » yangtingkun
在10203 for Linux X86-64上又碰到一个ORA-7445错误。 错误日志中的信息为:Errors in file /data/oracle/admin/shandong/udump/shandong_ora_3202.trc:ORA-07445: exception encountered: core dump [qkabxo()+15] [SIGSEGV] [Address not mapped to object] [0x000000000] [] []由于错误SQL比较复杂,将问题SQL尽量的简化,得到最终错误SQL如下:SQL> EXPLAIN PLAN FOR 2 SELECT /*+ FIRST_ROWS */ * 3 FROM 4 ( 5 SELECT ROWNUM ROW_NUM, A.* 6 FROM 7 ( 8 SELECT 9 SALER.ORG_NAME SALER_NAME 10 FROM INF_SALER SALER , 11 INF_ENTER...
13:24 Tips and tricks: How do I configure a Linux guest to shutdown from z/VM? (3182 Bytes) » Red Hat Magazine

This is accomplished through the combination of the SIGNAL SHUTDOWN command from z/VM and /etc/inittab file in Linux. First, logon to z/VM as MAINT, then run the following command:

==> CP SET SIGNAL SHUTDOWN 180

This instructs z/VM to wait 3 minutes (180 seconds) for each guest to complete shutdown. Increase this value if there are services running that require longer to stop.

Next, add this command to the AUTOLOG1 user’s PROFILE EXEC to ensure it is set at each IPL of z/VM:

==> LINK AUTOLOG1 191 1191 MR
==> ACC 1191 T
==> XEDIT PROFILE EXEC T

From here, insert the following line:

'CP SET SIGNAL SHUTDOWN 180'

Save and exit with the ‘FILE’ command, then unlink the disk:

==> REL T (DET

Now, from the Linux guest, edit /etc/inittab and change the line:

ca::ctrlaltdel:/sbin/shutdown -t3 -r now

to:

ca::ctrlaltdel:/sbin/shutdown -h now

This instructs Linux to halt when signaled. Now, when ‘CP SIGNAL SHUTDOWN’ is performed (either by MAINT directly or during z/VM reipl or shutdown), the Linux guest(s) will shutdown cleanly.

Red Hat’s customer service and support teams receive technical support questions from users all over the world. Red Hat technicians add the questions and answers to Red Hat Knowledgebase on a daily basis. Access to Red Hat Knowledgebase is free. Red Hat Magazine offers a preview into the Red Hat Knowledgebase by highlighting some of the most recent entries. The information provided in this article is for your information only. The origin of this information may be internal or external to Red Hat. While Red Hat attempts to verify the validity of this information before it is posted, Red Hat makes no express or implied claims to its validity.

12:57 旧金山传递 (2122 Bytes) » Fenng's shared items in Google Reader

今晚不打算睡觉了,遥远地关注着旧金山。 摆在我面前的是,搜狐及奥运官网的网页,CNN,BBC 电视新闻,及凤凰卫视及CCTV4. 还不时有从前方我们的记者传回来的消息。

根据我掌握的信息,支持北京奥运的海外华人,留学生的人群的数量比抗议北京奥运,主张西藏独立的人群的数量多很多,到处飘荡着五星红旗和奥运五环旗帜,电视上,BBC有时候还会有一些这样的画面,也会提到不仅有抗议的人,也有pro-China (向着中国)的人,而CNN 就极其恶劣了,几乎看不到红色的旗帜的海洋,净是抗议的人群与宣扬西藏独立的旗子,还不时穿插着批评中国在达尔富尔问题的态度,西藏的抗议,理查。基尔,希拉里的抗议,声援。其中西藏的一个片段是一个被暴徒打的头破血流的人被救下来,却被解释为警察的镇压。。。 我看了后简直想呕吐!难怪世界上有这么多人主张西藏独立,他们可能连西藏的方位,西藏的历史的一丁点都不知道,都是西方媒体长期带有偏见的宣传造成的结果。

CNN在全球华人面前一而再再而三地丢尽了脸面!

理查。吉尔这种人代表了另外一种无知,世界上很多西方人因为精神空虚,压力大,开始信奉藏传佛教,瑜伽,印度教等等,他们盲目地把对藏传佛教的宗教式的热情转化成西藏独立的诉求,殊不知,一种精神的寄托是解决不了复杂的社会问题的,宗教不能当饭吃,但可以被利用来进行奴隶式的剥削。。。。 况且,西藏本来就是中国的一部分,喜马拉雅山脉挡住了当年英国殖民主义者的进犯,直到现在还可以看出西方人的耿耿于怀。

好了,先写到这吧,火炬传递马上就要开始了,不知道又要发生什么事情。

张朝阳 2008年4月10日3点55分匆匆写于此

 

12:12 How fast can MySQL Process Data (39898 Bytes) » MySQL Performance Blog

Reading Barons post about Kickfire Appliance and of course talking to them directly I learned a lot in their product is about beating data processing limitations of current systems.

This raises valid question how fast can MySQL process (filter) data using it current architecture ?
I decided to test the most simple case - what if we take the in memory table with very narrow row and run simple query which needs to do simple filtering - how many rows per second it will be able to do?

SQL:
  1. CREATE TABLE `m` (
  2.   `i` int(11) NOT NULL
  3. ) ENGINE=MEMORY DEFAULT CHARSET=latin1
  4.  
  5. mysql> SELECT count(*) FROM m;
  6. +----------+
  7. | count(*) |
  8. +----------+
  9. 1047684 |
  10. +----------+
  11. 1 row IN SET (0.00 sec)
  12.  
  13. mysql> SELECT count(*) FROM m WHERE i>0;
  14. +----------+
  15. | count(*) |
  16. +----------+
  17. |   349229 |
  18. +----------+
  19. 1 row IN SET (0.15 sec)

So we get 0.15 sec to scan about 1.000.000 rows which gives us peak filtering speed of about 7M rows/sec on this Intel(R) Xeon(R) CPU 5130 @ 2.00GHz CPU. This number is per core. In theory this box which has 4 cores should be able to do up to 4 times more, though in practice scaling factor is less of course.

Interesting enough if we get bigger table (so smaller portion of table will fit in CPU cache) the filtering speed stays about the same:

SQL:
  1. mysql> SELECT count(*) FROM m3;
  2. +----------+
  3. | count(*) |
  4. +----------+
  5. | 10476840 |
  6. +----------+
  7. 1 row IN SET (0.00 sec)
  8.  
  9. mysql> SELECT count(*) FROM m3 WHERE i>0;
  10. +----------+
  11. | count(*) |
  12. +----------+
  13. 3492290 |
  14. +----------+
  15. 1 row IN SET (1.49 sec)

To check completely in-cache scenario I created a table with just 10000 rows and wrote little stored procedure to make timing easier:

SQL:
  1. mysql> DELIMITER //
  2. mysql> CREATE PROCEDURE test_read(pl INT)
  3.     -> BEGIN
  4.     -> DECLARE t INT;
  5.     -> SET @x = 0;
  6.     -> REPEAT SET @x = @x + 1;
  7.     -> SELECT COUNT(*) FROM m1 WHERE i>0 INTO t;
  8.     -> UNTIL @x> pl
  9.     -> END REPEAT;
  10.     -> END;
  11.     -> //
  12. Query OK, 0 rows affected (0.00 sec)
  13.  
  14. mysql> DELIMITER ;
  15.  
  16. mysql> call test_read(1000);
  17. Query OK, 0 rows affected (1.37 sec)

So we can get 10Mil rows filtered in 1.37 sec giving us again a bit over 7M rows/sec.

This CPU is 2Ghz so we get some 280 CPU Cycles per filtered row, which is not that bad considering abstraction of storage engine which requires "row by row" processing which means function calls for each row.

Lets see if we do some row function on those 10.000.000 rows (to keep it simple)
(In reality I did multiple runs to get accurate results, but I show only one here)

SQL:
  1. mysql> SELECT sum(i) FROM m3;
  2. +---------+
  3. | sum(i)  |
  4. +---------+
  5. | 3492290 |
  6. +---------+
  7. 1 row IN SET (1.86 sec)
  8.  
  9. mysql> SELECT avg(i) FROM m3;
  10. +--------+
  11. | avg(i) |
  12. +--------+
  13. | 0.3333 |
  14. +--------+
  15. 1 row IN SET (1.97 sec)
  16.  
  17. mysql> SELECT avg(i+sqrt(i+1)+abs(i)) FROM m3;
  18. +-------------------------+
  19. | avg(i+sqrt(i+1)+abs(i)) |
  20. +-------------------------+
  21. |         1.8047401583918 |
  22. +-------------------------+
  23. 1 row IN SET (2.56 sec)

So as you see as we add some math the row scan speed is significantly affected.

I also decided to see how longer rows affect performance and created the following table:

SQL:
  1. CREATE TABLE `m4` (
  2.   `c` char(128) NOT NULL
  3. ) ENGINE=MEMORY DEFAULT CHARSET=latin1
  4. mysql> SHOW TABLE STATUS LIKE "m4" \G
  5. *************************** 1. row ***************************
  6.            Name: m4
  7.          Engine: MEMORY
  8.         Version: 10
  9.      Row_format: Fixed
  10.            Rows: 5000000
  11.  Avg_row_length: 129
  12.     Data_length: 685609952
  13. Max_data_length: 948528873
  14.    Index_length: 0
  15.       Data_free: 0
  16.  AUTO_INCREMENT: NULL
  17.     Create_time: NULL
  18.     Update_time: NULL
  19.      Check_time: NULL
  20.       Collation: latin1_swedish_ci
  21.        Checksum: NULL
  22.  Create_options:
  23.         Comment:
  24. 1 row IN SET (0.00 sec)
  25.  
  26. mysql> SELECT count(*) FROM m4 WHERE c>"a";
  27. +----------+
  28. | count(*) |
  29. +----------+
  30. |        0 |
  31. +----------+
  32. 1 row IN SET (1.16 sec)

So with a bit longer rows we instantly get 4.3M rows per second. And now if we look at the memory amount consumed by table we can see the filtering speed is about 600MB/sec which is surely small fraction of what memory bus capacity of this system can deliver.


Entry posted by peter | No comment

Add to: delicious | digg | reddit | netscape | Google Bookmarks

11:07 济南的大明湖 (2031 Bytes) » OracleBlog.cn

本周比较忙,要在济南做个数据库的迁移。届时,新主机在新机房上架,老存储搬去新机房。在第一阶段会进行迁移测试,然后会用rman追加归档的方式将数据迁移去新机。最后会把老存储dd到新存储。昨天和今天上午进行了迁移测试,测试结果ok,数据库打开都没问题。在工程的间隙,既然到了济南,就去看了看著名的大明湖。

总体感觉大明湖和杭州的西湖很像,都是“岸边杨柳”的风格,但是大明湖的做法就比西湖“不厚道”很多,进去还要买30块的门票,而且里面人工园林的商业味道很浓重,就一块猪肝形状的小湖,还不能环绕,只能由正门进东门出,或者返程。总之,大明湖名过于实,让我有些小小的失望……

下面是在大明湖的照片:(本人自曝pp一张,请将就着看吧……)

ps:济南下班时间的车可真堵!!17点半回去的时候,车在路上以龟速挪动-_-!!

10:08 Recovering from Loss of All Control Files (84 Bytes) » DBASupport
Follow these easy steps to restore a database when the control files have been lost.
09:50 SQL*Net break/reset to client (1 Bytes) » Tanel Poder's blog: Core IT for geeks and pros
06:53 农耕记 (11238 Bytes) » Fenng's shared items in Google Reader

我在村子里出生,虽然因为父母工作调动的关系,早早搬家到城里居住,但一直以农民的儿子为自豪。

小时候一直住平房,在我出生的屋子前面,是个小小的菜园子,还有一口土井。大概2岁左右的时候,趁着哥哥给钢笔吸墨水,把钢笔帽拿出来玩,结果掉进井里,我俩趴在井口,眼巴巴看着钢笔帽沉进水里,哥哥还试图用小桶把钢笔帽捞出来,未果。1979年,买一只钢笔要好几毛钱呐!后来哥哥就用一截玉米秫秸代替笔帽。至今还记得我俩在水面摇晃的倒影。

后来搬家到城里,住在城郊的一栋小平房里,虽然灰尘多一些,父母出于节省,冬季舍不得多烧煤炭,屋子里一直比较冷,不过很大的院子却带来许多快乐。院子非常大,刚刚给老爸打电话求证了一下,房子前面的空地,宽20米、长17米,屋后的空地长8米,总面积差不多500平米。(奢望一下,现在要是在城里有这么大的宅子,该值多少银子啊 谄媚  偷笑 不过,要是拆 迁就完蛋了,只能坚持当钉子 户。)空地的东南角,姐姐种了一棵龙爪柳,从小小的树苗一直长成粗壮的大树。这块空地,从1983年我们全家自农村搬到城里开始,就被勤劳的父母开垦成了菜园子,一直耕作到1992年搬家离开。

每年的五一前后,就开始耕作的准备。其实积肥等活计早在头一年的冬季就开始了,粪肥、小动物尸体、豆秸、塘泥什么的都堆积在一起发酵殴粪肥,开春的时候再把粪肥堆从中间翻开就可以了——这个在我老家的农活术语里叫做“倒粪”,刚跟老爸发短信确认的。具体的准备工作和种植大田差不多,先把地面上的垃圾清理一下,堆积在一起烧掉,不但清洁,草木灰还能肥沃土壤。接着是规划不同地块的种植品种,比如,种小白菜、生菜什么的地块要打成菜池子(菜畦)、种豆角、土豆、黄瓜、西红柿、茄子的地块要做打垅的准备。接下来用铁锹把土翻一下,疏松土壤,去除杂草。期间还要敲打土坷垃、上肥,然后用耙子平整,清理掉大块的粘土、石子、玻璃碎片等杂物,顺便修整一下灌溉用的小水渠、补补篱笆,差不多就可以播种了。而多年生的宿根蔬菜,比如韭菜,就没有这么多麻烦,简单清理、施肥就可以了,或者在韭菜分蘖、生长能力下降的时候,把老根挖出来换土、施底肥,去除死掉的部分。菜园子里种的韭菜,是从农村带过来的,每年都能吃到香喷喷的韭菜馅饺子和韭菜盒子。

除去小白菜和生菜,蔬菜的种子基本都是前一年留下来的。土豆不用种子,把前一年挑选、留下的长势茁壮、体型奎硕的土豆块茎切成几块,直接埋在土里就行。花花绿绿的豆角种子特别漂亮,经常被我拿来当玩具,比如画上嘴巴和眼睛,当成土人玩。有些种子要先发芽的,放在小盆子里浸泡,用纱布蒙好放在火炕上,最多一周就好了。

播种工作结束以后,如果不下雨,就要灌溉了。有钱的人家,买台白城地区的特产“小白龙”水泵抽水,我们这样节省的人家,舍不得一百几十块大洋,更舍不得电费,只好自己压水。赶上干旱的日子,春光明媚,暖风习习,龙爪柳上、前院的杨树林里常有鸟儿欢唱,听着收音机里放的节目,全家兴高采烈的压水灌菜园。我家的水井不大沉,但是井头有点高,小学三年级以前,要站在一块石头上才能勉强够得到井把(压水的杠杆),而且要使出吃奶的力气,把自己悬挂在压水的井把上,才能压出水来。后来,就没这么麻烦了。压水是个技术型劳作,不能压的太浅,会损伤活塞上的皮碗;也不能压的太快,否则很快就会双臂酸麻。压水要不急不缓,扎实有力。随着每次压水的动作,看着清澈、凉爽的水从水管子流进水渠、再流淌到菜畦里,想着不久就能吃到自己种出来的新鲜蔬菜,真是一件非常高兴和知足的事。

当时每天都坚持写“大自然日记”——小学三年级时,自然老师向竺可桢先生学习布置的细致作业,我坚持了很久。“大自然日记”每天记一页,记录包括气温、风向、风速、日照等气候条件,还有观察到的自然现象,比如植物开花、蚂蚁搬家、树叶落了等等,写在一个横格子笔记本上。后来,一个本子不够了,妈妈就用针线继续缝一本加进去,还加了个牛皮纸皮。可惜后来都丢掉了,想想真的非常可惜。那几年,我还到处采集植物的叶子,压在大辞典里,制作简易的植物标本,厚厚的一叠。(看来,从事植物分类学工作也是老天早就注定的害羞 )家里的仓房里存着好多《儿童时代》、《少年文艺》、《接班人》、《红小兵》、《中学科技》、《小学科技》等杂志,还有一套无敌的科普书——文 革版《十万个为什么》,放学回家后,除去写作业、跑出去玩,就是坐在仓房的门槛上专心致志看书。综合起来,可能对自然科学的爱好,都是那时候培养起来的。

我还自己动手用胶合板做了个简易风向标,是模仿气象站屋顶上的做的。在胶合板上画好图形后,费力的用小锯、剪子加工好风向标,再钉在一根大树枝上。后来风向标发现不够高,就用细铁丝捆绑在晾衣杆上,一直到1992年搬家的时候,风向标还在。记得做风向标的时候,爸妈一直在旁边鼓励、支持我,而且不提出任何改进意见,等到风向标做好了,爸妈还告诉我要收拾好工具,放回到原来的工具箱里。现在做实验之余,每每想起父母的教诲,看看现在孩子们做实验时乱七八糟的实验操作台,儿时的积累果然受益匪浅。小的时候大家都不是特别富裕,玩具什么的也非常简单,除了泥巴之类的自然产物,剩下的就是玻璃球、瓶盖之类的玩意,谁要是有一把玩具手枪、一整套积木、一列玩具小火车,都是值得长期炫耀的事情。我没有那么多奢望,好多玩具都是自己动手做的,小到风筝、大到火药枪,完全是自己动手、丰衣足食,至于后来发展成闻名遐迩的“破坏之王”,实属意外,不影响我现在做实验等的快捷、严谨和整齐。

八十年代末,姐姐已经出嫁,哥哥远在异地读大学,这样的耕作基本都是父母干,小学三年级以前我在菜园子里玩,后来大一些了,就干些力所能及的活。最常干的活是翻土和压水。刚开始的时候,每次只能翻一小块田,因为自己还没有铁锹高;后来就可以翻整个菜畦了,再后来可以翻上一整天,压水也差不多。后来一家三口一起干活,配合非常默契,直到现在,我仍然特别怀念那段在父母身边的时光。小学六年级的时候(特殊的年份,1 9 8 9),爸妈打算在院子里种葡萄。老家县城的土壤都是碱土,我家的地势还比较低洼,挖下去不到一米就是很厚重的粘土,葡萄不会成活,只能换土。换土需要挖很深的坑,把挖出来的土倒掉,再换上塘泥、粪肥。这项工作就由我来干。挑了一个天气特别好的星期天,从早晨就开始这项活计,先是挖一个一米宽、四米长的浅坑,然后加深。刚开始的时候还不是很繁重,后来越挖粘土越多,水分也越大,鞋底、铁锹上都沾满了粘土,要不断的磕掉才能继续干活。挖出来的粘土,用扁担、筐子挑到院子外面的河塘(其实就是臭水沟)里丢掉,再担回肥力很高的塘泥。兴高采烈的挖了一整天,挖的坑竟然比我的身高还深。现在想想,土方量惊人啊!估计现在怎么也干不动了!土换好以后,种了大概五、六株葡萄,看着葡萄苗越长越高,真是高兴极了,春季掐蔓、夏季搭葡萄架、秋季把葡萄藤埋在树叶、土壤里防寒,一样的高兴。眼看着长到第三年,终于结出小葡萄来,差不多每天都要看几次,祈祷葡萄早日成熟,梦想着坐在葡萄藤下赏月,可是,一场大雨,院子里变成了水泊梁山,全家防洪,门口用沙袋堵住,只能从窗子进出。别说葡萄了,房子都差一点倒塌。满胡同的积水抽走后,翠绿的小葡萄和葡萄藤一起烂掉了……那个郁闷啊!

ps:水淹七军等事,详见:http://smz77.blog.sohu.com/40583023.html

初三那年,搬家到楼房,终于实现了“一拉灯,那屋子里亮通通,自来水拧一下,水流哗啦啦”的理想,可是,学习越来越忙,没扩招时候的高考可是一把达摩克利斯之剑,要想改变自己的命运,不在老家县城里打杂、去要倒闭的工厂里苦捱,只能拼命学习,从此基本没有了耕作的机会。上了大学以后,帮苗先生、何先生耕作实验田,本来是件好事情,可是被一只石头苍蝇搅的恶心,干脆不去了。

这两天,又重操就业,在系办公楼下开垦了两小块田。先是铲掉绿化草坪,把铲下来的草皮运走丢掉,挑拣大石块,倒上买来的花土;然后翻土、继续挑拣石块、打碎土坷垃、放上收集的干杂草放火烧掉,最后用耙子平整。说起来挺轻松,可是土里的砖头瓦块实在太多,还有塑料袋、碎玻璃、烟蒂、铁丝、水泥渣、一次性纸杯等,没办法,谁让这是新盖的楼呢,到处都是建筑垃圾。基本上每挖一锹都要停下来,挑挑拣拣,竟然在草皮下挖出没去掉的二十几块水泥路砖来,可见这些绿化工作有多敷衍。最倒霉的是工具非常不顺手,铁锹把太长,而且不锋利,尤其那个烂耙子,不断掉头。刚开始的时候还非常牛,几十斤种的花土,我双手一悠,扔在肩膀上扛起来就走,后来就变成爬了……

经过连续两个下午的艰苦奋斗,累的要吐血了,终于开垦出两块小地来,总计15平米多一点。

唉,啥也不说了!

01:47 经济学不等于金融学 (4043 Bytes) » 玉面飞龙的BLOG
最近阅读了周洛华的“经济学家是我的敌人”,书中很多”实践过”的观点让我耳目一新。是难得将金融学讲的透彻的好书。推荐对投资感兴趣的各位阅读。 摘录一些书中内容在此。 如:资产价格与供求无关,资金收益与资金成本无关。人民币升值将导致房价下跌,而加息则无助于打压房价。投资因该对冲,而不应该组合。 消息面的误区 有投资界的朋友问今年的行情怎么样,我说”今天所有的利好消息(白天鹅)都是确定性的事件,我们已经能够预知其影响程度了。但是宏观调控和其他新政策有可能产生利空消息(黑天鹅)却是不确定的事件,今天无法预测它将怎样影响股市。”这是一个“北极熊市”的格局。牛市的格局应该正好相反:我们知道了最坏的情况,知道了“黑天鹅”和”冰山”的分布情况,利空消息对我们已经成为了确定性的事件;而利好消息的影响,却是我们无法全部预计的。 资金面的误区 诺贝尔经济学奖的获奖定理–米勒和莫迪利亚尼定理:资产负债表两边并不相关,融资成本和资产价值无关。资产价值只取决于其盈利能力和风险,而与资金的供应无关。简而言之,就是,好的项目一定会吸引到资金,而资金本身却无法堆彻出好的项目。 资产流动性的价值 国外的上市公司大多是全流通的,许多并购案可以通过资本市场的换股来实现。其意义在于,把资源交给那些更有能力的公司去经营。这样体现为资本的效率,体现为价值创造。一项资产,在你手中每年创造利润1亿,如果交给更有能力的人去经营,可能就有2亿的利润。因此,当一个公司并购另外一家公司的时候,往往出现股票价格上涨,这就是资本市场价值发现的过程,这个过程的核心是对经营能力的认可。 人民币升值 人民币升值,将使我们无法再依赖于外延式增长,我们股市会迎来一个普遍上涨的行情。只有那些掌握核心竞争力,具有竞争优势的行业龙头公司才能从升值的行情中受益。企业将通过提高效率,降低成本,提高产品质量,进入高利润的市场等内涵式的增长,做强自己,击溃同行业的没有竞争力的企业。那些没有竞争力的企业,其实是在人民币贬值时期,在银行贷款的积极配合下,才得以生存的。一旦经营陷入困难,这些企业将很快被淘汰。 股票的价值是公司的基因。 加息将使房价反升 爱因斯坦物理学认为能量存在于一切物质之中,现代金融学认为头寸存在于一切资产之中。什么是头寸?头寸就相当于立场。你做多了某项资产的同时,也就做空了另一项资产。如果我们看空人民币的实际购买力,那么我们应该如何行动呢?我们应该提前买入实物资产,这样就可以规避人民币币值缩水的风险。 所以,房地产作为一项资产具有“对冲人民币币值缩水”的“人民币空头”头寸的意义。大家买入房地产的根本原因就在于防止人民币缩水。这就是为什么房租一路下跌,而房价却在上涨的原因。提高存款利率向市场暗示了人民币未来有可能进一步贬值的信号。如果投资人将这一信号转化为人民币空头头寸,房地产价格就将进一步上涨。就像美元贬值时,投资人推高石油和黄金的价格一样,两者都具有做空美元的头寸。 尤其需要指出的是,此次长期利率的提高幅度大于短期利率的升幅。这就使人感觉到人民币在未来相对长的一段时间内可能加速贬值。因此,有可能进一步刺激投资人的买房热情。 金融学确实能够揭示生活中资产(能生钱)的价格,经济学也只能解释商品(吃完成便便)的价格。
00:30 Oracle Security 101 (Chinese Version) (0 Bytes) » del.icio.us/fenng/oracle
00:30 Facebook 的 PHP 性能与扩展性 (5207 Bytes) » DBA notes

作者:Fenng 发布在 dbanotes.net. FeedBurner 订阅数量,点击则可进行订阅

炙手可热的 Facebook 是用 PHP 开发的。随着一些技术交流,逐渐能看到 Facebook 技术人员分享的经验。近期这个 geekSessions 站点上看到 Facebook 的 Lucas Nealan 分享的文档比较有参考价值。

Cache 为 王

任何一个成功的站点都有一套最合适自己的 Cache 策略。

Facebook_Cache_Level.png

Note:这个层次图画的稍微有点问题,不是严格从上到下的。

The Alternative PHP Cache , APC

Facebook 平均每个用户每天要访问超过 50 个页面,PHP的页面载入时间的优化就比较重要了。在 PHP Cache 层,Facebook 采用了 APC

Lucas Nealan 的 PPT 举了一个例子,一个页面显示的时间从 4000 多毫秒降到了 100 多 毫秒。在 apc.stat 关闭的模式下,性能还要更好一些。不过需要重启动或用apc_cache_clear() 来通知更新。

PHP_APC.png

Memcached 层

APC Cache 的是非用户相关的信息,而用户相关的数据 Cache 当然是在 Memcached 中。

Facebook 部署了超过 400 台 Memcached 服务器,超过 5TB 的数据在 Memcached 中。这是当前世界上最大的 Memcached 集群了。也给 Memcached 贡献了不少代码,包括 UDP 的支持和性能上的提升(性能提升超过 20%)。

程序 Profiling

Facebook 开发人员大量采用 Callgrind 、APD、 xdebug 、KCachegrind 等工具进行基准性能测试。任何一个 Web 项目,这也是不可或缺,也是比较容易忽略的一环。所有开发人员都应该具备熟练使用这些工具的能力才好。

补充一下:语言的选择

为什么 Facebook 选择 PHP 而不是其他语言? 用Flickr 的 Cal Henderson 这句话就能说明了: "Languages's don't Scale, Architecture Scale"。

从 80-20 的原则看,APC 和 Memcached 是最主要的。在这两个环节上下功夫,受益/开销比要大于另外几个环节。

(上面的图是从 Lucas Nealan 的文档截的,版权所有是他的)

--EOF--

相关文章|Related Articles

评论数量(5)|Add Comments

本文网址:
最近作者还说了什么? Follow Twitter / Fenng

2008-04-08 Tue

23:55 数据字典表之:DBA_TABLES » Oracle Life
23:51 MySQL should have dynamic durability settings » MySQL Performance Blog
23:51 MySQL should have dynamic durability settings » Fenng's shared items in Google Reader
21:27 “阻挠”用户下载图片 » Fenng's shared items in Google Reader
20:53 去年网侠大会的照片 » Uploads from dbanotes
20:50 Web Scale Using Standby Reader Farms » Uploads from dbanotes
18:54 昨日手机上MSN了一把 » AnySQL.net
18:27 无题 » 柔嘉维则@life.oracle.eng
17:45 100万签名可让电影导演Uwe Boll退休 » Fenng's shared items in Google Reader
17:01 百度 城管 与 GFW » Oracle Life
16:01 ORA-7445(kkttrex)错误 » yangtingkun
16:01 ORA-7445(kkttrex)错误 » yangtingkun
14:09 EMC Buys 90s High Flyer Iomega For $213 Million » Fenng's shared items in Google Reader
13:37 Gmail at DreamHost » Fenng's shared items in Google Reader
13:01 COLLABORATE 08 Presentations » Oracle Security Blog
11:47 Oracle Critical Patch Updates Database Patchset Support » Fenng's shared items in Google Reader
11:42 阿里巴巴如何帮助千万中小企业过冬 » Fenng's shared items in Google Reader
09:26 Oracle Critical Patch Updates - Types of Fixes in Database Patches » Fenng's shared items in Google Reader
08:30 健康生活 » DBA notes
06:27 有助于你职场发展现在能做的15件事 » Fenng's shared items in Google Reader
03:56 随笔 » Think in 88
02:59 Zmanda Recovery Manager for MySQL 2.0 released » Fenng's shared items in Google Reader
02:25 Storage Engines at the MySQL Conference » Fenng's shared items in Google Reader

2008-04-07 Mon

23:53 baidu被城管了 » 玉面飞龙的BLOG
22:21 Performance testing - with curl » Fenng's shared items in Google Reader
21:39 小猪猪一岁十个月 » Ricky's Test Blog
19:44 生日—生病 » OracleDBA Blog---请享受无法回避的痛苦!
18:36 Skype 用 PostgreSQL 支撑海量用户 - DBA notes » Fenng's shared items in Google Reader
17:01 ORA-600(keltnfy-ldmInit)错误 » yangtingkun
17:01 ORA-600(keltnfy-ldmInit)错误 » yangtingkun
15:28 Tweaking Storage for The Cloud » Fenng's shared items in Google Reader
10:30 It has been a while... » The Tom Kyte Blog
07:41 update下 » Fenng's shared items in Google Reader
07:05 sequence » ilonng
06:41 肉包变成了小笼包 » NinGoo@Net