存档

2011年12月 的存档

百度Hi博客转移到WordPress工具(PHP)V1.0[原创]

2011年12月29日 没有评论

最近刚刚把博客转移到WordPress上了,博客托管在百度Hi上面确实不是长久之际,长期被鸡肋的功能和诸多限制折磨摧残,实在是不堪回首。

工具采用PHP编写,运行在CLI模式下。本人在XP下php5.29下运行测试通过。程序生成SQL文件,直接在MySQL管理工具(PHPMyAdmin、Navicat等)下执行SQL文件。

工具采用BSD协议授权,因为本人是开源新手,确实还有很多东西没有弄清楚,发布这个工具形式意义大于实际作用,寄此以自勉,希望以后能有更多更成熟的东西在开源社区分享。

博客上面写的东西不多,主要以转载为主,这2年下来也有100多往篇,百度Hi不带博客导出功能,Google了N久也没找到个满意的方案,遂动手写了一个,功能是简单了点,比较适合有一定编程基础的人使用.

软件名称:Baidu-hi2WordPress 1.0
软件作者:clear – 直来直往
授权方式:BSD
发布日期:2011.12.29
运行环境:WinXP/Linux
托管地址:https://github.com/aboustudy/baidu-hi2wordpress

baidu-hi2wordpress

 

当前只支持博客内容以及图片本地化,将来考虑评论导出功能,敬请期待。

使用过程中需要帮助请联系我 email

分类: 其他 标签:

开源协议常识

2011年12月28日 没有评论

先了解一下几个关于开源协议的基本常识

开源≠免费

开源世界有个很重要的容易被误解的地方就是“开源即免费”,并不是这样的,开源不等于免费,GPL的倡导组织自由软件组织也一再强调过“free不是免费,free是指自由”。由于大多数开源软件都是免费的,所以容易造成这种误解。

Contributors 和 Recipients

Contributors 指的是对某个开源软件或项目提供了代码(包括最初的或者修改过的)发布的人或者实体(团队、公司、组织等),Contributors 按照参与某个软件开源的时间先后,可以分为 an initial Contributor 和 subsequent Contributors .

Recipients指的是开源软件或项目的获取者,显然,subsequent Contributors 也属于 Recipients之列.

Source Code 和 Object Code

Source Code 指的是各种语言写成的源代码,通过Source Code,结合文档, 可以了解到整个软件的体系结构及具体到某个功能函数的实现方法等.

Object Code 指的是Source Code 经过编译之后,生成的类似于“类库”一样的,提供各种接口供他人使用的目标码,按我的理解,它就是像常见的DLL、ActiveX、OCX控件性质的东西.(不知道这样理解对不对)

分清楚这两个概念的目的在于,有些开源,只发布Object Code ,当然,大多数发布的是Source Code.很多协议也对 “你发布的是哪种Code的时候应该怎样”,有着明确的约束.

Derivative Module 和 Separate Module

Derivative Module 指的是,依托或包含“最初的”或者“从别人处获取的”开源代码而产生的代码,是原“源代码”的增强(不等于增加)、改善和延续的模块,意为“衍生模块”.

Separate Module 指的是,参考或借助原“源代码”,开发出的独立的,不包含、不依赖于原“源代码模块”,意为“独立的模块”.理解这两个概念的目的在于,很多协议对涉及到商业发布的时候,会有哪些是衍生的,哪些是独立的,有着明确的商业发布规定.

专有软件:需要购买,然后才能使用,且只能使用该软件而不能作其他用途。如修改、分享、再发布等。

共享软件:基本上就是专有软件,但你能在实际购买前试用。

免费软件:你可以自由的分享和使用该软件,但你无法修改该软件,因为该软件的源代码不是公开的。

开源软件/自由软件:你能够自由分享该软件与其源代码、使用该软件并可随意修改该软件源码 – 这给予了你最大的自主权。 阅读全文…

分类: 其他 标签: , , , , ,

linux命令Sysctl及常见内核参数调整

2011年12月22日 没有评论

        Sysctl命令用来配置与显示在/proc/sys目录中的内核参数.proc下的内核参数文件为内存映射,虚拟文件,实际中不存在,不能使用编辑器进行编辑。如果想使参数长期保存,可以通过编辑/etc/sysctl.conf文件来实现。

命令格式及参数:

sysctl [-n] [-e] -w variable=value
sysctl [-n] [-e] -p (default /etc/sysctl.conf)
sysctl [-n] [-e] Ca
-w  临时改变某个指定参数的值,如
# sysctl -w net.ipv4.ip_forward=1
-a  显示所有的系统参数

-p从指定的文件加载系统参数,默认从/etc/sysctl.conf 文件中加载,如:

# echo 1 > /proc/sys/net/ipv4/ip_forward
# sysctl -w net.ipv4.ip_forward=1
以上两种方法都可能立即开启路由功能,但如果系统重启,或执行了
# service network restart
命令,所设置的值即会丢失,如果想永久保留配置,可以修改/etc/sysctl.conf文件,将 net.ipv4.ip_forward=0改为net.ipv4.ip_forward=1
分类: Linux 标签:

MySQL服务器安装完之后如何调节性能

2011年12月21日 没有评论

看了原文觉得挺实用的,确实对于DB新农来讲,用系统默认配置或者MySQL自带的几个配置模板比较多,顶多会去调几个参数。这编博客列出的点如作者所述,“MySQL可调的参数确实不少,不过真正对系统性能有非常显著的影响就那么几个”。

