birdeye 绘制拓扑关系图

[不指定 2011/09/30 11:48 | by ipaddr ]

BirdEye是一个开源的Adobe Flex图表制作组件。用于创建多维数据分析可视化界面。

birdeye 可以绘制 拓扑图,关系图,流程图,星空图,地图,饼图 等等..

birdeye 项目地址:http://code.google.com/p/birdeye/

birdeye 源码下载:http://code.google.com/p/birdeye/source/checkout  需要用SVN.

birdeye Demo:http://birdeye.googlecode.com/svn/branches/ng/examples/demo/BirdEyeExplorer.html

birdeye  svn源码地址:

svn checkout http://birdeye.googlecode.com/svn/trunk/ birdeye-read-only

不管是管理1台,或者是上万台机器,puppet都能轻松搞定。让你的所有配置工作整齐划一。所谓配置管理系统,就是管理机器里面诸如文件,用户,进程,软件包这些资源。传统的方法要管理1千台相同的机器,可以选择cfengine,或者是for循环,其实for循环是用的最多的方法。

用puppet,可以运行一个服务器端,然后每个客户端通过ssl证书连接服务器,得到本机器的配置列表,然后更加列表的来完成配置工作。

所以如果硬件配置好了,你在一天之内配置好上万台机器是很轻松的事情。前提是大部分机器配置类似。google用puppet管理了6000多台mac桌面机器。

这个是puppet的官方主页:http://reductivelabs.com/projects/puppet

个人用户也很有用,可以把你常用的配置记录成puppet格式的配置文件,下次重装系统,只需要运行这个配置就能配置到你指定的状态。比如我自己的机器,就是所有的软件包和各种各样的配置全都搞好了。


What is PacketShader?

PacketShader is a high-performance PC-based software router platform that accelerates the core packet processing with Graphics Processing Units (GPUs). Based on our observation that the CPU is the typical performance bottleneck in high-speed sofware routers, we scale the computing power in a cost-effective manner with massively-parallel GPU. PacketShader offloads computation and memory-intensive router applications to GPUs while optimizing the packet reception and transmission path on Linux. With extensive batch processing and pipelining, PacketShader achieves an unprecedented IP packet forwarding performance of 40 Gbps on an eight-core Nehalem server even for 64-byte packet size.

http://shader.kaist.edu/packetshader/

nginx配置文件中的location详解

[不指定 2011/08/21 18:45 | by ipaddr ]

location
语法:location [=|~|~*|^~] /uri/ { … }
默认:否

上下文:server

这个指令随URL不同而接受不同的结构。你可以配置使用常规字符串和正则表达式。如果使用正则表达式,你必须使用 ~* 前缀选择不区分大小写的匹配或者 ~ 选择区分大小写的匹配。

确定 哪个location 指令匹配一个特定指令,常规字符串第一个测试。常规字符串匹配请求的开始部分并且区分大小写,最明确的匹配将会被使用(查看下文明白 nginx 怎么确定它)。然后正则表达式按照配置文件里的顺序测试。找到第一个比配的正则表达式将停止搜索。如果没有找到匹配的正则表达式,使用常规字符串的结果。

有两个方法修改这个行为。第一个方法是使用 “=”前缀,将只执行严格匹配。如果这个查询匹配,那么将停止搜索并立即处理这个请求。例子:如果经常发生”/”请求,那么使用 “location = /” 将加速处理这个请求。

第二个是使用 ^~ 前缀。如果把这个前缀用于一个常规字符串那么告诉nginx 如果路径匹配那么不测试正则表达式。

而且它重要在于 NGINX 做比较没有 URL 编码,所以如果你有一个 URL 链接’/images/%20/test’ , 那么使用 “images/ /test” 限定location。

总结,指令按下列顺序被接受:
1. = 前缀的指令严格匹配这个查询。如果找到,停止搜索。
2. 剩下的常规字符串,长的在前。如果这个匹配使用 ^~ 前缀,搜索停止。
3. 正则表达式,按配置文件里的顺序。
4. 如果第三步产生匹配,则使用这个结果。否则使用第二步的匹配结果。

