Joel Berman explains the ‘G’ part of the MRG offering–the grid. Watch as he demonstrates how the Amazon Cloud can be used to help complete resource-intensive tasks much more quickly.

More information

• MRG overview on redhat.com
• the MRG FAQ
• Amazon Elastic Compute Cloud information from Amazon.com

I use Maatkit for a lot of grunt work and thought you might appreciate this quick tip. Suppose you have a bazillion tables to convert from MyISAM to InnoDB, but they are mixed in with other tables that are already InnoDB, or are another storage engine that you don't want to touch.

Here's a bonus tip, while I'm at it. I had a client a while back whose application creates tables as needed, so they had about 90,000 tables in a bunch of different databases, all named things like user_123_456_friends. I wanted to add an index to them -- but not to the ones named friends_123_456_user.

Boy, is that a lot easier than adding indexes to 90k tables by hand!

Entry posted by Baron Schwartz | 2 comments

Add to: | | | |

文。赵二

“你还真拿流氓没辙，就好像你总是只能眼睁睁的看着周鸿祎耍流氓一样。”

“周鸿祎是互联网知名流氓”—这不是我说的，这是我在网络里看到的，我只是引用，所以万一周流氓看到了偶的文字心里不爽，大可以在电脑前痛斥这互联网的肮脏和无耻，支持在痛斥之前，先想一想为啥大伙都称呼您为互联网著名流氓？是不是您老干了太多的可以被称之为流氓的龌龊事？

为了查证“流氓”是否为贬义词，我特意翻了一下字典：流氓原指居所不定之流氓者，后来才慢慢演化为如今的“流氓”意义。流氓就是无业或者不务正业者，这一点是毋庸怀疑的。不过，由于游民无产业，不事劳作，到处游荡，所以有时为了谋生，必然会采取一些不择手段的方式以攫取生活必需品，这种行为方式的实施自然会枝节出“不务正业”等内涵。

周鸿祎是不是流氓，就要看他有没有住所？有没有固定职业？

周鸿祎也算是互联网大亨，所以谁要说他没住所，我肯定和他急，所以这一点上周鸿祎不符合流氓的标准；周鸿祎创办过3721，给雅虎中国打过工，现在既是奇虎的老板，据说也进军天使投资的行业，所以周鸿祎是有固定职业而且有不菲收入的人，从这一点来说，周鸿祎也不算是流氓。

为什么大伙都说周鸿祎-这个互联网潮人是流氓哪?我不禁陷入了沉思？

难道说是广大网民都有眼无珠到了难辨好坏的地步，又或者流氓已经成了一个光耀门庭的金字招牌？所以广大网民才把“流氓”这一称号安到了周鸿祎这尊互联网大仙的头上？

就在我苦思冥想之时，有一个声音从很远的地方传过来，声音既飘渺又絮絮叨叨，有一点像流行的说唱音乐：

“呦，，呦，，流氓软件，，，呦，，呦，，真的善变，，，呦，，呦，，，这是我们的暴利时代，，这就是流氓。，，。，呦，，，呦，，，周鸿祎的时代，，，呦，，，，呦，，，，”

恍然大悟啊，原来大家伙都还记仇啊，大家都记得一代流氓软件之教父周鸿祎啊！人们的眼睛是雪亮的啊，都还记得曾经被流氓软件残害的日子啊！所以大伙还不能原谅这个老老实实做事业的周鸿祎，继续揪住其过往的流氓行径而大加鞭笞！哎，人们群众爱憎很分明啊！

周鸿祎是3721的创始人，3721是流氓软件的鼻祖，这是许多人的印象！

说实话，在互联网行业，3721是一个奇迹，一个属于插件时代的商业奇迹，不论后期毁誉如何，周鸿祎做的3721都应该在互联网产品史留下重要的痕迹！

可是为什么大家都忘记了这一页，而牢牢记住了流氓周鸿祎和他的流氓插件哪？很有可能，我猜测的原因，是因为流氓周鸿祎为了推自己的360而和雅虎中国的那场口水仗！恩，反水，无间道，兄弟反目，等等大戏都在那一仗中上演，可惜啊，最终还是无疾而终的口水仗，害了3721和雅虎中国，火了奇虎和360卫士。

