这个文件记录着比较详细的内存配置信息，使用 cat /proc/meminfo 查看。
目前市场上的虚拟化技术种类很多，例如moby(docker)、LXC、RKT等等。在带来方便应用部署和资源充分利用的好处的同时，如何监控相应Container及其内部应用进程成为运维人员不可避免遇到的新情况。UAV.Container从虚拟化技术的基础原理和Linux操作系统的内核特性出发，得到Container容器和内部进程的各维度监控数据，使无论是虚拟机或物理机运维人员，还是业务运维人员角度，都能得到合适的监控维度。
一般 Unix 系统中，用户态的程序通过malloc()调用申请内存。如果返回值是 NULL， 说明此时操作系统没有空闲内存。这种情况下，用户程序可以选择直接退出并打印异常信息或尝试进行 GC 回收内存。然而 Linux 系统总会先满足用户程序malloc请求，并分配一片虚拟内存地址。只有在程序第一次touch到这片内存时，操作系统才会分配物理内存给进程。具体我们可以看下如下demo:
目前大部分的操作系统和应用程序并不需要16EB( 2^64 )如此巨大的地址空间, 实现64位长的地址只会增加系统的复杂度和地址转换的成本, 带不来任何好处. 所以目前的x86-64架构CPU都遵循AMD的Canonical form, 即只有虚拟地址的最低48位才会在地址转换时被使用, 且任何虚拟地址的48位至63位必须与47位一致(sign extension). 也就是说, 总的虚拟地址空间为256TB( 2^48 ）
本文参考Flink1.10官方多篇文章相关知识收集、翻译、整合和内化而写成的关于Flink内存模型详解的文章，其中Job Manager、Task Manager和Client 分别是什么，各自之间的运行关系怎样，任务运行过程中所使用任务槽和资源情况的内存模型构成详解，内存设置需要配置哪些参数，参数功能描述等。暂时不熟悉Flink相关概念的童鞋自觉查阅笔者以往分享关于Flink术语基本概念的文章链接：Flink优化器与源码解析系列--Flink相关基本概念。
说到监控CPU，目前主要是监控CPU的使用率，以及每一个进程占用CPU资源，Linux系统中主要使用 top、vmstat、pstree 三个命令。
top命令是我们在日常工作中用的比较多的一个，学会使用top，就相当于有了一把趁手的兵器，上可九天揽月，下可五洋捉鳖。
k8s kubectl top命令和contained内部 ps 看到的进程内存占用不一致。下午的时候，我被这个问题问倒了。具体如图
那么如果设置了 -yjm 1024 ，JobManager的JVM的堆内存大小是多少呢？
我们知道，java进程中的线程，是直接映射到服务的线程上，当创建的线程过多时，创建线程会失败，现象如下:
任何进程都与文件关联；我们会用到lsof工具（list opened files），作用是列举系统中已经被打开的文件。在linux环境中，任何事物都是文件，设备是文件，目录是文件，甚至sockets也是文件。用好lsof命令，对日常的linux管理非常有帮助
1. top命令的显示 在这个例子中，它将显示如下信息tasks,memory,cpu和swap.按 q 退出窗口。 # top 2. 用 -O（大写字母O）排序。 按 （Shift+O) 通过字段字母对字段进行排序，例如按 a 用 PID 对进程进行排序的字母 (Process ID）。 使用top对进程 ID 进行排序 键入任意键以返回到已排序的主窗口PID顺序如下图所示。按 q 退出退出窗口。 排序进程 ID 3. 显示特定用户进程 使用带有u选项的top命令将显示特定User过程细节。 # top
Redis 是一种内存数据库，将数据保存在内存中，读写效率要比传统的将数据保存在磁盘上的数据库要快很多。所以，监控 Redis 的内存消耗并了解 Redis 内存模型对高效并长期稳定使用 Redis 至关重要。
atop就是一款用于监控Linux系统资源与进程的工具，它以一定的频率记录系统的运行状态，所采集的数据包含系统CPU、内存、磁盘、网络的资源使用情况和进程运行情况，并能以日志文件的方式保存在磁盘中，服务器出现问题后，可获取相应的atop日志文件进行分析。
线上问题不同于开发期间的 bug，与运行时环境、压力、并发情况、具体的业务相关。对于线上的问题利用线上环境可用的工具，收集必要信息 对定位问题十分重要。
Java常见线上问题总结绝⼤多数Java线上问题从表象来看通常可以归纳为4个方面：CPU、内存、磁盘、网络。比如，应用上线后突然CPU使用率99%、内存泄漏、STW时间过长，这些问题通常可以分为两大类：系统异常 （CPU占用率过高、磁盘使用率100%、系统可用内存低等）业务异常 （服务运⾏⼀段时间⾃动退出、服务间调⽤时间过⻓、多线程并发异常、死锁等）1.如何去定位问题解决问题的第⼀步是定位问题，排查手段⼀般包括以下⼏项，也可以将此理解为排查顺序：业务⽇志分析排查APM分析排查物理环境排查应⽤服务排查云⼚商或
Flink 使用内存 = 框架堆内和堆外内存 + Task堆内和堆外内存 + 网络缓冲内存 + 管理内存。
Apache Flink通过严格控制其各种组件的内存使用，在JVM之上提供高效的工作负载。
自从写 Flink 系列文章，收到了太多读者的私信，希望我不断更新完善 Flink 专栏，为此，土哥还专门创建了一个文档，用来记录粉丝和读者在使用 Flink 组件时遇到的典型问题。
关键词：VSS、RSS、PSS、USS、_mapcount、pte_present、mem_size_stats。
先来看一下官网上对flink内存设置的介绍。Flink JVM 进程的进程总内存（Total Process Memory）包含了由 Flink 应用使用的内存（Flink 总内存）以及由运行 Flink 的 JVM 使用的内存。Flink 总内存（Total Flink Memory）包括 JVM 堆内存（Heap Memory）和堆外内存（Off-Heap Memory）。其中堆外内存包括直接内存（Direct Memory）和本地内存（Native Memory）。
性能压测场景 1、本次需要对查询接口进行100、200、500并发逐渐递增方式进行性能压测 2、在压测过程中，100、200并发响应时间、吞吐量、报错率为0，满足性能需求 3、当并发用户为500时，报错率达到22%，此时经过监控服务器，发现服务器cpu、内存、硬盘、网络、应用服务gc情况未出现异常，满足指标 4、经过排查，本次应用服务使用的是Dubbo服务，通过修改jmeter断言，返回响应结果提示threadpool is exhausted ,detail msg:Thread poo
上一周我有幸观看了高级架构师李国讲师的直播，内容是关于 Java 内存问题排查和解决。
在公司内部，我负责帮助研究院的小伙伴搭建机器学习web服务，研究院的小伙伴提供一个机器学习本地接口，我负责提供一个对外服务的HTTP接口。
平常处理服务器的问题遇到的最多的是负载高了，内存高了，io高了等问题，这里最明显的表现就是相关的监控指标了，对于诊断这种问题起到事半功倍的效果。
Redis子进程负责AOF或者RDB文件的重写，它的运行过程主要涉及CPU、内存、硬盘三部分的消耗
系统内存是硬件系统中必不可少的部分，定时查看系统内存资源运行情况，可以帮助我们及时发现内存资源是否存在异常占用，确保业务的稳定运行。
说明：sar -P ALL > aaa.txt 重定向输出内容到文件 aaa.txt
简单来说，AOF 重写机制就是在重写时，Redis 根据数据库的现状创建一个新的 AOF 文件，也就是说，读取数据库中的所有键值对，然后对每一个键值对用一条命令记录它的写入。
《研发日记》这个系列的诞生初衷，是希望分享 AutoMQ 版本迭代中我们的研发故事，其中会包括技术调研、问题诊断、性能优化等内容。如果你也对 AutoMQ 背后的技术和进展感兴趣的话，欢迎关注我们。
任何进程都与文件关联；我们会用到lsof工具（list opened files），作用是列举系统中已经被打开的文件。在linux环境中，任何事物都是文件，设备是文件，目录是文件，甚至sockets也是文件。用好lsof命令，对日常的linux管理非常有帮助。
管理 Kubernetes Pod 中运行的 Java 进程的内存使用情况比人们想象的更具挑战性。即使使用正确的 JVM 内存配置，仍然可能会出现OOMKilled问题，您想知道为什么吗？
大概在十多年前，我当时还是一个产品经理。由于一些工作的原因，需要向运维工程师学习一些linux常用命令。当使用linux ps这个十分常用的命令时，遇到了一个小小的疑惑。有些工程师推荐使用ps aux的命令组合，有些工程师推荐使用ps -aux的命令组合，从输出结果上来看似乎也没有什么不同。考虑到如常用的ls -l命令在内，很多linux命令选项前都要加上一个短横线，这么来看似乎ps -axu是正确的。但是一些早期的linux版本，在执行ps -axu时又会报出如下错误Warning: bad syntax，而ps aux却没有这样的报错信息，这么看来似乎ps aux又是正确的。查阅市面上的一些linux书籍，在介绍linux ps命令示例时，有些说用ps aux，而有些又说用ps -axu。实在是让我这个初学者摸不着头脑。
说明 由于 PHP 语言不支持多线程，因此 Swoole 使用多进程模式，在多进程模式下存在进程内存隔离，在工作进程内修改 global 全局变量和超全局变量时，在其他进程是无效的。 对应的解决方案有： 1. 使用Redis数据库、关系型数据库Mysql 2. 内存文件/dev/shm 首先数据库的操作都牵扯到IOD等待时间，因此推荐使用Table
进程启动后，在 jemalloc 载入的时候会调用 jemalloc_constructor 执行一些初始化操作。这里利用了编译器的一些特殊支持，让函数在库加载的时候就执行了，有兴趣的可以根据代码看看 jemalloc_constructor 做了些什么。
$ZSTORAGE包含JOB的进程私有内存的最大内存量(以KB为单位)。此内存可用于局部变量、堆栈和其他表。此内存限制不包括例程目标代码的空间。此内存根据需要分配给进程，例如在分配数组时。
我们一般通过两个工具 pmap 还有 jcmd 中的 VM.native_memory 命令去查看 Java 进程内存占用，由于 pmap 命令有点复杂而且很多内存映射是 anon 的，这里采用 jcmd 中的 VM.native_memory 命令，去看一下 JVM 内存的每一部分。
(以Flink 1.10为蓝本，Flink 1.10对之前的Flink版本的内存模型做了大量优化)
C/C++程序为编译后的二进制文件，运行时载入内存，运行时内存分布由代码段、初始化数据段、未初始化数据段、堆和栈构成，如果程序使用了内存映射文件（比如共享库、共享文件），那么包含映射段。Linux环境程序典型的内存布局如图1-5所示。
前段时间，由于太多的因素造成redis故障, 负面影响较大。复盘后决定将内存超出内存一半就需要告警，便于运维人员及时介入处理。 网上这种redis规划内存预留一半的文章汗牛充栋(https://cloud.tencent.com/developer/article/1095192)。真实的情况下，真的需要预留下一半的内存吗？ 搞清楚这个问题，需要弄清楚2个事情: 1. Redis bgsave/AOF重写的运行机制。 2. Linux下的进程内存分布以及redis内存管理机制。 先说问题1: 1.redis跟内存相关的运行机制莫过于rdb持久化/AOF重写/内存剔除策略(高版本redis还存在着内存碎片整理的配置选项), 其中AOF重写和rdb持久化都属于fork子进程来完成的。本次就以rdb持久化为例，rdb的持久化可以由持久化的配置策略或者命令行bgsave或者主从全同步触发。redis在做bgsave的时候，fork出子进程来做bgsave。具体的过程如下: rdbSaveBackground()中fork子进程 ---> rdbSave() ---> rdbSaveRio()。fork后子进程拥有和父进程一模一样的进程空间，虽然采用了COW机制(父子进程的虚拟内存指向相同的物理page)，但是ps或者top命令中的RSS显示的值都会算成自己进程所占的物理内存，这个可能是很多运维同学/DBA同学经常可以眼见的现象，恐怕这个就是潜意识里需要内存预留一半的重要因素。
看到这张图的同学，千万不要到处分享。我们仅限于小范围讨论，因为这张图威力很大，是我花了10年时间才画出来的！
Java 凭借着自身活跃的开源社区和完善的生态优势，在过去的二十几年一直是最受欢迎的编程语言之一。步入云原生时代，蓬勃发展的云原生技术释放云计算红利，推动业务进行云原生化改造，加速企业数字化转型。
从操作系统的角度来说，内存就是一块数据存储区域，是可被操作系统调度的资源。在多任务（进程）的操作系统中，内存管理尤为重要，操作系统需要为每一个进程合理的分配内存资源。所以可以从操作系统对内存分配和回收两方面来理解内存管理机制。
可以从以下几个方面监控CPU的信息： （1）中断； （2）上下文切换； （3）可运行队列； （4）CPU 利用率。
Java 语言是当前互联网应用最为广泛的语言，作为一名 Java 程序猿，当业务相对比较稳定之后平常工作除了 coding 之外，大部分时间（70%~80%）是会用来排查突发或者周期性的线上问题。由于业务应用 bug（本身或引入第三方库）、内外部环境、底层硬件问题等原因，Java线上服务出现故障/问题几乎不可避免。例如，常见的现象包括部分请求超时、用户明显感受到系统发生卡顿等等。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
云直播
