System Admin(SA,System maintanence,Shell script)

twemproxy (nutcracker) 介绍

[不指定 2014/07/21 11:28 | by ipaddr ]
twemproxy (pronounced "two-em-proxy"), aka nutcracker is a fast and lightweight proxy for memcached andredis protocol. It was primarily built to reduce the connection count on the backend caching servers.

https://github.com/twitter/twemproxy

Ipaddr注: twemproxy的目的不是为了提升性能、容灾,而是为了减少Redis/Memcached的连接数。

Features

  • Fast.
  • Lightweight.
  • Maintains persistent server connections.
  • Keeps connection count on the backend caching servers low.
  • Enables pipelining of requests and responses.
  • Supports proxying to multiple servers.
  • Supports multiple server pools simultaneously.
  • Shard data automatically across multiple servers.
  • Implements the complete memcached ascii and redis protocol.
  • Easy configuration of server pools through a YAML file.
  • Supports multiple hashing modes including consistent hashing and distribution.
  • Can be configured to disable nodes on failures.
  • Observability through stats exposed on stats monitoring port.
  • Works with Linux, *BSD, OS X and Solaris (SmartOS)

Redis知识汇总[转]

[不指定 2014/07/15 19:41 | by ipaddr ]

https://github.com/springside/springside4/wiki/Redis


1. Overview
1.1 资料
    - <The Little Redis Book> ,最好的入门小册子,可以先于一切文档之前看,免费。
    - 作者Antirez的博客Antirez维护的Redis推特
    - Redis 命令中文版, huangz同学的翻译,同时还有Redis官网几篇重要文档的翻译。
    - Redis设计与实现 ,又是huangz同学的巨作,深入了解内部实现机制。
    - Redis 2.6源码中文注释版 ,继续是huangz同学的大功德。
    - NoSQL Fan里的Redis分类
    - 《Redis in Action》 (Manning, 2013) 挺实战的一本书。
1.2 优缺点

非常非常的快,有测评说比Memcached还快(当大家都是单CPU的时候),而且是无短板的快,读写都一般的快,所有API都差不多快,也没有MySQL Cluster、MongoDB那样更新同一条记录如Counter时慢下去的毛病。

丰富的数据结构,超越了一般的Key-Value数据库而被认为是一个数据结构服务器。组合各种结构,限制Redis用途的是你自己的想象力,作者自己捉刀写的用途入门

因为是个人作品,Redis2.6版只有2.3万行代码,Keep it simple的死硬做法,使得普通公司而不需淘宝那个级别的文艺公司也可以吃透它。 Redis宣言就是作者的自白,我最喜欢其中的“代码像首诗”,”设计是一场与复杂性的战斗“,“Coding是一件艰苦的事情,唯一的办法是享受它。如果它已不能带来快乐就停止它。为了防止这一天的出现,我们要尽量避免把Redis往乏味的路上带。”

让人又爱又恨的单线程架构,使得代码不用处理平时最让人头痛的并发而大幅简化,也不用老是担心作者的并发有没有写对,但也带来单CPU的瓶颈,而且单线程被慢操作所阻塞时,其他请求的延时变得不确定。

那Redis不是什么?

    - Redis 不是Big Data,数据都在内存中,无法以T为单位。
    - 在Redis 3.0的Redis-Cluster发布并被稳定使用之前,Redis没有真正的平滑水平扩展能力。
    - Redis 不支持Ad-Hoc Query,提供的只是数据结构的API,没有SQL一样的查询能力。

Redis运维实践

[不指定 2014/07/15 19:25 | by ipaddr ]
彩票业务的核心流程使用了Redis来实现消息队列,近期在世界杯的影响下,业务爆发式增长,给各组件尤其是Redis的运维也提出了新的挑战,简单整理一下运维过程中的一些心得:

Redis是什么?