例子:

location = / {
# 只匹配 / 查询。
[ configuration A ]
}

location / {
# 匹配任何查询,因为所有请求都已 / 开头。但是正则表达式规则和长的块规则将被优先和查询匹配。
[ configuration B ]
}

location ^~ /images/ {
# 匹配任何已 /images/ 开头的任何查询并且停止搜索。任何正则表达式将不会被测试。
[ configuration C ]
}

location ~* \.(gif|jpg|jpeg)$ {
# 匹配任何已 gif、jpg 或 jpeg 结尾的请求。然而所有 /images/ 目录的请求将使用 Configuration C。
[ configuration D ]
}

例子请求:

/ -> configuration A

/documents/document.html -> configuration B

/images/1.gif -> configuration C

/documents/1.jpg -> configuration D

注意:按任意顺序定义这4个配置结果将仍然一样。

(location =) > (location 完整路径 ) >(location ^~ 路径) >(location ~*, ~ 正则) >(location 部分起始路径)
正则表达式根据配置文件中的前后顺序影响匹配, 前面的优先匹配. 其它则根据匹配长度来优先匹配.

参考:
http://wiki.nginx.org/NginxHttpCoreModule#location

This directive allows different configurations depending on the URI. It can be configured using both literal strings and regular expressions. To use regular expressions, you must use a prefix:

  1. "~" for case sensitive matching
  2. "~*" for case insensitive matching

To determine which location directive matches a particular query, the literal strings are checked first. Literal strings match the beginning portion of the query - the most specific match will be used. Afterwards, regular expressions are checked in the order defined in the configuration file. The first regular expression to match the query will stop the search. If no regular expression matches are found, the result from the literal string search is used.

For case insensitive operating systems, like Mac OS X or Windows with Cygwin, literal string matching is done in a case insensitive way (0.7.7). However, comparison is limited to single-byte locale's only.

Regular expression may contain captures (0.7.40), which can then be used in other directives.

It is possible to disable regular expression checks after literal string matching by using "^~" prefix. If the most specific match literal location has this prefix: regular expressions aren't checked.

By using the "=" prefix we define the exact match between request URI and location. When matched search stops immediately. E.g., if the request "/" occurs frequently, using "location = /" will speed up processing of this request a bit as search will stop after first comparison.

On exact match with literal location without "=" or "^~" prefixes search is also immediately terminated.

To summarize, the order in which directives are checked is as follows:

  1. Directives with the "=" prefix that match the query exactly. If found, searching stops.
  2. All remaining directives with conventional strings. If this match used the "^~" prefix, searching stops.
  3. Regular expressions, in the order they are defined in the configuration file.
  4. If #3 yielded a match, that result is used. Otherwise, the match from #2 is used.

It is important to know that nginx does the comparison against decoded URIs. For example, if you wish to match "/images/%20/test", then you must use "/images/ /test" to determine the location.


Nginx内置变量: http://wiki.nginx.org/HttpCoreModule

Google开源Key-Value数据库LevelDB

[不指定 2011/08/01 10:54 | by ipaddr ]

Google宣布将LevelDB开源,并且遵守New BSD许可证。LevelDB是一个嵌入式的key-value数据库。它的键和关联值可以是任意的字节数组,并且按照键值排序,排序机制是可以被重载的。数据存储机制非常简单,仅仅支持Put,Get和Delete命令,然后还有前向和后向迭代遍历。

数据会自动使用Snappy压缩,这是一个压缩库,Google将其用于BigTable,MapReduce和RPC中,并且在四月份宣布开源。LevelDB也有一些局限:不支持SQL查询和索引,支持多线程单进程访问,并且可以用于嵌入式设备,这将使某些项目收益,但是也会给其他的项目来带麻烦。