“流氓会武术，谁也挡不住”---周鸿祎会炒作，谁也拦不住！

这话放在互联网圈绝对实用，想一想周鸿祎是怎么推广奇虎和360就可以看出周鸿祎的炒作手法之高明。应该说奇虎做的论坛搜索确实挺好，我挺喜欢，为了这个功能，我是一边腹议着流氓周鸿祎一边在奇虎搜帖子，可惜啊，奇虎没坚持住，改行做问答了！

这更加坚定了我认为周鸿祎是流氓的定义：

前有炮轰3721，不管雅虎与周鸿祎的对错，应该说周鸿祎在3721的时候忽悠了许多的客户，从对客户的意义上来说，周鸿祎就是流氓，一个创造了一个商业模式然后打破模式的流氓，完全忽视客户的利益；从奇虎来说，周鸿祎也是个流氓，论坛搜索对用户挺有吸引力的，可能是因为不赚钱，竟然说抛弃就抛弃，这家伙不流氓，还有谁流氓！！

所以对于周鸿祎的流氓定义应该是这样的：

第一:这家伙太自私，为了利益谁都敢得罪；

第二，这家伙漠视客户的利益，当然这个客户是指以往的；

第三，这家伙太善变，不能坚持，让人无所适从；

写到这里，我已经不知道是夸这个流氓还是贬低这个流氓了，啊门！

周鸿祎就是流氓了，咱们又能怎么样？

你还真拿周鸿祎没辙，古今中外没有谁敢规定一个人是不可以做流氓的，就好像从来也没有规定一个人要做好人一样。

做流氓做到周鸿祎份上，这可不是普通流氓的境界了，想一想互联网教父都拿周鸿祎没辙，更何况我们这些互联网小民。虽然周鸿祎从来都是抱着网民第一，用户第一的口号一样，但是大家伙都觉得这家伙就是一个流氓---虽然说这个圈子里流氓很多，可是日子过的像周鸿祎一样舒坦的可也不多。

认清了周鸿祎的流氓本质，才可以理解周鸿祎最近热炒的免费杀毒的实质了。

“羊毛出在羊身上”“天上不会掉馅饼”这是作为消费者的我们要谨记的；

运营一个公司需要多少钱？

开发和维护一个好的杀毒软件需要多少钱？

如果产品完全免费，公司能否生存？

有人说周鸿祎不收用户的钱，而是收杀毒软件公司的钱？

那么请问，杀毒软件公司的钱从何而来?还不是用户提供的？

难道说就好像有人爆料说周鸿祎又想回去做插件做弹窗收取广告费吗？

杀毒软件免费，确实可行，可是获得的服务和收费肯定是有差异的。这才是事实！

所以别相信周鸿祎这个大忽悠，不然吃亏的可是咱们自己。

本文就是扯淡，偶在免费的争议之后才写就是不想凑那个热闹，在这里只是想谈一些自己对于互联网流氓大亨周鸿祎的崇敬之情，犹如那滔滔江水连绵不绝啊…………….

发表日：2008/7/30
作者：长野雅广(Masahiro Nagano)
原文链接：http://gihyo.jp/dev/feature/01/memcached/0005

前几次的文章在这里：

• 第1次：http://tech.idv2.com/2008/07/10/memcached-001/
• 第2次：http://tech.idv2.com/2008/07/11/memcached-002/
• 第3次：http://tech.idv2.com/2008/07/16/memcached-003/
• 第4次：http://tech.idv2.com/2008/07/24/memcached-004/

我是Mixi的长野。memcached的连载终于要结束了。 到上次为止， 我们介绍了与memcached直接相关的话题，本次介绍一些mixi的案例和 实际应用上的话题，并介绍一些与memcached兼容的程序。

mixi案例研究

mixi在提供服务的初期阶段就使用了memcached。 随着网站访问量的急剧增加，单纯为数据库添加slave已无法满足需要，因此引入了memcached。 此外，我们也从增加可扩展性的方面进行了验证，证明了memcached的速度和稳定性都能满足需要。 现在，memcached已成为mixi服务中非常重要的组成部分。