Redis是一个快速,小巧,简单,但又十分强大的K/V组件;
http://www.iamadmin.com/ 原创,转载请注明)
主要特性:
  • 所有数据都在内存中。 
  • 多种的数据结构:String / Hash / List / Set / Ordered Set。 
  • 数据过期时间支持。 
  • 不完全的事务支持。 
  • 服务端脚本:使用Lua Script编写,类似存储过程的作用。 
  • PubSub:捞过界的消息一对多发布订阅功能,起码Redis-Sentinel使用了它。 
  • 持久化:支持定期导出内存的Snapshot 与 记录写操作日志的Append Only File两种模式。 
  • Replication:Master-Slave模式,Master可连接多个只读Slave,暂无专门的Geographic Replication支持。 
  • Fail-Over:Redis-Sentinel节点负责监控Master节点,在master失效时提升slave,独立的仲裁节点模式有效防止脑裂。 
  • Sharding:开发中的Redis-Cluser。 
  • 动态配置:所有参数可用命令行动态配置不需重启,并重新写回配置文件中,对云上的大规模部署非常合适。

为什么要用Redis?

类似的KV组件非常多,业界有非常出名的Memcached、MongoDB,公司有大名鼎鼎的CKV;但Redis应用场景不止是简单的cache,与它们相比,个人觉得Redis的最大特色是拥有非常丰富的数据类型,比如新浪微博曾维护世界上最大的Redis来存储他们的关系链,消息队列;这是其它KV组件所无法实现的功能;
此外,Redis的持久化、复制功能等功能也非常完备,大大提升了组件本身的可用性;

Redis的缺陷?

Redis也不是完美的,同样存在一些使用限制:
  • 异常IO+单进程模型:由单个进程对外提供服务,一些内部异步操作(例如持久化,复制)通过fork+copy on write来实现,单进程模型最大的优点就是简单、高效,但带来的问题就是同时只有一个请求被处理;如果单个操作延时较大,或是单个客户端死循环的方式读写的话,必然会堵塞其它请求;程序设计时需要重点考虑这个限制,避免单个复杂操作或死循环式读写;
  • 数据全部存储在内存,优点还是简单、快速;缺点是内存成本较高并且单机有上限,稍不注意会有OOM Killer的风险;解决方案主要有:
    • 数据水平、垂直拆分,集群化管理;新版的Reids 3.0自带了cluster功能,当前仍是Beta阶段,稳定性未知;
    • 程序识别冷热数据,并将冷数据落地到其它组件;

Redis监控

Redis不仅仅是Cache,通常情况下还存储了相当多的业务第一手数据,所以对Redis的可用性、可靠性要求非常高;除了优化Redis本身的配置,还需要监控Redis运行情况,为排障、优化、预警提供数据;
组件本身有相当多的统计数据,可以通过info指令获取,我们通过脚本,每分钟获取info输出,再进行对比和分析,就可以实现有效的监控;
当前我们监控的主要数据有:
  • Redis当前已连接客户端  
  • Redis堵塞连接客户端 
  • Redis使用内存数(M) 
  • Redis占用内存数(M) 
  • Redis未保存操作次数 
  • Redis当前周期新连接数
  • Redis当前周期处理命令数
当前我们监控的主要异常有:
  • Redis无法连接; 
  • Redis角色为slave,但是同步中断; 
  • Redis角色为master时,所属的slave增加或减少都会有异常通知; 
  • Redis使用内存数,超过物理内存80%

常见错误:

1. 连接数不够
当前彩票架构还没有做到服务化,导致所有PHP进程都是直连Redis,且考虑到一些后台服务需要频率连接Redis而使用了pconnect,带来的问题就是Redis连接数非常多;
Redis在2.6以前,连接数限制在10240,如果在增加的话需要修改程序重编,在2.6之后组件自身没有做限制;
操作系统层面还有程序的FD限制,请在启动Redis前或系统初始化的时候设置ulimit -n
架构设计时,需要重点考虑连接数问题,即使在2.6+后无连接数限制,也应该将业务尽量服务化,收敛业务逻辑以及到Redis,DB,Memcached等组件的连接;
2. 无法持久化或复制
当Redis内存使用量约超过物理内存一半时,Redis在fork进程进行bgsave时将会失败,此时无法rdb持久化以及新slave同步将失败,通常在日志中可以看到:
Can't save in background: fork: Cannot allocate memory
这种情况,可以将Linux的 vm.overcommit_memory = 1,但理论上也会存在风险,如果在rdb dump期间业务有相当多的数据更新,将会导致系统内存不足而发生OOM;
3. 持久化时请求被堵塞
虽然持久化时会fork进程出来,避免主进程堵塞,但大量的磁盘IO仍然会影响系统负载,导致处理性能严重下降,业务请求受到堵塞;
为避免给业务带来影响,通常做法有:
  • 在master上面关闭持久化,但需要特别注意,master挂掉后,不能自动拉起进程,否则所有数据都会被清空,slave也不能幸免;
  • 配置调优,修改no-appendfsync-on-rewrite,appendfsync两个参数,可以一定程度缓解IO压力;