key_buffer_size
innodb_buffer_pool_size
innodb_additional_mem_pool_size
innodb_log_file_size
innodb_log_buffer_size
innodb_flush_log_at_trx_commit
table_cache
thread_cache
query_cache_size

阅读全文…

分类: MySQL 标签:

MySQL如何避免使用swap

2011年12月20日 没有评论

Linux有很多很好的内存、IO调度机制,但是并不会适用于所有场景。对于DBA来说Linux比较让人头疼的一个地方是,它不会因为MySQL很重要就避免将分配给MySQL的地址空间映射到swap上。对于频繁进行读写操作的系统而言,数据看似在内存而实际上在磁盘是非常糟糕的,响应时间的增长很可能直接拖垮整个系统。这篇blog主要讲讲我们作为DBA,怎样尽量避免MySQL惨遭swap的毒手。

首先我们要了解点基础的东西,比如说为什么会产生swap。假设我们的物理内存是16G,swap是4G。如果MySQL本身已经占用了12G物理内存,而同时其他程序或者系统模块又需要6G内存,这时候操作系统就可能把MySQL所拥有的一部分地址空间映射到swap上去。

cp一个大文件,或用mysqldump导出一个很大的数据库的时候,文件系统往往会向Linux申请大量的内存作为cache,一不小心就会导致L使用swap。这个情景比较常见,以下是最简单的三个调整方法:
1、/proc/sys/vm/swappiness的内容改成0(临时),/etc/sysctl.conf上添加vm.swappiness=0(永久)
这个参数决定了Linux是倾向于使用swap,还是倾向于释放文件系统cache。在内存紧张的情况下,数值越低越倾向于释放文件系统cache。
当然,这个参数只能减少使用swap的概率,并不能避免Linux使用swap。
2、修改MySQL的配置参数innodb_flush_method,开启O_DIRECT模式。
这种情况下,InnoDB的buffer pool会直接绕过文件系统cache来访问磁盘,但是redo log依旧会使用文件系统cache。值得注意的是,Redo log是覆写模式的,即使使用了文件系统的cache,也不会占用太多。
3、添加MySQL的配置参数memlock
这个参数会强迫mysqld进程的地址空间一直被锁定在物理内存上,对于os来说是非常霸道的一个要求。必须要用root帐号来启动MySQL才能生效。

还有一个比较复杂的方法,指定MySQL使用大页内存(Large Page)。Linux上的大页内存是不会被换出物理内存的,和memlock有异曲同工之妙。
具体的配置方法可以参考:http://harrison-fisk.blogspot.com/2009/01/enabling-innodb-large-pages-on-linux.html

这里需要补充一下上面4种方法原理和实现机制,对于Linux api不感兴趣的同学可以直接跳过。

一、操作系统设置swap的目的
程序运行的一个必要条件就是足够的内存,而内存往往是系统里面比较紧张的一种资源。为了满足更多程序的要求,操作系统虚拟了一部分内存地址,并将之映射到swap上。对于程序来说,它只知道操作系统给自己分配了内存地址,但并不清楚这些内存地址到底映射到物理内存还是swap。
物理内存和swap在功能上是一样的,只是因为物理存储元件的不同(内存和磁盘),性能上有很大的差别。操作系统会根据程序使用内存的特点进行换入和换出,尽可能地把物理内存留给最需要它的程序。但是这种调度是按照预先设定的某种规则的,并不能完全符合程序的需要。一些特殊的程序(比如MySQL)希望自己的数据永远寄存在物理内存里,以便提供更高的性能。于是操作系统就设置了几个api,以便为调用者提供“特殊服务”。

二、Linux提供的几个api
1、mlockall()和munlockall()
这一对函数,可以让调用者的地址空间常驻物理内存,也可以在需要的时候将此特权取消。mlockall()的flag位可以是MCL_CURRENT和MCL_FUTURE的任意组合,分别代表了“保持已分配的地址空间常驻物理内存”和“保持未来分配的地址空间常驻物理内存”。对于Linux来说,这对函数是非常霸道的,只有root用户才有权限调用。

2、shmget()和shmat()
这一对函数,可以向操作系统申请使用大页内存(Large Page)。大页内存的特点是预分配和永驻物理内存,因为使用了共享内存段的方式,page table有可能会比传统的小页分配方式更小。对于多进程共享内存的程序(比如ORACLE),大页内存能够节省很多page table开销;而对于MySQL来说,性能和资源开销都没有显著变化,好处就在于减少了内存地址被映射到swap上的可能。至于为什么是减少,而不是完全避免,之后再讲解。

3、O_DIRECT和posix_memalign()
以上两个方法都不会减少内存的使用量,调用者的本意是获取更高的系统特权,而不是节约系统资源。O_DIRECT是一种更加理想化的方式,通过避免double buffer,节省了文件系统cache的开销,最终减少swap的使用率。O_DIRECT是Linux IO调度相关的标志,在open函数里面调用。通过O_DIRECT标志打开的文件,读写都不会用到文件系统的cache。传统的数据库(ORACLE、MySQL)基本都有O_DIRECT相关的开关,在提高性能的同时,也减少了内存的使用。至于posix_memalign(),是用来申请对齐的内存地址的。只有用posix_memalign()申请的内存地址,才能用来读写O_DIRECT模式下的文件描述符。

4、madvise()和fadvise()
这对函数也是比较温和的,可以将调用者对数据访问模式的预期传递给Linux,以期得到更好的性能。
我们比较感兴趣的是MADV_DONTNEED和FADV_NOREUSE这两个flag。前者会建议Linux释放指定的内存区域,而后者会建议文件系统释放指定文件所占用的cache。

