rsync的几种优化应用方案

为了解决文件增多导致rsync变慢的问题，方案是很多的。1、使源目录保存较少文件这是一个传统优化办法，因为rsync虽然是同步所有文件，但和同步最近更新的文件是一个道理，因此将源服务器上的目录删除，仅仅保持最近更新的文件，文件数量就变得不但很少，而且是稳定的，随着时间推移，这数量也不会涨得很快。但这样做有个缺点，就是rsync不能使用删除模式，如果有文件要删除，可以将其弄成空文件，假如有更严格要求，可以另一个程序来删除。2、使用/dev/shm内存分区在源目录保持较少文件的前提下，将文件不存在硬盘上而放入内存，就可以避免系统IO带来的问题，但是这个内存分区在系统reboot后会丢掉所有数据，虽然并不常常需要reboot，但是其中的风险也需要计算清楚。3、使用推送方式因为性能问题是出现在rsync的客户端，用生产服务器抓取源服务器的话，性能问题就会出现在生产服务器上，这当然不很妥当。假如在生产服务器上使用 rsync daemon，源服务器执行rsync命令将文件推送到生产服务器上，性能问题就转移到了源服务器上，这在一定程度可以保证生产服务器的稳定性。4、仅用一台作同步比较假如源服务器的文件要被同步到很多台生产服务器，那么会出现rsync并发。可以分析到这些生产服务器在同一时刻文件是一致的，因此每台机都和源服务器做一次比较就是浪费的。这时可以让源服务器和生产服务器同步一次，并且使用-v参数打印出log，其它生产服务器通过同步这个log记录的文件就可以避免数次比较过程。5、使用inotifyinotify就不是rsync了，inotify是一个守护进程，它可以监控到文件目录下的文件变动情况，根据其输出然后用rsync做文件传输，就可以减掉文件比较这个环节。inotify使用并不复杂，对文件变更情况的监控是实时的，也不消耗很多性能。6、双路同步以上均是对rsync性能方面做优化，但是优化也会带来问题。在3、4、5号方案中，假如生产服务器有一台机器因为负载或其它问题reboot了，在 reboot过程中同步就失败了，这部分失败的文件假如没有其它处理，就永远不会再同步到生产服务器上。这时可以使用多一路rsync来处理，譬如使用 inotify，做到了实时同步，然后再每小时进行一次完整的rsync同步。这样就可以保证有很高的同步速度，又能使丢失文件的风险控制在一小时之内。

一、编译安装过程优化
1减小Nginx编译后的文件大小
在编译Nginx时，默认以debug模式进行，而在debug模式下会插入很多跟踪和ASSERT之类的信息，编译完成后，一个Nginx要有好几兆字
节。在编译前取消Nginx的debug模式，编译完成后Nginx只有几百千字节，因此可以在编译之前，修改相关源码，取消debug模式，具体方法如
下：
在Nginx源码文件被解压后，找到源码目录下的auto/cc/gcc文件，在其中找到如下几行：
# debug CFLAGS=”$CFLAGS -g”
注释掉或删掉这两行，即可取消debug模式。
2为特定的CPU指定CPU类型编译优化
在编译Nginx时，默认的GCC编译参数是“-O”，要优化GCC编译，可以使用以下两个参数：
--with-cc-opt='-O3'
--with-cpu-opt=CPU #为特定的 CPU 编译，有效的值包括：pentium, pentiumpro, pentium3, pentium4, athlon, opteron, amd64, sparc32, sparc64, ppc64
要确定CPU类型，可以通过如下命令:
[root@localhost home]#cat /proc/cpuinfo | grep "model name"
二、利用TCMalloc优化Nginx的性能
TCMalloc的全称为Thread-Caching
Malloc，是谷歌开发的开源工具“google-perftools”中的一个成员。与标准的glibc库的malloc相比，TCMalloc库在
内存分配效率和速度上要高很多，这在很大程度上提高了服务器在高并发情况下的性能，从而降低系统负载。下面简单介绍如何为Nginx添加TCMalloc
库支持。
要安装TCMalloc库，需要安装libunwind（32位 *** 作系统不需要安装）和google-perftools两个软件包，libunwind
库为基于64位CPU和 *** 作系统的程序提供了基本函数调用链和函数调用寄存器功能。下面介绍利用TCMalloc优化Nginx的具体 *** 作过程：
1安装libunwind库
可以从>