总体来看,Redis是一个很棒的KV组件,在性能、稳定性、持久化、可用性方面都表现非常出色,但也需要正确使用和优化。

附:

Redis 2.8新特性
  • Slaves 能够和master部分重新同步,所以不用再担心网络瞬断导致master重新向各个 slaves发送完整的RDB文件的彻底的重新同步了。
  • 增加了IPv6支持
  • 添加了slaves 能够明确的ping master,master也能够独立的检测每个slave的超时
  • 当没有足够的给出最大延时的slave链接时,master可以停止接收写操作
  • 设置了进程的名字,方便使用ps命令输出时候能够辨别实例的监听端口或者是一个saveing的子进程
  • 能够绑定多个IP地址
  • 实现了配置重写,当使用CONFIG SET命令修改配置之后使用CONFIG REWRITE的能够同时将配置文件修改。
Redis 2.6新特性
  • 支持lua脚本。
  • VM(虚拟内存)去掉了。
  • 对于client的limit限制变成无限制。
  • aof性能提升了不少。
  • key的过滤时间可以支持毫秒级别了,原来是秒。
  • list与hash 的属性filed或value包含小整数,内存优化列好(使用了jemalloc,以前是malloc)。
  • 提供了BITCOUNT与BITOP,前者支持位值count,后者支持了位操作。(以前只支持key-value 的置位操作)
  • 支持新命令dump以及restore ,即序列化与反序列化操作。
  • 大数据存储性能优化

【转】mogilefs管理

[不指定 2014/06/24 12:58 | by ipaddr ]

扶凯关于mogilefs的文章已经非常全面和具体了,读完所有这些文章应该可以算是精通mogilefs,简单引用一下:

通用 MogileFS 维护手册
http://www.php-oa.com/2012/03/14/mogilefs-maintenance.html

MogileFS 文件系统检查
http://www.php-oa.com/2012/03/14/mogilefs-fsck.html

MogileFS Rebalance(文件的重新均衡)
http://www.php-oa.com/2012/03/27/running-a-mogilefs-rebalance.html

MogileFS 中怎么删除主机
http://www.php-oa.com/2012/07/28/mogilefs-delete-host.html

在 MogileFS 中使用 Nginx
http://www.php-oa.com/2012/03/09/mogilefs-nginx.html

MogileFS 高级排错
http://www.php-oa.com/2011/06/30/mogilefs-troubleshooting-request-failure-fetching.html

其它:
http://www.php-oa.com/tag/mogilefs


MogileFS 是一个分布式数据存储的系统,它可以有很多的存储节点和许多 trackers. 然而,它必须有一个单一的元数据存储,这是 trackers 的对所有文件的坐标点. 我要重复一次.因为这个地方太值得多提一下:所有的 trackers 必须指向相同的数据库实例.他们使用advisory locking 来确保他们不复制过程中发生碰撞,并通过事物协调队列处理.没有这个,你可能会永久丢失数据.

可以看出,mogilefs的核心在DB,所有元数据和协调都是通过DB来完成的。

     MogileFS 是一个开源的分布式文件系统,用于组建分布式文件集群,由 LiveJournal 旗下 Danga Interactive 公司开发,Danga 团队开发了包括 Memcached、MogileFS、Perlbal 等不错的开源项目:(注:Perlbal 是一个强大的 Perl 写的反向代理服务器).

    目前使用 MogileFS 的公司非常多,比如国外的一些公司,日本前几名的公司基本都在使用这个.