三、MySQL内存使用相关的一些代码
1、memlock
在MySQL的源码目录里面查询memlock,可以知道这个参数的作用是使MySQL调用mlockall()。在源码里面匹配可以得知NDB、MyISAM和mysqld都调用了mlockall()。NDB是可以独立于MySQL而存在的存储引擎,此处按下不表。mysqld调用mlockall()的方式有点出乎意料,在init_server_components()函数里传给mlockall()的flag是MCL_CURRENT,也就是说之后申请的内存一概不用锁住。再看看MyISAM的调用顺序是:mlockall() <- lock_memory() <- mi_repair(),MyISAM只有修复的时候会调用mlockall()函数。

2、large-pages
根据Linux的内核文档,大页内存有两种方法可以用到:一种是创建hugetlb类型的文件,并将它mmap到程序的内存地址里面,然后进行正常的读写操作。另外一种是之前说到的shmget()+shmat(),也正是MySQL采用的方式。在MySQL的源码目录里面匹配shmget,可以发现BDB、NDB、InnoDB、MyISAM都调用了这个函数。接着看一下比较常用的InnoDB和MyISAM引擎。
在InnoDB里面可以找到os_mem_alloc_large()调用了shmget(),而调用os_mem_alloc_large()的函数只有buf_pool_init()――InnoDB Buffer Pool的初始化函数。根据观察得到的结论是,InnoDB会根据配置参数在Buffer Pool里面使用大页内存,Redo log貌似就没有这个待遇了。
对于MyISAM,在storage层级的代码里面找不到对shmget()的直接调用。这是因为MyISAM是MySQL的原生存储引擎,很多函数存放在上一层的mysys目录里面。通过搜索shmget(),我们可以找到MyISAM的调用顺序是这样的:shmget() <- my_large_malloc_int() <- my_large_malloc() <- init_key_cache()。也就是说MyISAM只有索引缓存用到了大页内存,这是很容易理解,因为MyISAM的数据是直接扔给文件系统做缓存的,没法使用大页内存。

3、innodb_flush_method
O_DIRECT是BDB、NDB、InnoDB特有的参数,在这里只讨论InnoDB这个比较常见的引擎。在InnoDB的源码目录里面匹配O_DIRECT,很容易找到一个叫做os_file_set_nocache()的函数,而这个函数作用是将文件的打开方式改为O_DIRECT模式。再跟踪一下,会发现只有os_file_create()函数调用了os_file_set_nocache()。虽然函数名里面还有create,实际上os_file_create()会根据传入参数的不同,选择打开或者新建一个文件。同时os_file_create()还会根据MySQL的配置,来调用os_file_set_nocache()关闭文件系统的相应cache。在os_file_create()函数里面有如下一段代码:
/* We disable OS caching (O_DIRECT) only on data files */
if (type != OS_LOG_FILE &&
srv_unix_file_flush_method == SRV_UNIX_O_DIRECT)
{
os_file_set_nocache(file, name, mode_str);
}
这段代码的意思是,只有InnoDB的数据文件有资格使用O_DIRECT模式,Redo log是不能使用的。

以上的分析基于5.0.85版本的原版MySQL,InnoDB是Innobase。
版本不同情况下可能会有一些出入,欢迎参与讨论。

参考文献:
Virtual memory@wiki
All about Linux swap space
HugeTLB C Large Page Support in the Linux Kernel
Page table@wiki
原文 http://www.taobaodba.com/html/552_mysql_avoid_swap.html

分类: MySQL 标签:

MySQL Query Cache 运行参数及状态检测

2011年12月19日 没有评论

MySQL的Query Cache系统变量都是以“query_cache“作为前后缀的,它们分别是:

have_query_cache
query_cache_limit
query_cache_min_res_unit
query_cache_size
query_cache_type
query_cache_wlock_invalidate

其中”have_query_cache“变量标识是QueryCache是否可用。可通过以下命令查看:

通常这个变量值为YES,即使QueryCache功能不可用的时候:当“query_cache_size”的值为0的时候,即使”have_query_cache=YES”,QueryCache也不可用。

标准版MySQL中“query_cache_size”为0,也即,默认配置下QueryCache是不可用的。

我们可以通过配置文件、启动参数和命令设置相关参数。如通过”SET”命令设置“query_cache_size”:

全局设置:mysql> SET GLOBAL query_cache_size = 1048576;
会话设置:mysql> SET SESSION query_cache_size = 1048576;

      如果你使用的时候标准 MySQL 分发版的话,Query Cache 功能默认都是打开的,我们可以通过调整 MySQL Server 的参数选项打开该功能。它们主要由以下5个参数构成:

  • query_cache_limit:允许 Cache 的单条 Query 结果集的最大容量,默认是1MB,超过此参数设置的 Query 结果集将不会被 Cache
  • query_cache_min_res_unit:设置 Query Cache 中每次分配内存的最小空间大小,也就是每个 Query 的 Cache 最小占用的内存空间大小
  • query_cache_size:设置 Query Cache 所使用的内存大小,默认值为0,大小必须是1024的整数倍,如果不是整数倍,MySQL 会自动调整降低最小量以达到1024的倍数。
    query_cache_size最小值不能小于40KB,否则系统将会产生一个WARNING:Query cache failed to set size 39936;new query cache size is 0.
  • query_cache_type:控制 Query Cache 功能的开关,可以设置为0(OFF),1(ON)和2(DEMAND)三种,意义分别如下:
    • 0(OFF):关闭 Query Cache 功能,任何情况下都不会使用 Query Cache
    • 1(ON):开启 Query Cache 功能,但是当 SELECT 语句中使用的 SQL_NO_CACHE 提示后,将不使用Query Cache
    • 2(DEMAND):开启 Query Cache 功能,但是只有当 SELECT 语句中使用了 SQL_CACHE 提示后,才使用 Query Cache
  • query_cache_wlock_invalidate:控制当有写锁定发生在表上的时刻是否先失效该表相关的 Query Cache,如果设置为 1(TRUE),则在写锁定的同时将失效该表相关的所有 Query Cache,如果设置为0(FALSE)则在锁定时刻仍然允许读取该表相关的 Query Cache。

