彩神大发快三_神彩大发快三官方

【360开源】Pika最佳实践

时间:2020-02-03 02:49:37 出处:彩神大发快三_神彩大发快三官方

Pika的内存占用主要集中在sst文件的cache和连接申请内存,而通常连接申请内存会比sst的cache要大这一 这一 ,Pika目前已支持连接申请内存的动态调整、回收,或者连接占用的总内存大小是还还能能粗略估算的,将会你的Pika内存占用远超预估或大于10g,没办法 将会为你当前使用的版本趋于稳定内存泄漏疑问,尝试依次执行命令client kill all和tcmalloc free来对连接内存进行强制回收,将会效果不好请升级到最新版本

Pika和Redis一样支持慢日志功能并可通过slowlog命令查看,但大伙知道slowlog的存储是有上限的,你你这一 上限取决于你的配置,将会配置过大会造成slowlog占用过多内存,而Pika允许将慢日志记录到pika.ERROR日志中用于追溯、分析,该功能还要将slowlog-write-errorlog设置为yes

将会发现Pika有数据但info keyspace的显示均为0,这是将会Pika并没办法 像Redis对key的数量做实时统计并展示,Pika中key的统计还要人工触发,执行info keyspace 1,注意执行info keyspace是不想触发统计的,没办法 带上最后的参数1将会仅仅展示上一次的统计结果,key的统计是还要时间的,执行状况还还能能通过info stats中的is_scaning_keyspace进行查看,该项值为yes表明统计正在进行,为no时表明没办法 正在进行的统计/上一次统计已现在现在开始 ,在统计执行完毕前info keyspace不想更新,info keyspace的数据是存中放内存里的,重启将清零

对趋于稳定极少量过期、多数据形态学 内元素操作的实例配置compact-cron还还能能非常好地处置无效但还未被彻底清理的数据对性能造成的影响,或升级到3.0后打开新的key级auto_compact功能,将会你遇到了下面的状况,没办法 你的实例将会趋于稳定无效数据风险:

在Pika中执行key 过多会造成Pika阻塞(Pika是多多守护进程 的),但在趋于稳定巨量key的场景下将会会造成临时占用巨量内存(哪些地方地方内存用于该连接存放key 的执行结果,会在key 执行完毕后释放),或者使用keys 一定要小心谨慎

Pika的备份生成为快照式,通过硬链接存中放dump目录中以日期为后缀,备份每天里还还能能 生成一份,多次生成备份时新的备份会覆盖一个多多多的。在生成备份快照的一个多多多,为了确保数据的一致性Pika会暂时阻塞写入,阻塞时间与实际数据量相关,根据测试30g的Pika生成备份快照也仅需30ms,在写入阻塞的过程中连接不想中断请求不想异常,但client会感觉到“在那一瞬间请求耗时增加了这一 ”。将会Pika的快照是db目录中sst文件的硬连接,或者最初你你这一 目录是不想占用磁盘空间的,而在Pika db目录中的sst文件趋于稳定了合并、删除后,硬链接会将会其形态学 而体现真实体积从而现在现在开始 占用磁盘空间,这一 这一 请根据实际的磁盘空间调整备份保留天数,处置备份过多而造成磁盘空间用尽

过多在Pika执行全量compact的一个多多多触发key统计(info keyspace 1)或执行keys ,或者会造成数据体积暂时膨胀直到key统计、keys 执行现在现在开始

异常的数据体积(大于估算值10%以上),还还能能通过执行compact命令,在compact执行完毕后观察数据体积否是恢复正常

在使用Pika多数据形态学 (hash,list,zset,zset)的一个多多多,尽量确保每个key中的field过多过多,将会业务类型为耗时敏感型没办法 建议每个key的field数量过多超过1万个,特大key还还能能考虑拆分为多个小key,一个多多多还还能能处置超大key这一 这一 潜在的性能风险,而存储型业务(耗时不敏感)则没办法 你你这一 要求

Pika已在2019年1月24日更新至3.0.7,但仍然有极少量用户守候在两年前的2.2.X或一年前的2.3.X,大伙建议使用3.0的最新版,将会不想我使用3.X没办法 请使用2.3.6,或者要我发现你遇到的这一 这一 疑问都会大伙的bug修复列表中