国内所知道的使用 MogileFS 的公司有图片托管网站 yupoo又拍,digg, 土豆, 豆瓣,1 号店, 大众点评,搜狗,安居客等等网站.基本很多网站容量,图片都超过 30T 以上。

    MogileFS 是 51.com 的存储设计的大师碧轩非常推荐的,51 的集群文件系统也是基于这个原理实现的.简单来讲 MogileFS 是基于 Google File System 实作出来的.

官方的介绍网站:
http://www.danga.com/mogilefs/

Google Code 上的信息
http://code.google.com/p/mogilefs/
这个地址有很多值得读读的信息,还有那些用户在使用 MogileFS ,以级使用多大的量,详细内容见http://code.google.com/p/mogilefs/wiki/Users.

普通文件存储的方法

  • rsync
  • NAS/SAN
  • FTPd
  • WebDAV
  • NFS

MogileFS 特性就介绍,官方介绍

  • 应用层 – 不需要特殊的核心组件
  • 无单点失败 — MogileFS分布式文件存储系统安装的三个组件(存储节点、跟踪器、跟踪用的数据库),均可运行在多个 机器上,因此没有单点失败.(你也可以将跟踪器和存储节点运行在同一台机器上,这样你就没有必要用4台机器)推荐至少两台机器.
  • 自动的文件复制 — 基于不同的文件“分类”,文件可以被自动的复制到多个有足够存储空间的存储节点上,这样可以满足这个“类别”的最少复制要求.比如你有一个图片网站,你可以设置原始的JPEG图片需要复制 至少三份,但实际只有1or2份拷贝,如果丢失了数据,那么MogileFS分布式文件存储系统可以重新建立遗失的拷贝数.用这种办法,MogileFS(不做RAID)可以节约磁盘,否则你将存储同样的拷贝多份,完全没有必要.
  • “比RAID好多了”– 在一个非存储区域网络的RAID(non-SAN RAID)的建立中,磁盘是冗余的,但主机不是,如果你整个机器坏了,那么文件也将不能访问. MogileFS分布式文件存储系统在不同的机器之间进行文件复制,因此文件始终是可用的.
  • 传输中立,无特殊协议 — MogileFS分布式文件存储系统客户端可以通过NFS或HTTP来和MogileFS的存储节点来通信,但首先需要告知跟踪器一下.
  • 简单的命名空间 –文件通过一个给定的key来确定,是一个全局的命名空间.你可以自己生成多个命名空间,只要你愿意,不过这样可能在同一MogileFS中会造成key冲突.
  • 不用共享任何东西 — MogileFS分布式文件存储系统不需要依靠昂贵的SAN来共享磁盘,每个机器只用维护好自己的磁盘.
  • 不需要RAID — 在MogileFS中的磁盘可以是做了RAID的也可以是没有,如果是为了安全性着想的话RAID没有必要买了,因为MogileFS分布式文件存储系统已经提供了.

MogileFS 的结构图


在使用前,我们需要对 MogileFS 有个基本的了解,就是他的三个大的部分,Tracker(Database) , Storage Nodes 和 Client 组成.有二个服务进程 MogileFSd 和 mogstored .

工作原理如图:
客户端.连接到一个域,然后在域中拿着文件的 key 来查文件的位置,然后通过查到集群中的位置来打开这个文件.

下面的部分的详细介绍

MogileFS 的三个大的部分


     前面提到 Tracker(Database) , Storage Nodes 和 Client 组成,我们这先不讲 Client.因为Client实际上是一个 Perl 的模块,可以写程序调用该模块来操作 MogileFS 系统,对整个系统进行读写操作.另外,象 nginx 之类有相关的客户端模块.另外也有做成象文件系统一样采用 fuse 方式挂载看起来象一个本地文件系统.其它语言的客户端也非常多.
 

  • Tracker(跟踪器 ,调度器)- (MogileFSd 进程)

这个是 MogileFS 的核心部分,通俗点讲,就他是一个调度器.MogileFSd 进程就是 trackers 进程程序,类似 MogileFS 的 wiki 上介绍的,trackers 做了很多工作,Replication ,Deletion,Query,Reaper,Monitor 等等.这个是基于事件的( event-based ) 父进程/消息总线来管理所有来之于客户端应用的交互(requesting operations to be performed), 包括将请求负载平衡到多个"query workers"中,然后让 MogileFSd 的子进程去处理.
mogadm,mogtool 的所有操作都要跟 trackers 打交道,Client 的一些操作也需要定义好 trackers,因此最好同时运行多个 trackers 来做负载均衡.trackers 也可以只运行在一台机器 上,也可以跟其他程序运行在一起(不建议).
tracker 配置文件: /etc/mogilefs/mogilefsd.conf

  • 数据库(MySQL)部分

