nosql专栏

一、背景 活动前云上ES所在VM需要冷迁移到独享资源池中，从而避免活动期间ES的底层宿主机资源出现CPU争抢的情况发生。 活动结束后，又需要冷迁移资源回原先的资源池。 以上两个阶段的操作，需要手动操作

目的 复现12.21号出现的大index查询导致磁盘IO异常。 在yum2环境压测未能复现，现在在测试环境进行测试。 节点信息： 索引信息： 压测方案 使用esperf 工具实现并发压测。 上次压测未

一、背景 APM ES cpu需要限制，apm es的性能暂时不用考虑，64C的主机算力，限制使用50C就行。 二、操作 命令 截图 说明： 0-49C，全部使用满； 剩余的14C，基本空闲。 验证

版本 说明 编写人 时间 v1.0 文档创建 xxx 2022年8月9日 一、准备 ES版本7.6.2 拼音分词器版本7.6.2 本次操作使用 ansible方式批量操作 本次使用的用例 二、操作 下

ES（7.6.2） vs ES（7.7.1） 测试工具：esrall 数据集: geomanes 地理数据文档（官方提供的标准测试数据集） GC 回收模式：CMS JVM 启动参数： 未做额外配置，使

概述 Redis作为业界广泛采用的中间件，在百胜中国的消费者IT应用系统中被作为高速缓存的标准组件，得到了大量使用。截止本文V1.0版本成文时（2021.11.22），百胜S级业务系统使用的Redis

一、摘要 对redis服务本身进行压测，配置一个节点。如果是分片集群，将每个master节点同时压测。 二、部署 随着redis server 的安装自带上了。 三、参数 参数 说明 -h 连接的主机

一、起因 有个兄弟询问一套redis分片集群的连接数信息 redis集群信息 二、信息搜集 连接数信息 redis进程的limit文件信息 sysctl信息 limits.conf文件 三、分析 公司

一、背景 自建redis之间数据同步的需求带来的调研。 2.1.1的使用文档和2.0.3一样，文档来源是基于2.1.1，但使用的工具是2.0.3 二、工具介绍 工具介绍 本文档基于V2.1.1版本的r

一、背景 redis组名： redis-xxx-xxx-hw 目的： 操作时间 2024.08.22 周四早上 4:50 - 5:10 二、变更前的信息 需要先将maxmemory-policy参数配

版本 说明 编写人 v1.0 特殊需求redis clustr 需求操作 xxx v1.1 新集群部署 韦xx 需求： 现有一套redis大集群不满足dmp部署要求，需要手动部署，具体要求如下： 70

一、告警 二、日志输出 三、分析 主从复制的时候，复制的rdb文件超过buffer的限制导致。 四、处理 检查get set 检查

redis-cli -a "2ghlmvl_EC" -h 172.21.36.87 -p 6379 --bigkeys redis-cli -a "2ghlmvl_EC" -h 172.21.36.

一、背景 DBA标准redis是通过dmp管理平台实现部署交付与管理，但对超大容量的redis集群的管理dmp会出问题，所以就手工部署这类的超大容量的redis。 大数据部分会有一些非标的redis部

最终调整后 二、准备 redis规划 最终是5主5从的cluster 三、对标的redis集群 问题点： 对标集群中，5主5从，有几个分片的maxmemory 配置的是192G，其他是250G 四、部

一、背景 非标redis水平扩容后，槽位平衡 变更背景： 推荐中台 新发展机房redis组件扩容 变更环境： y4 影响范围： xxx 变更类型： 黑屏操作 涉及SID： xx 涉及系统等级： A级

一、背景与目的 经过压测后业务怀疑DBA交付的redis性能不及开发自己部署的redis，所以组织本次压测。 目的： 验证两套redis之间的性能差距。 验证redis白皮书中关于性能的指标 二、准备

一、背景 非标redis水平扩容后，旧分片的数据迁移与旧分片下线。 变更背景： 推荐中台 新发展机房redis组件扩容 变更环境： y4 影响范围： 推荐中台PH场景 变更类型： 黑屏操作 涉及SID

一、摘要 对redis服务本身进行压测，配置一个节点。如果是分片集群，将每个master节点同时压测。 二、部署 随着redis server 的安装自带上了。 三、参数 参数 说明 -h 连接的主机

测试与验证HA模式数据全量迁移到分片集群， 工具： redisShake4.3.1 二、准备 原集群 目的集群 工具 三、全量数据同步源 原集群数据量检查 redisShake配置文件调整shake.