Tip: 看不到本站引用 Flickr 的图片? 下载 Firefox Access Flickr 插件 | AD: 订阅 DBA notes -- ![]()
2008-05-01 Thu
In the previous post I mentioned a way I use to preload Clustered Index (data) for Innodb tables. Though I thought this topic would benefit from a bit more information.
But lest first start with feature request for Innodb Team: All ways I mention here are hacks and they can’t be as efficient as native support. It would be great if Innodb would implement command to preload table to Innodb buffer pool, which would simply go through .ibd file sequentially and inject pages in the buffer pool. This would make preload done using sequential file scan even if indexed suffered a lot of page splits.
Now lets continue to the hacks
So As I mentioned you can load Innodb Table Clustered Index in the buffer pool pretty efficiently by using something like SELECT count(*) FROM tbl WHERE non_index_col=0 This works relatively well (though can be slow for fragmented tables) but it does not preload indexes in memory neither it does externally stored objects - BLOB and TEXT fields.
If you would like some non PRIMARY Indexes preloaded you can use something like SELECT count(*) from tbl WHERE index_col like “%0%” for each index. Only one such query per index is enough even if it is multiple column index.
To fetch BLOB/TEXT externally stored columns you can use similar query: SELECT count(*) from tbl WHERE blob_col like “%0%”. Note if you preloading BLOB/TEXT columns you do not need to use first query I mentioned because scanning potentially externally stored blobs will also scan Clustered key Anyway.
Now, say you have bunch of tables having few indexes - should you run multiple queries in parallel to get best preload speed ?
It depends - depending on key/clustered key fragmentation it may be faster to run queries one by one (keeping IO more sequential) or run multiple queries at once to get more outstanding requests at the same time - benchmark to find out.
If you just need to preload single large table you can chop it into several ranges and preload in parallel, such as SELECT count(*) FROM tbl WHERE id BETWEEN 1 and 10000000 AND non_index_col=0
Entry posted by peter | No comment
Recently I was working with the customer who need quick warmup - to get Innodb table fetched in memory as fast as possible to get good in memory access performance.
To do it I run the query: “SELECT count(*) FROM tbl WHERE non_idx_col=0″ I use this particular form of query because it will do full table scan - running count(*) without where clause may pick to scan some small index instead.
If your table is not fragmented one of two things should happen - either you should be reading at your hard drive sequential read rate or you would see MySQL becoming CPU bound if IO subsystem is too fast.
In this case however I saw neither - The vmstat showed read speed less than 10MB/sec which is very low for this system which had 6 15K SAS hard drives in RAID10.
Another indication of bad fragmentation was average IO size seen in SHOW INNODB STATUS output. It was around 20KB which means most reads are single page (16K reads). In case of non fragmented table you would see Innodb sequential read-ahead kick in which does reads in 1MB blocks and so you would see average IO size in hundreds of KB.
Now it is worth to notice you can see poor sequential scan performance even if table is not logically fragmented and Innodb is reading data in large blocks - this can happen in case Innodb table file is itself fragmented.
To check if this is the case I usually do “cat table.ibd > /dev/null” and watch IO statistics. If you see small IO request sizes in iostat and simply read speed. Like for the customer in question I saw file read speed of about 50MB/sec which is of course much better than 10MB/sec but well below RAID array capacity.
To check if file fragmentation is the issue or it is poor or miss configured IO subsystem I do another check by running cat /dev/sdb1 > /dev/null - Physical hard drive should never suffer fragmentation so you can get as much sequential IO as you can get (using IO pattern “cat” uses). In this case I got about 300MB/sec which confirmed file fragmentation is also the issue.
Interesting enough the “cure” for both fragmentation issues is the same - OPTIMIZE TABLE tbl - this command recreates the table by writing the new .ibd file (if you’re using innodb_file_per_table=1) which normally would be much less fragmented because it is written at once. Too bad however it requires table to be locked while it is being rebuilt and also it really only defragments clustered key but not the index.
P.S It would be cool to get Innodb objects (data and Index) fragmentation statistics which actually should not be that hard to implement.
Entry posted by peter | No comment
开始是盘算着把我写的blog印出来,几年来,我写了几百篇blog,字数不少,但我写blog很随意,什么都写。我写的成系列的东西不多,最近的装修日记算是一个,不过都是流水帐,而且这东西对别人的价值很小。想来想去,之前我写过一些的“细节思考”和“产品思考”,还有一些对产品经理职业的思考,还能算是成系列的东西,记录我对互连网产品设计的一些思考内容。之前我写过23篇,我的todolist里面还有2、30个选题,我打算多写一些这类的思考,然后将其印成一本书。我的计划大致这样:
1,系统整理选题,大致需要1周;
2,以每周2篇的速度完成新选题的写作,大致需要10周;
3,完善修改之前写过的选题,大致需要4周;
4,使用超印速提供的word模板进行排版、设计封面封底、写篇序,大致需要1周;
5,校对,大致需要2周。
全部需要18周,也就是4个多月,我的婚期是9月14日,我希望可以将其做为结婚礼物送给我自己。每篇文章最多也就几千字,每周2篇的速度看起来不快,但对于我来说压力已经不小了。这几个月我有很多事情要做,没有很多闲下来的时间可以仔细的梳理我的想法,我只能抽空做这件事。而且每篇都需要仔细的思考,也需要一些调查和研究,根据之前的经验,每写一篇都非常不容易。而且每篇都还需要再加工,逻辑、段落、文理、遗漏,这些都需要大量的时间。这对我的时间管理能力提出了挑战,虽然很忙,但我希望可以完成这件事。这本书预计10万字左右,32开,5号字,大该有140个页码,至少应该有0.5厘米厚,哈哈。
写个字儿,出个书,现在已经不是什么新鲜事儿了,我现在搞这件事儿,自己也觉得挺土的。相比那些著书立说的朋友,这就是个小儿科,只是对我来说,这是的一次。书名还没想好,现在看不容易,有几个东西需要体现,互连网、产品经理,细节。
How did Mark Proctor get started on the Drools project and–more importantly–why? (To get caught up on what Drools is and find out who Mark is, see the first part of this video.) Hear about how an interest in artificial intelligence drew Proctor in and what sort of university developments and business uses keep him–and the project–going.
And if you enjoy this kind of access to smart developers speaking about the projects they’re passionate about? Then you’ll want to join us at the Red Hat Summit. Or catch some more of the highlights from JBoss World 2008. That’s where we filmed this piece, and so much more. Enjoy.
Sun is aggressively pushing T2000 as Scalable MySQL Platforms, and indeed it is Scalable in terms of high concurrency workloads - it is able to execute a lot of concurrent threads and so speed gain from 1 thread to say 32 thread will be significant.
But thing a lot of people miss is - Being Scalable is Not Enough - you need to scale from reasonable base to claim the good performance, and this is where T2000 performs subpar in many cases.
I often hear about people complaining queries take much longer on T2000 compared to recent Intel or AMD CPUs when there is no concurrent load - It is reported T2000 can be as much as 5-15 times slower in this case depending on the workload.
Here is example run of purely CPU consuming "Benchmark" function for 2.6Ghz Intel Xeon vs T2000:
-
# XEON
-
mysql> SELECT benchmark(100000000,1+2);
-
+--------------------------+
-
| benchmark(100000000,1+2) |
-
+--------------------------+
-
| 0 |
-
+--------------------------+
-
1 row IN SET (1.50 sec)
-
-
# T2000
-
-
mysql> SELECT benchmark(100000000,1+2);
-
+--------------------------+
-
| benchmark(100000000,1+2) |
-
+--------------------------+
-
| 0 |
-
+--------------------------+
-
1 row IN SET (18.89 sec)
As you can see this is hell a lot of difference !
Depending on your application performance with single thread may be important or non important for you - it is surely important for the slave if you're having active replication, if you're running time sensitive long running CPU bound queries or if queries contribute significant time to generating web page.
For example if on Xeon queries take 50ms to generate the page, the MySQL Latency you may see on T2000 may be as high as 500ms which would be well above performance guidelines for many web applications.
I'm hearing Sun is working on new CPUs which would offer significantly higher single thread performance, but at this time I have to be very careful advising this platform to the customers.
Entry posted by peter | 7 comments
大家都说Google PageRank又更新了,但我却一直没有注意到存储部落的Google PageRank值有没有变化。今天猛然看到Google PageRank已经升到5时,心里一阵阵的狂喜,回头想想Google PageRank升到4订阅数超过100时的日期,好像也只是几天前的事情。
这个网站从去年5月份正式开张,到今天差几天一年时候。这一年时间内大多数的晚上和周末都忙于修改博客,写文章,有时想想真的很累,但心里却已经放不开了。一天不上来看看,就会坐立不宁,什么事情也做不了。
呵呵,Google PageRank升到5,首先要感谢经常来访问存储部落的朋友,正是大家对存储部落的喜爱使得我有充足的信心将网站继续下去。
通过存储部落,我也获得了很多好处。现在外出做技术交流时,60%的客户中就有一个技术工程师上过我的网站,有的差不多时天天访问。很多人说他是我的粉丝,呵呵。因为这些粉丝,我的工作成效提高了很多,我支持的项目的成功率也比以前提高了很多。
感谢大家!希望大家继续支持存储部落。
作者:Fenng 发布在 dbanotes.net. ![]()
好多 Windows 平台的 DBA 一定比较烦操作系统升级时 "重启动才能生效" 这个问题,可能就是因为这个原因,可能没多少人愿意管理 Windows 平台的数据库。其实 Linux 有的时候也有类似的毛病,对 Kernel 打 Patch 基本也要重启动操作系统,除非你不去理它。而最近 Slashdot 一则关于 Linux 的新闻值得关注, Ksplice: Rebootless Linux kernel security updates,对于非常关注系统可用性的 DBA 来说,这是个很关键的技术改进。
提高可用性技术,前期细致周密的规划是重要一环。比如大文件系统的 fsck 问题,默认情况下达到一定 mount 次数或者超过一定时间,系统会自动启动 fsck 检验操作。而一个运行一段时间的 Linux Server 如果崩溃 reboot 后,文件系统校验时间漫长的叫人绝望。如果最初对这个问题进行预处理,即可避免不必要的停机时间。
另外维护中能尽量积累那些"可用性高"的技术或技巧也是必不可少的。比如 Kernel 重新读取分区表的问题,Fdisk 命令是搞不定的,而这里提到的 partprobe 命令 刚好派上用场。
以前我也记录过类似 Linux 如何不重启而识别新增的 LUN 的话题,积少成多,也就有用了。
--EOF--
相关文章|Related Articles
评论数量(0)|Add Comments
本文网址:http://www.dbanotes.net/arch/linux_availability.html
最近作者还说了什么? Follow Twitter / Fenng
作者:Fenng 发布在 dbanotes.net. ![]()
炙手可热的 Facebook 是用 PHP 开发的。随着一些技术交流,逐渐能看到 Facebook 技术人员分享的经验。近期这个 geekSessions 站点上看到 Facebook 的 Lucas Nealan 分享的文档比较有参考价值。
Cache 为 王
任何一个成功的站点都有一套最合适自己的 Cache 策略。
Note:这个层次图画的稍微有点问题,不是严格从上到下的。
The Alternative PHP Cache , APC
Facebook 平均每个用户每天要访问超过 50 个页面,PHP的页面载入时间的优化就比较重要了。在 PHP Cache 层,Facebook 采用了 APC。
Lucas Nealan 的 PPT 举了一个例子,一个页面显示的时间从 4000 多毫秒降到了 100 多 毫秒。在 apc.stat 关闭的模式下,性能还要更好一些。不过需要重启动或用apc_cache_clear() 来通知更新。

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
评论数量(10)|Add Comments
本文网址:http://www.dbanotes.net/web/facebook_php.html
最近作者还说了什么? Follow Twitter / Fenng
明天就是五一假期了,同事都已放假。我不打算在假期加班,因为加班也无事可做,手头上的工作都需要与人合作。
前几天和新同事吃夜宵,大家聊的异常兴奋,我也忍不住开始想当年。当年那些美好的日子,记忆已经很模糊了。我想再过个两年,估计我都不能准确回忆起那些曾经对我影响深刻的日子准确的时间。是时候记下点什么,对自己是一种纪念。
我这人有个优点,选择性记忆,那些不快的回忆很容易随风而去。活在我记忆中的人们,对他们只留下感激。我也曾经爱写日记,很早我就写电子日记,记在自己的机器上,PDA 上,当我有一些不愿意再回忆的事情时,我会个将整个文件加上密码,长长的一次性密码,保证自己只能记住一小段日子。当这段日子过去,密码就消失在记忆中。然后再也打不开这些文字,等到下次更换硬盘,无论我多么的想再看一眼当年的自己,也无能为力,只好把加密过的文件删去。
我想我就是这么成长过来,没有什么挫折的感觉被反复咀嚼,都已经抛在脑后。生命中没有什么不可以失去的,这个道理很早就明白了。我曾经懊恼过丢失了大量的源代码、自以为写的不错的文章、早年的聊天记录、珍贵的日记、数年的电子邮件…… 最后我明白了,一切的一切不过是身外之物,我能拥有回忆中最美好的部分,那么已经是特别幸福了。
不过也正是如此,以下的记录也只能是我努力的回忆。或许因为时间久远,跟真实有所偏差,或许从我的角度只看到的事物的一面,但是、我可以保证,并没有故意在叙述中掺差虚假的东西。
是的,我想讲一个真实的故事,一个拥有数千万玩家的游戏诞生的故事。我并不喜欢这个游戏系列本身,但是我为这个产品自豪。我的代码曾运行在几千万用户的机器上,作为一个程序员,还有什么比这更让人满足的呢?也许有,比如让这个用户数量再扩大 10 倍。
认识“古月”还是我读大四下学期的时候(2000 年初)。有一天,他在 QQ 上蹦出来,问我一些“风魂”的问题。我当时上网主要在泡 sina 的游戏制作论坛,“风魂”就是那几年写的游戏之作。
更早的时候,我比较喜欢在 dos 下写点东西。研究一下 allegro 这个游戏开发库。我翻译了 allegro 第 3 版的所有文档(为此还自己做了一个辅助翻译工具),这项工程耗去了很长的时间,从 98 年开始到 99 年中,业余时间我几乎都在维护这个东西。为了翻译不出差错,同时也阅读了大部分 allegro 的源代码,从中学习到了许多游戏引擎的理念。
那些日子,时常在 allegro 的 maillist 说几句话,为一些代码做优化并迅速被 allegro 开发社区吸收进去。同时我也提出了许多自己的想法。不过由于新的想法需要对 allegro 的接口做调整,这是一个成熟的库不可接受的,和 allegro 的原作者 Shawn 通 email 的过程中,Shawn 用很友好的语气说,如果你觉得那样比较好,为什么不自己做一套东西出来?然后我就做了,甚至第一个版本在 allegro 的 mallist 中发布。有人说,这样的东西没什么意义,allegro 已经够好了(当时已经有了 Windows 版)。Shawn 还帮我解释。
哦,我说的就是“风魂”。甚至不到一个月,风魂就有了一个匈牙利用户,他还用它做了一个小游戏。
这是 1999 年 3 月 4 日到 3 月 8 日的事情。我在网吧通宵了三个晚上把风魂的第一个版本完成。之所以日子记的这么清楚,是因为我查到了当年留下的一份记录文档。开发环境是 MSVC 5 ,因为我不愿意(也没有足够的硬盘空间)装 IE4 ,所以没有安装 6.0 的 VC 。
“古月”,就是天夏的 client 主程,也担当了后来大话西游1 的 client 主要逻辑的编写工作。那个年代,精通 Windows 写游戏编写的人不多,我也只是稍微熟悉而已。很多人刚从 dos 年代过来不久,DirectX 的中文资料很少,且比较难查到。我很能理解他们选择使用“风魂”这个学生作品的缘故:开源 + 使用简单(简单的 C 接口) + 高效(在硬件条件受限的时候,我在软件优化上下了许多工夫)。
天夏这个小公司当时正在开发一款图形 MUD ,名字就叫“天下”。当时估计有很多 mud 迷想把 mud 图形化,但是做出来的产品寥寥。我只记得有一款叫作“笑傲江湖”的所谓图形 mud ,仅仅只是给文字 mud 加了点图片而已。真正意义上的图形化还没有人完成。
显然,天夏的开发团队也没有前人的经验可以追寻,甚至他们没有开发过单机游戏。忘了当年“古月”问了我一些什么,只是最后,他想请我帮忙做一些模块,可以让游戏开发更简单一点。这个工作是有酬的,这点吸引了我。要知道当时都是穷学生,我连买块硬盘的钱都没有,显示器也已经严重老化(93 年购入的时候已经是国外的电子垃圾,不知道服役过多少年了), 我的开发机器中的 CPU 是网友的公司赞助的,主板是编程比赛的奖品,内存条这些配件用的先前一些兼职工资买的。
所以,任何一个用自己的技能赚钱的机会都不会放过。这样,我又认识了 micro ,天夏当时的头儿之一,据说他当过 mud 的巫师,也写一些服务器的代码。不过后来我们见过面之后,一起在网易共事的日子里,几乎没见他再写过什么代码,这些是后话了。
我写了一个支持 Z buffer 的 2d 模块。这样,他们可以简单的处理 2d 游戏中 sprite 的遮罩问题。因为需要让当时配置比较差的机器(486)能跑起来,我尽可能的用汇编优化。这些工作耗费了我一两周的时间。
快完成的时候,我在网上询问了朋友(逆火的庞鑫,他与我同届,但是他在大学期间已经发行了一个游戏了:天惑),庞鑫告诉我说,他们为了养活自己的工作室,时常也接一些单来做。这样的单大约应该开个 1500 的价。当时我天真的觉得,1500 实在是个天价,要知道 97 年的时候,我帮人用 delphi 1.0 做了一个完整的软件也才拿了 600 多点,那个用了我半个暑假。
所以我跟 micro 提的价码是 1000 。有点意外的是 micro 还是觉得有点高了,不过我理解他们的艰辛(当时是一个很小的工作室,没有什么投资,几个人自己在弄),重新核算了一下,把自己花掉的时间统计了一下。按每小时 20 块(比家教的水平高多了,当时就这么想的)得到一个大约 500 的数字,micro 把款打给了我。这就是我和天夏的第一次合作。
btw, 具体的数字我记不太清了,只能说大约这个数量级吧。大学毕业后我就再也没缺过钱用,对钱的数字极其不敏感,所以忘的快。
毕业的第 2 天,我去了北京。在创意鹰翔待了三天。林广利是我很好的朋友,我看他似大哥一样。他邀请我去的北京。鹰翔当时的情况看起来不是很好,不过我不太所谓。总算毕业了,我觉得我自由了,再也不用看老师的脸色,不用应付烦心的考试,不用担心课堂点名……
当被问及我们应该重新开始做个怎样的游戏时,大家并没有想到网络游戏,虽然那个时候石器时代已经开始流行。我听到的圈子里的说法是,“目前国内有 200 个网络游戏正在开发,明年至少有 20 个上市,再开始做已经晚了,也没啥意思”。事实上,2001 年并没有那么多国产网游被开发出来,我所熟知的一个:大话西游,可耻的失败鸟 :D
那几天我们讨论了许多,但是不知道为啥,我始终没什么兴趣。我不知道我需要什么,但是我知道那些不是我想要的。
逆火工作室在创意鹰翔对面的院子里,我联系庞鑫出来聚一下的时候才发现这一点。太巧了,北京如此之大,此刻又如此之小。
庞鑫是个典型的北京人,说话极富煽动性(会忽悠?不过人家也的确有真本事)。我 98 年在北京参加一个大学生计算机比赛时,认识的他。他倒不像我是参加编程部分的比赛,而是展出他的 3d engine 。98 年,3d 显卡还是很稀罕的年代,所以我很是佩服。
庞鑫试图说服我加入他们的工作室,跟随一个投资者(yan dan ,那个时候听说很有名,他说他帮过许多人,比如雷军)做手机的软件。据说很有前景。EPOC 系统,我第一次听说,现在已经改叫 Symbian OS 了。我们为 EPOC 做一个 3d 游戏引擎,应该很不错的。我可以做我最熟悉的一块,在 arm 处理器上,用 arm 汇编优化 2d 部分(因为手机当时还不能配备 3d 硬件,都是软件实现,最终都需要转到 2d 显示)以及一些底层核心代码。
安宁(后来为天下 2 写了几年的程序)当时也在那里,我挺喜欢这个人,他曾经用汇编写了一个软件 3d engine 。符合我心目中的牛人标准。
庞鑫的说服工作只用了几个小时就成功了。我给林广利打了个电话,他只是叹气而已,没太说什么。我就直接住进了逆火工作室租的那间大屋子。
那段日子过的挺自在,都是一帮好朋友,住在一起,半夜饿了就打车出去永和喝豆浆。白天叫些外卖。伴晚时分,也出去闲逛。我在北京有很多朋友可以一个个蹭饭 :)。几乎都是游戏圈子的。比如,最早拉我进入这个圈子的王欣(八爪鱼工作室的负责人);为无数国产游戏“擦过屁股(修补 bug 并完成游戏好拿出来卖)”的余雪松(可能说起后来的 kele8 大家更熟悉一下)等等。
这段日子一直过到天气开始转凉。我还清晰的记得那一天,有人通知我们第 2 天去深圳见风险投资的公司代表。我们连夜做了 PPT ,赶上第 2 天早上第一班飞机南下。我们只在飞机上打了个盹就被拉到另一个合作的团队的驻扎地。这个团队当时叫做 wass ,后来其主干有建立了家新公司唤作“数位红”,现在好象已经不存在了,不过应该 google 的到。
原来投资商是再后一天从新加坡去广州的。我们在深圳只是再准备一下。这次让我领略了该怎么忽悠风险投资 :)我们掐着秒表准备演讲内容,甚至连中场休息的笑话都是预备好的。
我的部分不太需要准备,反正不是说大话,怎么想怎么说即可。所以得以有两三小时的睡眠。等天再此蒙蒙亮的时候,我们已经上了去广州的 taxi 。几乎是一睁眼就到了,除了困,我什么都不记得了。
我和庞鑫的演讲部分安排在最后,会议室里,我们拼命的喝着不加糖的咖啡,中间上了三次厕所。我和站在外面吸烟处猛着抽烟的新哥们相似而笑。 40 多小时没怎么合眼。大家都困死了。
投资商是宏基,看起来比较重视,派了个元老过来谈的,带了很多人。我和庞鑫的演说很成功,想来是因为我们年轻,表现的相当有激情,甚至还为技术细节吵了两句。说完了我们就回房间睡觉去了。晚上有人来敲门的时候,已经带着好消息。
虽然我们要求的四百万美刀没有被答应,不过对方还是答应投资 1.5M 。我们这大摊子人一共保留多少股份不太记得了。只记得逆火工作室的哥几个分到百分之十几。
我们需要签四年的合同,合同很厚很厚,回北京后还安排了律师给我们讲解。我觉得学到了许多。只是最后签字前的那一晚,我想了一个问题:这是不是我的追求,我要的人生?
庞鑫曾经跟我说,没错,如果我们有 15w RMB 我们就可以自己干。即使大家现在一无所有,只要有技术,无论做点什么,不需要多少时间就可以赚到这么多钱,然后开始做自己更想做的东西。但是,或许有更好的路,让我们就有更高的起点,节约我们的生命。我知道逆火的兄弟曾经过的很辛苦,《天惑》做了三年多,只卖了五万块 RMB ,而且出版商还拖欠款项很久。但是我没有亲身经历,我不喜欢手机这个开发平台,离我的想法太远。
在那个大屋子里,大家围坐在一起,劝我不要走。我也很犹豫。负责投资的那个头儿接了电话过来,只问了我是否真的想离开。我说,我不确定,但是我知道,这些不是我想要的。这句话,很多年后我又说过一次。每次说出来,都得到了理解。就这样,我离开了这个团队。
下次再接着写吧,我想会一直写到梦幻西游的成功,是个很长的故事,不知道有没有朋友会一直读下去。我只是想记录这几年的历程,没有读者也无所谓。
注:本文全凭记忆复述,和事实或有偏差。如以后发现错误之处,会尽量修正。顾谢绝转载。
我在北京生活了半年。接触北京这个城市要更早一些。大约 85 年的时候去过,一周时间几乎玩遍了北京所有的景点。小时候的记忆特别美好,我在那个时候爱上了北京。记忆中,天安门广场是那么的大,紫禁城的宫殿如此雄伟…… 以至于回到学校时,不知道用怎样的形容词才能形容。
10 多年后,我在学校的机房上网,泡 bbs ,做个人主页,写一些关于游戏的自己的想法。交了许多的网友。大家都是业余的,年轻气盛,想自己做出好玩的游戏。王欣是第一个给我发 email 的职业游戏人。更早的 97 年,国内有两家大的游戏公司,前导和腾图,有如台湾的大宇和智冠。可惜生不逢时,前导做不了大陆的大宇,腾图也远不及智冠。
腾图命中注定的散掉,王欣的八爪鱼工作室从腾图分的出来。98 年,王欣邀请我在假期去北京玩,他把我带进游戏这个圈子。我又有机会站在天安门广场,原来并没有那么大。我想,如果毛泽东纪念馆挪一下地方的话,广场会更宽广一些,和我儿时记忆中的一样。小时候怎么就没这种感觉呢 :) 。
那个年代,我成月成月的逃课,去北京帮王欣做些兼职工作,并听他说些早年北京游戏圈子有趣的八卦,有如今天我给新人说起往事。回忆起来,自己其实什么也没做,似乎又做过点什么,反正最后一次,我拿了一小笔兼职工资。不过没有花掉,因为回到学校的时候,一个同班同学缺钱交学费,我全部借给了他,毕业那天他才凑起来还我。
当然,身在北京,我就有机会四处拜访网友同好。随即发现,其实许多网友都已经专职在做游戏了。有些人后来再没怎么联系,比如曾经在金洪恩做《自由与荣耀》的 3d engine 的 riso ,我还记得他在那个晚上,他抱怨他的后继者让代码从几万行膨胀到十几万;又比如做《独闯天涯》的郭巍,他念叨过来北京前没有钱吃饭,小组里每个人一个冷馒头就可以啃一天,脑子里只想着把游戏做出来 ……
两个很重要的朋友,也是在那段时间见的面 —— 余雪松和吴东黎。我们通过在网易个人空间(当时叫 N-SPACE)交换链接认识的。他们搭档了很多年(直到今天),经历很传奇。
刚在网上认识他们的时候,他们还是业余在做,个人网站上放着一个 RTS 的 demo ,看起来很火暴。
据说早年他们在做别的软件,有个自己的小公司。做完个项目后,分了钱大家去北京散心,看看专业做游戏的公司是什么样子的。去过前导也去过腾图,不是去应聘,只是转转。这些“专业”的公司得到的业余者之评价是:不过如此。跟自己业余做的 demo 也差不多水准。
不过腾图把他们留了下来(有八卦说,前导的头儿追悔莫及)。就是那种很随性的,“不如你来上班吧”,旅人结束了自己的旅途。据说那个时候腾图偌大的公司,已经快散伙了,留了许多半拉子产品,补不完的 bug 。这是我听过国内游戏圈的历史中最传奇的故事,余雪松一个人修补了四个产品,把它们做到基本可以摆上货架。我是听别人转述的,但我相信那不是件容易的事情。
见到老余的时候,他们小组已经接受一家台湾公司的小额投资在做《烽火三国》。小组没做垮,产品上了市,那家台湾公司却先垮了。等我毕业再次来到北京,老余他们跟着谢成鸿在做 kele8 。
老谢,用过笔名“小谢”。我们居然很早就有过交情,在我的个人主页创办早期,他给我 email 来了几篇稿子,让我放上去。有兴趣的朋友可以看看怀旧 :)
老谢早期最有名的作品是一个 web 象棋,不需要下载就可以在网上和人对弈。这个东西曾经挂在 sina 的游戏版面很久,我想他是用这个淘到的第一桶金。当然更大的资金注入来至于当时如日中天的联众。btw, 第一次见到鲍岳桥的时候,我有种奇怪的感觉,中学时就在 UCDOS 上看到作者名字,我心目中的名人,原来也是个普通人。这种感觉在碰见求伯君时还有,等到日后见到丁磊时已经没有了。
老余听说我正闲着没事做,甚至也没有收入。他请我吃了顿饭。一共四个人,老谢、老余、老吴,还有我。一家很小的馆子,大家骑着自行车过去,点了些家常菜。2000 年的 9 月,老谢对 web game 充满信心。北京的夏天已到末尾,冬天不远了。当他邀请我去 kele8 的时候,我没有太犹豫。我不知道自己能做些什么,该做些什么。我知道这些朋友都有很好的技术,都有火热的激情,看起来不错,不是吗?
我的工资是 6k/月,第一个月发工资时,信封里装了 5500 ,我没有问,我想是扣了 500 的税吧。工资数字对我是无所谓的东西,真的。大学没毕业时,有个朋友说,来我这里干吧,一年 10 万。我在心里吐了吐舌头,这么多啊,父母为我读大学的学费和生活开销,攒了十年的钱,也不过四万而已;我和庞鑫等哥几个去忽悠风投的飞机上,庞鑫说,别不好意思,以后报自己的薪酬,只管写上五位数;我想我一个月吃饭不过几百块,一年难买两件衣服,能用上几个子呢,真的是无所谓的一件事情。
在北京的后几个月,我和安宁(以及嫂子),李民(庞鑫的同学)四个人租的屋子。在西直门外,出门就是北京最著名的西直门立交桥。老实说,并没有传说中的那么恐怖啦,我只迷路过一次而已。论可恨程度,远不及紫竹桥那个,南北不通,每次过都需要把自行车搬上搬下。
房租 2800 ,大约每人摊 1000 。我无所求,所以住的最小的一间。屋内空空,只有一张床和一口箱子。每天早上 9 点起床去上班,逆火的兄弟们在白石桥租的高层写字楼,我在魏公村。都不远,大家骑车即可。我的车是来北京后朋友送的,价值 20 块。没有后档泥板,一下雨,背后就是一条黑线。有一天下班时,魏公桥下没有人也没有车,我被黑暗角落窜出来的交警拦下,闯红灯,罚款 20 。他瞅了一眼我的破车,怎么没有车牌?我很想把车留给他,然后自己走回去。但是我没有,兜里只有 20 块,换了一张罚单。后来离开北京的时候,我把这辆破车停了某个天桥下,一年后等我再次到北京时,车居然还在,口袋里的钥匙也在。
在 kele8 的日子很闲,老谢不知道可以安排我做什么。老余说,等下一个版本,全部交给我来做。我就自己给自己找事情做。我去的时候,办公室里就 7 个人。两个美术,一个专心做 3d 模型,一个只会画平面的东西,但是画的真好。我原以为做游戏需要很多很多的美术,其实不用。合理的调配人力,帮助美术节省一些不必要的机械劳动,两个人也能做很多事出来。
程序算上老谢有 4 个。不过老谢写 java 的,老余写 C++ ,他们技术上合不来,而老余的技术和经验高很多,所以整个底层都是老余在做。吴东黎是个很有趣的人,年纪不小,没谈女朋友。和我一样,成天待在办公室。除了打 quake (技术真的很棒),没太见他玩别的游戏。你不可以说他的技术到底是好还是坏,讨论语言的细节他或许不行,但是他做东西就是来的很快。无论是用什么。他和老余是天生的搭档,余雪松设计出脚本语言,他就拿过来用,用的很好。另外一个哥们也是写脚本的,在 kele8 ,包括以后的大部分程序员都是工作在老余自己设计出来的脚本语言和开发集成环境上。
起初,我想写个 C 编译器玩儿。因为我觉得游戏做大了还是需要嵌入脚本,除了 C ,我对别的语言都没什么兴趣。写了一半,我又莫名其妙的喜欢上 javascript 和 css ,觉得设计的挺有趣。实现个 javascript 的解释器也不错,不过也没能实施这个想法。后来我读到了一本书:《 C ++ 编程思想》,海淀图书城里看到的。伫立在书架边,读了一个小时,而后就抱回了家。大约用了 2 天时间,没日没夜的啃,仔仔细细的读完了每一个字。
按理说,读初中那会儿,我就喜欢上了 C++ 。不过我的认识也就停留在了 92 年的国内翻译的一些 C++ 书籍上。2000 年底,《 C++ 编程思想 》这本书对我的冲击很大,我觉得我重新认识了 C++ 。我想我应该把“风魂”重新做一遍,用 C++ 。甚至我还觉得 kele8 的引擎做的不够 C++ ,比如我们应该用巧妙的继承和类层次关系去取代那些函数指针。而且老余那个时候跟我一样,不知道可以用 ->* 这样的操作符去用指针调用成员函数,const 这个关键字也没有被准确的使用,等等。
做产品毕竟不是研究技术,这些都是想想而已。我们只是每天在骑车回家的路上聊聊。
只记得那段时间做了两件事:一是把原来“风魂”里的声音播放的模块移植到 kele8 的引擎中,让那些 web game 能够发声。还有就是做一个台球的游戏的技术研究。
写了一个 2d 下 3d 效果带光照的球面渲染;以及做了一些碰撞方面的 demo 后,真正的 kele8 台球程序还是老余自己重新写的。我那个时候思维总停留在 C 和 C++ 上,用不惯那些脚本。老余倒是对自己的东西使的游刃有余,就在一个阳光明媚的早上,他兴冲冲从包里拎出硬盘,推入活动硬盘匣,给我展示了一晚上的成果:一个台球游戏基本可以玩了。
kele8 的台球这个游戏无疑是成功的。那段日子,我去台球俱乐部里打 snooker ,听到有人谈论它,心里都一阵得意,我也贡献了代码呢。
那个冬天还有什么?我给远方那单恋了 5 年的 mm 送了一大束百合,是在她的生日那天,没有留下我的名字。虽然她已有男友,但是后来我依然固执的打了一个月的电话。我本以为那个月的手机话费会爆掉,可实际上也不过 400 块多点。看来我不够疯狂,不知道李民怎样让花费一个月超过 1000 块的。吴东黎给我讲了老余过去的故事。那个时候他们两个单身汉合租,老余的女朋友还没有升级成妻子。一下班,就瞅见他就躲进屋子,到第 2 天早上要上班时,居然还没挂电话呢。
我想我不够疯狂。
在北京过的最后一个冬天,满是落魄。这是种内心的感觉。我觉得对不起给我发工资的人,对不起朋友。我没做出什么更有意义的事情。而大多数人都做的比我好。
2001 年的新年来的特别早,1 月 23 日是除夕,我们的春假放的更早。
事后我想,估计老谢明白我想离开。旧年里最后一个月的工资决定等年后再发。不过我领到了 800 元的新年红包。
我实在不好意思说辞职,因为似乎我没为团队做点什么就要走。回到家,我在网上留了言说想休个长假,好好的想想未来的计划。
每次我觉得对不起周遭的朋友们时,大家都表示出莫大的理解。我真的是一个幸运儿,拥有这样多的好朋友。每个人都能体谅我的自私。
那个时刻,我已打定主意离开北京了。
争取在 5.1 假期内多写一点,应该能写到大话西游项目的开始。原本还有很多的人很多的故事可以写,这里略过了许多。比如那些年出没在 sina 游戏制作论坛上的众多 id :小箭2000 (每年还在给我寄贺卡)、做模拟飞行的黄海、写“我的游戏梦”的指顾江山等等。那两年,在北京我见了许多人,跟许多朋友彻夜不眠的长谈。听了许多故事。自己也经历了许多。
每当我努力回忆一点,就会有如泉涌般的冒出来。甚至让我夜晚睡不着。我想人的记忆其实不会遗失,只是藏在那个角落里,等你努力挖掘的时候自然会蹦出来。
对想出现在这个故事中,却没能露脸的朋友说声抱歉了(我挺喜欢出现在别人的故事中,我想很多人都喜欢)。不是我已经忘记你们,也不是故事里的人对我更重要。我只是随机选择了一些片段记录。
10 年前的事情,真的是很模糊了。
最后,还是那样:谢绝转载。因为不能保证没有记忆的偏差,我希望有机会纠正。
All of the videos from the 2008 MySQL Conference have been processed and uploaded. Links to the videos, slides, notes, photos for each presentation are all on the mega-conference page at:
http://forge.mysql.com/wiki/MySQLConf2008Notes
This represents many hours of my own toil, but it also reflects plenty of people who have blogged, edited the wiki pages and speakers who wrote and gave tutorials and presentations. I am proud of everyone’s efforts to offer so many learning resources for free….
Enjoy! EDIT: I forgot to thank Jay, the folks at O’Reilly and all the speakers for giving me explicit permission to video and freely offer their presentations.
If you know of any video, audio, notes, slides, photos, etc that are not linked, please link them at the wiki page. If you can’t or won’t, please comment here and I will update the wiki for you.
Please note that there’s still some work to be done for a volunteer — Currently there is no one page where you can get all the videos, notes and slides for a presentation. The Forge Wiki page linked above is very close — it is missing many presentations and their corresponding slides.
O’Reilly has all of the slides speakers submitted at http://en.oreilly.com/mysql2008/public/schedule/presentations/. If someone or a few folks work on linking the slides on the O’Reilly site to the presentations on the Forge Wiki page at http://forge.mysql.com/wiki/MySQLConf2008Notes, then the Forge Wiki page will be comprehensive and folks can go to one page to get any and all information about a presentation at the conference.
彩虹飞来为天桥,巨龙卧波笑海风。今天下午3时40分,随着180辆仪仗车南北双向对开,全长36公里世界上最长的跨海大桥——杭州湾跨海大桥试运营通车。这一长江三角洲一体化进程中的重要时刻,将永留史册。
五月底去宁波吃海鲜,哈哈哈