LevelDB优化了批量写操作。它将多个修改请求有序缓存在内存中,在累计到配置文件预设置的阈值之后再写入到磁盘中。对于顺序和随机写操作,以及顺序读操作来说,它的性能非常优秀,根据Google的性能基准测试,它能在某些测试项目中得分领先SQLite两个数量级。SQLite在随机读操作中比LevelDB稍好,而在写入较大数据的时候速度两倍快于LevelDB。LevelDB同样也表现得比Kyoto Cabinet优秀,Kyoto Cabinet也是一个key-value数据库,不过Google并没有像SQLite那样在所有测试项目中均进行比较。同样,Riak进行了一些测试对比LevelDB和InnoDB,在一些测试项目中,Google的LevelDB要比InnoDB要优秀或者能达到相同性能。

LevelDB是使用C++编写,一些外部的依赖库已经成功地移植到Windows、Mac OS X、Android和各种Unix上。在实际的应用中,Chrome的一些实验性版本中已经使用了LevelDB,将其作为IndexDB API的实现。而Riak则将其用于节点级的存储。不仅如此,一家开发3D地图软件的公司UpNext也使用了这套系统。


http://www.mydumper.org/

Mydumper (aka. MySQL Data Dumper) is a high-performance multi-threaded backup (and restore) toolset for MySQL and Drizzle.  The main developers originally worked as Support Engineers at MySQL (one has moved to Facebook and another to SkySQL) and this is how they would envisage mysqldump based on years of user feedback.

Mydumper features

  • Lightweight C source
  • Up to 10x faster dumps compared to mysqldump
  • Consistent snapshots for transactional and non-transactional tables (in 0.2.2 onwards)
  • File compression on-the-fly
  • Binary log dumps
  • Multi-threaded restore utility (in 0.2.1 onwards)
  • Daemon mode for timed snapshots and continuous binary logs (in 0.5.0 onwards)
  • Open Source! (GNU GPLv3)

Mydumper is still under active development but is well tested/used in production on some large installations.

性能测试工具sysbench简介

[不指定 2011/06/29 13:23 | by ipaddr ]

sysbench是一款开源的多线程性能测试工具,可以执行CPU/内存/线程/IO/数据库等方面的性能测试。数据库目前支持MySQL/Oracle/PostgreSQL。本文只是简单演示一下几种测试的用法,后续准备利用sysbench来对MySQL进行一系列的测试。具体的一些参数设置,需要根据不同的测试要求来进行调整。

下载
http://sourceforge.net/projects/sysbench/


调节内核参数:
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 30

如果,你的服务器,和所有可能的客户,都不处于NAT环境,还可以打开
net.ipv4.tcp_tw_recycle = 1

这里要注意一点,普通公网的机器不能起用回收,否则会导致问题。
参考:

http://zhangle.is-a-geek.org/2010/11/tcp_tw_recycle%E5%92%8Cnat/


如发现系统存在大量TIME_WAIT状态的连接,通过调整内核参数解决,
vim /etc/sysctl.conf
编辑文件,加入以下内容:
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout = 30
然后执行 /sbin/sysctl -p 让参数生效。

net.ipv4.tcp_syncookies = 1 表示开启SYN Cookies。当出现SYN等待队列溢出时,启用cookies来处理,可防范少量SYN攻击,默认为0,表示关闭;
net.ipv4.tcp_tw_reuse = 1 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接,默认为0,表示关闭;
net.ipv4.tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收,默认为0,表示关闭。
net.ipv4.tcp_fin_timeout 修改系?默认的 TIMEOUT 时间

百万级PHP网站架构工具箱

