Using xtrabackup for copying files can really saturate your disks, and that why we made special option --throttle=rate to limit rate of IO per second. But it really works when you do local copy.
What about stream backup ? Even you copy just to remote box with
innobackupex --stream=tar | ssh remotebox "tar xfi -"
, read may be so intensive so your mysqld feels impact, slave getting behind, etc…

For this there is a nice small utility - pv .

With pv you run:
innobackupex --stream=tar | pv -q -L10m | ssh remotebox "tar xfi -"

and it will limit channel rate to 10 M per second.

---

Entry posted by Vadim | No comment

Add to: | | | |

作者 Google 广告管理系统小组 李小轲

我的同事在前期推广的过程中，发现很多发布商对于“展示位置”这个概念很模糊。其实这是欧美互联网一个比较流行的概念。在很多情况下，欧美的广告主会针对一个网站多个物理广告位打包进行购买，这个时候如果在下订单时，还需要一个个添加广告位置，就会显得比较繁琐，所以广告主可以直接针对打包的广告位 – 即展示位置 – 进行购买。具体来说，展示位置是指广告客户的广告可在其中展示的一个或多个广告位置。例如，假设您在运营一个门户网站： 可创建一个展示位置，其中包含您网站上所有频道的右侧顶部摩天大楼广告位； 可再创建另一个展示位置，其中包含运动频道内容页上的所有广告位置。 这两个展示位置都能够包含运动频道内容页上的右侧顶部摩天大楼广告位。您还可以为网站的国际资讯频道、旅游频道和天气频道中的所有广告位置组合起来创建一个展示位置。

但是，如果您的直销团队仍然在按照广告位置来进行销售，您可以为每一个物理广告位创建一个对应的展示位置。

下面，我们介绍一下，如何在系统中创建展示位置，并和广告位置进行关联。

- 在登录系统以后，点击“广告资源”选项卡，默认进入“展示位置”界面，点击“新展示位置”（如下图所示）



- 进入“新展示位置”界面后，我们现在就需要创建一个展示位置，并关联对应的广告位置。在这个界面上，我们可以看到如下选项：

• 展示位置名称：一般来说，展示位置代表一个或多个相关的广告位置。 为展示位置命名时，您可以根据以下条件描述广告位置：广告位所在频道，实际位置和大小、与同一网页上其他元素的关系或与您网站上特定主题或板块间的关系。例如，某门户体育频道顶部728-90。
• 定位：当我们为对应的广告位置启用了 Google AdSense 来补充空档时，一旦勾选此选项，Google AdWords 广告客户可以将广告定位到此特定展示位置。 选择这个选项后，您将会看见如下选项，填写这些信息将会帮助您更好的向 Google AdWords 广告销售您的广告位。
• 展示广告的网页：请确保选择正确的频道位置。如果广告位不是在主页，请在此填写正确的页面信息，如“体育”
• 广告位置：选择广告位对应的位置，如“顶部居中”
• 广告客户说明： 这里的广告位说明信息对于向Google AdWords 广告客户非常重要，信息越详细，广告客户对您的广告位置的认识就越深刻，约有可能投放广告到此位置。

- 在填写完展示位置信息之后，我们就需要把在上一节中创建的广告位置和这个展示位置做关联。选中您希望关联的广告位置，点击对应的“添加”来完成关联操作。

- 点击“保存”

这样，我们就完成了展示位置的创建和关联。如果多有个展示位置，我们需要在此逐一创建。

I should say I can see results of new engineering/refactoring/bug hunt efforts inside Sun/MySQL.
Over last couple of weeks I started getting a lot of messages from the bugs system about bugs I reported long ago which were deferred to be fixed later or were left in open state. Here is example of such a bug.

I really hope this effort will result in a lot of these old annoyances fixed, which really matches my vision for MySQL - we do not need more big features we need old ones to work well and be convenient.

---

Entry posted by peter | 2 comments

Add to: | | | |

Today we're excited to announce a new feature in Google Analytics, tracking for YouTube brand channels. YouTube brand channels allow partners and advertisers to have a hub of content on YouTube, where they can collect videos, publish playlists, and get YouTube users deeply engaged with their brand. Now brand channel owners can get fully enabled Google Analytics reporting on their channel as if it were their own site.

For more information, check out the newly launched YouTube Biz Blog.

Posted by Beth Liebert, Google Analytics Team

At the core of the new real-time web, which is really really old, are continuous queries. I like how this paper proposed to handle dynamic demand and dynamic resource availability by making the underlying system adaptable, which seems like a very cloudy kind of thing to do.

Abstract:

The long-running nature of continuous queries poses new scalability challenges for dataflow processing. CQ systems execute pipelined dataflows that may be shared across multiple
queries. The scalability of these dataflows is limited by their constituent, stateful operators – e.g. windowed joins or grouping operators. To scale such operators, a natural solution is to partition them across a shared-nothing platform. But in the CQ context, traditional, static techniques
for partitioned parallelism can exhibit detrimental imbalances as workload and runtime conditions evolve. Longrunning CQ dataflows must continue to function robustly in
the face of these imbalances. To address this challenge, we introduce a dataflow operator
called Flux that encapsulates adaptive state partitioning and dataflow routing. Flux is placed between producerconsumer stages in a dataflow pipeline to repartition stateful operators while the pipeline is still executing. We present the Flux architecture, along with repartitioning policies that can be used for CQ operators under shifting processing and memory loads. We show that the Flux mechanism and
these policies can provide several factors improvement in throughput and orders of magnitude improvement in average latency over the static case

A software-based distributed caching system such as memcached is an important piece of today's largest Internet sites that support millions of concurrent users and deliver user-friendly response times. The distributed nature of memcached design transforms 1000s of servers into one large caching pool with gigabytes of memory per node. This blog entry explores single-instance memcached scalability for a few usage patterns.

Table below shows out-of-the-box (no custom OS rewrites or networking tuning required) performance with 10G networking hardware and one single-socket UltraSPARC T2-based server with 8 cores and 8 threads per core (64 threads on a chip)...

Object Size / Ops/Sec / Bandwidth
100 bytes / 530,000 / 1.2 Gb/s
2048 bytes / 370,000 / 6.9 Gb/s
4096 bytes / 255,000 / 9.2 Gb/s

Check out the link for more details!