如上图所显示的,数据库用来存放 MogileFS 的元数据 (命名空间, 和文件在哪里). 是 Trackers 来操作和管理它.你可以用 mogdbsetup 程序来初始化数据库.因为数据库保存了MogileFS的所有元数据,如果这儿挂了,那么整个 MogileFS 将处于不可用状态.因此最好是HA结构.

  • 存储节点(Storage Nodes )-(mogstored 进程, Apache 和 Nginx 等)

实际文件存放的地方. 存储节点是一个 HTTP 服务器,用来做删除,存放,重命名等事情.任何 WebDAV 服务器都可以, 不过推荐使用 mogstored . MogileFSd 可以配置到两个机器上使用不同端口… mogstored 来进行所有的 DAV 操作和流量,IO监测, 并且你自己选择的 HTTP 服务器(默认为 perlbal)用来做 GET 操作给客户端提供文件.
典型的应用是一个挂载点有一个大容量的 SATA 磁盘,它们被挂载到 /var/mogdata/devNN. 只要配置完配置文件后 mogstored 程序的启动将会使本机成为一个存储节点.当然还需要 mogadm 这个工具增加这台机器到 Cluster 中.
mogstored 的配置文件: /etc/mogilefs/mogstored.conf

MogileFS 的二个服务进程

这二个程序分别对应上面的部分
MogileFSd — MogileFS 的主守护进程:

就是上面指的 trackers(跟踪器 ),由 /etc/MogileFS/MogileFSd.conf 这个配置文件控制.

mogstored — MogileFS 存储守护进程

这个就是上面指的存储节点(Storage Nodes ),由 /etc/MogileFS/mogstored.conf 这个配置文件控制.

MogileFS 的其它


     有几个小工具,主要就是 mogadm,mogtool 这两个工具了,用来在命令行下控制整个 MogileFS 系统以及查看状态等等.我后面会针对这个进行详细的讲解.

MogileFS 复制策略
     在 MogileFS 中,默认的 MogileFS::ReplicationPolicy::MultipleHosts 会试着 put 文件到不同主机的硬盘中.如果只有一个主机和2个硬盘,很明现这个是不行的,但它还是会勉强的 put 到相同的主机.
如果你有三个硬盘,设置的最小的复制份数为 2,它会 put 2 个复本到不同的主机.如果你有 2 个主机 4 个硬盘设置的最小复制份数为 3,你会得到 3 个复本在不同的硬盘设备上,但是会有二份在同一个主机上.这认为是没问题的.

High-level 流程:

  • 应用程序请求打开一个文件 (通过RPC 通知到 tracker, 找到一个可用的机器). 做一个 “create_open” 请求.
  • tracker 做一些负载均衡(load balancing)处理,决定应该去哪儿,然后给应用程序一些可能用的位置。
  • 应用程序写到其中的一个位置去 (如果写失败,他会重新尝试并写到另外一个位置去).
  • 应用程序 (client) 通过”create_close” 告诉tracker文件写到哪里去了.
  • tracker 将该名称和域命的名空间关联 (通过数据库来做的)
  • tracker, 在后台, 开始复制文件,知道他满足该文件类别设定的复制规则
  • 然后,应用程序通过 “get_paths” 请求 domain+key (key == “filename”) 文件, tracker基于每一位置的I/O繁忙情况回复(在内部经过 database/memcache/etc 等的一些抉择处理), 该文件可用的完整 URLs地址列表.
  • 应用程序然后按顺序尝试这些URL地址. (tracker’持续监测主机和设备的状态,因此不会返回死连接,默认情况下他对返回列表中的第一个元素做双重检查,除非你不要他这么做..)