数据和日志文件分开存放在不同磁盘上

数据文件和日志文件的 *** 作会产生大量的I/O 在可能的条件下 日志文件应该存放在一个与数据和索引所在的数据文件不同的硬盘上以分散I/O 同时还有利于数据库的灾难恢复

tempdb数据库单独存放在不同磁盘上

tempdb数据库是其他所有数据库都有可能使用的临时数据库 当使用select into 在没建立索引的列上执行Orderby时就会在tempdb数据库中产生临时表来存储中间数据 由于建立和填充临时表会严重降低系统性能 所以在尽可能的情况下应该为要排序的列建立索引 同时 tempdb数据库是为所有的用户和应用程序共享 所以如果一个用户占据了tempdb数据库的所有空间 则其他数据库将不能再使用 在可能的情况下 tempdb数据库应该单独放置在一个速度更快的硬盘或者RAID阵列上 分离tempdb数据库的I/O *** 作以加快性能 tempdb数据库应该有适当的容量 以满足用户的需要 应该允许tempdb数据库的空间自动增长 如果设置为不允许自动增长 当查询 *** 作建立了超过tempdb数据库容量的临时表时 *** 作将无法完成

适当设置tempdb数据库的增长幅度 过小的增长幅度会产生更多的外部碎片 会占用更多的资源

避免热点数据的发生

在SQLServer 之前 对于没有聚集索引的表（堆集表） 新插入的数据行总是放置在磁盘中表的物理结尾处 如果并发的用户很多 同时在对表执行插入或者更新数据的 *** 作 这将使得十分繁忙的表的末尾有可能产生数据热点 并发的I/O *** 作集中对少数页面进行 *** 作 将导致数据库性能的下降

在SQLServer中 新的数据行的物理存储空间的分配是通过PFS页面来进行的 PFS页面的管理算法将插入 *** 作进行分散来尽量避免产生数据热点

在设计应用系统和数据库时 要避免在自然增长的列上建立主键 这样有可能导致热点数据的发生

数据类型要少

在设计表时 尽可能少用数据类型 这样一个数据页面上可以保存最多的信息 数据页面就少 检索数据页面的I/O *** 作就少 所以效率会高

监控和整理空间碎片

文件空间的自动增长提高了自动管理性 但可能导致空间碎片 物理空间与数据的逻辑空间不再连续 定期的监控和空间碎片整理有利于提高I/O性能

使用主数据文件和次要数据文件

每个数据库的一个主数据文件属于主文件组 对于 GB左右规模的数据库 一个数据文件就够了 如果有次要数据文件 主数据文件中有管理次要数据文件的指针

采用多个数据文件时 主数据文件用于存储系统对象和表 次要数据文件用于存储用户数据和索引 在可能的情况下 主数据文件和次要数据文件可以单独存放在不同的磁盘上以分散I/O

如果采用多个数据文件 推荐主数据文件存储系统数据 次要数据文件存放用户数据和索引 这样会有助于提高I/O性能

利用文件组改善性能

在大型数据库系统中 可以考虑建立文件组来管理数据文件 将表和索引通过存放在不同的物理磁盘上进行性能监控比较 最后得出优化的存储方案

重视自动增长和自动收缩可能导致的性能问题

数据库文件的自动增长和自动收缩功能对于小型数据库的管理十分有用 但可能导致大型数据库的性能问题 因为文件的自然增长的同时会导致存储碎片的发生 当文件空间变大时 新分配的空间不一定和原来的空间连续 当文件空间收缩时 释放了部分空间 然而当文件又需要增长存储空间却不能利用原先释放的空间 也会导致碎片的发生

分离系统数据和用户数据

将系统数据库和用户数据库分开存放在不同的物理磁盘上有助于改善I/O性能 有助于数据库备份和恢复

优化索引设计

索引的设计对数据库的性能十分重要 具体不再阐述 可参见本博相关文章

定期更新统计信息

SQLServer默认使用基于代价的优化 所以统计信息的及时更新对于查询优化十分重要

定期的一致性检查

lishixinzhi/Article/program/SQLServer/201311/22434

---