图1 现在的系统组件

服务器配置和数量

mixi使用了许许多多服务器，如数据库服务器、应用服务器、图片服务器、 反向代理服务器等。单单memcached就有将近200台服务器在运行。 memcached服务器的典型配置如下：

• CPU：Intel Pentium 4 2.8GHz
• 内存：4GB
• 硬盘：146GB SCSI
• 操作系统：Linux（x86_64）

这些服务器以前曾用于数据库服务器等。随着CPU性能提升、内存价格下降， 我们积极地将数据库服务器、应用服务器等换成了性能更强大、内存更多的服务器。 这样，可以抑制mixi整体使用的服务器数量的急剧增加，降低管理成本。 由于memcached服务器几乎不占用CPU，就将换下来的服务器用作memcached服务器了。

memcached进程

每台memcached服务器仅启动一个memcached进程。分配给memcached的内存为3GB， 启动参数如下：

/usr/bin/memcached -p 11211 -u nobody -m 3000 -c 30720

由于使用了x86_64的操作系统，因此能分配2GB以上的内存。32位操作系统中， 每个进程最多只能使用2GB内存。也曾经考虑过启动多个分配2GB以下内存的进程， 但这样一台服务器上的TCP连接数就会成倍增加，管理上也变得复杂， 所以mixi就统一使用了64位操作系统。

另外，虽然服务器的内存为4GB，却仅分配了3GB，是因为内存分配量超过这个值， 就有可能导致内存交换(swap)。连载的第2次中 前坂讲解过了memcached的内存存储“slab allocator”，当时说过，memcached启动时 指定的内存分配量是memcached用于保存数据的量，没有包括“slab allocator”本身占用的内存、 以及为了保存数据而设置的管理空间。因此，memcached进程的实际内存分配量要比 指定的容量要大，这一点应当注意。

mixi保存在memcached中的数据大部分都比较小。这样，进程的大小要比 指定的容量大很多。因此，我们反复改变内存分配量进行验证， 确认了3GB的大小不会引发swap，这就是现在应用的数值。

memcached使用方法和客户端

现在，mixi的服务将200台左右的memcached服务器作为一个pool使用。 每台服务器的容量为3GB，那么全体就有了将近600GB的巨大的内存数据库。 客户端程序库使用了本连载中多次提到车的Cache::Memcached::Fast， 与服务器进行交互。当然，缓存的分布式算法使用的是 第4次介绍过的 Consistent Hashing算法。

• Cache::Memcached::Fast - search.cpan.org

应用层上memcached的使用方法由开发应用程序的工程师自行决定并实现。 但是，为了防止车轮再造、防止Cache::Memcached::Fast上的教训再次发生， 我们提供了Cache::Memcached::Fast的wrap模块并使用。

通过Cache::Memcached::Fast维持连接

Cache::Memcached的情况下，与memcached的连接（文件句柄）保存在Cache::Memcached包内的类变量中。 在mod_perl和FastCGI等环境下，包内的变量不会像CGI那样随时重新启动， 而是在进程中一直保持。其结果就是不会断开与memcached的连接， 减少了TCP连接建立时的开销，同时也能防止短时间内反复进行TCP连接、断开 而导致的TCP端口资源枯竭。

但是，Cache::Memcached::Fast没有这个功能，所以需要在模块之外 将Cache::Memcached::Fast对象保持在类变量中，以保证持久连接。

package Gihyo::Memcached;

use strict;
use warnings;
use Cache::Memcached::Fast;

my @server_list = qw/192.168.1.1:11211 192.168.1.1:11211/;
my $fast;  ## 用于保持对象

sub new {
    my $self  = bless {}, shift;
    if ( !$fast ) {
        $fast = Cache::Memcached::Fast->new({ servers => \@server_list });
    }
    $self->{_fast} = $fast;
    return $self;
}

sub get {
   my $self = shift;
   $self->{_fast}->get(@_);
}

上面的例子中，Cache::Memcached::Fast对象保存到类变量$fast中。