系统的 Query Cache 的运行状态参数
MySQL 提供了一系列的 Global Status 来记录 Query Cache 的当前状态,具体如下:

  • Qcache_free_blocks:目前还处于空闲状态的 Query Cache 中内存 Block 数目
  • Qcache_free_memory:目前还处于空闲状态的 Query Cache 内存总量
  • Qcache_hits:Query Cache 命中次数
  • Qcache_inserts:向 Query Cache 中插入新的 Query Cache 的次数,也就是没有命中的次数
  • Qcache_lowmem_prunes:当 Query Cache 内存容量不够,需要从中删除老的 Query Cache 以给新的 Cache 对象使用的次数
  • Qcache_not_cached:没有被 Cache 的 SQL 数,包括无法被 Cache 的 SQL 以及由于 query_cache_type 设置的不会被 Cache 的 SQL
  • Qcache_queries_in_cache:目前在 Query Cache 中的 SQL 数量
  • Qcache_total_blocks:Query Cache 中总的 Block 数量

可以根据这几个状态计算出 Cache 命中率,计算出 Query Cache 大小设置是否足够,通常不建议将 Query Cache 的大小设置超过256MB,这也是业界比较常用的做法。

分类: MySQL 标签:

软件级负载均衡器(LVS/HAProxy/Nginx)的特点和对比

2011年12月14日 没有评论

现在网站发展的趋势对网络负载均衡的使用是随着网站规模的提升根据不同的阶段来使用不同的技术:

一种是通过硬件来进行进行,常见的硬件有比较昂贵的NetScaler、F5、Radware和Array等商用的负载均衡器,它的优点就是有专业的维护团队来对这些服务进行维护、缺点就是花销太大,所以对于规模较小的网络服务来说暂时还没有需要使用;另外一种就是类似于LVS/HAProxy、Nginx的基于Linux开源免费的负载均衡软件策略,这些都是通过软件级别来实现,所以费用非常低廉,所以我个也比较推荐大家采用第二种方案来实施自己网站的负载均衡需求。

近期朋友的项目成功上线了,PV达到了亿级/日的访问量,最前端用的是HAProxy+Keepalived双机作的负载均衡器/反向代理,整个网站非常稳定;这让我更坚定了以前跟老男孩前辈聊的关于网站架构比较合理设计的架构方案:即Nginx/HAProxy+Keepalived作Web最前端的负载均衡器,后端的MySQL数据库架构采用一主多从,读写分离的方式,采用LVS+Keepalived的方式。

在这里我也有一点要跟大家申明下:很多朋友担心软件级别的负载均衡在高并发流量冲击下的稳定情况,事实是我们通过成功上线的许多网站发现,它们的稳定性也是非常好的,宕机的可能性微乎其微,所以我现在做的项目,基本上没考虑服务级别的高可用了。相信大家对这些软件级别的负载均衡软件都已经有了很深的的认识,下面我就它们的特点和适用场合分别说明下。

LVS:使用集群技术和Linux操作系统实现一个高性能、高可用的服务器,它具有很好的可伸缩性(Scalability)、可靠性(Reliability)和可管理性(Manageability),感谢章文嵩博士为我们提供如此强大实用的开源软件。

LVS的特点是:

  1. 抗负载能力强、是工作在网络4层之上仅作分发之用,没有流量的产生,这个特点也决定了它在负载均衡软件里的性能最强的;
  2. 配置性比较低,这是一个缺点也是一个优点,因为没有可太多配置的东西,所以并不需要太多接触,大大减少了人为出错的几率;
  3. 工作稳定,自身有完整的双机热备方案,如LVS+Keepalived和LVS+Heartbeat,不过我们在项目实施中用得最多的还是LVS/DR+Keepalived;
  4. 无流量,保证了均衡器IO的性能不会收到大流量的影响;
  5. 应用范围比较广,可以对所有应用做负载均衡;
  6. 软件本身不支持正则处理,不能做动静分离,这个就比较遗憾了;其实现在许多网站在这方面都有较强的需求,这个是Nginx/HAProxy+Keepalived的优势所在。
  7. 如果是网站应用比较庞大的话,实施LVS/DR+Keepalived起来就比较复杂了,特别后面有Windows Server应用的机器的话,如果实施及配置还有维护过程就比较复杂了,相对而言,Nginx/HAProxy+Keepalived就简单多了。