近来大家在安装最新的 MogileFS 时,会发现测试的时候,怎么样复制文件的过程都不正常.使用 telnet 到 7001 中使用 !watch 来查看时会不断的报下面的错(详细使用见 MogileFS 高级排错).

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
!watch
Added you to watcher list.
.
:: Child 10106 (replicate) died: 256 (UNEXPECTED)
:: Job replicate has only 9, wants 10, making 1.
:: Child 10091 (replicate) died: 256 (UNEXPECTED)
:: Job replicate has only 9, wants 10, making 1.
:: Child 10121 (replicate) died: 256 (UNEXPECTED)
:: Job replicate has only 9, wants 10, making 1.
:: Child 10134 (replicate) died: 256 (UNEXPECTED)
:: Job replicate has only 9, wants 10, making 1.
:: Child 10120 (replicate) died: 256 (UNEXPECTED)
:: Job replicate has only 9, wants 10, making 1.
:: Child 10135 (replicate) died: 256 (UNEXPECTED)
:: Job replicate has only 9, wants 10, making 1.
:: Child 10136 (replicate) died: 256 (UNEXPECTED)
:: Job replicate has only 9, wants 10, making 1.
:: Child 10149 (replicate) died: 256 (UNEXPECTED)
:: Child 10150 (replicate) died: 256 (UNEXPECTED)
:: Job replicate has only 8, wants 10, making 2.
:: Child 10152 (replicate) died: 256 (UNEXPECTED)
:: Job replicate has only 9, wants 10, making 1.

上次我使用 MogileFS 的 DEBUG 模式跟过这个问题,是由于 Sys::Syscall 这个模块升级成 0.25 的新版本引起的.
我们可以使用下面的命令来检查当前的版本

1
2
$ perl -MSys::Syscall -e 'print $Sys::Syscall::VERSION'
0.25

如果发现是显示上面的 0.25 就一定会出问题.建议退回到 0.23 就不会在出问题了.所以建议大家在安装完 MogileFS 后,先退回这个模块到 0.23.

二个月以前发现这个问题,近来很多人来问我,发现问题还很严重,特此记录.希望能帮到大家.
ps: 最新的 MogileFS 的客户端连接数据库一定要求要有密码,不然启动会有问题…

在编写脚本时,通常有单实例运行的需求;比如某个监控脚本,希望同时间只能有一个脚本进程在运行,避免影响业务或是误判断。
一般的做法是通过ps+grep+wc来判断有几个进程在运行,如果超过一个以上则退出,但此方法不够严谨,一方面grep匹配可能有误判,另一方面可能有两个同时刻启动的可能;
还有做法是在脚本最前面,创建一个文件或目录来标识,脚本退出后再清理这个文件,此方法在脚本运行到一半被kill或重启后,由于未执行清理而导致下次运行时判断会失败,就无法再次运行了;

操作系统提供了原子操作级别的文件锁机制,可以在脚本启动时加锁,退出时解锁,同时脚本被意外中断后,文件锁也会被OS释放以避免无法运行,很好的解决了上面的所有问题。

按上面的思路,分别用perl, bash验证了一下,基本符合预期:
(Bash下,不同flock的命令参数可能有所区别。)

Bash:

#!/bin/bash
# Author: tomzhou(admin.net#163.com)

sFile=$0
rMode=$1

#Setting
lFile="/tmp/monitor.tomzhou.lock"


#Locking
touch "$lFile"
if [ "$rMode" != "-r" ]; then
        flock --timeout=0 "$lFile" "$sFile" -r
     #flock -x -w 0 "$lFile" -c "$sFile -r"
     if [ "$?" -ne "0" ]; then
                      echo "Script is running."
                      exit 1
          fi
          exit 0
fi


echo "doing....."
sleep 10
echo "done"


Perl:

#!/usr/bin/perl
# Author: tomzhou(admin.net#163.com)

use Fcntl ':flock';
use Cwd qw(abs_path);
use File::Basename qw(dirname);

#Setting

#Locking
open my $tmpSelFile,'<',$0 or die "Con't open self:$!";
flock $tmpSelFile, LOCK_EX | LOCK_NB or die("Script is running!");


print("doing\n");
sleep(10);
print("done\n");


#Close file
close($tmpSelFile);