公共数据的处理和rehash

诸如mixi的主页上的新闻这样的所有用户共享的缓存数据、设置信息等数据， 会占用许多页，访问次数也非常多。在这种条件下，访问很容易集中到某台memcached服务器上。 访问集中本身并不是问题，但是一旦访问集中的那台服务器发生故障导致memcached无法连接， 就会产生巨大的问题。

连载的第4次 中提到，Cache::Memcached拥有rehash功能，即在无法连接保存数据的服务器的情况下， 会再次计算hash值，连接其他的服务器。

但是，Cache::Memcached::Fast没有这个功能。不过，它能够在连接服务器失败时， 短时间内不再连接该服务器的功能。

my $fast = Cache::Memcached::Fast->new({
    max_failures     => 3,
    failure_timeout  => 1
});

在failure_timeout秒内发生max_failures以上次连接失败，就不再连接该memcached服务器。 我们的设置是1秒钟3次以上。

此外，mixi还为所有用户共享的缓存数据的键名设置命名规则， 符合命名规则的数据会自动保存到多台memcached服务器中， 取得时从中仅选取一台服务器。创建该函数库后，就可以使memcached服务器故障 不再产生其他影响。

memcached应用经验

到此为止介绍了memcached内部构造和函数库，接下来介绍一些其他的应用经验。

通过daemontools启动

通常情况下memcached运行得相当稳定，但mixi现在使用的最新版1.2.5 曾经发生过几次memcached进程死掉的情况。架构上保证了即使有几台memcached故障 也不会影响服务，不过对于memcached进程死掉的服务器，只要重新启动memcached， 就可以正常运行，所以采用了监视memcached进程并自动启动的方法。 于是使用了daemontools。

daemontools是qmail的作者DJB开发的UNIX服务管理工具集， 其中名为supervise的程序可用于服务启动、停止的服务重启等。

• daemontools

这里不介绍daemontools的安装了。mixi使用了以下的run脚本来启动memcached。

#!/bin/sh

if [ -f /etc/sysconfig/memcached ];then
        . /etc/sysconfig/memcached
fi

exec 2>&1
exec /usr/bin/memcached -p $PORT -u $USER  -m $CACHESIZE -c $MAXCONN $OPTIONS

监视

mixi使用了名为“nagios”的开源监视软件来监视memcached。

• Nagios: Home

在nagios中可以简单地开发插件，可以详细地监视memcached的get、add等动作。 不过mixi仅通过stats命令来确认memcached的运行状态。

define command {
command_name                   check_memcached
command_line                   $USER1$/check_tcp -H $HOSTADDRESS$ -p 11211 -t 5 -E -s 'stats\r\nquit\r\n' -e 'uptime' -M crit
}

此外，mixi将stats目录的结果通过rrdtool转化成图形，进行性能监视， 并将每天的内存使用量做成报表，通过邮件与开发者共享。

memcached的性能

连载中已介绍过，memcached的性能十分优秀。我们来看看mixi的实际案例。 这里介绍的图表是服务所使用的访问最为集中的memcached服务器。

图2 请求数

图3 流量

图4 TCP连接数

从上至下依次为请求数、流量和TCP连接数。请求数最大为15000qps， 流量达到400Mbps，这时的连接数已超过了10000个。 该服务器没有特别的硬件，就是开头介绍的普通的memcached服务器。 此时的CPU利用率为：

图5 CPU利用率

可见，仍然有idle的部分。因此，memcached的性能非常高， 可以作为Web应用程序开发者放心地保存临时数据或缓存数据的地方。

兼容应用程序

memcached的实现和协议都十分简单，因此有很多与memcached兼容的实现。 一些功能强大的扩展可以将memcached的内存数据写到磁盘上，实现数据的持久性和冗余。 连载第3次 介绍过，以后的memcached的存储层将变成可扩展的（pluggable），逐渐支持这些功能。

这里介绍几个与memcached兼容的应用程序。

repcached

为memcached提供复制(replication)功能的patch。

Flared

存储到QDBM。同时实现了异步复制和fail over等功能。