[不指定 2011/06/15 19:33 | by ipaddr ]

  在了解过世界最大的PHP站点,Facebook的后台技术后,今天我们来了解一个百万级PHP站点的网站架构:Poppen.de。Poppen.de是德国的一个社交网站,相对Facebook、Flickr来说是一个很小的网站,但它有一个很好的架构,融合了很多技术,如 Nigix、MySql、CouchDB、Erlang、Memcached、RabbitMQ、PHP、Graphite、Red5以及Tsung。

  Poppen.de目前有200万注册用户数、2万并发用户数、每天20万条私有消息、每天25万登录次数。而项目团队有11个开发人员,两个设计,两个系统管理员。该站点的商业模式采用免费增值模式,用户可以使用搜索用户、给好友发送消息、上载图片和视频等功能。

  如果用户想享受不受限制发送消息和上载图片,那么就得根据需要支付不同类型的会员服务,视频聊天及网站其他服务也采用同样的策略。

  Nginx

  Poppen.de 所有的服务都是基于Nginx服务上的。前端有两台Nginx服务器在高峰期提供每分钟15万次请求的负载,每个机器已经有四年寿命,并且只有一个CPU 和3GB RAM。Poppen.de拥有三台独立的图像服务器,由三台Nginx服务器为*.bilder.poppen.de提供每分钟8万次请求服务。

   Nginx 架构中一个很酷的设计就是有很多请求是由Memcached处理的,因此请求从缓存中获取内容而不需要直接访问PHP机器。比如,用户信息页(user profile)是网站需要密集处理的内容,如果把用户信息页全部缓存到Memcached上,那么请求直接从Memcached上获取内容。 Poppen.de的Memcached每分钟可以处理8000次请求。

  架构中有三个Nginx图像服务器提供本地图像缓存,用户上载 图像到一个中央文件服务器。当向这三个Nginx之一中请求图像时,如果服务器本地中没有存在该图像,则从中央文件服务器下载到该服务器上作缓存并提供服务。这种负载均衡的分布式图像服务器架构设计可以减轻主要存储设备的负载。

  PHP-FPM

  该网站运行在PHP- FPM上。共有28台双CPU、6GB内存的PHP机器,每个机器上运行100个PHP-FPM的工作线程。使用启用了APC的PHP5.3.x。 PHP5.3可以降低CPU和内存使用率的30%以上。

  程序代码是基于Symfony1.2框架之上开发的。一是可以使用外部资源,二是能够提高项目开发进度,同时在一个著名的框架上可以让新开发人员更容易加入到团队中来。虽然没有任何事情都是十全十美的,但可以从Symfony框架中得到很多好处,让团队可以更多的精力放在Poppen.de的业务开发上去。

  网站性能优化使用XHProf,这是Facebook开源出来的一个类库。这个框架非常容易个性化和配置,能够可以缓存大部分高代价的服务器计算。

  MySQL

  MySQL是网站主要的RDBMS。网站又几个MySql服务器:一台4CPU、32GB的服务器存储用户相关信息,如基本信息、照片描述信息等。这台机器已经使用了4 年,下一步计划会使用共享集群来替换它。目前仍基于这个系统上进行设计,以简化数据访问代码。根据用户ID进行数据分区,因为网站中大部分信息都是以用户为中心的,如照片、视频、消息等。

  有三台服务器按主-从-从配置架构提供用户论坛服务。一台从服务器负责网站自定义消息存储,到现在有 2.5亿条消息。另外四台机器为主-从配置关系。另外由4台机器配置成NDB族群专门服务于密集型写操作数据,如用户访问统计信息。

  数据表设计尽量避免关联操作,尽可能缓存最多的数据。当然,数据库的结构化规范已经完全被破坏掉了。因此,为了更容易搜索,数据库设计创建了数据挖掘表。大部分表是MyISAM型表,可以提供快速查找。现在的问题是越来越多的表已经全表锁住了。Poppen.de正考虑往XtraDB存储引擎上迁移。

  Memcached

  网站架构中Memcached应用相当多,超过45GB的高速缓存和51个节点。缓存了Session会话、视图缓存以及函数执行缓存等。架构中有一个系统当记录被修改时可以自动地把数据更新到缓存中去。未来改善缓存更新的可能方案是使用新的Redis Hash API或者MongoDB。

  RabbitMQ

   在 2009年中开始在架构中使用RabbitMQ。这是一个很好的消息解决方案,便于部署和集中到这个架构中去,在LVS后运行了两台RabbitMQ服务器。在上个月,已经把更多的东西集成到该队列中,意味着同一时刻有28台PHP服务器每天要处理50万次请求。发送日志、邮件通知、系统消息、图像上载等更多的东西到这个队列中。

  应用PHP-FPM中的fastcgi_finish_request()函数集成队列消息,可以把消息异步发送到队列中。当系统需要给用户发送HTML或JSON格式响应时,就调用这个函数,这样用户就没有必要等到PHP脚本清理。

  这个系统可以改善架构资源管理。例如,在高峰期服务每分钟可以处理1000次登录请求。这表示有1000并发更新用户表保存用户的登录时间。由于使用了队列机制,可以按相反的顺序来运行这些查询。如果需要提高处理速度,只需要增加更多的队列处理者即可,甚至可以增加更多的服务器到这集群中去,而不需要修改任何配置和部署新节点。

  CouchDB

  日志存储CouchDB运行在一台机器上。在这台机器上可以根据模块/行为进行日志查询 /分组,或者根据错误类型等等。这对定位问题非常有用。在使用日志聚合服务CouchDB之前,不得不逐台登录到PHP服务器上设法日志分析定位问题,这是非常麻烦的。而现在把所有的日志集中到队列中保存到CouchDB中,可以集中进行问题检查和分析。

  Graphite

  网站使用Graphite采集网站实时信息并统计。从请求每个模块/行为到Memcached的命中和未命中、RabbitMQ状态监控以及Unix负载等等。Graphite服务平均每分钟有4800次更新操作。实践已经证实要监测网站发发生什么是非常有用的,它的简单文本协议和绘图功能可以方便地即插即 用的方式用于任何需要监控的系统上。

  一件很酷的事情是使用Graphite同时监控了网站的两个版本。一月份部署了Symfony框架新版本,以前代码作为一个备份部署。这就意味着网站可能会面临性能问题。因此可以使用Graphite来对两个版本在线进行对比。

  发现新版本上的Unix负载表较高,于是使用XHProf对两个版本进行性能分析,找出问题所在。

  Red5

  网站为用户也提供了两种类型的视频服务,一种是用户自己上载的视频,另外一种是视频聊天,用户视频互动和分享。到2009年年中,每月为用户提供17TB的流量服务。

  Tsung

  Tsung 是一个Erlang编写的分布式基准分析工具。在Poppen.de网站中主要用于HTTP基准分析、MySQL与其他存储系统(XtraDB)的对比分析。用一个系统记录了主要的MySQL服务器的流量,再转换成Tsung的基准会话。然后对该流量进行回放,由Tsung产生数以千计的并发用户访问实验室的服务器。这样就可以在实验环境中与真实场景非常接近。