Nginx的特点是:

  1. 工作在网络的7层之上,可以针对http应用做一些分流的策略,比如针对域名、目录结构,它的正则规则比HAProxy更为强大和灵活,这也是许多朋友喜欢它的原因之一;
  2. Nginx对网络的依赖非常小,理论上能ping通就就能进行负载功能,这个也是它的优势所在;
  3. Nginx安装和配置比较简单,测试起来比较方便;
  4. 也可以承担高的负载压力且稳定,一般能支撑超过几万次的并发量;
  5. Nginx可以通过端口检测到服务器内部的故障,比如根据服务器处理网页返回的状态码、超时等等,并且会把返回错误的请求重新提交到另一个节点,不过其中缺点就是不支持url来检测;
  6. Nginx仅能支持http和Email,这样就在适用范围上面小很多,这个它的弱势;
  7. Nginx不仅仅是一款优秀的负载均衡器/反向代理软件,它同时也是功能强大的Web应用服务器。LNMP现在也是非常流行的web架构,大有和以前最流行的LAMP架构分庭抗争之势,在高流量的环境中也有很好的效果。
  8. Nginx现在作为Web反向加速缓存越来越成熟了,很多朋友都已在生产环境下投入生产了,而且反映效果不错,速度比传统的Squid服务器更快,有兴趣的朋友可以考虑用其作为反向代理加速器。

HAProxy的特点是:

  1. HAProxy是支持虚拟主机的,以前有朋友说这个不支持虚拟主机,我这里特此更正一下。
  2. 能够补充Nginx的一些缺点比如Session的保持,Cookie的引导等工作
  3. 支持url检测后端的服务器出问题的检测会有很好的帮助。
  4. 它跟LVS一样,本身仅仅就只是一款负载均衡软件;单纯从效率上来讲HAProxy更会比Nginx有更出色的负载均衡速度,在并发处理上也是优于Nginx的。
  5. HAProxy可以对Mysql读进行负载均衡,对后端的MySQL节点进行检测和负载均衡,不过在后端的MySQL slaves数量超过10台时性能不如LVS,所以我向大家推荐LVS+Keepalived。
  6. HAProxy的算法现在也越来越多了,具体有如下8种:
    ① roundrobin,表示简单的轮询,这个不多说,这个是负载均衡基本都具备的;
    ② static-rr,表示根据权重,建议关注;
    ③ leastconn,表示最少连接者先处理,建议关注;
    ④ source,表示根据请求源IP,这个跟Nginx的IP_hash机制类似,我们用其作为解决session问题的一种方法,建议关注;
    ⑤ ri,表示根据请求的URI;
    ⑥ rl_param,表示根据请求的URl参数’balance url_param’ requires an URL parameter name;
    ⑦ hdr(name),表示根据HTTP请求头来锁定每一次HTTP请求;
    ⑧ rdp-cookie(name),表示根据据cookie(name)来锁定并哈希每一次TCP请求。 
原文:http://www.linuxde.net/2011/12/3867.html

分类: 架构 标签:

【原创翻译】GIT初始化–bare参数:git init & git init –bare

2011年12月12日 没有评论

       在使用Git初始化版本库的时候,使用"git init"命令和使用"git init –bare"命令有什么区别呢?

       用"git init"初始化的版本库(暂且称之为working repository)将会生成2类文件:“.git“版本库目录(记录版本历史)和实际项目文件的拷贝。你可以把这类版本库叫做“工作目录”。工作目录是一个包含有版本历史目录“.git"和源文件的目录。你可以在工作目录修改你的源文件并使用"git add"和"git commit"命令进行版本管理。

       用“git init –bare"初始化的版本库(暂且称之为bare repository)仅包含".git"目录(记录版本历史),不含项目源文件拷贝。如果你进入版本目录,你会发现仅有".git"目录,没有其他文件。版本库仅包含记录着版本历史的文件。

什么情况下使用“git init"和"git init –bare"呢?

       working repository适合于实际编辑生产过程中,在工作目录下,你将会进行实际的编码、文件管理操作和保存项目在本地工作。如果你开始创建一个项目将包含有源代码和和版本跟踪记录的时候你可以使用"git init".或者,如果你克隆"git clone"一个已经存在的版本库的时候,你也可以得到一个working repository,它也将包含".git"目录和源文件的拷贝。

       bare repository主要是用作分享版本库。开发者使用bare repository可以向其他人分享存储在本地的版本库,以便于实时分享代码更新和团队协作 。通过使用"git push"命令,你可以将你的本地更新提交至“中心版本库”(其他开发者可访问的中心库)。其他开发者可以使用“git pull"命令者接受你提交的版本更新。如果你正在一个多人协作的项目团队或者同一个项目需要在不同电脑上面完成的时候,bare repository可以满足你的分布式开发需求。

       总结:“工作目录”是通过使用“git init“或“git clone”创建的本地项目拷贝。我们可以在工作目录下面修改和测试代码。通过测试后我们可以使用“git add“和”git commit“命令本地提交修改,然后使用“git push”命令向远程 bare repository库提交更新,通常bare repository指定其他服务器,其他开发者将可以及时看到你的更新。当我们想去更新本地工作目录的时候,我们可以使用“git pull”命令去接受其他开发者提交的更新。

原文:what is a bare git repository? http://www.saintsjd.com/2011/01/what-is-a-bare-git-repository/
译By:  直来直往 http://hi.baidu.com/aboutstudy/blog/item/8cec7226e3c101098a82a1c6.html

分类: 其他 标签:

MongoDB、HandlerSocket和MySQL性能测试及其结果分析

2011年12月8日 没有评论

MongoDB性能还是十分强悍的,但HandlerSocket可以与传统MySQL同时使用MySQL数据库,互相不冲突,而且还可以继续使用MySQL的Master-Slave、Replication等成熟的机制,系统运维与传统的MySQL运维一致。


一、测试环境
1、测试服务器状况
共涉及4台测试服务器:

压力测试服务器
Web服务器
MongoDB服务器

MySQL服务器。

 

机器配置为:
CPU:Intel(R) Core(TM)2 Duo CPU     E7200  @ 2.53GHz
RAM:8G DDR2 667
磁盘:SATA