memcachedb

存储到BerkleyDB。还实现了message queue。

Tokyo Tyrant

将数据存储到Tokyo Cabinet。不仅与memcached协议兼容，还能通过HTTP进行访问。

Tokyo Tyrant案例

mixi使用了上述兼容应用程序中的Tokyo Tyrant。Tokyo Tyrant是平林开发的 Tokyo Cabinet DBM的网络接口。它有自己的协议，但也拥有memcached兼容协议， 也可以通过HTTP进行数据交换。Tokyo Cabinet虽然是一种将数据写到磁盘的实现，但速度相当快。

mixi并没有将Tokyo Tyrant作为缓存服务器，而是将它作为保存键值对组合的DBMS来使用。 主要作为存储用户上次访问时间的数据库来使用。它与几乎所有的mixi服务都有关， 每次用户访问页面时都要更新数据，因此负荷相当高。MySQL的处理十分笨重， 单独使用memcached保存数据又有可能会丢失数据，所以引入了Tokyo Tyrant。 但无需重新开发客户端，只需原封不动地使用Cache::Memcached::Fast即可， 这也是优点之一。关于Tokyo Tyrant的详细信息，请参考本公司的开发blog。

• mixi Engineers' Blog - Tokyo Tyrantによる耐高負荷DBの構築
• mixi Engineers' Blog - Tokyo (Cabinet|Tyrant)の新機能

总结

到本次为止，“memcached全面剖析”系列就结束了。我们介绍了memcached的基础、内部结构、 分散算法和应用等内容。读完后如果您能对memcached产生兴趣，就是我们的荣幸。 关于mixi的系统、应用方面的信息，请参考本公司的开发blog。 感谢您的阅读。

dbanotes posted a photo:

dbanotes posted a photo:

这几天下雨，草帽很管用

最近在优化网站内容
其中一个部分就是压缩JS以及CSS程序
比较常见的就是DOJO的ShrinkSafe
以及jsmin,ESC
不过taobao团队使用yuicompressor作为底层开发了windows下的jsMinifier
jsminifier.rar下载
目前版本2.0
使用yuicompressor+native2ascii
对于YAHOO的工具
我还是比较信任的
毕竟他们的performance团队的工作成果
是世人皆知的

最近在Field的帮助下完成了fetion短信报警,下面以磁盘空间报警为例(采用的是Solarwinds报警后自动执行VbScript调用飞信机器人发送短信报警)

• 一、 软件环境（Windows 2003为例）

Solarwinds+飞信机器人

• 二、 安装过程

飞信机器人下载包地址:

WINDOWS(2000/XP/VISTA):支持库  最新程序fetion20080618002-win32.rar  

其中支持库和安装包如下：

fetion20080618002-win32.rar解压缩你指定的目录，支持库 的内容解压缩后复制至和fetion.exe同一目录即可

• 三、 配置过程
• 1. Solarwinds报警配置磁盘空间监控

在上图中的Configure Alerts中新建报警DiskStatus，按照你的需要配置监控的服务器，报警的条件，监控的周期等，然后按照下图配置满足报警要求后的Action

按照上图添加2个Alert Action

Alert Action 1：log the alert to a file将报警保存为alter.log（可随意指定文件名和目录）

Alert Action 2：Execute an external VBScript指定要执行的VbScript，请将VbScript放在fetion的安装目录下，因为下面的VbScript指定的路径是相对路径

备注：请一定要先设置报警保存的log，然后在设置要执行的VbScript，因为只有先生成log，然后在执行VbScript读取log中的短信报警信息，设置好后如下图：

配置生效后应该先生成log然后执行VBScript发送短信

• 2.Log样本如下：

Alert: Percent Space Used of 100.121-D:\ is now 84 %

Alert: Percent Space Used of 100.102-C:\ is now 82 %

• 3. VBScript如下：

以上内容保存为alter.vbs放在fetion.exe同一目录即可

备注：由于监控的机器不多，而且报警的条件也比较高，所有报警次数比较少，生成的log就比较小，如果每天生成的log很大，建议log每天生成，增加日期变量即可