监测数据库的健康和行为：有哪些重要指标？
对数据库的监测可能过于困难或者没有找到关键点。本文将讲述如何正确的监测数据库。我们没有对数据库讨论过多少。在这个充满监测仪器的时代，我们监测我们的应用程序、基础设施、甚至我们的用户，但有时忘记我们的数据库也值得被监测。这很大程度是因为数据库表现的很好，以至于我们单纯地信任它能把任务完成的很好。信任固然重要，但能够证明它的表现确实如我们所期待的那样就更好了。为什么监测你的数据库？监测数据库的原因有很多，其中大多数原因与监测系统的任何其他部分的原因相同：了解应用程序的各个组件中发生的什么，会让你成为更了解情况的，能够做出明智决策的开发人员。更具体地说，数据库是系统健康和行为的重要标志。数据库中的异常行为能够指出应用程序中出现问题的区域。另外，当应用程序中有异常行为时，你可以利用数据库的指标来迅速完成排除故障的过程。问题最轻微的调查揭示了监测数据库的一个问题：数据库有很多指标。说“很多”只是轻描淡写，如果你是 史高治 Scrooge McDuck （LCTT 译注：史高治，唐老鸭的舅舅，以一毛不拔著称），你不会放过任何一个可用的指标。如果这是 摔角狂热 Wrestlemania 比赛，那么指标就是折叠椅。监测所有指标似乎并不实用，那么你如何决定要监测哪些指标？解决方案开始监测数据库的最好方式是认识一些基础的数据库指标。这些指标为理解数据库的行为创造了良好的开端。吞吐量：数据库做了多少？开始检测数据库的最好方法是跟踪它所接到请求的数量。我们对数据库有较高期望；期望它能稳定的存储数据，并处理我们抛给它的所有查询，这些查询可能是一天一次大规模查询，或者是来自用户一天到晚的数百万次查询。吞吐量可以告诉我们数据库是否如我们期望的那样工作。你也可以将请求按照类型（读、写、服务器端、客户端等）分组，以开始分析流量。执行时间：数据库完成工作需要多长时间？这个指标看起来很明显，但往往被忽视了。你不仅想知道数据库收到了多少请求，还想知道数据库在每个请求上花费了多长时间。 然而，参考上下文来讨论执行时间非常重要：像 InfluxDB 这样的时间序列数据库中的慢与像 MySQL 这样的关系型数据库中的慢不一样。InfluxDB 中的慢可能意味着毫秒，而 MySQL 的 SLOW_QUERY 变量的默认值是 10 秒。监测执行时间和提高执行时间不一样，所以如果你的应用程序中有其他问题需要修复，那么请注意在优化上花费时间的诱惑。并发性：数据库同时做了多少工作？一旦你知道数据库正在处理多少请求以及每个请求需要多长时间，你就需要添加一层复杂性以开始从这些指标中获得实际值。如果数据库接收到十个请求，并且每个请求需要十秒钟来完成，那么数据库是忙碌了 100 秒、10 秒，还是介于两者之间？并发任务的数量改变了数据库资源的使用方式。当你考虑连接和线程的数量等问题时，你将开始对数据库指标有更全面的了解。并发性还能影响延迟，这不仅包括任务完成所需的时间（执行时间），还包括任务在处理之前需要等待的时间。利用率：数据库繁忙的时间百分比是多少？利用率是由吞吐量、执行时间和并发性的峰值所确定的数据库可用的频率，或者数据库太忙而不能响应请求的频率。该指标对于确定数据库的整体健康和性能特别有用。如果只能在 80% 的时间内响应请求，则可以重新分配资源、进行优化工作，或者进行更改以更接近高可用性。好消息监测和分析似乎非常困难，特别是因为我们大多数人不是数据库专家，我们可能没有时间去理解这些指标。但好消息是，大部分的工作已经为我们做好了。许多数据库都有一个内部性能数据库（Postgres：pg_stats、CouchDB：Runtime_Statistics、InfluxDB：_internal 等），数据库工程师设计该数据库来监测与该特定数据库有关的指标。你可以看到像慢速查询的数量一样广泛的内容，或者像数据库中每个事件的平均微秒一样详细的内容。结论数据库创建了足够的指标以使我们需要长时间研究，虽然内部性能数据库充满了有用的信息，但并不总是使你清楚应该关注哪些指标。从吞吐量、执行时间、并发性和利用率开始，它们为你提供了足够的信息，使你可以开始了解你的数据库中的情况。你在监视你的数据库吗？你发现哪些指标有用？告诉我吧！via: https://opensource.com/article/18/10/database-metrics-matter作者：Katy Farmer 选题：lujun9972 译者：ChiZelin 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
通过学习这些关键的术语和概念来理解 Python 应用监测。当我第一次看到术语“ 计数器 counter ”和“ 计量器 gauge ”和使用颜色及标记着“平均数”和“大于 90%”的数字图表时，我的反应之一是逃避。就像我看到它们一样，我并不感兴趣，因为我不理解它们是干什么的或如何去使用。因为我的工作不需要我去注意它们，它们被我完全无视。这都是在两年以前的事了。随着我的职业发展，我希望去了解更多关于我们的网络应用程序的知识，而那个时候就是我开始去学习 监测指标 metrics 的时候。我的理解监测的学习之旅共有三个阶段（到目前为止），它们是：阶段 1：什么？（王顾左右）阶段 2：没有指标，我们真的是瞎撞。阶段 3：出现不合理的指标我们该如何做？我现在处于阶段 2，我将分享到目前为止我学到了些什么。我正在向阶段 3 进发，在本文结束的位置我提供了一些我正在使用的学习资源。我们开始吧！需要的软件在文章中讨论时用到的 demo 都可以在 我的 GitHub 仓库 中找到。你需要安装 docker 和 docker-compose 才能使用它们。为什么要监测？关于监测的主要原因是：理解 正常的 和 不正常的 系统和服务的特征做容量规划、弹性伸缩有助于排错了解软件/硬件改变的效果测量响应中的系统行为变化当系统出现意外行为时发出警报指标和指标类型从我们的用途来看，一个指标就是在一个给定时间点上的某些数量的 测量 值。博客文章的总点击次数、参与讨论的总人数、在缓存系统中数据没有被找到的次数、你的网站上的已登录用户数 —— 这些都是指标的例子。它们总体上可以分为三类：计数器以你的个人博客为例。你发布一篇文章后，过一段时间后，你希望去了解有多少点击量，这是一个只会增加的数字。这就是一个 计数器 counter 指标。在你的博客文章的生命周期中，它的值从 0 开始增加。用图表来表示，一个计数器看起来应该像下面的这样：一个计数器指标总是在增加的。计量器如果你想去跟踪你的博客每天或每周的点击量，而不是基于时间的总点击量。这种指标被称为一个 计量器 gauge ，它的值可上可下。用图表来表示，一个计量器看起来应该像下面的样子：一个计量器指标可以增加或减少。一个计量器的值在某些时间窗口内通常有一个 最大值 ceiling 和<ruby最小值floor。柱状图和计时器 柱状图 histogram （在 Prometheus 中这么叫它）或 计时器 timer （在 StatsD 中这么叫它）是一个跟踪 已采样的观测结果 的指标。不像一个计数器类或计量器类指标，柱状图指标的值并不是显示为上或下的样式。我知道这可能并没有太多的意义，并且可能和一个计量器图看上去没有什么不同。它们的不同之处在于，你期望使用柱状图数据来做什么，而不是与一个计量器图做比较。因此，监测系统需要知道那个指标是一个柱状图类型，它允许你去做哪些事情。一个柱状图指标可以增加或减少。Demo 1：计算和报告指标Demo 1 是使用 Flask 框架写的一个基本的 web 应用程序。它演示了我们如何去 计算 和 报告 指标。在 src 目录中有 app.py 和 src/helpers/middleware.py 应用程序，包含以下内容：from flask import request import csv import time def start_timer(): request.start_time = time.time() def stop_timer(response): # convert this into milliseconds for statsd resp_time = (time.time() - request.start_time)*1000 with open('metrics.csv', 'a', newline='') as f: csvwriter = csv.writer(f) csvwriter.writerow([str(int(time.time())), str(resp_time)]) return response def setup_metrics(app): app.before_request(start_timer) app.after_request(stop_timer)当在应用程序中调用 setup_metrics() 时，它配置在一个请求被处理之前调用 start_timer() 函数，然后在该请求处理之后、响应发送之前调用 stop_timer() 函数。在上面的函数中，我们写了时间戳并用它来计算处理请求所花费的时间。当我们在 demo1 目录中运行 docker-compose up，它会启动这个 web 应用程序，然后在一个客户端容器中可以生成一些对 web 应用程序的请求。你将会看到创建了一个 src/metrics.csv 文件，它有两个字段：timestamp 和 request_latency。通过查看这个文件，我们可以推断出两件事情：生成了很多数据没有观测到任何与指标相关的特征没有观测到与指标相关的特征，我们就不能说这个指标与哪个 HTTP 端点有关联，或这个指标是由哪个应用程序的节点所生成的。因此，我们需要使用合适的元数据去限定每个观测指标。《Statistics 101》（LCTT 译注：这是一本统计学入门教材的名字）假如我们回到高中数学，我们应该回忆起一些统计术语，虽然不太确定，但应该包括平均数、中位数、百分位和柱状图。我们来简要地回顾一下它们，不用去管它们的用法，就像是在上高中一样。平均数 平均数 mean ，即一系列数字的平均值，是将数字汇总然后除以列表的个数。3、2 和 10 的平均数是 (3+2+10)/3 = 5。中位数 中位数 median 是另一种类型的平均，但它的计算方式不同；它是列表从小到大排序（反之亦然）后取列表的中间数字。以我们上面的列表中（2、3、10），中位数是 3。计算并不是非常直观，它取决于列表中数字的个数。百分位 百分位 percentile 是指那个百（千）分比数字低于我们给定的百分数的程度。在一些场景中，它是指这个测量值低于我们数据的百（千）分比数字的程度。比如，上面列表中 95% 是 9.29999。百分位的测量范围是 0 到 100（不包括）。0% 是一组数字的最小分数。你可能会想到它的中位数是 50%，它的结果是 3。一些监测系统将百分位称为 upper_X，其中 X 就是百分位；upper 90 指的是在 90% 的位置的值。分位数“q-分位数”是将有 N 个数的集合等分为 qN 级。q 的取值范围为 0 到 1（全部都包括）。当 q 取值为 0.5 时，值就是中位数。（ 分位数 quantile ）和百分位数的关系是，分位数值 q 等于 100 百分位值。柱状图<ruby柱状图histogram这个指标，我们前面学习过，它是监测系统中一个实现细节。在统计学中，一个柱状图是一个将数据分组为 桶 的图表。我们来考虑一个人为的不同示例：阅读你的博客的人的年龄。如果你有一些这样的数据，并想将它进行大致的分组，绘制成的柱状图将看起来像下面的这样：累积柱状图一个 累积柱状图 cumulative histogram 也是一个柱状图，它的每个桶的数包含前一个桶的数，因此命名为累积。将上面的数据集做成累积柱状图后，看起来应该是这样的：我们为什么需要做统计？在上面的 Demo 1 中，我们注意到在我们报告指标时，这里生成了许多数据。当我们将它们用于指标时我们需要做统计，因为它们实在是太多了。我们需要的是整体行为，我们没法去处理单个值。我们预期展现出来的值的行为应该是代表我们观察的系统的行为。Demo 2：在指标上增加特征在我们上面的的 Demo 1 应用程序中，当我们计算和报告一个请求的延迟时，它指向了一个由一些特征 唯一标识的特定请求。下面是其中一些：HTTP 端点HTTP 方法运行它的主机/节点的标识符如果我们将这些特征附加到要观察的指标上，每个指标将有更多的内容。我们来解释一下 Demo 2 中添加到我们的指标上的特征。在写入指标时，src/helpers/middleware.py 文件将在 CSV 文件中写入多个列：node_ids = ['10.0.1.1', '10.1.3.4'] def start_timer(): request.start_time = time.time() def stop_timer(response): # convert this into milliseconds for statsd resp_time = (time.time() - request.start_time)*1000 node_id = node_ids[random.choice(range(len(node_ids)))] with open('metrics.csv', 'a', newline='') as f: csvwriter = csv.writer(f) csvwriter.writerow([ str(int(time.time())), 'webapp1', node_id, request.endpoint, request.method, str(response.status_code), str(resp_time) ]) return response因为这只是一个演示，在报告指标时，我们将随意的报告一些随机 IP 作为节点的 ID。当我们在 demo2 目录下运行 docker-compose up 时，我们的结果将是一个有多个列的 CSV 文件。用 pandas 分析指标我们将使用 pandas 去分析这个 CSV 文件。运行 docker-compose up 将打印出一个 URL，我们将使用它来打开一个 Jupyter 会话。一旦我们上传 Analysis.ipynb notebook 到会话中，我们就可以将 CSV 文件读入到一个 pandas 数据帧 DataFrame 中：import pandas as pd metrics = pd.read_csv('/data/metrics.csv', index_col=0)index_col 表明我们要指定时间戳作为索引。因为每个特征我们都要在数据帧中添加一个列，因此我们可以基于这些列进行分组和聚合：import numpy as np metrics.groupby(['node_id', 'http_status']).latency.aggregate(np.percentile, 99.999)更多内容请参考 Jupyter notebook 在数据上的分析示例。我应该监测什么？一个软件系统有许多的变量，这些变量的值在它的生命周期中不停地发生变化。软件是运行在某种操作系统上的，而操作系统同时也在不停地变化。在我看来，当某些东西出错时，你所拥有的数据越多越好。我建议去监测的关键操作系统指标有：CPU 使用系统内存使用文件描述符使用磁盘使用还需要监测的其它关键指标根据你的软件应用程序不同而不同。网络应用程序如果你的软件是一个监听客户端请求和为它提供服务的网络应用程序，需要测量的关键指标还有：入站请求数（计数器）未处理的错误（计数器）请求延迟（柱状图/计时器）排队时间，如果在你的应用程序中有队列（柱状图/计时器）队列大小，如果在你的应用程序中有队列（计量器）工作进程/线程用量（计量器）如果你的网络应用程序在一个客户端请求的环境中向其它服务发送请求，那么它应该有一个指标去记录它与那个服务之间的通讯行为。需要监测的关键指标包括请求数、请求延迟、和响应状态。HTTP web 应用程序后端HTTP 应用程序应该监测上面所列出的全部指标。除此之外，还应该按 HTTP 状态代码分组监测所有非 200 的 HTTP 状态代码的大致数据。如果你的 web 应用程序有用户注册和登录功能，同时也应该为这个功能设置指标。长时间运行的进程长时间运行的进程如 Rabbit MQ 消费者或任务队列的工作进程，虽然它们不是网络服务，它们以选取一个任务并处理它的工作模型来运行。因此，我们应该监测请求的进程数和这些进程的请求延迟。不管是什么类型的应用程序，都有指标与合适的元数据相关联。将监测集成到一个 Python 应用程序中将监测集成到 Python 应用程序中需要涉及到两个组件：更新你的应用程序去计算和报告指标配置一个监测基础设施来容纳应用程序的指标，并允许去查询它们下面是记录和报告指标的基本思路：def work(): requests += 1 # report counter start_time = time.time() # < do the work > # calculate and report latency work_latency = time.time() - start_time ...考虑到上面的模式，我们经常使用修饰符、内容管理器、中间件（对于网络应用程序）所带来的好处去计算和报告指标。在 Demo 1 和 Demo 2 中，我们在一个 Flask 应用程序中使用修饰符。指标报告时的拉取和推送模型大体来说，在一个 Python 应用程序中报告指标有两种模式。在 拉取 模型中，监测系统在一个预定义的 HTTP 端点上“刮取”应用程序。在推送 模型中，应用程序发送数据到监测系统。工作在 拉取 模型中的监测系统的一个例子是 Prometheus。而 StatsD 是 推送 模型的一个例子。集成 StatsD将 StatsD 集成到一个 Python 应用程序中，我们将使用 StatsD Python 客户端，然后更新我们的指标报告部分的代码，调用合适的库去推送数据到 StatsD 中。首先，我们需要去创建一个客户端实例：statsd = statsd.StatsClient(host='statsd', port=8125, prefix='webapp1')prefix 关键字参数将为通过这个客户端报告的所有指标添加一个指定的前缀。一旦我们有了客户端，我们可以使用如下的代码为一个计时器报告值：statsd.timing(key, resp_time)增加计数器：statsd.incr(key)将指标关联到元数据上，一个键的定义为：metadata1.metadata2.metric，其中每个 metadataX 是一个可以进行聚合和分组的字段。这个演示应用程序 StatsD 是将 statsd 与 Python Flask 应用程序集成的一个完整示例。集成 Prometheus要使用 Prometheus 监测系统，我们使用 Promethius Python 客户端。我们将首先去创建有关的指标类对象：REQUEST_LATENCY = Histogram('request_latency_seconds', 'Request latency', ['app_name', 'endpoint'] )在上面的语句中的第三个参数是与这个指标相关的标识符。这些标识符是由与单个指标值相关联的元数据定义的。去记录一个特定的观测指标：REQUEST_LATENCY.labels('webapp', request.path).observe(resp_time)下一步是在我们的应用程序中定义一个 Prometheus 能够刮取的 HTTP 端点。这通常是一个被称为 /metrics 的端点：@app.route('/metrics') def metrics(): return Response(prometheus_client.generate_latest(), mimetype=CONTENT_TYPE_LATEST)这个演示应用程序 Prometheus 是将 prometheus 与 Python Flask 应用程序集成的一个完整示例。哪个更好：StatsD 还是 Prometheus？本能地想到的下一个问题便是：我应该使用 StatsD 还是 Prometheus？关于这个主题我写了几篇文章，你可能发现它们对你很有帮助：使用 Prometheus 监测多进程 Python 应用的方式使用 Prometheus 监测你的同步 Python 应用使用 Prometheus 监测你的异步 Python 应用指标的使用方式我们已经学习了一些关于为什么要在我们的应用程序上配置监测的原因，而现在我们来更深入地研究其中的两个用法：报警和自动扩展。使用指标进行报警指标的一个关键用途是创建警报。例如，假如过去的五分钟，你的 HTTP 500 的数量持续增加，你可能希望给相关的人发送一封电子邮件或页面提示。对于配置警报做什么取决于我们的监测设置。对于 Prometheus 我们可以使用 Alertmanager，而对于 StatsD，我们使用 Nagios。使用指标进行自动扩展在一个云基础设施中，如果我们当前的基础设施供应过量或供应不足，通过指标不仅可以让我们知道，还可以帮我们实现一个自动伸缩的策略。例如，如果在过去的五分钟里，在我们服务器上的工作进程使用率达到 90%，我们可以水平扩展。我们如何去扩展取决于云基础设施。AWS 的自动扩展，缺省情况下，扩展策略是基于系统的 CPU 使用率、网络流量、以及其它因素。然而，让基础设施伸缩的应用程序指标，我们必须发布 自定义的 CloudWatch 指标。在多服务架构中的应用程序监测当我们超越一个单应用程序架构时，比如当客户端的请求在响应被发回之前，能够触发调用多个服务，就需要从我们的指标中获取更多的信息。我们需要一个统一的延迟视图指标，这样我们就能够知道响应这个请求时每个服务花费了多少时间。这可以用 分布式跟踪 来实现。你可以在我的博客文章 《在你的 Python 应用程序中通过 Zipkin 引入分布式跟踪》 中看到在 Python 中进行分布式跟踪的示例。划重点总之，你需要记住以下几点：理解你的监测系统中指标类型的含义知道监测系统需要的你的数据的测量单位监测你的应用程序中的大多数关键组件监测你的应用程序在它的大多数关键阶段的行为以上要点是假设你不去管理你的监测系统。如果管理你的监测系统是你的工作的一部分，那么你还要考虑更多的问题！其它资源以下是我在我的监测学习过程中找到的一些非常有用的资源：综合的监测分布式系统观测和监测最佳实践谁想使用秒？StatsD/GraphiteStatsD 指标类型PrometheusPrometheus 指标类型Prometheus 计量器如何工作？为什么用 Prometheus 累积柱形图？在 Python 中监测批量作业Prometheus：监测 SoundCloud避免犯错（即第 3 阶段的学习）在我们学习监测的基本知识时，时刻注意不要犯错误是很重要的。以下是我偶然发现的一些很有见解的资源：如何不测量延迟Prometheus 柱形图：悲伤的故事为什么平均值很讨厌，而百分位很棒对延迟的认知错误谁动了我的 99% 延迟？日志、指标和图形HdrHistogram：一个更好的延迟捕获方式想学习更多内容，参与到 PyCon Cleveland 2018 上的 Amit Saha 的讨论，Counter, gauge, upper 90—Oh my!关于作者Amit Saha — 我是一名对基础设施、监测、和工具感兴趣的软件工程师。我是“用 Python 做数学”的作者和创始人，以及 Fedora Scientific Spin 维护者。关于我的更多信息via: https://opensource.com/article/18/4/metrics-monitoring-and-python作者: Amit Saha 选题者: lujun9972 译者: qhwdw 校对: wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
Linux有问必答：如何检查Linux的内存使用状况
问题：我想要监测Linux系统的内存使用状况。有哪些可用的图形界面或者命令行工具来检查当前内存使用情况？当涉及到Linux系统性能优化的时候，物理内存是一个最重要的因素。自然的，Linux提供了丰富的选择来监测珍贵的内存资源的使用情况。不同的工具，在监测粒度（例如：全系统范围，每个进程，每个用户），接口方式（例如：图形用户界面，命令行，ncurses）或者运行模式（交互模式，批量处理模式）上都不尽相同。下面是一个可供选择的，但并不全面的图形或命令行工具列表，这些工具用来检查Linux平台中已用和可用的内存。1. /proc/meminfo一种最简单的方法是通过“/proc/meminfo”来检查内存使用状况。这个动态更新的虚拟文件事实上是诸如free，top和ps这些与内存相关的工具的信息来源。从可用/闲置物理内存数量到等待被写入缓存的数量或者已写回磁盘的数量，只要是你想要的关于内存使用的信息，“/proc/meminfo”应有尽有。特定进程的内存信息也可以通过“/proc//statm”和“/proc//status”来获取。$ cat /proc/meminfo 2. atopatop命令是用于终端环境的基于ncurses的交互式的系统和进程监测工具。它展示了动态更新的系统资源摘要（CPU, 内存, 网络, 输入/输出, 内核），并且用醒目的颜色把系统高负载的部分以警告信息标注出来。它同样提供了类似于top的线程（或用户）资源使用视图，因此系统管理员可以找到哪个进程或者用户导致的系统负载。内存统计报告包括了总计/闲置内存，缓存的/缓冲的内存和已提交的虚拟内存。$ sudo atop 3. freefree命令是一个用来获得内存使用概况的快速简单的方法，这些信息从“/proc/meminfo”获取。它提供了一个快照，用于展示总计/闲置的物理内存和系统交换区，以及已使用/闲置的内核缓冲区。$ free -h 4. GNOME System MonitorGNOME System Monitor 是一个图形界面应用，它展示了包括CPU，内存，交换区和网络在内的系统资源使用率的较近历史信息。它同时也可以提供一个带有CPU和内存使用情况的进程视图。$ gnome-system-monitor 5. htophtop命令是一个基于ncurses的交互式的进程视图，它实时展示了每个进程的内存使用情况。它可以报告所有运行中进程的常驻内存大小（RSS）、内存中程序的总大小、库大小、共享页面大小和脏页面大小。你可以横向或者纵向滚动进程列表进行查看。$ htop 6. KDE System Monitor就像GNOME桌面拥有GNOME System Monitor一样，KDE桌面也有它自己的对口应用：KDE System Monitor。这个工具的功能与GNOME版本极其相似，也就是说，它同样展示了一个关于系统资源使用情况，以及带有每个进程的CPU/内存消耗情况的实时历史记录。$ ksysguard 7. memstatmemstat工具对于识别正在消耗虚拟内存的可执行部分、进程和共享库非常有用。给出一个进程识别号，memstat即可识别出与之相关联的可执行部分、数据和共享库究竟使用了多少虚拟内存。$ memstat -p <PID> 8. nmonnmon工具是一个基于ncurses系统基准测试工具，它能够以交互方式监测CPU、内存、磁盘I/O、内核、文件系统以及网络资源。对于内存使用状况而言，它能够展示像总计/闲置内存、交换区、缓冲的/缓存的内存，虚拟内存页面换入换出的统计，所有这些都是实时的。$ nmon 9. psps命令能够实时展示每个进程的内存使用状况。内存使用报告里包括了 %MEM (物理内存使用百分比), VSZ (虚拟内存使用总量), 和 RSS (物理内存使用总量)。你可以使用“--sort”选项来对进程列表排序。例如，按照RSS降序排序：$ ps aux --sort -rss 10. smemsmem命令允许你测定不同进程和用户的物理内存使用状况，这些信息来源于“/proc”目录。它利用“按比例分配大小（PSS）”指标来精确量化Linux进程的有效内存使用情况。内存使用分析结果能够输出为柱状图或者饼图类的图形化图表。$ sudo smem --pie name -c "pss" 11. toptop命令提供了一个运行中进程的实时视图，以及特定进程的各种资源使用统计信息。与内存相关的信息包括 %MEM (内存使用率), VIRT (虚拟内存使用总量), SWAP (换出的虚拟内存使用量), CODE (分配给代码执行的物理内存数量), DATA (分配给非执行的数据的物理内存数量), RES (物理内存使用总量; CODE+DATA), 和 SHR (有可能与其他进程共享的内存数量)。你能够基于内存使用情况或者大小对进程列表进行排序。12. vmstatvmstat命令行工具显示涵盖了CPU、内存、中断和磁盘I/O在内的各种系统活动的瞬时和平均统计数据。对于内存信息而言，命令不仅仅展示了物理内存使用情况（例如总计/已使用内存和缓冲的/缓存的内存），还同样展示了虚拟内存统计数据（例如，内存页的换入/换出，虚拟内存页的换入/换出）$ vmstat -s via: http://ask.xmodulo.com/check-memory-usage-linux.html译者：Ping 校对：wxy本文由 LCTT 原创翻译，Linux中国 荣誉推出