TCMalloc(Thread-Caching Malloc)与标准glibc库的malloc实现一样的功能,但是TCMalloc在效率和速度效率都比标准malloc高很多。TCMalloc是google-perftools工具中的一个(gperftools四个工具分别是:TCMalloc、heap-checker、heap-profiler和cpu-profiler),这个工具是开源的,以源码形式发布。如果觉得自己维护一个内存分配器麻烦的话,可以考虑将TCMalloc静态库连接到你的程序中。使用的时候和glibc中的malloc调用方式一模一样。你需要做的只是把TCMalloc的动态库或者静态库连接进你的程序中,你就可以获得一个高效,快速,安全的内存分配器。

与标准的glibc库的malloc相比,TCMalloc在内存的分配效率和速度要高,可以在高并发的情况下很好的控制内存的使用,提高服务器的性能,降低负载。TCMalloc的实现原理和测试报告请见一篇文章:《TCMalloc:线程缓存的Malloc

tcmalloc作为可选项已经添加到lnmp最新源码一键安装包

安装libunwind库:
如果系统是64位的需要先安装libunwind库,32位系统则不需要安装。

libunwind库为基于64位CPU和操作系统的程序提供了基本的堆栈辗转开解功能,其中包括用于输出堆栈跟踪的API用于以编程方式辗转开解堆栈的API以及支持C++异常处理机制的API。

wget http://download.savannah.gnu.org/releases/libunwind/libunwind-1.1.tar.gz tar zxf libunwind-1.1.tar.gz cd libunwind-1.1 CFLAGS=-fPIC ./configure make CFLAGS=-fPIC make CFLAGS=-fPIC install cd ../

gperftools的安装:

wget http://gperftools.googlecode.com/files/gperftools-2.1.tar.gz tar xzf gperftools-2.1.tar.gz cd gperftools-2.1

可以加入参数只编译tcmalloc(./configure –enable-minimal、–disable-cpu-profiler、–disable-heap-profiler、–disable-heap-checker、–disable-debugalloc),64位操作系统不安装libunwind也不会报错,注意生成的库文件是libtcmalloc_minimal.*
64位操作系统,如下

./configure 

32位系统,不需要安装libunwind,但是一定要添加–enable-frame-pointers参数,如下

./configure --enable-frame-pointers 
make && make install

编译安装后,输入以下命令:

echo '/usr/local/lib' > /etc/ld.so.conf.d/local.conf ldconfig #必须执行

使用TCMalloc优化MySQL
MySQL 5.1静态编译方法,./configure预编译时假设下面参数

--with-mysqld-ldflags=-ltcmalloc

MySQL 5.5静态编译方法,cmake预编译时加上下面参数

-DCMAKE_EXE_LINKER_FLAGS="-ltcmalloc" -DWITH_SAFEMALLOC=OFF

采用动态加载

sed -i 's@executing mysqld_safe@executing mysqld_safe\nexport LD_PRELOAD=/usr/local/lib/libtcmalloc.so@' /usr/local/mysql/bin/mysqld_safe service mysqld restart

验证加载tcmalloc在MySQL中是否生效,如下:

lsof -n | grep tcmalloc

使用TCMalloc优化Nginx
为了使nginx支持google-perftools,需要在安装过程中添加”–with-google_perftools_module”选项重新编译nginx。安装如下:

cd lnmp/src/nginx-1.4.2 make clean ./configure --prefix=/usr/local/nginx --user=www --group=www \ --with-http_stub_status_module --with-http_ssl_module --with-http_flv_module \ --with-http_gzip_static_module --with-google_perftools_module make && make install

为添加线程目录:

mkdir /tmp/tcmalloc chown -R www.www /tmp/tcmalloc vi /usr/local/nginx/conf/nginx.conf #pid下一行添加 google_perftools_profiles /tmp/tcmalloc;

验证tcmalloc是否在Nginx中生效

lsof -n | grep tcmalloc

每个线程(work_processes的值)会有一行记录。每个线程文件后面的数字值就是启动的nginx的pid值。

使用TCMalloc优redis 
注意:redis-2.4以上自带jemalloc,你不需要加任何参数,通过zmalloc.c源码中我们可以看到,Redis在编译时,会先判断是否使用tcmalloc,如果是,会用tcmalloc对应的函数替换掉标准的libc中的函数实现。其次会判断jemalloc是否使得,最后如果都没有使用才会用标准的libc中的内存管理函数。所以用tcmalloc优化请谨慎使用,这两着分配器碎片率相差不大,建议用自带jemalloc