write2file的角色为宜binlog,应当根据实际写入状况调整write2file到为宜的保留周期/数量,建议write2file保留周期/数量不低于48小时,足够的write2file还还能能让这一 这一 状况变得轻松,之类:大数据集群的从库扩容、从库服务器关机维修、从库迁移等等,不想将会主库write2file过期而被迫全量重传

Pika的性能和IO性能息息相关,大伙不建议在机械盘上部署耗时敏感项目的Pika,另外为了处置这一 稀奇古怪的疑问,主从服务器的硬件性能应当尽量一致

client kill命令被加强了,将会你想一次性杀掉当前Pika的所有连接,只还要执行client kill all,不想担心,用于同步的连接不想受到影响

大伙会随着Pika版本的不断更新及用户的反馈定期更新Pika最佳实践

非常不建议单机运行Pika,最简集群状况应为一主一从,而主从集群的容灾模式有这一 这一 种,还还能能考虑使用lvs、vip漂移、配置管理后边件等

Pika的数据目录含高极少量的sst文件,哪些地方地方文件随着Pika数据量的增加而增加,或者你还要为Pika配置一个多多更大的open_file_limit处置欠缺用,将会你不希望Pika占用过多的文件描述符,还还能能通过适当增大单个sst的体积来降低sst的总数量,对应参数为target-file-size-base

root-connection-num参数非常有用,意为“允许通过127.0.0.1登录Pika的连接数”,它与最大连接数配置项maxclients独立,maxclients的用尽过多会影响root-connection-num,或者在趋于稳定异常maxclients被用尽的场景中,管理员仍然还还能能登录Pika所在服务器并通过127.0.0.1来登入Pika处置疑问,处置了maxclients耗尽无法登录处置的尴尬局面

适当地调整timeout参数,通过该参数Pika会主动断开不活动时间超过timeout值的连接,处置连接数耗尽疑问的趋于稳定,将会连接也还要申请内存,或者合理的配置timeout参数里还还能能在一定程度上降低Pika的内存占用

开源地址:https://github.com/Qihoo330/pika

奇技指南

Pika是330 热门的c++开源项目,基于rocksdb开发的大容量类Redis存储,力求在全版兼容Redis协议、继承Redis便捷运维设计的前提下通过持久化存储法律土办法处置Redis在大容量场景下主从同步代价高、恢复时间慢、单多守护进程 相对脆弱、内存成本高等疑问。

Pika没办法 提供Redis的命令改名(rename-command)功能,将会主次命令的改名会造成这一 工具、后边件的工作异常(之类将config改名后哨兵会无法工作),或者Pika额外增加了userpass、userblacklist来处置你你这一 疑问。userpass对应requirepass,使用userpass登录的用户会受到userblacklist的限制,它们无法执行配置在userblacklist中的命令,而requirepass则不受影响,还还能能简单的将通过requirepass登录Pika的用户理解为“超级用户”,将通过userpass登录Pika的用户理解为“普通用户”,大伙非常建议Pika运维将userpass提供给业务用于代码访问并在userblacklist增加之类slaveof,config,shutdown,bgsave,dumpoff,client,keys等管理类、风险性命令来处置误操作造成的故障

将会你的Pika单机运行(非主从、主主集群),并部署在可靠的存储上,没办法 还还能能考虑通过关闭binlog(将write-binlog参数设置为no)来提高写入性能,不过大伙过多推荐单机运行,为宜应当一个多多多从库用于容灾

Pika的全量同步是通过rsync来进行的,或者大伙提供了rsync的传输限速参数db-sync-speed,该参数的单位是mb,大伙建议在千兆环境中该参数设置不应高于75,而在万兆环境中不应高于30,一个多多多还还能能处置Pika在全量同步的一个多多多将所在服务器网卡用尽而影响到部署在服务器上的其它服务

Pika对数据进行了压缩,默认压缩算法为snappy,并允许改为zlib,或者每一次数据的存入、读出都还要经过压缩、解压,这对cpu有一定的消耗,非常建议像使用Redis一样使用Pika:在Pika中关闭压缩,而在client中完成数据的压缩、解压,一个多多多不仅还还能能降低数据体积,还能有效降低Pika的cpu压力,将会你的存储空间都会疑问但过多想调整client,还还能能关闭压缩来降低cpu压力,代价是磁盘占用的增加,注意关闭、开启压缩还要重启实例但不想重做数据

