• Feeds

  • Archive for August, 2009


    利用Gearman来实现远程监控与管理

    Gearman是一个分发任务的程序框架,可以用在各种场合,与Hadoop相比,Gearman更偏向于任务分发功能。它的任务分布非常简单,简单得可以只需要用脚本即可完成。Gearman最初用于LiveJournal的图片resize功能,由于图片resize需要消耗大量计算资源,因此需要调度到后端多台服务器执行,完成任务之后返回前端再呈现到界面。

    gearman

    Gearman分布式任务实现原理上只用到2个字段,function name和data。function name即任务名称,由client传给job server, job server根据function name选择合适的worker节点来执行。data通常为执行任务所需的自定义的内容,比如简单的做法可以把需要执行的脚本当成data即可(当然要注意其中的安全防范)。如果有多个worker可以处理同一个function name, 则job server会自动分配一个。当用于远程监控场景时,我们可以让每个worker注册成不同的业务名称,以达到方便控制每台worker节点的目的。

    下面介绍Gearman实践中可用于多服务器管理的一些小功能,如果你的服务器有多台,重复执行命令过于繁琐,那可以借助下面一些脚本来完成一些有趣的功能。比如要实时看到所有服务器上的 netstat -nat | grep 80, 按下面步骤搭好环境之后,只需要几行脚本代码即可实现。

    1. 安装gearman
    最早的gearman是perl版的,由于国内开发人员对perl熟悉的不多,所以推荐安装C版本
    http://gearman.org/index.php?id=download
    解开后 ./configure; make; make install 即可

    2. 启动 job server
    cd sbin; ./gearmand -d

    3. 到 worker 节点启动 worker

    先按步骤1在worker机上安装 gearman, 然后创建一个执行worker的python脚本。

    #!/usr/bin/env python
    import os
    
    def main():
        cmd = raw_input()
        print os.popen(cmd).read()
    
    if __name__ == "__main__":
        main()

    cd bin; ./gearman -w -h <job_server_ip> -f server1 — ./monitor.py

    4. 通过远程 web 管理
    JSP示例:

    <%@ page language="java" import="java.util.*,java.util.concurrent.*,
    org.gearman.client.*,org.gearman.common.*"%><%!
            private static String host = "192.168.1.1";
            private static int port = 4730;
            public String testGearman(String func, String data) {
                    byte[] input = data.getBytes();
                    String uniqueId = null;
    
                    GearmanJobServerConnection conn =
                        new GearmanNIOJobServerConnection(host, port);
                    GearmanClient client = new GearmanClientImpl();
                    client.addJobServer(conn);
                    GearmanJob job = GearmanJobImpl.createJob(func, input, uniqueId);
                    Future<GearmanJobResult> f = client.submit(job);
                    GearmanJobResult jr = null;
                    String result = null;
                    try {
                            jr = f.get(3, TimeUnit.SECONDS);
                            result = new String(jr.getResults());
                    } catch (Exception e) {
                            result = e.getMessage();
                    }
    
                    client.shutdown();
                    return result;
            }
    %><%
    out.println(testGearman("test", "netstat -nat | grep 80");
    %>

    PHP示例:

    # Create our client object.
    $client= new GearmanClient();
    
    # Add default server (localhost).
    $client->addServer();
    
    echo "Sending job\n";
    
    # Send reverse job
    $result = $client->do("server1", "netstat -nat | grep 80");
    if ($result)
      echo "Success: $result\n";

    第一期广州技术沙龙活动总结

    活动搞完,一般都得总结一下。但人们对自己当事的东西通常很难表达。就像以前学校考试,每次考完被问考得怎样,往往不知道该怎么回答。大部分题目感觉像是做对了,但又不知道是否符合“标准答案”。考试的标准答案是老师定的,那活动或者演讲的“标准答案”呢,则是在每个参与者心中。

    现场情况

    很多参会的同学都做了精彩的总结,很客观,所以我也没必要进一步补充了。本次计划人数是50人,结果超出了一点,所以会场有点挤。(还有不少同学后到的,实际人数比照片上要多)
    第一期广州技术沙龙
    不足

    根据大家的反馈来看,主要有以下几点

    1. 交流机会不足

    本次也是依照传统的活动方式,演讲加提问,然后剩下时间小范围自由交流然后散会。由于会议室较小人又偏多,所以技术沙龙变成了技术演讲会。这个也是我们技术沙龙需要继续思考的一个问题,是限制参加人数以便形成多方讨论?还是召集更多的技术人来进行单向技术分享会?(当然不管哪种方式,并不妨碍我们用视频直播,视频及演讲稿分享等方式传达给更多群体)

    2. 不够专业及深入

    由于我选的Key value store题目过大,所以大部分内容只能蜻蜓点水。最大的价值可能就是给对这些方面感兴趣的同学提供一个参考的学习方向。

    演讲稿说明

    大家感兴趣的可能是Benchmark那部分,其实那个只是花了几个小时的功夫,因为手头的测试试验环境相对比较全面,所以测试起来也没费什么周折。其实我自己最看重、最希望传达的是演讲稿的后半部分,希望大家在设计自己的网络应用的时候,能够借鉴一些先进的分布式思想,指导自己少走一些弯路。部分观点其实我也没有实践经验,但是根据自己目前手头的一些应用的现状,觉得应用这些思想到系统中可以极大的提高系统的可扩展性及可维护性。Dynamo等Paper像一座桥梁,可以拉近我们与国外分布式设计思想的距离,让我们在这些已经被认可的方法的基础上去发现新的问题,迎接更有意义的挑战。

    由于这次要组织活动,所以基本没同来参会的各位向往已久的同学深入交流,这个是最大的遗憾。

    下一期的技术沙龙是zhuzhaoyuan的nginx源码剖析方面话题,预计在9月中上旬召开,地点在网易。

    附:搜集到一些同学的作业

    MemcacheDB, Tokyo Tyrant, Redis performance test

    I had tested the following key-value store for set() and get()

    1. Test environment

    1.1 Hardware/OS

    2 Linux boxes in a LAN, 1 server and 1 test client
    Linux Centos 5.2 64bit
    Intel(R) Xeon(R) CPU E5410  @ 2.33GHz (L2 cache: 6M), Quad-Core * 2
    8G memory
    SCSI disk (standalone disk, no other access)

    1.2 Software version

    db-4.7.25.tar.gz
    libevent-1.4.11-stable.tar.gz
    memcached-1.2.8.tar.gz
    memcachedb-1.2.1-beta.tar.gz
    redis-0.900_2.tar.gz
    tokyocabinet-1.4.9.tar.gz
    tokyotyrant-1.1.9.tar.gz

    1.3 Configuration

    Memcachedb startup parameter
    Test 100 bytes
    ./memcachedb -H /data5/kvtest/bdb/data -d -p 11212 -m 2048 -N -L 8192
    (Update: As mentioned by Steve, the 100-byte-test missed the -N paramter, so I added it and updated the data)
    Test 20k bytes
    ./memcachedb -H /data5/kvtest/mcdb/data -d -p 11212 -b 21000 -N -m 2048

    Tokyo Tyrant (Tokyo Cabinet) configuration
    Use default Tokyo Tyrant sbin/ttservctl
    use .tch database, hashtable database

    ulimsiz=”256m”
    sid=1
    dbname=”$basedir/casket.tch#bnum=50000000″ # default 1M is not enough!
    maxcon=”65536″
    retval=0

    Redis configuration
    timeout 300
    save 900 1
    save 300 10
    save 60 10000
    # no maxmemory settings

    1.4 Test client

    Client in Java, JDK1.6.0, 16 threads
    Use Memcached client java_memcached-release_2.0.1.jar
    JRedis client for Redis test, another JDBC-Redis has poor performance.

    2. Small data size test result

    Test 1, 1-5,000,000 as key, 100 bytes string value, do set, then get test, all get test has result.
    Request per second(mean)key-value-performance-1(Update)

    Store Write Read
    Memcached 55,989 50,974
    Memcachedb 25,583 35,260
    Tokyo Tyrant 42,988 46,238
    Redis 85,765 71,708

    Server Load Average

    Store Write Read
    Memcached 1.80, 1.53, 0.87 1.17, 1.16, 0.83
    MemcacheDB 1.44, 0.93, 0.64 4.35, 1.94, 1.05
    Tokyo Tyrant 3.70, 1.71, 1.14 2.98, 1.81, 1.26
    Redis 1.06, 0.32, 0.18 1.56, 1.00, 0.54

    3. Larger data size test result

    Test 2, 1-500,000 as key, 20k bytes string value, do set, then get test, all get test has result.
    Request per second(mean)
    (Aug 13 Update: fixed a bug on get() that read non-exist key)
    key-value-performance-2(update)

    Store Write Read
    Memcachedb 357 327
    Tokyo Tyrant 3,501 257
    Redis 1,542 957

    4. Some notes about the test

    When test Redis server, the memory goes up steadily, consumed all 8G and then use swap(and write speed slow down), after all memory and swap space is used, the client will get exceptions. So use Redis in a productive environment should limit to a small data size. It is another cache solution rather than a persistent storage. So compare Redis together with MemcacheDB/TC may not fair because Redis actually does not save data to disk during the test.

    Tokyo cabinet and memcachedb are very stable during heavy load, use very little memory in set test and less than physical memory in get test.

    MemcacheDB peformance is poor for write large data size(20k).

    The call response time was not monitored in this test.

    12