《Redis性能优化培训》.ppt

操作系统优化 内存分配控制内核参数vm.overcommit_memory Redis建议把这个值设置为1，是为了让fork能够在低内存下也执行成功 swappiness参数 决定操作系统使用swap的倾向程度 取值范围是0~100，swappiness的值越大，说明操作系统可能使用swap的概率越高，swappiness值越低，表示操作系统更加倾向于使用物理内存 设置方法： echo vm.swappiness={bestvalue} >> /etc/sysctl.conf 操作系统优化 Transparent Huge Pages 支持大内存页(2MB)分配，默认开启，Redis建议禁用，禁用方法： echo never > /sys/kernel/mm/transparent_hugepage/enabled OOM killer OOM killer会在可用内存不足时选择性的杀掉用户进程 对于Redis服务器来说，可以将所有Redis的oom_adj设置为最低值或者稍小的值，降低被OOM killer杀掉的概率 操作系统优化 NTP时间同步 保证Redis集群时间同步，避免因时间不一致导致的各种问题，例如故障转移 TCP backlog Redis默认的tcp-backlog为511，ubuntu操作系统默认128，需修改系统值： echo 511 > /proc/sys/net/core/somaxconn 读写分离机制 Redis主从复制高可用集群方案可以实现一主多从的多节点架构 主节点接收所有写请求，并将数据同步给多个从节点 可以让从节点提供对实时性要求不高的读请求服务，以减小主节点压力 尤其针对使用长耗时命令的统计类任务，应指定在从节点上执行 读写分离机制 优化建议 Master最好不要做任何持久化工作 如果数据比较关键，某个Slave开启AOF备份数据，策略为每秒同步一次 为了主从复制的速度和连接的稳定性，Slave和Master最好在同一个局域网内 尽量避免在压力较大的主库上增加从库 主从复制不要用图状结构，用单向链表结构更稳定 Redis集群 集群分片的必要性： Redis中存储的数据量大，一台主机的物理内存已经无法容纳 Redis的写请求并发量大，一个Redis实例无法承载 Redis 集群能力： 能够自动将数据分散在多个节点上 当访问的key不在当前分片上时，能够自动将请求转发至正确的分片 当集群中部分节点失效时仍能提供服务 性能测试 Redis-benchmark 官方自带Redis性能测试工具，可以有效的测试Redis服务的性能 测试案例: 测试redis服务器100个并发连接，100000个请求的性能 ./redis-benchmark -h 192.168.101.201 -p 6379 -c 100 -n 100000 测试指定操作命令的性能 ./redis-benchmark -t set,lpush -n 100000 -q * * * * 上面问题中提到的数据库某一时间压力暴增，是由于在缓存模式下，redis请求失败，请求的压力瞬间集中到数据库。 * * * 默认10ms。slowlog只会记录其命令执行的时间，不包含io往返操作，也不记录单由网络延迟引起的响应慢。 通常1gb带宽的网络延迟，预期在200μs左右，倘若一个命令仅执行时间就超过10ms，那比网络延迟慢了近50倍。 * * * * 在硬盘上进行读写操作要比在内存上进行读写操作，时间上慢了近5个数量级，内存是0.1μs单位、而硬盘是10ms * Redis在储存小于100个字段的Hash结构时，存储效率非常高，因此在不需要集合“set”操作或“list”的“push/pop”操作时，我们应尽可能地使用Hash结构。 在Redis配置文件中(一般为“redis.conf”文件)，设置“maxmemory”的值可以限制Redis最大使用内存，修改后重启实例生效。 在Redis配置文件中(一般为“redis.conf”文件)，设置“maxmemory”的值可以限制Redis最大使用内存，修改后重启实例生效。 * 设置“maxmemory”的值为系统可用内存的45%或95%(取决于持久化策略)，设置“maxmemory-policy”为“volatile-ttl”或“allkeys-lru”(取决于过期设置)，可以比较准确的限制Redis最大内存使用率，在绝大多数场景下使用这2种方式可确保Redis不会进行内存交换。 * Redis默认的内存分配器采用jemalloc 额外碎片的产生是由于Redis释放了内存块，但编译时制定的内存分配器glibc、jemalloc或tcmalloc并没有返回内存给操作系统。 通过比