大家春天好！

2009年3月话题： 邮箱和邮件服务

北京，西直门附近奇遇花园，
15号（周日）、下午14:30，
联系人：千鸟 13366219527

上海，龙华路2577号5号楼 BlogBus办公室，
15号（周日）、下午14:30，
联系人：Ami 13816759271

南京，珠江路665号南楼6楼 途牛旅游网，
15号（周日）、下午14:30，
联系人：JunChen 13913833651

深圳，问道旅行馆南山店，
15号（周日）、下午14:30，
联系人：Lytous 13723766365

广州，广州市天河区科韵路16号广州信息港E栋 网易大厦1楼网站部，
15号（周日）、下午14:30，
联系人：胡晓 13560220908

杭州，文二路285号枫华府第4幢1单元1101，
15号（周日）、下午14:30，
联系人：坏人 15068883444

通过 Google Maps 查看地址详情

书友会详细信息：http://ucdchina.com/book/about/

感谢BlogBus、途牛旅游网、虾米网提供书友会场地。

转载请注明出自UCDChina.com，谢谢。

相关文章

• No Related Posts

We finally managed to get Intel X25-E SSD drive into our lab. I attached it to our Dell PowerEdge R900. The story making it running is worth separate mentioning - along with Intel X25-E I got HighPoint 2300 controller and CentOS 5.2 just could not start with two RAID controllers (Perc/6i and HighPoint 2300). The problem was solved by installing Ubuntu 8.10 which is currently running all this system. Originally I wanted to publish some nice benchmarks where InnoDB on SSD outperforms RAID 10, but recently I faced issue which can make previous results inconsistent.

In short words using Intel SSD X25-E card with enabled write-cache (which is default and most performance mode) does not warranty storing all InnoDB transactions on permanent storage.
I am having some déjà vu here, as Peter was rolling this 5 years ago http://lkml.org/lkml/2004/3/17/188 regarding regular IDE disks, and I did not expect this question poping up again.

Long story is:
I started with puting XFS on SSD and running very primitive test with INSERT INTO fs VALUES(0) into auto-increment field into InnoDB table. InnoDB parameters are

Actually most interesting one are innodb_flush_log_at_trx_commit=1 and innodb_flush_method = O_DIRECT (I tried also default innodb_flush_method, with the same result), using innodb_flush_log_at_trx_commit=1 I expect to have all committed transactions even in case of system failure.

Running this test with default XFS setting I saw SSD was doing 50 writes / s, this is something so forced me to check results several times - come on, it's SSD, we should have much more IO there. Investigations put me into barries/nobarriers parameters and with mounting -o nobarrier I got 5300 writes / s. Nice difference, and this is something we want from SSD.

Now to test durability I do plug off power from SSD card and check how many transactions are really stored - and there is second bumper - I do not see several last N commited transactions.

So now time to turn off write-cache on SSD - all transactions are in place now, but write speed is only 1200 writes / s, which is comparable with RAID 10

So in conclusion to warranty Durability with SSD we have to disable write-cache which can affect performance results significantly (I have no results on hands, but it is to be tested).