2008-04-30 Wed
2008-04-29 Tue
2008-04-28 Mon
AnySQL.net
DBA notes
Oracle & Starcraft
eagle's home
Give you some color to see see!
AnySQL.net English
Oracle Scratchpad
Oracle Life
OracleDBA Blog---请享受无法回避的痛苦!
Uploads from dbanotes
Chanel [K]
xzh2000的博客
Oracle Security Blog
ERN空间
Eddie Awad's Blog
MySQL Performance Blog
The Tom Kyte Blog
del.icio.us/fenng/oracle
AIXpert
O'Reilly Databases
Red Hat Magazine
DBASupport
DB2 Magazine 中文版
developerWorks : AIX 专区的文章,教程
Pythian Group Blog » Log Buffer
车东[Blog^2]
blue_prince
玉面飞龙的BLOG
此生 今世
人生就是如此
Orange Tiger 木匠 的 移民生活
生活帮-LifeBang
Hey!! Sky!
dba on unix
Oracle Notes Wiki
Brotherxiao's Home
柔嘉维则@life.oracle.eng
Fenng's shared items in Google Reader
jametong's shared items in Google Reader
缥缈游侠-logzgh
Tanel Poder's blog: Core IT for geeks and pros
DBA Tools
ilonng
yangtingkun
NinGoo@Net
Oracle & Unix
Inside the Oracle Optimizer - Removing the black magic
Ricky's Test Blog
DBA@Taobao
存储部落
Think in 88
Alibaba DBA Team
Oracle Team @SNC
淘宝数据仓库团队
OracleBlog.cn