将会写入量巨大且磁盘性能欠缺以满足rocksdb memtable的及时刷盘需求,没办法 rocksdb很将会会进入写保护模式(写入将被全版阻塞),对于该疑问大伙建议更换性能更好的存储来支撑,将会降低写入频率(之类将集中写数据的2小时拉长到4小时),也可适当加大write-buffer-size的值来提高memtable的总容量从而降低整个memtable被写满的将会,但实际根据测试发现修改该参数过多能彻底处置该疑问,将会“写的memtable迟早要刷下去的!一个多多多刷不动,现在也刷不动!”

大伙根据330外部的Pika使用经验及社区用户的疑问反馈,分派了本文并在这里分享给大伙

Pika的多守护进程 数量建议和cpu总多守护进程 数一致,将会是单机多实例的部署,每个Pika实例的多守护进程 数量还还能能酌情降低,但不建议低于cpu总多守护进程 数的1/2

建议使用主从集群而都会双主模式,在实际使用中双主模式对使用规范的要求、网络环境要求相对更高,使用不规范、网络环境不好会造成双主模式再次再次出现疑问,在再次再次出现疑问后,双主模式的数据修复比主从集群数据修复僵化 度要大

请求耗时一直异常增大,还还能能通过执行compact命令,在compact执行完毕后观察请求耗时否是恢复正常

全量compact的原理是逐步对rocksdb的每一层做数据合并、清理工作,在你你这一 过程中会新增、删除极少量的sst文件,或者在执行全量compact的一个多多多还还能能发现数据体积先增大后减小并最终减小到一个多多稳定值(无效、重复数据合并、清理完毕仅剩有效数据),建议在执行compact前确保磁盘空余空间不低于30%处置新增sst文件时将磁盘空间耗尽,另外pika支持对指定数据形态学 进行compact,之类一个多多实例中已知hash形态学 的无效数据很少但hash形态学 数据量很大,set形态学 数据量很大且无效数据这一 这一 ,在你你这一 例子中hash形态学 的compact是没办法 必要的,要我通过compact set实现仅仅对set形态学 的compact

备份是以硬链接db目录中的sst的法律土办法产生的,或者在趋于稳定备份文件的状况下,一旦执行全量compact将会Pika db目录中的所有sst都会被compact“清洗”一遍(逐步将所有老的sst删除替加在新的sst),这将造成备份硬链接文件的体积变为真实体积,极端状况下备份文件会额外占用一倍的空间,或者将会你的磁盘空余空间不大,没办法 在执行全量compact一个多多多最好删除备份

过多修改log目录中的write2file文件和manifest,它们是同步相关的重要文件,write2file为binlog角色,而manifest则用来确保实例重启后的binlog续写及实例为从库时帮助同步中断重连后续传

读写分离有点痛 要,Pika在常见的主从集群中将会写入是单点的(主库),或者写入性能是有极限的,而读取还还能能通过多个从库来一并支撑,或者Pika集群的读取性能是随着从库数量的增加而增加的,这一 这一 对于读取量很大的场景,建议在业务层代码加入读写分离策略一并在Pika层增加从库数量通过多个从库来提供读服务,一个多多多还还能能大幅度提高集群稳定性并有效降低读耗时

在主库写入量过大(普通ssd,大致写入qps大于8万)的状况下从库将会会趋于稳定同步延迟疑问,还还能能调整从库的sync-thread-num参数来提高从库同步性能,该参数控制着从库的同步多守护进程 ,每个多守护进程 通过hash来负责对应的key的同步,或者主库写入操作的不同的key的数量过多该参数的效果就会越好,而将会巨量的写入仅集中在几只key中,没办法 该参数将会无法达到预期效果

在Pika3.0中大伙提供了过期key的统计(可通过info keyspace 1来触发统计,通过info keyspace查看统计结果),统计结果中的invaild_keys的值为“已删除/过期但还未被物理删除的key的数量”,Pika会在后台逐步地对已删除/过期的key进行物理清理,将会这是一个多多后台行为,或者在趋于稳定大规模过期key的场景下哪些地方地方key将会无法被及时清理,或者建议关注该值,若发现无效key数量过多可通过compact命令进行全面清理,一个多多多还还能能将未物理清理的无效数据控制在一个多多较好的程度从而确保Pika的性能稳定,将会Pika中存储的数据是规律性过期的,之类每个key的过期时间为半年,没办法 建议通过配置compact-cron参数来实现每天的定时全自动全量compact,compact会占用一定的IO资源,或者将会磁盘IO压力过大,建议将其配置为业务低峰期执行,之类午夜

热门

热门标签