What about LVM there ? Well, we often recommend to use LVM for backup purposes (even recent results are bad, we have no good replacement yet) and I tried LVM under XFS. With write-cache ON and default mount options (i.e. with barrier) I have 5250 writes / s, this is because LVM ignores write barriers (see http://dammit.lt/2008/11/03/xfs-write-barriers/ ), but again with enable write-cache you may lose transactions.

So in final conclusion:
1. Intel SSD X25E is NOT reliable in default mode
2. To have durability we need to disable write cache ( with following performance penalty, how much we need to test yet)
3. Possible solution could be put SSD into RAID controller with battery-backup-ed write cache, but I am not sure what is good ones - another are for research
4. XFS without LVM is putting barrier option which decreases write performance a lot

---

Entry posted by Vadim | 3 comments

Add to: | | | |

大社区在上线之初，针对很多人的疑惑，我们强调大社区的使命和愿望，以及一些规则。
又过了半年多，大社区积累了2000多篇优秀的文章，创建了近200个话题。

期间出现类似《装不装用户》这样的设计思想大碰撞；
也有聚合了像《人物角色》、《情景设计》、《任务分解》这样一些方法类的话题；
再比如类似如何设计一个《首页》、一个《表单按钮》要如何摆放？这样具体的设计案例；
当然还有每次书友会讨论的话题；
……

这也是原来首页想要传递给大家的信息，我们的价值在于聚合而成的话题，我们期望我们聚合而成的话题能沉淀下来，若干年后，我们还能知道这群设计师关注过什么，他们在想什么……

把首页用文章代替原来的话题，并非要把话题边缘化，相反，我们需要更加集中呈现内容，把更多行业内优秀的文章引进来，让更多的人一起参与。
首页的改变只是第一步，更多的的改变稍后放出，也欢迎大家反馈意见。

积累更多优秀的文章，沉淀更多精彩的话题，是大社区一贯的使命。

转载请注明出自UCDChina.com，谢谢。

相关文章

• No Related Posts

作者 AdSense 支持小组

在我们启动身份证验证功能以后，得到了很多发布商的关注和支持。同时也有发布商提出了一些问题，现在我们就对支持论坛上的几个热点问题进行解答：）

问题1：提交身份证号码后，需要多久能够完成验证？
解答：我们一般需要10个工作日完成验证。完成后会回复你的邮件通知您，还会在每个月的10号，20号，30号召论坛公告版公布通过验证的发布商ID，方便您及时查看。

问题2：我的身份证是一代身份证，可以进行验证吗？
解答：可以，一代和二代身份证都可以进行验证。

问题3：我的收入还不到10美元，也可以提交身份证验证吗？
解答：不可以。如果收入不到 10美元，系统无法触发 PIN 码，同样也无法对身份证进行验证。身份证验证是对 PIN 码验证的补充，您必须在PIN 码已经发出，并且3周后仍无法收到，才能申请身份证验证。

问题4：Google 使用第三方进行身份证验证，我们的个人信息会不会泄漏给第三方？
解答：不会，请放心。进行验证的第三方机构是专业的身份证验证机构，不会泄漏您的任何个人信息。

如果您有任何其他问题，欢迎到支持论坛发帖提问，我们会随时关注论坛文章，并及时为您解答：）

周末这两天非常冷，感觉到现在是料峭春寒的时节。当然，休城怎么冷都不及纽约，周一的纽约又下大雪，几乎快闹雪灾的样子，白雪纷飞并不浪漫，反而给人们生活带来困扰。

这一阵子冷过之后，春天就会真正来了。

1.

上周和同事聊天，听到了一些数学知识，感觉许多学科有相通之处，天下学问是一家。同事分享了“梯度法（sequential gradient method）”这个数学名词，Oliver发现这个名词和最近看到的关于职业生涯的文章异曲同工。

简单举爬山的例子来说，从山脚到山顶画一条直线，而后沿着这个路径直接走下去，就会到达山顶，这是一种爬山的方法。然而，这样的方法难处在于如何找出那条直线。每一座山各色各样，不是那么简单可以找出这样的一条路径。这看起来更像是理想化的路径。

第二种方法就是“梯度法”，不管怎么样，先从山脚下开始走再说。走出第一步，就为走出第二步打下了基础。每走一段路，海拔就会上升，朝山顶的距离就靠近了一步。每走一段路所停驻的那个点，在山坡线上具有一定的斜率，所产生的切线也不相同，每一个点的切线，指引下一段路程的方向。这样逐渐调整的路径，最终都能到达山顶。

Oliver以前在福州时，经常在周末时去爬鼓山。也经常和同伴——现在的太太——分享关于这个条条路径通鼓岭的感受。

2．

同事也分享了在一楼办公的一位朋友的故事。这位朋友的女儿现在大概上七年级，他没有要求女儿一定去学什么技能，只是让她尝试各种兴趣项目，弹琴、跳舞、唱歌、游泳等等。这个女孩身形较胖，自然舞姿不是那么优美，她也不喜欢唱歌等等。逐渐的，这位朋友发现她的水性很好，尤其是她很喜欢打水球，“如鱼得水”的说法用在这里就恰到好处了。

这位朋友就鼓励她女儿往这方面发展，参加学校的水球队，参与比赛。几年下来，现在已经是全美少年奥林匹克水球队的队员。同事和这位朋友说，或许2012年的奥运会赛场有可能看到她的身影。他回答说，这不是没有可能。另外，在学业上，这个女孩对海洋生物学非常着迷。这位父亲就送她去参加这个主题的夏令营，也为她专门请了海洋生物学方面的专家和教授来进行家庭辅导，培养她朝这方面去发展。

3.

上周看到幸福课博客上的一篇文章《埃米尼亚.伊瓦拉：如何转变职业生涯？》，讲到了在职业生涯中，尽可能多尝试各种可能性，放手实践，开发自己的潜能，塑造多种工作身份，逐渐地职业路径就会浮现出来。

《埃米尼亚.伊瓦拉：如何转变职业生涯？》

传统智慧认为，成功转变职业生涯的关键在于必须知道自己下一步想干什么，然后据此来指导我们的行动。然而，耶鲁大学组织行为学博士埃米尼亚.伊瓦拉的研究发现，采取传统方法，试图改变职业生涯的人，往往在尝试几个月之后失败告终。但是，如果采取”职业身份塑造“（Working identity）的方法，则最终都找到了通往全新职业生涯的道路。

当各种“可能的自我”漫无目的地变来变去时，使职业生涯转变产生的唯一途径就是把我们各种可能的身份变成现实，然后再不断地对这些身份进行锻造，直到我们积累的实际经验足够丰富，能够指导我们采取更有决定意义的行动为止。按照这种思路，成功转变职业生涯的关键做法有：创造试验机会、改变关系网、解释我们正在经历的转变。

全文看这里：http://www.xingfuke.net/psyblog/xingfuke1087.html

读了这篇文章后，Oliver深有感触。每一件事情，规划理想化的路径是没有用处的，因为很经常，那个理想化的路径是不存在的。老话说，欲速则不达。不如，在有了大致的愿景和蓝图之后，就立即开始行动，一点一点尝试起来。即使暂时失败了也没有关系，调整一个方向，继续尝试和行动。如此，坚持日积月累，那么终有所获。

这篇文章也为Oliver近来所思考的关于业余活动的心得提供了理论基础，将来会在这个blog里分享这些心得。

相比现实生活，网络提供了一个全新的空间，让人们可以在上面实验和尝试，探索自己的各种可能性，人们在透过网络分享自己的见解，贡献自己的技能时，潜能就会逐渐释放出来，这是利己利人的最佳路径。程乐华老师的虚拟自我的研究成果，也从专业角度揭示了这一点。

只要专注于你的个人愿景，在不断尝试中，你总会发现一些适合你的路径。

Today we announce release 1.0.2-3 of our XtraDB storage engine.

Here is a list of enhancements:

• Move to MySQL 5.1.31
• Scalability fix — ability to use several rollback segments

Increasing the number of rseg may be helpful for CPU scale of write-intentional workloads. See benchmark results.

• Scalability fix — replaced page_hash mutex to page_hash read-write lock. See benchmark results.
• Fix broken group commit in InnoDB

As you know, the group commit of InnoDB doesn't work after MySQL 5.0 with binlog.
We pretend to fix this and added "innodb_enable_unsafe_group_commit=[0|1]" parameter. Note if you set this parameter to "1" record order of binlog and InnoDB transaction log could be not same. But because InnoDB manages transactions in correct order most users may not have problem with this.

• New parameters in the XtraDB io patches:
  • innodb_ibuf_max_size — Restrict innodb-insert-buffer size
  • innodb_ibuf_active_contract — Enabling it makes the each user threads positive to contract the insert buffer as possible in asynchronous
  • innodb_ibuf_accel_rate — This parameter is additional tuning the amount of insert buffer processing by background thread.
  • innodb_flush_neighbor_pages — When you use the storage which don't have "head seek latency" (e.g. SSD or enough Write-Buffered), 0 may show better performance.
• Changed parameter for control read ahead activity. Now it accepts string values:
  • innodb_read_ahead = [none|random|linear|both]
• Deb builds for Ubuntu

Percona XtraDB 1.0.2-3 (Sapporo) available in source and several binary packages.

XtraDB is compatible with existing InnoDB tables (unless you used innodb_extra_undoslots) and we are going to keep compatibility in further releases. We are open for features requests for new engine and ready to accept community patches. You can monitor Percona’s current tasks and further plans on the Percona XtraDB Launchpad project. You can also request features and report bugs there. Also we have setup two maillists for General discussions and for Development related questions.

---

Entry posted by Evgeniy Stepchenko | 2 comments

Add to: | | | |

There are few terms you need to have a good understanding if you're working with high volume systems. I commonly see these mixed and people not understanding the difference between them.

Performance - The performance comes down to performing up to users expectations (or expectations of your boss) which drills down to two important metrics - response time also sometimes called latency and throughput also called capacity. Response time applies to even single user and mostly critical in applications when a complex task needs to be performed such as report generation or search. It is just unacceptable if search takes a minute even if system has a capacity running for 100 of them at the same time. The response time is the most important aspect of performance because when we define system capacity we also define conditions on response time. For example system can handle 100 transactions a second with 95 percentile response time of 1 second.

Scalability - In the high volume applications we assume scaling to larger amount of users, larger systems, larger database size and this is what I will be speaking about. There is also aspects of scaling down for embeddable systems but it is whole other story. The question of scalability usually comes because system needs to handle larger load (or operate with larger database) which comes to the question of performance on the same system, getting larger box "scaling up" or using multiple systems "scaling out". Scalability is really funny term because it is used in some many different context. You may hear "It does not scale" applied to the application on same system as load or database size increases as well as to the no significant response to getting more hardware. So I would define Scalability as ability to increase or sustain performance as response to the environment changes.

Efficiency This is my favorite one. Your application may be performing well and scaling to insane load and data size but If I can do the same with half the hardware (or half development costs) my application is more efficient than yours. The complexity of Efficiency term comes from the fact you can set the optimization goals very differently. Some are concerned about development time and operations complexity, others about hardware and software cost and TCO and third about power consumption.

What is interesting in many cases I see the focus on Performance and Scalability while not really focusing on efficiency a lot (at least until VC money run out). I'm constantly being surprised how efficient and inefficient systems you can find among top web sites. It is not an exception to see the difference in efficiency as much as 10 times or sometimes even more.

When you evaluate different solutions, see some suggestions in the internet I'd urge you to use all 3 metrics above for evaluation (using efficiency metric which is most critical for you right now). It is quite possible the most efficient solution somebody have picked is efficient using different metric compared to what you need.

---

Entry posted by peter | No comment

Add to: | | | |