以下很多东西都是来自网上的分享，我这里整理以下。我觉得对一些运维来说还是非常有用
1.技术需求
apache,nginx,squid,bind,ftp,php,hippop,postfix,jboss,tomcat等
svn,git
mfs(shadow-mfs),fastdfs,glusterfs
lvs,haproxy,keepalived
redis,monogodb,memcached,varnish
shell,python(jinja2,mako,tornado,django),perl,ruby
ansible,puppet,salt
xen,kvm,exsi
lxc,docker,zerovm,vagrant
cloudstack,openstack
oracle,mysql,postgressql
hadoop,hbase,hive
devops,运维2.0
couchbase,rabbimq,erlang,zookeeper,kafaka,0mq,Cassandra
java/C/C++/go
2.技术总结
mysql
工具
mysqlreport,profile，mysqldiff，pt-heartbeat
pt-table-checksum，pt-table-sync，pt-kill
命令
show processlist
show global status
show global variables
show master status
show slave status
show binary logs
show engine innodb status\G
show engine myisam status\G
查看information_schema
show status和应用特点了解各种SQL的执行频率
使用脚本检测 tuning-primer.sh
SLOW QUERIES
BINARY UPDATE LOG
WORKER THREADS
MAX CONNECTIONS
INNODB STATUS
MEMORY USAGE
KEY BUFFER
QUERY CACHE
SORT OPERATIONS
JOINS
OPEN FILES LIMIT
TABLE CACHE
TEMP TABLES
TABLE SCANS
TABLE LOCKING
或者
执行下面的SQL语句查看适合的参数值. (如果有很多表,可能耗时几分钟.)
SELECT ENGINE,
ROUND(SUM(data_length) /1024/1024, 1) AS "Data MB",
ROUND(SUM(index_length)/1024/1024, 1) AS "Index MB",
ROUND(SUM(data_length + index_length)/1024/1024, 1) AS "Total MB",
COUNT(*) "Num Tables"
FROM INFORMATION_SCHEMA.TABLES
WHERE table_schema not in ("information_schema", "performance_schema")
GROUP BY ENGINE;
调优
淘宝系统分析师蒋江伟的一句话：只有勇于承担，才能让人有勇气，有承担自己的错误的勇气
除了用上面的脚本检测你配置参数，还有一下东西会限制数据库的性能
30% + 70%
cpu
当CPU需要的数据超出CPU缓存，主缓存带宽就成为内存的一个瓶颈
io
首先你可以通过命令查询你数据库写入和读写次数，就可以知道是否写压力很大
可以用的一些办法
读写分离，分业务入库，分库分表,/dev/shm,多个磁盘并行读写,使用缓存，比如memcached
如果你的MySQL是主－从结构，可以考虑打开其中一台从服务器的慢查询日志，这样既可以监控慢查询，对系统性能影响又小
线程池和NUMA
thread_handling = pool-of-threads
######NUMA #########################
innodb_buffer_pool_populate = 1
大内存分页(huge pages)
启用 Huge pages
通知操作系统分配适当的数量(和 buffer_pool 个数一致)
通知MySQL使用huge pages
内存
cat /proc/sys/vm/swappiness 不能设置过低
一些特别注意的参数
max_statement_time = 1000 #自动杀死超过1s的慢sql，PerconaDB5.6支持，不建议使用
线程池,在高并发高负载情况下表现出出色的数据库性能
query_cache_type = off
query_cache_size = 0
#这两项是禁用缓存，这个使服务器用途而定：写比较多的数据库最好禁用，因为没写一次他要修改缓存中的数据，给数据库带来额外的开销，读比较的可以开启，可以提高查询效率
#一下4个参数是mysql5.6上的新特性
innodb_buffer_pool_dump_at_shutdown = 1 #解释：在关闭时把热数据dump到本地磁盘。
innodb_buffer_pool_dump_now = 1 #解释：采用手工方式把热数据dump到本地磁盘。
innodb_buffer_pool_load_at_startup = 1 #解释：在启动时把热数据加载到内存。
innodb_buffer_pool_load_now = 1 #解释：采用手工方式把热数据加载到内存。
innodb_io_capacity = 20000#根据硬盘的情况修改，stat的用100，sas的200，sas做riad10的为400fision-io的可以设置为20000
innodb_flush_neighbors —— 默认值为 1. 在SSD存储上应设置为0(禁用) ,因为使用顺序IO没有任何性能收益. 在使用RAID的某些硬件上也应该禁用此设置,因为逻辑上连续的块在物理磁盘上并不能保证也是连续的.
innodb_io_capacity and innodb_io_capacity_max —— 这些设置会影响InnoDB每秒在后台执行多少操作. 如果你深度了解硬件性能(如每秒可以执行多少次IO操作),则使用这些功能是很可取的,而不是让它闲着
innodb_lru_scan_depth - 默认值为 1024. 这是mysql 5.6中引入的一个新选项. Mark Callaghan 提供了 一些配置建议. 简单来说,如果增大了 innodb_io_capacity 值, 应该同时增加 innodb_lru_scan_depth
performance_schema_max_table_instances=600
table_definition_cache=400
#log-queries-not-using-indexes#这个参数不安全
#relay_log_recovery=1#这个参数在丛库上一定要加上
innodb_buffer_pool_instances - 在 MySQL 5.5, 设置它为 4， 在 MySQL 5.6 – 设置它为 8 或者甚至是 16
thread_cache_size=4 这个值似乎会影响show global status输出中Threads_created per Connection的hit rate
innodb_read_io_threads, innodb_write_io_threads
innodb_old_blocks_time = 1000 - 这个可以帮助你防止 由于偶尔的 scans 造成的 buffer pool 污染
skip-locking 避免MySQL的外部锁定，减少出错几率增强稳定性
tmpdir - 有时候指定 tmpdir 为 /dev/shm 是一个好注意，以至于 on-disk temporary 表实际是写入内存中，但是在 MySQL 5.5 有一个重要的警告：如果你这样做了，它禁用了 AIO acorss the board，因为 tmpfs 不支持 AIO。因此我将监控在当前 tmpdir（/tmp） 的活跃性，并且如果我发现它有问题的时候，切换到 /dev/shm
back_log = 384 系统在一个短时间内有很多连接，则需要增大该参数的值
max_connections = 1000,那大概就需要 200 MB,或者更多. 同时连接数太大可能会引起其他某些问题,这点需要注意. Max_used_connections / max_connections * 100% ≈ 85%
在5.6(或 MariaDB5.5)中,可以选择线程池与 max_connections 交互. 这是一个高级话题.
线程栈溢出很少出现. 如果确实发生了,可以设置: thread_stack = 256K
innodb_file_per_table=1 表会增大
innodb_flush_method = O_DIRECT 直接写入磁盘，sync
对于事务型的应用，通过Com_commit和Com_rollback可以了解事务提交和回滚的情况，对于回滚操作非常频繁的数据库，可能意味着应用编写存在问题
Slow_queries 慢查询的次数，定位执行效率较低的SQL语句
锁
数据库设置concurrent_insert直接从表尾并发插入，这样可以有效降低大量注册与登录的锁竞争
query_cache_size由于查询缓存的互斥竞争
要想合理利用Innodb 的行级锁定，做到扬长避短，我们必须做好以下工作：
a) 尽可能让所有的数据检索都通过索引来完成，从而避免Innodb 因为无法通过索引键加锁而升级为表级锁定；
b) 合理设计索引，让Innodb 在索引键上面加锁的时候尽可能准确，尽可能的缩小锁定范围，避免造成不必要的锁定而影响其他Query 的执行；
c) 尽可能减少基于范围的数据检索过滤条件，避免因为间隙锁带来的负面影响而锁定了不该锁定的记录；
d) 尽量控制事务的大小，减少锁定的资源量和锁定时间长度；
e) 在业务环境允许的情况下，尽量使用较低级别的事务隔离，以减少MySQL 因为实现事务隔离级别所带来的附加成本；
由于Innodb 的行级锁定和事务性，所以肯定会产生死锁，下面是一些比较常用的减少死锁产生概率的的小建议，读者朋友可以根据各自的业务特点针对性的尝试：
a) 类似业务模块中，尽可能按照相同的访问顺序来访问，防止产生死锁；
b) 在同一个事务中，尽可能做到一次锁定所需要的所有资源，减少死锁产生概率；
c) 对于非常容易产生死锁的业务部分，可以尝试使用升级锁定颗粒度，通过表级锁定来减少死锁产生的概率；
系统锁定争用情况查询
对于两种锁定级别，MySQL 内部有两组专门的状态变量记录系统内部锁资源争用情况
MySQL提供了几个语句调节符，允许你修改它的调度策略：
· LOW_PRIORITY关键字应用于DELETE、INSERT、LOAD DATA、REPLACE和UPDATE。
· HIGH_PRIORITY关键字应用于SELECT和INSERT语句。
· DELAYED关键字应用于INSERT和REPLACE语句
分区or分片
如果你已经通过 date 来 partitions，实际上是 subpartitions
我将鼓励你尝试分片（如果你还没有使用分片）或者是通过 BASH subpartitions，正如我们在 partitioning in some cases can increase the throughput of InnoDB 发现的那样
依然没有得到足够的 new values per second （并且这不是你的硬件限制）。尝试通过 hash partitioning 或 subpartitioning 表的 key
分库分表
那么分库分表多少合适呢?
经测试在单表1000万条记录一下,写入读取性能是比较好的. 这样在留点buffer,那么单表全是数据字型的保持在
800万条记录以下, 有字符型的单表保持在500万以下.
如果按 100库100表来规划,如用户业务:
500万*100*100 = 50000000万 = 5000亿记录.
sql优化
show explain
1.少作计算
2.少join 优化器效率低，join复杂性能低
3.少排序 索引，减少排序的记录条数，非必要不对数据进行排序
4.不要select *
5.用join代替子查询
6.少 or 用union all 或者union代替
7.尽量用 union all 代替 union
8.早过滤
9.避免类型转换
10.优先优化高并发的 SQL，而不是执行频率低某些“大”SQL
11.从全局出发优化，而不是片面调整 不能顾此失彼，因小失大
12.尽可能对每一条运行在数据库中的SQL进行 explain
13.内存排序
14.增加索引
列出几篇参考文章
MySQL查询优化器--逻辑查询优化技术（一）--视图重写
一个20秒SQL慢查询优化的经历与处理方案
生产环境高并发MySQL SQL语句优化10条案例
MySQL 性能优化的最佳20多条经验分享
10 MySQL settings to tune after installation
关于MYSQL的优化全面详解
阿里巴巴MySQL DBA面试题
中间件
atlas,mycat,oneproxy,myproxy,amoeba
主从
先差主从数据库表结构是否一致mysqldiff
不停止MySQL服务增加从库
Seconds_Behind_Master 为 0，不代表主从数据一致，原因是从不会主动去主上同步数据
预防：正确设置 --master-retry-count,--master-connect-retry,--slave-net-timeout 复制重试参数
半同步复制
5.7的新特性
如何缓解主写的压力
1.硬件，xfs，ssd,内核deadline
2.采用MariaDB发行版，它实现了相对真正意义上的并行复制，其效果远比ORACLE MySQL好的很多。在我的场景中，采用MariaDB作为slave的实例，几乎总是能及时跟上master。如果不想用这个版本的话，那就老实等待官方5.7大版本发布吧
3.一般而言，slave相对master延迟较大，其根本原因就是slave上的复制线程没办法真正做到并发
4.ORACLE MySQL 5.6版本开始支持多线程复制，配置选项 slave_parallel_workers 即可实现在slave上多线程并发复制。不过，它只能支持一个实例下多个 database 间的并发复制，并不能真正做到多表并发复制。因此在较大并发负载时，slave还是没有办法及时追上master
5.调整业务
6.将统计分析类型的SQL语句在单独的BI数据库服务器上做查询，不要在主库和从库上，因为这种类型的SQL都比较复杂，执行的时间也很长
7.pt-kill部署线上环境，定义5-10秒，杀死耗时很长的SQL，这样在读写分离时，从库不会因为一条SQL卡在那里，出现延迟
测试读写分离
tcpdump -i eth0 -s0 -nn -A tcp dst port 3306 and dst host 192.168.18.202
tcpdump -i eth0 -s0 -nn -A tcp dst port 3306 and dst host 192.168.18.1
tcpdump -i eth0 -s0 -nn -A tcp dst port 3306 and dst host 192.168.18.2
高可用分案，比较靠谱的
mmm,mha,mysql cluster(限制为ndb引擎)
MySQL 高可用架构在业务层面的分析研究
Mysql Fabric HA配置测试
双机高可用、负载均衡、MySQL(读写分离、主从自动切换)架构设计
mysql基于RHCS、Gtid主从复制的高性能、LB、HA集群架构
探索MySQL高可用架构之MHA
Mysql中间件代理 Atlas
再谈Mysql MHA
利用MariaDB Galera Cluster(无引擎限制)实现mariadb的多主复制
使用haproxy+keepalived来实现mariadb galera cluster的高可用架构
推荐的书
《MySQL高性能》第三版
数据库的回滚
以上参考hcymysql和其他作者的博文
任何发生于数据库上的操作一定要三思而后回车，血的教训数不胜数，所以验证无误的固定操作，用脚本来实现是个不错的选择
最后就是有的公司选择PostgreSQL，不用mysql，说PostgreSQL比mysql性能好
2.shell
多写，即使你照着别人的敲都行，可以学到很多，比如数组
比如常用的
nc -w2 -z 192.168.28.$i 80
curl -I -H “Host:www.XXX.com” -o /dev/null -s -w “%{http_code}\n
3.性能调优
1.基本调优原则
不要让资源争用,比如进程竞争
优化方向是不是错了
2.基本判断
网卡
高并发、大流量网卡调优
cpu
in,cs,r
io
r/s+w/s数量
svctm<20ms，不是磁盘性能的问题
await一般系统IO响应时间应低于5ms，如果大于10ms就比较大了(有的说大于15)
raid卡加大缓存
内核修改为 deadline 调度模式
echo deadline > /sys/block/sda/queue/scheduler
修改完这个后 还需要修改 deadline的一些参数 什么 write_expire 跟 read_expire
好像网上的建议 是 read_expire = 1/2 write_expire
ext3 data=writeback 方式
barrier=0 (前面已经采用witeback 得关闭这个 )
改下磁盘的IO调度 算法
cat /sys/block/sda/queue/scheduler （查看 sda盘的算法） 有 noop(fifo), as, cfq 这3种
noop多用于SAN/RAID存储系统
as多用于大文件顺序读写
cfq适于桌面应用
如果使用ats，那么上面调优参数很多没用的。
关闭ext3 日志记录功能（来着网上 线上未测试）
tune2fs -O^has_journal /dev/sdb1
磁盘预读 （线上未测试）
blockdev –setra 256 /dev/sdb 256为sectors
碎片化IO是否可以缓存批量读写，需要频繁读入的文件可以考虑放入/dev/shm
bi，bo
内存
修改swappiness 值（默认为60）
3.缓存
4.网络和内核优化
netstat -nat发现诸如TIME_WAIT过多，连接数不够用，连接数一直上不来，打开文件数过多等，通过修改/etc/sysctl.conf优化、该apache/nginx配置优化，修改TCP buffer,backlog等
net.core.netdev_max_backlog
5.connect sock连接时间，具体的tcp连接时间
例子 记一次tps提升,做的配置变更
故障排除
从下到上 ping,route,ss,iftop,ifstat,nethogs,mpstat,tsar,iotop,lsof,starce,xhprof,gdb
集群情况
日志跟踪
网络转包-->tcpdump
应用程序的性能,处理能力，缓存命中率，tcp的复用，连接池的使用
例子 OOM killer
一些web缓存相关的概念.cache-control expires no-cache no-store maxage
nginx
1.
server {
listen 80 default;
server_name _;
return 403;
}
2.location / {
root /var/www/w1;
index index.html index.htm;
autoindex on; #开启自动index功能，在没有index文件时，自动显示目录
autoindex_exact_size on #让nginx设置按照什么单位显示目录大小
}
3.开启nginx的gzip功能
gzip on; 开启gzip压缩的功能
gzip_buffers 32 4k; 设置系统的缓存大小，以存储GZIP压缩结果的数据流，它可以避免nginx频烦向系统申请压缩空间大小
gzip_comp_level 1; 压缩级别为1
gzip_min_length 1024; 最小长度为1K字节数
gzip_types text/html text/css application/xml; 压缩的类型
4.实现nginx本地浏览器缓存
location ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$
{
expires 30d;
}
location ~.*\.(js|css)?$
{
expires 1h;
}
模块
nginx_tcp_proxy_module代理sshd服务
GeoIP,http_realip_module,Lua,mod_security,nginx-upstream-jvm-route
nginx_substitutions_filter
ngx_http_limit_conn_module
ngx_http_limit_req_module
ngx_http_upstream_module
sticky
tfs
nginx_flv
nginx_moglifes
nginx_upstream_check_module
http://wiki.nginx.org/3rdPartyModules
http://rmingwang.com/install-nginx-third-modules-http_sub_module.html
open files数量优化
Worker Processes数量优化
CPU Affinity
Keep Alive
tcp_nodelay 和 tcp_nopush优化
Buffers size优化
fastcgi_buffers，proxy_buffers 处理后端（PHP,Apache）响应
nginx的gzip模块
client_header_buffer_size 4k; 分页大小可以用命令getconf PAGESIZE
nginx事件驱动适合于IO密集型服务
nginx安全加固
1、屏蔽IP
if ( $geoip_country_code !~ ^(CN|US)$ ) {
return 403;
}
2、封杀各种user-agent
if ($http_user_agent ~* "java|python|perl|ruby|bash|echo|uname|base64|md5sum|select|concat|HttpRequest|nmap|scan" ) {
return 403;
}
3、封杀特定的url
location ~* \.(bak|save|sh|sql|mdb|svn|git|old)$ {
rewrite ^/(.*)$ $host permanent;
}
location /(admin|phpadmin|status) { deny all; }
4、封杀特定的http方法和行为
if ($request_method !~ ^(GET|POST|HEAD)$ ) {
return 405;
}
5、强制网站使用域名访问，可以逃过IP扫描，比如
if ($http_range ~ "\d{9,}") {
return 444;
}
if ( $host !~* 'abc.com' ) {
return 403;
}
6、url 参数过滤敏感字,比如
if ($query_string ~* "union.*select.*\(") {
rewrite ^/(.*)$ $host permanent;
}
if ($query_string ~* "concat.*\(") {
rewrite ^/(.*)$ $host permanent;
}
7、封杀IP
定时做日志分析，手动将恶意IP加入iptables拒绝名单，推荐使用ipset模块
8、定时总结和丰富过滤规则
apache
/usr/local/apache/bin/apxs -c mod_rewrite.c
/usr/local/apache/bin/apxs -i -a -n mod_rewrite
LoadModule rewrite_module modules/mod_rewrite.so
调优
perfork、worker、event
KeepAlive
不需要的LoadModule注释掉
Timeout
netstat -n | awk ‘/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}’
使用 mod_gzip/mod_deflate
禁用 .htaccess
mod_deflate
apachectl -M | grep deflate
/usr/local/apache/bin/apxs -c -I -A apache
mod_expires
httpd.conf启用模块:loadmodule expires_module modules/mod_expires.so
缓存机制
全局、目录和虚拟主机
apache,re.sin多进程或线程适合于CPU密集型服务
lnmp
LNAMP第二版（nginx 1.2.0+apache 2.4.2+php 5.4）
Tcmalloc
mysql-5.5.23.tar.gz
隐藏apache版本信息
php打入补丁.有助于防止邮件发送被滥用
安装php扩展模块memcache-3.0.6.tgz
php的扩展memcache，不支持cas，所以我们要装memcached扩展，memcached扩展是基于libmemcached，所以要先安装libmemcached
因eaccelerator-0.9.6.1不支持php 5.4.0，所以就改用XCache 2.0.0
php安全设置,禁用函数
为apache安装rpaf模块,该模块用于apache做后端时获取访客真实的IP
使用apxs安装模块.这里要使用此前apache编译安装后的apxs
全面优化—配置高性能lnmp架构
2.nginx-1.0.14.tar
3.php-5.3.6.tar.bz2
4.xcache-1.3.2.tar.gz
5. mysql-5.5.22-linux2.6-i686.tar.gz
6.gperftools-2.0.tar.gz
7.最新的libevent库
8.php额外的一些插件
lnmp或者lamp
调优
1.利用fastcgi_cache缓存，减少nginx与PHP交互，减轻php和数据库(mysql)的压力
2.为zend引擎缓存opcode，使用X-cache缓存opcode，减少php脚本语句转换中间代码的次数
3.利用TCMalloc优化Nginx和mysql的内存分配效率访问性能，提高高并发的性能（nginx本身对内存优化就很好，这里主要是针对mysql优化）
4.安装最新的libevent提高nginx和php的事件触发性能
5.开启gzip压缩网页文件
6.优化nginx中fastcgi参数
7.优化php-fpm参数
xcache，为php加速
# /usr/local/php/bin/phpize
# ./configure --enable-xcache --with-php-config=/usr/local/php/bin/php-config
# make && make install
lnmpa并不是说nginx不行,而是php-fpm不行,为了避免502所以才转由apache来处理php
整体写的很不错，php这块可以在完善下。
nginx＋php-fpm 最大的瓶颈不在nginx，而是在php。
1、如果是php ，nginx缓存php 最好别开。
2、EA的最新版本性能比Xcache要好。且对新的PHP支持较好
3、pm.max_children = 50 #最大进程数
pm.start_servers = 5 #初始进程数
pm.min_spare_servers = 2 #最小空闲进程
pm.max_spare_servers = 8 #最大空闲进程
php-fpm的模式分静态跟动态，静态的话只第一个参数生效，动态后面设置才有用
python
redis和mongodb比较多得公司在用
QPS
1、QPS：系统每秒处理的请求数（query per second）
2、RT：系统的响应时间，一个请求的响应时间，也可以是一段时间的平均值
3、最佳线程数量：刚好消耗完服务器瓶颈资源的临界线程数
?
QPS和RT的关系：
对于单线程：QPS=1000/RT
对于多线程：QPS=1000*线程数量/RT
QPS（TPS）= 并发数/平均响应时间
通常的技术方法：
1. 找出系统的最高TPS和日PV，这两个要素有相对比较稳定的关系（除了放假、季节性因素影响之外）
2. 通过压力测试或者经验预估，得出最高TPS，然后跟进1的关系，计算出系统最高的日吞吐量。B2B中文和淘宝面对的客户群不一样，这两个客户群的网络行为不应用，他们之间的TPS和PV关系比例也不一样
tomcat
屏蔽DNS查询
修改的属性是enableLoopups="false"
调整线程数
调整最大连接数 一般设置为maxProcessors的1.5倍即可
调整网络超时
一般设置成connectionTimeout="30000"
压缩管理
compression="on" # 打开压缩功能
compressionMinSize="50" # 启用压缩的输出内容大小，默认为2KB
noCompressionUserAgents="gozilla, traviata" # 对于以下的浏览器，不启用压缩
compressableMimeType="text/html,text/xml,text/javascript,text/css,text/plain"
JVM内存调优
比如其初始空间(即-Xms)是物理内存的1/64，最大空间(-Xmx)是物理内存的1/4
参考文章
tomcat配置调优与安全总结
深入理解JVM性能调优
ddos，cc
屏蔽ICMP，服务器缩短SYN等待时间，限制单个IP打开SYN最大数量
syn flood 、DNS Query Flood 、HTTP Flood 、 CC、慢速连接攻击
服务器被入侵后，该怎么做
登录系统查看可疑用户
锁定可疑用户
查看系统日志
检查并关闭系统可疑进程
chkrootkit
rpm -Va
安装Tripwire进行系统文件，web静态文件，php文件，以及各种配置文件的签名保护，设置好安全密码。定期运行tripwire经行验证，如果服务器可以承受，同时进行rootkit扫描
同步文件
rsync+inotify或者sersync或者svn+puppet 300s
rsync-vzrtopgl --progress --delete --exclude=.svn /data/web/a.test.cn/test@172.31.0.15::a.test.cn --password-file=/shell/rsync-passwd/rsync.passwd
rsync -az --delete --exclude "file10" /null/ /xx/
将dirA的所有文件同步到dirB内，并保留文件的属主，属组，文件权限等信息
rsync -avz dirA/ dirB/
将dirA的所有文件同步到dirB内，并删除dirB内多余的文件
rsync -avz --delete /dirA dirB/
将dirA的所有文件同步到dirB，但是在dirB内除了fileB3.txt这个文件不删之外，其他的都删除
rsync -avz --delete --exclude "fileB3.txt" dirA/ dirB/
将dirA目录内的fileA1.txt和fileA2.txt不同步到dirB目录内
rsync -avz --exclude="fileA1.txt" --exclude="fileA2.txt" dirA/ dirB/
将dirA目录内的fileA1.txt和fileA2.txt不同步到dirB目录内，并且在dirB目录内删除多余的文件
rsync -avz --exclude="fileA1.txt" --exclude="fileA2.txt" --delete dirA/ dirB/
将dirA目录内的fileA1.txt和fileA2.txt不同步到dirB目录内，并且在dirB目录内删除多余的文件，同时，如果dirB内有fileA2.txt和fileA1.txt这两个被排除同步的文件，仍然将其删除
rsync -avz --exclude="fileA1.txt" --exclude="fileA2.txt" --delete-excluded dirA/ dirB/
监控
基于Linux的系统监控或性能监控，写下你熟悉的一种监控软件（nagios,cacti,nmon或者其他工具或命令）能控制哪些性能指标，报警有哪些级别，有哪些报警方式
Apache性能监控支持以下指标：
Apache吞吐率
Apache并发连接数
Apache并发连接数详细统计，包括读取请求、持久连接、发送响应内容、关闭连接、等待连接
Lighttpd性能监控支持以下指标：
Lighttpd吞吐率
Lighttpd并发连接数
Lighttpd并发连接数详细统计，包括建立连接、读取请求、读取POST数据、处理请求、发送响应内容、关闭连接
Nginx性能监控支持以下指标：
Nginx吞吐率
Nginx并发连接数
Nginx并发连接数详细统计，包括读取请求、处理请求和发送响应、持久连接
Nginx持久连接利用率
MySQL性能监控支持以下指标：
MySQL查询吞吐率，包括Change DB、Select、Insert、Update、Delete
MySQL持久连接利用率
MySQL查询缓存空间使用率
MySQL查询缓存命中率
MySQL缓存查询数
MySQL索引缓存命中率
MySQL索引读取统计
MySQL连接吞吐率
MySQL连接缓存命中率
MySQL并发连接数，包括最大允许连接数、实际最大连接数、当前连接数、活跃连接数、缓存连接数
MySQL流量统计
MySQL表统计锁定
今天来看看zabbix如何监控mysql性能，这边使用mysql自带的模板，可以监控如下内容：OPS（增删改查）、mysql请求流量带宽，mysql响应流量带宽
参考文章 使用zabbix全方位监控MySQL
MongoDB性能监控支持以下指标：
MongoDB全局锁时间比例。此指标反映MongoDB进入锁状态的时间比例。
MongoDB当前等待锁总数。是读锁数和写锁数的总和。
MongoDB当前等待读锁数。因读请求过高时触发的锁数。
MongoDB当前等待写锁数。因写请求过高时触发的锁数。
MongoDB查询吞吐率。也就是MongoDB每秒处理的请求数，根据请求类别的不一样细分有query，update，delete，getmore吞吐率。
MongoDB使用内存，使用磁盘空间。此指标能反映MongoDB使用内存，磁盘空间的状况。
MongoDB分页次数，此指标反映内存分页的次数，有助于对MongoDB的性能分析。
MongoDB索引命中率，即单位总命中次数除以总命中次数与未命中次数之和。
MongoDB索引访问次数每秒，此指标反映索引的使用频率。
MongoDB当前链接数，可用链接数。
Memcache性能监控支持以下指标：
Memcache缓存命中率，即单位总命中次数除以总命中次数与未命中次数之和；
Memcache当前链接数，即当前已经建立的链接数量；
Memcache链接数每秒，即单位时间内新建立的链接数量；
Memcache使用内存，即当前存储的items所占用的字节数；
Memcache当前条目数量，即当前存储的items数量；
Memcache读写每秒，分为读每秒和写每秒，读每秒是指单位时间内新增的读的次数，写每秒是指单位时间内新增的写的次数；
Memcache空间使用率，当前存储的items所占用的字节数除以系统分配给Memcache的内存大小
Redis性能监控支持以下指标：
Redis链接客户数。
Redis链接从库数。此指标反映Redis的从库链接数。
Redis链接数每分钟。此指标反映Redis的请求频率。
Redis阻塞客户数。当并发请求数过高时触发阻塞。此指标反映Redis的并发请求状况。
Redis Pub/Sub通道数。
Redis Pub/Sub模式数。
Redis命中率。即单位总命中次数除以总命中次数与未命中次数之和。
Redis使用内存。此指标反映Redis当前占用内存量。
Redis执行命令数每分钟。此指标反映Redis执行命令频率。
Tomcat性能监控支持以下指标：
JVM内存，包括JVM可使用内存、JVM所使用内存、JVM最大可使用内存；
Tomcat请求数，包括每秒请求数，每秒出错数；
Tomcat网络流量统计，包括进流量统计，出流量统计；
Tomcat线程，包括最大线程数，当前线程数，当前繁忙线程数；
Tomcat处理时间，包括最大处理时间，平均处理时间；
监控以下硬件信息：
1、cpu处理器状态
2、cpu省电模式状态（如果开启了省电模式，在压力大的时候，会很卡的）
3、raid状态（比如做了哪个raid模式，raid状态是否正常）
4、内存状态（可以查看当前服务器最大支持多少内存，当前多少内存，如果内存有问题，可以显示哪个位置内存故障）
5、机器温度状态（监控机器的温度是否超过阀值）
6、物理硬盘状态（监控物理硬盘是否有故障）
7、电源状态（是单电还是双电，是否有故障）
8、系统面板CMOS电池（cmos电池是否有故障）
9、网卡状态（当前的网卡数量，以及网卡是否有问题）
10、风扇（当前的风扇数量，以及是否有故障）
Omsa来监控Dell服务器，or Ipmi、Megacli、Smart
LSI 芯片的监控 openmanager
运维工程师的工作需要严谨及富有创新精神
不要轻信别人的话，可以借鉴，最根本的是，是现在的情况，你做了改动，是否有不好的影响，在重大时刻一定要慎重，考虑最坏结果和有一个很好的备案，保证现在的访问
本文转自 liqius 51CTO博客，原文链接：http://blog.51cto.com/szgb17/1686230，如需转载请自行联系原作者
