先来认识 CPU 的架构，只有理解了 CPU 的 架构，才能更好地理解 CPU 是如何读写数据的，对于现代 CPU 的架构图如下：
Linux释放内存的命令： sync echo 1 > /proc/sys/vm/drop_caches
drop_caches的值可以是0-3之间的数字，代表不同的含义： 0：不释放（系统默认值） 1：释放页缓存 2：释放dentries和inodes 3：释放所有缓存
很久没有在windows上配过node, 记得以前node环境变量是要加 NODE_PATH 到用户变量，再在系统变量引入NODE_PATH的，而npm install的全局包目录会存放在C:/Users[用户]/administrator[你的计算机名字]/AppData/Roaming/npm目录下，而现在貌似有更高级的做法！
在Linux系统下，我们一般不需要去释放内存，因为系统已经将内存管理的很好。但是凡事也有例外，有的时候内存会被缓存占用掉，导致系统使用SWAP空间影响性能，例如当你在Linux下频繁存取文件后,物理内存会很快被用光,当程序结束后,内存不会被正常释放,而是一直作为caching。，此时就需要执行释放内存(清理缓存)的操作了。
再开始这个问题之前，我们先的准备一下环境， mysql 8.027 8G 内存 SSD 磁盘 4核心CPU 。同时通过sysbench来对系统进行测试数据的填充。
我们知道外设访问内存需要通过DMA进行数据搬移，关于cpu, cache, device, dma, memory的关系可以通过下图说明：
DMA应该多多少少知道点吧。DMA(Direct Memory Access)是指在外接可以不用CPU干预，直接把数据传输到内存的技术。这个过程中可以把CPU解放出来，可以很好的提升系统性能。那么DMA和Cache有什么关系呢？这也需要我们关注？
说这个问题是在是惭愧, 到底为什么惭愧结尾说, 事情是MYSQL 8.011 的一些机器的max_connections 经常被改为214, 而明明我们的设置的是2000的最大连接数, 但过一段时间就会被改为214.
设计的目的就是当上面提到的+buffers/cache表示的可用内存都已使用完，新的读写请求过来后，会把内存中的部分数据写入磁盘，从而把磁盘的部分空间当做虚拟内存来使用。
线上集群后端某台Web服务器例行检查时，我观察到+buffers/cache值（即Linux内存的实际使用情况）一直都是5365左右，就算停掉Nginx+FastCGI程序和其它程序也是一样，考虑到这台机器经常在使用rsync+inotify，肯定会存在着频繁存取文件的情况。而Linux系统有一个特性：在Linux下频繁存取文件时，就会占用物理内存。当程序结束时并不会自动释放被占用的内存，而是一直作为Cache存在。实际上内核结束一个程序后，它是会释放内存的，但是内核并没有立刻将这部分收集到free当中，而是存在在cached或者buffer当中，提高系统的io效率，cache和buffered的内存是由内核进行动态的配置管理，如果系统的free大小不够的时候，系统会自动释放cache buffer的内存给程序使用（因此如果是看到used很多，来手动释放内存其实是不需要的，我前面的文章及书籍其实也说明了我们应该如何观察Linux系统的实际内存使用情况，这里就不再多描述了）。
编辑说明：《Oracle性能优化与诊断案例精选》出版以来，收到很多读者的来信和评论，我们会通过连载的形式将书中内容公布出来，希望书中内容能够帮助到更多的读者朋友们。 这是我一个运营商客户的案例。其现象
此文重新发送的主要原因是，经过MONGODB 中文社区内容联席主席的指导下发现部分问题，进行修改，重新发送，修改问题的位置，已经标记成粗体。
当在Linux下频繁存取文件后，物理内存会很快被用光，当程序结束后，内存不会被正常释放，而是一直作为caching。
可以看出buff/cache占用的内存份额很大，有时候程序运行结束后，大量内存仍位于buff/cache中，有时运行程序会导致内存不足，因此需要将这部分内存释放出来。
首先需要 Python 环境，下面安装了一个 Miniconda，它会带 Python，如果已经有的话可以跳过。
linux使用page cache来缓存最近读取的文件，也有目录结构(dcache: Directory Entry Cache)缓存及inode缓存，它们都使用了LRU算法来管理这些page及dentries cache
在Linux系统中，我们经常用free命令来查看系统内存的使用状态。在一个RHEL6的系统上，free命令的显示内容大概是这样一个状态：
第一部分Mem行: total 内存总数 used 已经使用的内存数 free 空闲的内存数 shared 当前已经废弃不用 buffers Buffer 缓存内存数 cached Page 缓存内存数
在疫情期间，小编不得不待在家中远程办公。但变的是办公方式，不变的是美创运维的7*24小时不间断支持。
我告诉有朋友我一直用linux.他问我了一下我为什么linux使用的内存这么高.他讲他1G的内在free才232M.讲win xp才用200M的样子.
Buffer是用于存储数据块的临时内存区域，主要用于缓存I/O操作。当数据从磁盘或其他设备读取到内存时，首先会存储在Buffer中，以提供对这些数据的快速访问。Buffer可以看作是一个中介层，有助于优化读写性能。
今天发现突然有一台主机无缘无故死机了，于是翻看了/var/log/message日志，发现提示： echo 0 > /proc/sys/kernel/hung_task_timeout_secs;
对于全栈而言，数据库技能不可或缺，关系型数据库或者nosql，内存型数据库或者偏磁盘存储的数据库，对象存储的数据库或者图数据库……林林总总,但是第一必备技能还应该是MySQL。从LAMP的兴起，到Mariadb的出现，甚至PG的到来，熟练的MySQL技能都是大有用武之地的。
理想情况下，es应该单独在一个服务器上运行，能够使用服务器上的所有资源。为了达到上述目标，我们需要配置操作系统，来允许用户运行es并且获取比默认情况下更多的资源。
本文介绍了如何使用tslib工具进行代码编译和测试。首先，介绍了tslib工具的下载和安装过程，然后描述了如何使用tslib工具进行编译和测试。最后，给出了tslib工具的常用命令和测试数据。
1.清理前内存使用情况 free -m 2.开始清理 echo 1 > /proc/sys/vm/drop_caches 3.清理后内存使用情况 free -m 4.完成! 查看内存条数命令： dmidecode | grep -A16 "Memory Device$" ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ # sync # echo 1 > /proc/sys/vm/drop_caches echo
a). 进程使用的物理内存： find /proc/ -maxdepth 1 -iname "[0-9]*" | xargs -I{} cat {}/smaps | grep Pss: | awk '{s+=$2}END{print s}' b). slab分配占用的内存，采用slab机制主要是解决申请时候浪费page的问题，这一部分的内存并不是application 所占用的，所以要单独列出来, 可以在meminfo 中查看到其占用空间以及可回收空间大小. c). pagetable在虚拟地址到物理地址的转换中发挥着关键的作用，所以也不属于application占用的内存，属于系统所用，所以也单独列出来. 其大小随着内存的变大而变大，可以在meminfo 中找到占用的大小. d). free的内存，这一部分内存是从system的角度看，依然是free的，也就是说这一部分内存还没有被system 进行接管. e). cache/buffer内存的大小，这一部分可以在meminfo 中找到，这里主要是 application 的所使用的cache/buffer. f). 其他原因导致的内存gap, 在下面的示例中，上述所述的6种内存的总和大于实际的总内存，这是因为 shmem 是被application使用的，所以在计算进程使用的物理内存的时候，已经包含了shmem,而cache又计算了一次，因此最后的结果应该是减去SHMEM, 这样 和总内存相比，还有5497KB的gap .那么这个gap 到底应该是available的，还是算作used的，不得而知，那么因为这个gap 不大，所以对于内存的使用状况统计，我们可以暂且忽略该gap， 所以我们可以有如下的公式作为一个参考： total = free + cache + buffer + process_used_via_pss + slab + pagetables - shmem
CPU在摩尔定律的指导下以每18个月翻一番的速度在发展，然而内存和硬盘的发展速度远远不及CPU。这就造成了高性能能的内存和硬盘价格及其昂贵。然而CPU的高度运算需要高速的数据。为了解决这个问题，CPU厂商在CPU中内置了少量的高速缓存以解决I\O速度和CPU运算速度之间的不匹配问题。
PyTorch 自带很多预训练模型，在使用时会自动下载，本文记录修改下载位置的方法。 背景 PyTorch 下载预训练模型总得放个地方无可厚非，但默认路径在 Windows 中是 C:\Users\<username>\.cache ，很可能占用 C 盘几个 G 的空间，尝试修改该路径 模型加方式 当pretrained为True时，PyTorch会调用torch.utils的load_state_dict_from_url函数 load_state_dict_from_url函数最终调用torch
对于一个即将踏上“系统运维”或者更加高大尚的工作“系统调优”，如果这不跟这两哥们搞好关系了，坑的不只有内存，更坑的是你拿着调优的钱却干着随时被调的活。因为作为一个系统运维人员来说监控和优化IO性能这是最有可能你生存下来的技能，为啥呢？因为你不仅给老板省了钱，还提高了机器的工作效率。。虽然钱都进了老板兜里，但你渐渐地植入了他深深地脑海里，总有一天你比钱重要！好了闲话少扯，接下来说说这两个哥们到底是什么？
free 命令用于显示内存的使用情况，显示可用和已用物理内存和交换内存的总数，以及内核使用的缓冲区。
前言： qemu发生了crash。这种类型的问题比较少见，这里说一下这个问题的分析过程。 分析： 1，coredump 生成的coredump，一种是配置了/proc/sys/kernel/cor
一直在忙,之前一直怀疑机器中马,kswapd0这个进程4核心CPU24小时跑满单核心,简单排查无果,看了
最近一台 CentOS 服务器，发现内存无端损失了许多，free 和 ps 统计的结果相差十几个G，非常奇怪，后来Google了许久才搞明白。
编译器优化乱序和CPU执行乱序的问题可以分别使用优化屏障 (Optimization Barrier)和内存屏障 (Memory Barrier)这两个机制来解决：
2. yum -y install fontconfig 安装字体库
文章转载于：http://9388751.blog.51cto.com/9378751/1676821
nginx 进程数，建议按照cpu 数目来指定，一般为它的倍数 (如,2个四核的cpu计为8)。
tc(Traffic Control) 是linux系统中常用的来控制传输速率、模拟网络延时丢包等场景的工具，tc命令有三个主要的概念，是qdisc、class和filter，qdisc又分为classless qdisc和classful qdisc，在控制传输速度的方面大致有两种用法
Nginx(读音engine x)服务器由于性能优秀稳定、配置简单以及跨平台，被越来越多的公司和个人所采用，现已成为市场份额继Apache之后的第二大Web服务器。各大小网站论坛博客也介绍说明了Nginx从安装到优化的各种配置。
本文主要分享一个Cache一致性踩内存问题的定位过程，涉及到的知识点包括：backtrace、内存分析、efence、wrap系统函数、硬件watchpoint、DMA、Cache一致性等。
本文主要分析 Linux 系统内存统计的一些指标以及进程角度内存使用监控的一些方法。
目前大部分的操作系统和应用程序并不需要16EB( 2^64 )如此巨大的地址空间, 实现64位长的地址只会增加系统的复杂度和地址转换的成本, 带不来任何好处. 所以目前的x86-64架构CPU都遵循AMD的Canonical form, 即只有虚拟地址的最低48位才会在地址转换时被使用, 且任何虚拟地址的48位至63位必须与47位一致(sign extension). 也就是说, 总的虚拟地址空间为256TB( 2^48 ）
释放 reclaimable slab ，包括dentries and inodes cache
项目的扩容申请了一台机器，到手之后看一下机器的指标，看到内存使用情况是这样的。 1、查看内存 free $ free -h total used free shared buffers cached Mem: 125G 89G 36G 92K 212M 74G -/+ buffers/cache: 14G 111G Swap
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
云直播