cd lnmp/src/redis-2.6.16 make USE_TCMALLOC=yes FORCE_LIBC_MALLOC=yes /bin/cp src/{redis-benchmark,redis-check-aof,redis-check-dump,redis-cli,redis-sentinel,redis-server} /usr/local/redis/bin

转载自:http://wangyan.org/blog/nginx-alias-php.html

需求:通过 example.com 访问 /var/data/www,但通过 example.com/pa 访问的却是 /var/data/phpmyadmin,即保护phpmyadmin不暴露在www目录下。

一、方法一:(不推荐)

简介:这是网上普遍采用的 Rewrite 方式。

缺陷:简单的php程序还能应付,复杂一点的程序就"No input file specified"


server {
    listen 80;
    server_name example.com;
 
    root /var/data/www;
    index index.html index.php;
 
    location /pa {
        alias /var/data/phpmyadmin;
        index index.html index.php;
    }
 
    location ~ /pa/.+\.php$ {
        rewrite /pa/(.+\.php) /$1 break;
        fastcgi_pass  127.0.0.1:9000;
        fastcgi_index  index.php;
        fastcgi_param  SCRIPT_FILENAME  /var/data/phpmyadmin/$fastcgi_script_name;
        include  fastcgi_params;
    }
 
    location ~ .+\.php.*$ {
        fastcgi_pass  127.0.0.1:9000;
        fastcgi_index  index.php;
        fastcgi_param  SCRIPT_FILENAME  $document_root/$fastcgi_script_name;
        fastcgi_param  SCRIPT_FILENAME  $request_filename;
        include  fastcgi_params;
    }
}


二、方法二:(推荐)

简介:完美实现,无副作用。
特点:使用了一个叫"$valid_fastcgi_script_name"的变量


server {
    listen 80;
    server_name example.com;
 
    root /var/data/www;
    index index.html index.php;
 
    location /pa {
        alias /var/data/phpmyadmin;
        index index.html index.php;
    }
 
    location ~ /pa/.+\.php.*$ {
        if ($fastcgi_script_name ~ /pa/(.+\.php.*)$) {
            set $valid_fastcgi_script_name $1;
        }
        fastcgi_pass  127.0.0.1:9000;
        fastcgi_index  index.php;
        fastcgi_param  SCRIPT_FILENAME  /var/data/phpmyadmin/$valid_fastcgi_script_name;
        include  fastcgi_params;
    }
 
    location ~ .+\.php.*$ {
        fastcgi_pass  127.0.0.1:9000;
        fastcgi_index  index.php;
        fastcgi_param  SCRIPT_FILENAME  $document_root/$fastcgi_script_name;
        fastcgi_param  SCRIPT_FILENAME  $request_filename;
        include  fastcgi_params;
    }
}


二、方法三:

简介:在 zhigang.net 上看到的创意方法,即一个站加两个server字段,然后通过反代的方式实现。
特定:方法有创意,稍微麻烦点。

http://openresty.org/cn/

OpenResty (也称为 ngx_openresty)是一个全功能的 Web 应用服务器,它打包了标准的 Nginx 核心,很多的常用的第三方模块,以及它们的大多数依赖项。

OpenResty 通过汇聚各种设计精良的 Nginx 模块,
从而将 Nginx 有效的变成一个强大的 Web 应用服务器,
这样, Web 开发人员可以使用 Lua 脚本语言调动 Nginx 支持的各种C以及Lua 模块,
快速构造出足以胜任 10K+ 并发连接响应的超高性能Web 应用系统.

OpenResty 的目标是让你的Web服务直接跑在 Nginx 服务内部,
充分利用 Nginx 的非阻塞 I/O 模型,
不仅仅对 HTTP 客户端请求,甚至于对远程后端诸如
MySQL,PostgreSQL,~Memcaches 以及 ~Redis 等都进行一致的高性能响应.
分页: 1/4 第一页 1 2 3 4 下页 最后页 [ 显示模式: 摘要 | 列表 ]