操作系统:Redhat 5.5

 

1. 压力测试服务器
安装Webbench 1.5,通过Webbench来压Web服务器。

 

2. Web服务器
Nginx 0.8.54 + PHP 5.3.3 (php-fpm),安装有Mongodb和HandlerSocket的php驱动。
Mongodb的php驱动为:mongodb-mongo-php-driver-1.1.1-19-gc584231.tar.gz
HandlerSocket的php驱动为:php-handlersocket-0.0.7.tar.gz
通过Php程序来调用Mongodb和HandlerSocket。

 

3. MongoDB服务器
MongoDB版本:1.6.5

 

4. MySQL服务器
MySQL版本:5.1.53
HandlerSocket版本:1.0.6-60-gf51e061
MySQL存储引擎:Innodb,调整了innodb的Thread Pool Size为2G

2、测试程序和测试数据提取
1. 为了避免打开连接和Http服务器成为瓶颈,在测试程序里设置为每1000个请求公用同一个连接,同时设置为每个页面请求执行1000次数据请求。
2. 测试的数据,包括QPS、CPU、IO等方面的数据,从操作系统提供的命令(如vmstat、iostat等)或者Mongodb、Mysql提供的命令(如mongostat、mysqladmin等)来获取。

二、测试结果
1、100万条记录
1. 查询

 

 

2. 插入

2、1000万条记录
1. 查询

2. 插入

 

3、2000万条记录

1. 查询

 
2. 插入

 

4、5000万条记录
1. 查询

 

2. 插入 

三、测试分析总结

1、 I/O读写情况
从插入情况下的TPS数据可以看出, MySQL、HandlerSocket和Mongodb的数据有比较明显的差别,这主要跟他们的内部实现和测试方式有关系。

 

测试场景下MySQL采用的是单条Insert的方式,所以可以看出QPS数和TPS数是基本一致的,也就是每个Insert操作,都对应有一次I/O写入操作。可以从MySQL数据库本身做一些优化,这次测试没有覆盖到这种场景。

 

HandlerSocket内部采用的是Bulk Insert操作,所以,可以看出QPS数明显大于TPS数,批量的插入操作明显提高了整体性能。

 

Mongodb内部采用合并操作的方式,采用数据先存放到内存中,然后再Flush到磁盘上的方式。所以,从测试数据可以看出,TPS曲线坡度非常大:有时候TPS是零,这时候是还放到内存中,还没有Flush到磁盘上;有时候TPS非常高,同时这时候CPU也非常高,几乎是100%,这时候是在做Flush到磁盘的操作。基于此种机制,以后会再做一些更细化的优化和测试,因为这样有可能会存在几种问题:
第一, 可能会导致某个时间段IO和CPU的压力非常大,甚至达到峰值,这种情况下,服务的整体健康状态将面临着一些挑战。
第二, 如果服务器重启,可能会出现数据丢失的情况,内存中的数据还没有Flush到磁盘的会丢失。当然这种情况是两面性的,因为采用这种方式,从测试结果也可以看出,整体的写入性能比MySQL和HandlerSocket都高,这是一种取舍,就看具体业务是否可以接受这样的以高性能换取数据可靠性,有些业务可能是可以接受的,比如Feed。

2、 CPU占用情况
从查询情况下的CPU数据可以看出,MySQL和Mongodb几乎都接近100%,而HandlerSocket由于省去了各种Sql Parser和相关的操作,CPU占用率保持在40%-60%之间,在一个比较合理的范围内。

 

从插入情况下的CPU数据可以看出,HandlerSocket的CPU占用率还是保持在40%-60%之间,低于MySQL和Mongodb。MySQL和Mongodb大部分情况保持在50%-90%之间。

 

3、 QPS情况
从查询情况下的QPS数据可以看出,HandlerSocket和Mongodb的查询性能几乎差不多,都达到3万以上,并且随着数据量的增长,性能没有回落,还是保持在3万以上。目前只是最大测试到5000万数据的情况,更高的数值这次测试还没有覆盖到。而MySQL的性能相比之下则差一些,一般在18000到25000之间。当然这次没有太多的针对MySQL做优化,只是增大了innodb_thread_pool大小和每次分配的数据块的大小,如果针对MySQL做优化,可能能同时提高HandlerSocket和MySQL的性能。

 

从插入情况下的QPS数据可以看出,Mongodb明显占有比较大的优势,这根之前说的它的实现方式有关。随着数据量的增长,QPS都相应的在减少,这方面,MySQL的幅度最大,数据量到达5000万以上时,MySQL的插入性能为2000-3000,而HandlerSocket能保持在1万以上,Mongodb为2万以上。

 

作者:洪小军
出处:http://www.cnblogs.com/inrie

分类: MySQL 标签:

HandlerSocket: 从MySQL到NoSQL的过渡替代方案?

2011年12月8日 没有评论

       HandlerSocket是MySQL的一个Plugin,通过它可以直接跟MySQL的Storage Engine Layer(比如InnoDB)交互,而不需要通过MySQL的Parser Layer。从性能角度有很大的提升。

       HandlerSocket特别适用于海量数据、高并发的具有简单业务模型的应用,比如微博、Feed。可以用来替代传统Memcached+MySQL的方式,而且性能上也接近于目前主流的NoSQL产品,所以还是有比较大的优势。但是需要清楚理性的看待这个问题,由于目前还刚发布不久,还远没有Memcached+MySQL成熟,所以,还是需要更多的功能和性能测试,更多地去研究它的源代码,这样才能更加放心的使用。现在的Memcached+MySQL的方式还是很好的方式,我觉得还将会长久下去,HandlerSocket+MySQL的出现,是给大家多了一个选择。 

