前言 前文《[linux][redis]bgsave引起的latency突刺问题分析》中记录了在执行bgsave的时候，因为fork子进程之后，会出现page fault导致了redis的延迟受到了影响。 前文《[THP][redis]THP对redis的影响》中分析了THP（transparent hugepage）对redis的延迟突刺的影响。 大约两年半以前，作者给redis提了PR(https://github.com/redis/redis/pull/5124)，但是maintainer并没有回复，一段时间后关闭。 几个月前，第二次提PR（https://github.com/redis/redis/pull/7381）希望解决这个问题，新任的maintainer Oran对THP问题比较感兴趣，同时也把三年多以前的另外一个PR（https://github.com/redis/redis/pull/4001）翻了出来。大约经过一周的讨论和修改，两个PR都已经合入了upstream。 分析 THP的内核逻辑 内核提供了THP开关可以控制，/sys/kernel/mm/transparent_hugepage/enabled，这个开关需要root权限，且是系统级别的影响。 always表示所有的进程都会被khugepaged扫描，尝试使用2M的透明大页。 madvise表示如果有进程调用了THP开关，则打开/关闭。 never表示khugepaged不会对任何进程生效，包括使用madvise的进程。 warning判断 redis的原有的逻辑是在启动阶段检查系统的THP配置，如果不是never，就会产生一个warning。redis自身并没有使用过madvise进行THP操作，即使使用了jemalloc，也不会对主要的内存进行THP操作。所以改成不是always就应该是安全的，所以，Oran接受了这个改动（https://github.com/redis/redis/pull/4001）。 关闭redis的进程THP 更加理想的做法是不管系统配置如何，redis都可以把自己进程的THP开关禁用掉，这样子不需要root权限控制，且不会影响其他的进程。Linux恰好提供了这样了一个syscall，所以在（https://github.com/redis/redis/pull/7381）中，会关闭掉。同时，根据Oran的意见，增加了配置项，在多数情况下，默认都是会自动关闭掉THP，除非用户强制指定了不关闭的配置。这样下来，在大多数情况下，用户都可以避免THP引起的fork之后的剧烈抖动问题。 关于conf的描述 在redis.conf中增加了一个新的配置项“disable-thp”，作者最初的描述是
使用huge page，可以在TLB容量固定的情况下，提高TLB的命中率，即便TLB miss，因为减少了页表级数，也可以减少查找页表的时间。在内存虚拟化中，由于地址转换需要的级数更多，huge page能发挥的作用就显得更为重要。
用过不少种类的数据库的人会遇到一个问题, transparent Hugepages 在不少的数据库中都被提到 disabled, turn off . Why should we turn off
前言： 前文《[linux][redis]bgsave引起的latency突刺问题分析》分析了redis-server执行bgsave因为fork引起的latency突刺问题。 而在http://antirez.com/news/84中也提到了“However this is definitely not the full story”，剩下的story则是Linux的THP对redis的影响。 分析： 1，THP vs Normal page 配置了THP策略分别是always和never，redis-server和redis-benchmark配置相同的参数，执行bgsave的latency对比：
我们之前在生产环境上遇到过很多起由操作系统的某些特征引起的性能抖动案例，其中 THP 作案次数较多，因此本文将和大家分享 THP 引起性能抖动的原因、典型的现象，分析方法等，在文章的最后给出使用THP 时的配置建议及关闭方法。
在正式部署前，你可以先阅读前置准备，对部署过程中用到的docker、redis操作和配置有一个理解，以防在自己电脑上复现时出错。 我们将在一台windows10机器上运行多个docker容器，配置Redis主从集群。
Huge pages ( 标准大页 ) 和 Transparent Huge pages( 透明大页 )
在 Linux 中大页分为两种： Huge pages (标准大页) 和 Transparent Huge pages(透明大页)。
如果有人问redis 到底跑的有多快,简单的回答,纳秒等级, 可如果再要细问,估计只能进行测试了,每台机器的物理硬件标准不同,所以就需要基准测试. 另外redis到底需要不需要进行调优,可能大部分场景不需要,但不需要不意味这你可以欣然接受你不会.
通常来看，Redis开发和运维人员更加关注的是Redis本身的一些配置优化，例如AOF和RDB的配置优化、数据结构的配置优化等，但是对于操作系统是否需要针对Redis做一些配置优化不甚了解或者不太关心，然而事实证明一个良好的系统操作配置能够为Redis服务良好运行保驾护航。
前言： redis启动的时候，可能会提示“WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled.” redis的作者antirez的解释：http://ntireza.com/news/84 在stackoverflow上也能找到类似的问题，在执行bgsave的时候，redis的latency监控能看到明显的突刺。 作者看到这个问题后，比较担心THP对虚拟化产生影响，于是做了对比实验，以及分析了这个突刺问题发生的原因。 分析： 1，THP 前文《[linux][memory]hugetlb和hugepage技术分析 》中提到了透明大页，在复现bgsave引起的latency突刺问题的时候，关闭THP的情况下，依然可以复现到突刺现象。鉴于这种情况，先来关闭THP，分析一下bgsave对redis的影响。 2，复现现象 关闭THP：echo never > /sys/kernel/mm/transparent_hugepage/enabled 启动redis-server：redis-server /etc/redis.conf 启动压测：redis-benchmark -t set -n 1000000 -r 1000000 -d 1024 -l 抓取latency数据：while (true); do redis-cli --latency >> latency.log; done 抓取redis的major和minor fault数据：while (true); do ps -o majflt,minflt -p 16321 >>flt.log ; sleep 1; done 启动bgsave：redis-cli bgsave 停止抓取数据，处理 latency.log 执行：cat latency.log | awk '{print $3}' | tr "\n" "," 处理后的数据画图分析：
研究人员发现，去年发现的脏牛漏洞(CVE-2016–5195)尚未被完全修复。 脏牛漏洞由竞争条件引发——Linux内核内存子系统在处理COW时存在问题。这个漏洞由Phil Oester发现，它会导致攻击者在目标系统内提权。 Linux内核的内存子系统在处理写入时复制（copy-on-write, COW）时产生了竞争条件（race condition）。恶意用户可利用此漏洞，来获取高权限，对只读内存映射进行写访问。 竞争条件，指的是任务执行顺序异常，可导致应用崩溃，或令攻击者有机可乘，进一步执行其他代
随着计算需求规模的不断增大，应用程序对内存的需求也越来越大。为了实现虚拟内存管理机制，操作系统对内存实行分页管理。自内存“分页机制”提出之始，内存页面的默认大小便被设置为 4096 字节（4KB），虽然原则上内存页面大小是可配置的，但绝大多数的操作系统实现中仍然采用默认的 4KB 页面。 4KB 大小的页面在“分页机制”提出的时候是合理的，因为当时的内存大小不过几十兆字节，然而当物理内存容量增长到几 G 甚至几十 G 的时候，操作系统仍然以 4KB 大小为页面的基本单位，是否依然合理呢？
处理大内存的性能关键计算应用程序工作集已经运行在libhugetlbfs之上，然后依次运行 hugetlbfs。透明的巨型页面支持是另一种使用大页为虚拟内存提供大页支持的方法， 该支持自动提升和降低页面大小和没有hugetlbfs的缺点。
一次不经意发现Hadoop的系统态CPU使用率很高，然后百度一下居然是个已知问题。
大页内存(HugePages)，有时也叫“大内存页”、“内存大页”、“标准大页”。操作系统以内存页为单位管理内存，内存页的大小对系统性能有影响。内存页设得太小，内存页会很多，管理内存页的数组会比较大，耗内存，同时TLB(Translation Lookaside Buffer，页表寄存缓冲器，可理解为页表缓冲)大小是固定的，导致TLB MISS增加。在不同的应用场合，内存页的大小的最优值是不同的。所以一般的系统都支持多种内存页的取值。
用户经常因为OOM killer造成数据库崩溃问题来找我们寻求帮助。Out Of Memory killer会杀死PG进程，并且是我们遇到的数据库崩溃问题中首要原因。主机内存不足的原因可能有多种，最常见的有：
前面提到了虚拟内存需要映射物理内存才能使用，这个映射关系被保存在内存中的页表（Page Table）。现代 CPU 架构中一般有 TLB （Translation Lookaside Buffer，翻译后备缓冲，也称为页表寄存器缓冲）存在，在里面保存了经常使用的页表映射项。TLB 的大小有限，一般 TLB 如果只能容纳小于 100 个页表映射项。 我们能让程序的虚拟内存对应的页表映射项都处于 TLB 中，那么能大大提升程序性能，这就要尽量减少页表映射项的个数：页表项个数 = 程序所需内存大小 / 页大小。我们要么缩小程序所需内存，要么增大页大小。我们一般会考虑增加页大小，这就大页分配的由来，JVM 对于堆内存分配也支持大页分配，用于优化大堆内存的分配。那么 Linux 环境中有哪些大页分配的方式呢？
如果使用Oracle Linux，可以通过Preinstallation RPM配置操作系统，如果安装OracleDomain Services Cluster，则需要配置GIMR，则需要考虑大页面会被GIMR的SGA使用1G，需要将此考虑到hugepages中，standalone则可以选择是否配置GIMR。
Redis 是一种内存数据库，将数据保存在内存中，读写效率要比传统的将数据保存在磁盘上的数据库要快很多。所以，监控 Redis 的内存消耗并了解 Redis 内存模型对高效并长期稳定使用 Redis 至关重要。
按照提示分别修复: 1.第一个提示somaxconn这个值为128太小了,这个值是系统的网络连接队列大小,而redis的TCP backlog设置的值为511,因此受限,所以修改下系统的值
透明巨页(Transparent hugepage, THP)特性自动化了创建和管理巨页的任务。内核守护进程(khugepage)在后台运行，将空闲页面拼接在一起形成/free大页面。
Redis用处很广泛，我不再详细说了，按照这里的教程在Linux上安装Redis，开始了踩坑过程，网上买了一个Linux CentOS 7.3，某云的，巨坑无比啊， Redis 为4.0。
[root@localhost local]# service network restart
在 【Linux 内核 内存管理】物理分配页 ② ( __alloc_pages_nodemask 函数参数分析 | __alloc_pages_nodemask 函数分配物理页流程 ) 博客中 , 分析了 __alloc_pages_nodemask 函数分配物理页流程如下 :
或者 链接:https://pan.baidu.com/s/1JdPCMMEq178hXV5V4Ild3Q 密码:03l1
去Redis官网下载最新的Linux包，Redis官方没有Windows版的下载。
案发现场的日志： 缓存集群redis重启错误报错： 29808:M 07 Jun 09:46:32.209 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128. 29808:M 07 Jun 09:46:32.209 # Server started, Redis version 3.0.4 2
1. 安装Ubuntu 2. 用Putty登录Ubuntu Welcome to Ubuntu 14.04.1 LTS (GNU/Linux 3.13.0-40-generic x86_64)
从 Linux 内核 VS 内存碎片 （上） 我们可以看到根据迁移类型进行分组只是延缓了内存碎片，而并不是从根本解决，所以随着时间的推移，当内存碎片过多，无法满足连续物理内存需求时，将会引起性能问题。因此仅仅依靠此功能还不够，所以内核又引入了内存规整等功能。
/proc/meminfo是了解Linux系统内存使用状况的主要接口，我们最常用的”free”、”vmstat”等命令就是通过它获取数据的 ，/proc/meminfo所包含的信息比”free”等命令要丰富得多，然而真正理解它并不容易，比如我们知道”Cached”统计的是文件缓存页，manpage上说是“In-memory cache for files read from the disk (the page cache)”，那为什么它不等于[Active(file)+Inactive(file)]？AnonHugePages与AnonPages、HugePages_Total有什么联系和区别？很多细节在手册中并没有讲清楚，本文对此做了一点探究。
本文主要分析 Linux 系统内存统计的一些指标以及进程角度内存使用监控的一些方法。
翻译整理 Watermelon 前言 很多投资者经常讨论股价的预测，基本面的消息等等。当我们在说这些的时候，其实，这些（我把它们归结为算法）算法的核心就是触发识别并采取适当的措施：短线或者长线。但是我们想在这两种情况下都赚钱。 今天编辑部为大家带来一个交易策略，将触发因素作为开仓交易策略的初始条件，在下一个交易日开盘的股票投入资金。目标是找到最有利的持仓期。 投资组合 该策略可以使用任何NN资产组合进行回溯测试。 为了简单起见，我们使用10个股票的随机子集作为当前道琼斯指数的一部分： 我们从Goo
Redis 利用了多路 I/O 复用机制，处理客户端请求时，不会阻塞主线程；Redis 单纯执行（大多数指令）一个指令不到 1 微秒，如此，单核 CPU 一秒就能处理 1 百万个指令（大概对应着几十万个请求吧），用不着实现多线程（网络才是瓶颈）。
可以看到，当前节点内存碎片率为226893824/209522728≈1.08，使用的内存分配器是jemalloc。
继续我们的配置文件的学习，上回我们已经学习完了整个 Redis 配置文件的前半部分，今天我们就向后半部分进发。这一部分的内容说实话有更多的内容是更偏门的，都不知道是干嘛用的。还是那句话，本着了解的态度，死磕也要过一遍，以后万一哪天用到了，再详细深入的研究也不迟。
之前的文章中：Pytorch拓展进阶(一)：Pytorch结合C以及Cuda语言。我们简单说明了如何简单利用C语言去拓展Pytorch并且利用编写底层的.cu语言。这篇文章我们说明如何利用C++和Cuda去拓展Pytorch，同样实现我们的自定义功能。
numa是控制cpu分配内存的控制手段，比如8核cpu 64G内存，每个核心分为8个核心的内存大家就不会争抢资源了，那为什么要关闭numa呢？
内存是计算机的重要资源，虽然今天大多数的服务对内存的需求都没有那么高，但是数据库以及 Hadoop 全家桶这些服务却是消耗内存的大户，它们在生产环境动辄占用 GB 和 TB 量级的内存来提升计算的速度，Linux 操作系统为了更好、更快地管理这些内存并降低开销引入了很多策略，我们今天要介绍的是 HugePages，也就是大页[^1]。
TiDB集群上线运行一段时间，近期巡检的时候发现一个问题，集群中TiKV节点内存占用比较高，尤其在导入数据的时候，节点的内存会更高
关系图谱（点击看大图）： 部分名词： 名词 全写 解释 备注 DPDK Data Plane Development Kit 数据平面开发套件或叫数据平面开发工具集 Intel开源的快速数据包处
因为需要redis的配置文件，这里最好还是去redis的官方去下载一个redis使用里面的配置文件即可
前置知识学习补充 Redis数据库基础入门介绍与安装 - https://blog.weiyigeek.top/2019/4-17-49.html Redis数据库基础数据类型介绍与使用 - https://blog.weiyigeek.top/2020/5-17-50.html Redis基础运维之原理介绍和主从配置 - https://blog.weiyigeek.top/2019/4-17-97.html Redis基础运维之哨兵和集群安装配置 - https://blog.weiyigeek.top/2019/4-17-576.html Redis基础运维之在K8S中的安装与配置 - https://blog.weiyigeek.top/2019/4-17-524.html Redis数据库性能测试及优化配置 - https://blog.weiyigeek.top/2019/4-17-527.html Redis数据库容灾备份企业实战 - https://blog.weiyigeek.top/2019/4-17-51.html Redis数据库客户端操作实践及入坑出坑 - https://blog.weiyigeek.top/2019/4-17-577.html
Redis 是一个遵循 BSD 许可的开源软件，是一个内存型数据结构存储，可以用作为数据库，缓存和消息中间件
MySQL中的存储引擎是插件式的，当然主流默认的是InnoDB，而且InnoDB存储引擎会随着MySQL官方的搭理投入会越来越火。有了MGR,还有InnoDB Cluster,其实听起来很炫彩，本质上InnoDB Cluster就是三大件（MySQL Shell,MySQL Router,MGR） 一直以来留给其他数据库的空间相对来说很小，比如MyISAM会在MySQL 8.0版本退出历史舞台，memory存储引擎也会逐步被替代，还有些存储引擎，自身发展的过程中也被革命掉了，比如falcon,还有些存储引擎
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