主从数据一致性校验的利器: mk-table-sync
http://www.maatkit.org/doc/mk-table-sync.html

Usage: mk-table-sync [OPTION...] DSN [DSN...]

mk-table-sync synchronizes data efficiently between MySQL tables.

This tool changes data, so for maximum safety, you should back up your data before you use it. When synchronizing a server that is a replication slave with the --replicate or --sync-to-master methods, it always makes the changes on the replication master, never the replication slave directly. This is in general the only safe way to bring a replica back in sync with its master; changes to the replica are usually the source of the problems in the first place. However, the changes it makes on the master should be no-op changes that set the data to their current values, and actually affect only the replica. Please read the detailed documentation that follows to learn more about this.

Sync db.tbl on host1 to host2:

  mk-table-sync --execute h=host1,D=db,t=tbl h=host2

Sync all tables on host1 to host2 and host3:

  mk-table-sync --execute host1 host2 host3

Make slave1 have the same data as its replication master:

  mk-table-sync --execute --sync-to-master slave1

Resolve differences that mk-table-checksum found on all slaves of master1:

  mk-table-sync --execute --replicate test.checksum master1

Same as above but only resolve differences on slave1:

  mk-table-sync --execute --replicate test.checksum \     --sync-to-master slave1

Sync master2 in a master-master replication configuration, where master2's copy of db.tbl is known or suspected to be incorrect:

  mk-table-sync --execute --sync-to-master h=master2,D=db,t=tbl

Note that in the master-master configuration, the following will NOT do what you want, because it will make changes directly on master2, which will then flow through replication and change master1's data:

  # Don't do this in a master-master setup!   mk-table-sync --execute h=master1,D=db,t=tbl master2
分页: 8/57 第一页 上页 3 4 5 6 7 8 9 10 11 12 下页 最后页 [ 显示模式: 摘要 | 列表 ]