一、HandlerSocket整体架构

HandlerSocket设计为MySQL的一个plugin,作为mysqld进程的daemon存在,与Client通过TCP/IP交互,进行CRUD相关的操作。基于此原因,不仅可以通过HandlerSocket操作存储层,还可以通过传统的MySQL的方式来操作。这样就可以实现:简单快速的操作通过HandlerSocket来实现,而对于一些复杂的操作,还是通过传统的MySQL方式来实现。

 

HandlerSocket的结构图如下(图片来自作者Blog):

 

这里分两条主线来分析上图:
1. MySQL Client -> MySQL Upper Layer -> Storage Engine Layer
这是传统的使用MySQL的方式,MySQL客户端通过3306端口与Upper层交互,在Upper层做SQL解析、打开表、查询计划优化、关闭表等操作,然后提交到Storage层。

2. HandlerSocket Client -> HandlerSocket daemon plugin -> Storage Engine Layer
这是采用HandlerSocket的方式,通过比较MySQL Upper Layer和HandlerSocket daemon plugin,可以明显看出,HandlerSocket减少了很多操作,这正是性能得以提高的最重要的关键点。这里使用的是9998和9999两个端口,9998作为读的端口,不能做写入操作,9999为写的端口,可以做读取操作,但是不建议使用,因为在9999端口做读取操作,从性能角度看,比起在9998端口上差一些。

 

下图更具体的列出了调用关系和结构:

 

注意目前版本的HandlerSocket暂时只支持Innodb,相信后续版本肯定会支持其他的Storage Engine。

二、HandlerSocket特点
HandlerSocket相比MySQL及其其他的NoSQL产品,具有一些优势:

1. 由于省去了MySQL的SQL层相关的操作,大大的减少了CPU开销。

2. 采用合并操作的方式,合并多个请求同时执行,减少了CPU开销和降低I/O操作次数。关于这个其他的一些NoSQL产品也有这样的机制,比如Mongodb。

3. 由于基于简单的文本协议,能节省不少网络流量,提高网络吞吐量。大部分的NoSQL产品都有这个优势,不少是兼容Memcached协议,当然更多的是采用专有的协议。

4. 能同时使用传统MySQL和HandlerSocket的方式访问MySQL数据库,互相不冲突。这个优势其实挺突出的,是HandlerSocket 的核心竞争力之一。 

5. 支持较大的并发连接,可以通过my.cnf的handlersocket_threads来配置连接数。

6. 还可以继续使用MySQL的Master-Slave、Replication等成熟的机制,系统运维与传统的MySQL运维一致。这也是HandlerSocket相比其他NoSQL产品具有的最大的优势。

7. 避免有双重缓存,比如对于Memcached+MySQL的应用来说,在Memcached和MySQL中都存有数据,需要双倍的内存资源,同时也可能会有数据不一致的问题。而采用HandlerSocket则可以避免这样的问题。具体的在接下来的应用场景里介绍。

8. 具有较高的读写性能,在CPU Bound的场景中,读取性能一般是同等环境下MySQL的3-7.5倍。同时写入性能也能达到3-5倍。

 

具有这些优势的同时,也要看到它目前存在的待改进或者应该注意的问题:
1. 由于采用合并操作的方式,这样做牺牲了响应时间,响应时间相比MySQL来说大一些。

2. 没有安全相关的保证,绝大部分NoSQL产品都有这样的问题。由于采用这样产品的应用的数据一般都不是核心数据,比如不会涉及到账户信息、用户信息等的,所以,安全性方面的暂时应该都不是什么大问题。

3. 在I/O Bound的场景中,性能的提升可能不是很明显。在这种场景下,性能的提升主要依靠的是合并操作,减少I/O操作次数,但是提高的幅度有限。

4. 由于2010年11月份刚发布,目前版本还有部分Bug待修复,比如通过HandlerSocket做Update操作后,没有清除Query Cache,这可能出现数据不一致的情况。

5. 目前只支持5.1和5.5的Innodb存储引擎,以后应该会支持其他存储引擎。

 

三、HandlerSocket应用场景
HandlerSocket目前已经在DeNA的生产环境上使用,据作者介绍,运行状态很不错,节省了不少Memcached和MySQL Slave服务器,同时网络传输量也减少了。到目前为止还没有发现什么性能问题,比如响应时间比较长等。

纵观目前绝大部分大型互联网应用,基本上采用的都是Memcached+MySQL的方式。这是一种很成熟并且很有效的方式,基本都成了标准方式。由于HandlerSocket在Innodb Buffer Pool命中率很高的情况下性能不会逊色于Memcached,所以在这种情况下,可以采用HandlerSocket+MySQL来替代Memcached+MySQL。这样有以下几个优势:

1. 采用Memcached+MySQL,需要保存两份数据:Memcached和MySQL本身的缓存,需要双倍的内存资源。而HandlerSocket+MySQL的方式,只需要保存一份缓存数据。

2. 采用Memcached+MySQL,需要保持Memcached与MySQL的数据一致性,有时候可能会出现数据不一致的情况,而如果用HandlerSocket+MySQL就没这情况。

3. 采用Memcached+MySQL,还有一个这样的应用都非常小心和特别注意的问题,就是雪崩效应。新应用上线的时候需要先做好各种预热,尽量减少瞬间超级大的I/O压力。前段时间新浪微博出现一次比较严重的故障,据不完全可靠消息证实,就是雪崩效应引起的,当时有部分Memcached服务器出现故障或者失效,导致DB服务器压力瞬间增大,支撑不住。当然了,HandlerSocket应用不是不需要预热,也是需要的,但是在面对这样的问题的时候,它的支撑能力比起MySQL+Memcached的能力强。

四、HandlerSocket性能

HandlerSocket作者测试HandlerSocket在查询情况下QPS为75K,Memcached为40K,MySQL为10K。但是需要注意到它的测试场景,一般的应用是很难有这样的场景的,所以说一般应用是很难达到7.5倍于MySQL的情况,但是性能的大幅度提高是不容置疑的。作者的测试场景如下:
1. 关闭MySQL的query cache:也就是MySQL的每次操作都需要执行sql解析等那一系列操作。

2. CPU Bound而非I/O Bound:InnoDB Buffer Pool设置为比较大,命中率接近100%。

所以,应该更客观的来看待测试数据。对于CPU Bound而非I/O Bound类型的应用,在InnoDB_Buffer_Pool接近100%命中率的时候,HandlerSocket可以将查询性能提高7.5倍。这一点其实不难理解,因为HandlerSocket主要性能优化点在于节省了SQL层的开销,SQL层的开销主要是CPU的开销。而如果对于一个I/O Bound的应用来说,HandlerSocket的查询性能可能就达不到7.5倍了,可能距离7.5倍有比较大的差距,所以,对于HandlerSocket的应用来说,应该尽量提高InnoDB_Buffer_Pool的大小,多多益善。

 

我也做过一些基准测试,基本上在插入的情况下,HandlerSocket的性能能达到同等环境的MySQL的3-5倍,数据量越大时候越明显,特别是达到5000万以后。在查询情况下,HandlerSocket是同等环境下MySQL的1.5-2倍,这跟作者的测试的7.5倍有比较大的出入,这也是上面我特别提到的,作者的测试数据是在Innodb_Buffer_Pool足够大并且命中率很高的情况,由于我做基准测试的机器条件有限,没有足够大的Buffer Pool,命中率不是很高,所以,I/O开销不小,这也验证了上面提到的,对于I/O Bound的场景,性能的提升不会特别的明显,所以应该尽量增大InnoDB_Buffer_Pool的大小,尽量接近于数据的大小。而且我在测试的时候,没有关闭Query Cache,所以对于MySQL的测试场景来说,能重用到执行计划和Cache数据等。

 

上面说到了,HandlerSocket具有不少的优点,性能也有很大的提升,但是也需要理性的来看待,有一些需要特别注意的事项,在做决策的时候,应该整体上的考虑,我这里简单的总结一下。
1. 应该尽量达到CPU-Bound场景,而非IO-Bound,这样才能更好的发挥出HandlerSocket的优势。具体做法是增大内存,尽量提高InnoDB_Buffer_Pool大小。

2. 由于采用合并操作,响应时间会有不同程度的增加,应该考虑好是否满足你的应用场景。可以继续关注后续版本优化策略,比如可能有些朋友会想要这样的:读取的时候不是合并操作,但是写入是合并操作,当然这样的情况读取的总体性能会有不同程度降低,不过一切不就是在权衡嘛?还是看具体应用场景。

 

五、HandlerSocket性能优化
前面也提到了,HandlerSocket性能相比传统MySQL有了比较显著的提高,但是要想更好的发挥出它的优势,需要做一些相关的优化。

 

性能优化主要从以下三方面考虑,当然除了这三方面,还有其他一些优化方式,比如优化操作系统,使用Direct IO等,这里说的这三方面是相对比较容易做到并且实现技术成本也不高的方式:
1. 硬件环境
前面也提到了,应该尽量提高Innodb Buffer Pool的大小,对应到硬件上,就是要尽量增加内存的大小,最理想的情况下是内存大小与数据大小一样。如果有资源,也可以考虑采用SSD,这有个基于SSD的测试数据(http://www.percona.com/docs/wiki/benchmark:handlersocket:ssd:start),性能还是非常给力的。

2. 客户端优化
客户端与服务端基于Socket通信,打开关闭连接、OpenIndex等操作都是比较耗费资源的操作,应该尽量避免频繁的做这些操作。所以,在客户端应该要做连接池,同时应该采用一些更好的通信模型,比如Linux下基于epoll和NIO等。比如,这个Java客户端(http://code.google.com/p/hs4j/)这方面就做得不错。

3. HandlerSocket和Innodb配置
HandlerSocket配置:
//读线程的个数,推荐为逻辑CPU个数,比如超线程的应该*2
handlersocket_threads = 16
//写线程的个数,目前的版本推荐设置为1
handlersocket_thread_wr = 1
//读请求的监听端口
handlersocket_port = 9998
//写请求的监听端口
handlersocket_port_wr = 9999

 

Innodb配置:
//Innodb Buffer Pool大小,推荐越大越好
innodb_buffer_pool_size
//Innodb日志文件大小,根据需求设置,在允许的情况下越大也越好
innodb_log_file_size, innodb_log_files_in_group
//mysqld进程可以打开的文件数,推荐为65535
open_files_limit = 65535
//设置为1能提高性能,但是相应的也会消耗内存,需要权衡好
innodb_adaptive_hash_index = 1

================================================================================

项目地址:

文库资料:http://wenku.baidu.com/view/c1898218a8114431b90dd88d.html

参考资料:http://www.cnblogs.com/inrie/archive/2011/01/28/1946998.html

分类: MySQL 标签: