ModelArts Standard资源监控概述 为了满足用户对资源使用的监控诉求，ModelArts Standard提供了多种监控查看方式。 方式一：通过ModelArts Standard控制台查看 您在可通过ModelArts控制台的总览页或各模块资源监控页签查看监控指标。具体涉及以下几个方面： 通过ModelArts控制台的总览页查看，具体请参见通过ModelArts控制台查看监控指标。 Standard训练作业：用户在运行训练作业时，可以查看训练任务占用的CPU、GPU或NPU资源使用情况。具体请参见训练资源监控章节。 Standard在线服务：用户将模型部署为在线服务后，可以通过监控功能查看该推理服务的CPU、内存或GPU等资源使用统计信息和模型调用次数统计，具体参见查看推理服务详情章节。 方式二：通过 AOM 查看所有监控指标 ModelArts Standard上报的所有监控指标都保存在AOM中，用户可以通过AOM服务提供的指标消费和使用的能力来进行指标消费。设置指标阈值告警、告警上报等，都可以直接在AOM控制台查看。具体参见通过AOM控制台查看ModelArts所有监控指标。 方式三：通过Grafana查看所有监控指标 当AOM的监控模板不能满足用户诉求时，用户可以使用Grafana可视化工具来查看与分析监控指标。Grafana支持灵活而又复杂多样的监控视图和模板，为用户提供基于网页仪表面板的可视化监控效果，使用户更加直观地查看到实时资源使用情况。 将Grafana的数据源配置完成后，就可以通过Grafana查看AOM保存的所有ModelArts Standard的所有指标。具体参见使用Grafana查看AOM中的监控指标。 通过Grafana插件查看AOM中的监控指标的操作流程如下： 安装配置Grafana 安装配置Grafana有在Windows上安装配置Grafana、在Linux上安装配置Grafana和在Notebook上安装配置Grafana三种方式，请您根据实际情况选择。 配置Grafana数据源 配置仪表盘查看指标数据 父主题： ModelArts Standard资源监控

操作步骤 查询所有用户的资源限额和资源实时使用情况。 1 SELECT * FROM PG_TOTAL_USER_RESOURCE_INFO; 得到的结果视图如下： username | used_memory | total_memory | used_cpu | total_cpu | used_space | total_space | used_temp_space | total_temp_space | used_spill_space | total_spill_space | read_kbytes | write_kbytes | read_counts | write_counts | read_speed | write_speed | send_speed | recv_speed -----------------------+-------------+--------------+----------+-----------+------------+-------------+-----------------+------------------+------------------+-------------------+-------------+--------------+-------------+--------------+------------+-------------+------------+------------ perfadm | 0 | 0 | 0 | 0 | 0 | -1 | 0 | -1 | 0 | -1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 usern | 0 | 17250 | 0 | 48 | 0 | -1 | 0 | -1 | 0 | -1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 (2 rows) 其中，IO资源监控字段(read_kbytes、write_kbytes、read_counts、write_counts、read_speed和write_speed)需要在GUC参数enable_user_metric_persistent开启时才有监控数据。 所查各字段说明详见PG_TOTAL_USER_RESOURCE_INFO 。 查询具体某个用户的资源限额和资源实时使用情况。 1 SELECT * FROM GS_WLM_USER_RESOURCE_INFO('username'); 查询结果如下： userid | used_memory | total_memory | used_cpu | total_cpu | used_space | total_space | used_temp_space | total_temp_space | used_spill_space | total_spill_space | read_kbytes | write_kbytes | read_counts | write_counts | read_speed | write_speed | send_speed | recv_speed --------+-------------+--------------+----------+-----------+------------+-------------+-----------------+------------------+------------------+-------------------+-------------+--------------+-------------+--------------+------------+-------------+------------+------------ 16407 | 18 | 1655 | 6 | 19 | 13787176 | -1 | 0 | -1 | 0 | -1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 (1 row) 查询所有用户的资源限额和资源历史使用情况。 1 SELECT * FROM GS_WLM_USER_RESOURCE_HISTORY; 查询结果如下： username | timestamp | used_memory | total_memory | used_cpu | total_cpu | used_space | total_space | used_temp_space | total_temp_space | used_spill_space | total_spill_space | read_kbytes | write_kbytes | read_counts | write_counts | read_speed | write_speed | send_speed | recv_speed -----------------------+-------------------------------+-------------+--------------+----------+-----------+------------+-------------+-----------------+------------------+------------------+-------------------+-------------+--------------+-------------+--------------+-------------+-------------+------------+------------ usern | 2020-01-08 22:56:06.456855+08 | 0 | 17250 | 0 | 48 | 0 | -1 | 0 | -1 | 88349078 | -1 | 45680 | 34 | 5710 | 8 | 320 | 0 | 0 | 0 userg | 2020-01-08 22:56:06.458659+08 | 0 | 15525 | 33.48 | 48 | 0 | -1 | 0 | -1 | 110169581 | -1 | 17648 | 23 | 2206 | 5 | 123 | 0 | 0 | 0 userg1 | 2020-01-08 22:56:06.460252+08 | 0 | 13972 | 33.48 | 48 | 0 | -1 | 0 | -1 | 136106277 | -1 | 17648 | 23 | 2206 | 5 | 123 | 0 | 0 | 0 对于系统表GS_WLM_USER_RESOURCE_HISTORY，仅当GUC参数enable_user_metric_persistent开启时，才会定期将视图PG_TOTAL_USER_RESOURCE_INFO中的数据保存到历史表中。 所查各字段说明详见GS_WLM_USER_RESOURCE_HISTORY。

注意事项 用户监控可以同时监控快慢车道（快车道管控简单作业，慢车道管控复杂作业）所有作业的CPU、IO和内存使用情况，不再受限于仅监控慢车道作业。 当前快车道作业内存和CPU不受控，在快车道运行作业占用资源较多情况下，可能出现已用资源大于资源限制的情况。 DN监控视图中，IO、内存和CPU显示的是本DN上资源池资源使用和资源限制信息。 CN监控视图中，IO、内存和CPU显示的是集群内所有DN资源池资源使用和资源限制的累积和。 DN每隔5s更新一次监控信息，CN每隔5s从DN收集一次用户监控信息，因为各实例单独更新/收集用户监控信息，因此各实例监控信息更新时间可能不一致。 辅助线程中每隔30s自动调用持久化函数，持久化用户监控数据，正常情况下不需要用户单独调用持久化函数持久化用户监控数据。 当用户数量较多，集群规模较大时，查询此类实时视图，因CN/DN间实时通信开销，会有一定的网络延时。 初始管理用户不进行资源监控。

操作步骤 查询所有用户的资源限额和资源实时使用情况。 1 SELECT * FROM PG_TOTAL_USER_RESOURCE_INFO; 得到的结果视图如下： username | used_memory | total_memory | used_cpu | total_cpu | used_space | total_space | used_temp_space | total_temp_space | used_spill_space | total_spill_space | read_kbytes | write_kbytes | read_counts | write_counts | read_speed | write_speed | send_speed | recv_speed -----------------------+-------------+--------------+----------+-----------+------------+-------------+-----------------+------------------+------------------+-------------------+-------------+--------------+-------------+--------------+------------+-------------+------------+------------ perfadm | 0 | 0 | 0 | 0 | 0 | -1 | 0 | -1 | 0 | -1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 usern | 0 | 17250 | 0 | 48 | 0 | -1 | 0 | -1 | 0 | -1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 (2 rows) 其中，IO资源监控字段(read_kbytes、write_kbytes、read_counts、write_counts、read_speed和write_speed)需要在GUC参数enable_user_metric_persistent开启时才有监控数据。 所查各字段说明详见PG_TOTAL_USER_RESOURCE_INFO 。 查询具体某个用户的资源限额和资源实时使用情况。 1 SELECT * FROM GS_WLM_USER_RESOURCE_INFO('username'); 查询结果如下： userid | used_memory | total_memory | used_cpu | total_cpu | used_space | total_space | used_temp_space | total_temp_space | used_spill_space | total_spill_space | read_kbytes | write_kbytes | read_counts | write_counts | read_speed | write_speed | send_speed | recv_speed --------+-------------+--------------+----------+-----------+------------+-------------+-----------------+------------------+------------------+-------------------+-------------+--------------+-------------+--------------+------------+-------------+------------+------------ 16407 | 18 | 1655 | 6 | 19 | 13787176 | -1 | 0 | -1 | 0 | -1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 (1 row) 查询所有用户的资源限额和资源历史使用情况。 1 SELECT * FROM GS_WLM_USER_RESOURCE_HISTORY; 查询结果如下： username | timestamp | used_memory | total_memory | used_cpu | total_cpu | used_space | total_space | used_temp_space | total_temp_space | used_spill_space | total_spill_space | read_kbytes | write_kbytes | read_counts | write_counts | read_speed | write_speed | send_speed | recv_speed -----------------------+-------------------------------+-------------+--------------+----------+-----------+------------+-------------+-----------------+------------------+------------------+-------------------+-------------+--------------+-------------+--------------+-------------+-------------+------------+------------ usern | 2020-01-08 22:56:06.456855+08 | 0 | 17250 | 0 | 48 | 0 | -1 | 0 | -1 | 88349078 | -1 | 45680 | 34 | 5710 | 8 | 320 | 0 | 0 | 0 userg | 2020-01-08 22:56:06.458659+08 | 0 | 15525 | 33.48 | 48 | 0 | -1 | 0 | -1 | 110169581 | -1 | 17648 | 23 | 2206 | 5 | 123 | 0 | 0 | 0 userg1 | 2020-01-08 22:56:06.460252+08 | 0 | 13972 | 33.48 | 48 | 0 | -1 | 0 | -1 | 136106277 | -1 | 17648 | 23 | 2206 | 5 | 123 | 0 | 0 | 0 对于系统表GS_WLM_USER_RESOURCE_HISTORY，仅当GUC参数enable_user_metric_persistent开启时，才会定期将视图PG_TOTAL_USER_RESOURCE_INFO中的数据保存到历史表中。 所查各字段说明详见GS_WLM_USER_RESOURCE_HISTORY。

注意事项 用户监控可以同时监控快慢车道（快车道管控简单作业，慢车道管控复杂作业）所有作业的CPU、IO和内存使用情况，不再受限于仅监控慢车道作业。 当前快车道作业内存和CPU不受控，在快车道运行作业占用资源较多情况下，可能出现已用资源大于资源限制的情况。 DN监控视图中，IO、内存和CPU显示的是本DN上资源池资源使用和资源限制信息。 CN监控视图中，IO、内存和CPU显示的是集群内所有DN资源池资源使用和资源限制的累积和。 DN每隔5s更新一次监控信息，CN每隔5s从DN收集一次用户监控信息，因为各实例单独更新/收集用户监控信息，因此各实例监控信息更新时间可能不一致。 辅助线程中每隔30s自动调用持久化函数，持久化用户监控数据，正常情况下不需要用户单独调用持久化函数持久化用户监控数据。 当用户数量较多，集群规模较大时，查询此类实时视图，因CN/DN间实时通信开销，会有一定的网络延时。 初始管理用户不进行资源监控。

简介 多租户管理框架下，用户关联资源池执行查询，用户执行查询所占用的资源将汇总至关联资源池上，通过资源池监控视图，用户可以直观的查询到所有资源池的实时资源使用情况，同时也可以通过资源池监控历史表查询资源池资源的历史使用情况。 资源池监控数据每5s更新一次，但是因为CN和DN时间差，实际监控数据更新时间可能会大于5s，正常不会超过10s。资源池监控数据每30s持久化一次，资源池监控和用户监控逻辑基本一致，因此共用GUC参数控制持久化和老化，使用GUC参数enable_user_metric_persistent控制是否进行资源池监控数据持久化，使用GUC参数user_metric_retention_time控制资源池监控数据老化。 资源池监控的资源包含：快慢车道作业运行和排队信息，CPU、内存以及逻辑IO资源监控信息。涉及的监控视图和历史表如下所示： 资源池实时运行信息监控视图(单CN)：GS_RESPOOL_RUNTIME_INFO； 资源池实时运行信息监控视图(所有CN)：PGXC_RESPOOL_RUNTIME_INFO； 资源池实时资源监控视图(单CN)：GS_RESPOOL_RESOURCE_INFO； 资源池实时资源监控视图(所有CN)：PGXC_RESPOOL_RESOURCE_INFO； 资源池历史资源监控表(单CN)：GS_RESPOOL_RESOURCE_HISTORY； 资源池历史资源监控视图(所有CN)：PGXC_RESPOOL_RESOURCE_HISTORY； 资源池监控可以同时监控快慢车道所有作业的CPU、IO和内存使用情况，不再受限于仅监控慢车道作业。 当前快车道作业内存和CPU不受控，在快车道运行作业占用资源较多情况下，可能出现已用资源大于资源限制的情况。 DN资源池监控视图中，IO、内存和CPU显示的是本DN上资源池资源使用和资源限制信息。 CN资源池监控视图中，IO、内存和CPU显示的是集群内所有DN资源池资源使用和资源限制的累积和。 DN每隔5s更新一次资源池监控信息，CN每隔5s从DN收集一次资源池监控信息，因为各实例单独更新/收集资源池监控信息，因此各实例监控信息更新时间可能不一致。 辅助线程中每隔30s自动调用持久化函数，持久化资源池监控数据，正常情况下不需要用户单独调用持久化函数持久化资源池监控数据。

操作步骤 查询资源池的作业实时运行情况。 1 SELECT * FROM GS_RESPOOL_RUNTIME_INFO; 得到的结果视图如下： 1 2 3 4 5 6 7 8 9 nodegroup | rpname | ref_count | fast_run | fast_wait | slow_run | slow_wait -----------+--------------+-----------+----------+-----------+----------+----------- vc1 | p2 | 10 | 0 | 0 | 0 | 0 vc2 | p3 | 10 | 5 | 5 | 0 | 0 vc2 | p4 | 0 | 0 | 0 | 0 | 0 vc1 | default_pool | 0 | 0 | 0 | 0 | 0 vc2 | default_pool | 0 | 0 | 0 | 0 | 0 vc1 | p1 | 20 | 5 | 5 | 3 | 7 (6 rows) 其中： ref_count为引用当前资源池信息的作业数，语句从进入管控到结束一直占用该计数； fast_run和slow_run为负载管理记账信息，只有管控(fast_limit/slow_limit大于0)时该值才有效； 该视图仅在CN上有效，持久化信息保存在GS_RESPOOL_RESOURCE_HISTORY中； 各字段说明详见GS_RESPOOL_RUNTIME_INFO。 查询资源池的资源限额和资源实时使用情况。 1 SELECT * FROM GS_RESPOOL_RESOURCE_INFO; 得到的结果视图如下： 1 2 3 4 5 6 7 8 9 nodegroup | rpname | cgroup | ref_count | fast_run | fast_wait | fast_limit | slow_run | slow_wait | slow_limit | used_cpu | cpu_limit | used_mem | estimate_mem | mem_limit |read_kbytes | write_kbytes | read_counts | write_counts | read_speed | write_speed -----------+--------------+---------------------+-----------+----------+-----------+------------+----------+-----------+------------+----------+-----------+----------+--------------+-----------+-------------+--------------+-------------+--------------+------------+------------- vc1 | p2 | DefaultClass:Rush | 10 | 0 | 0 | -1 | 0 | 0 | 10 | 9.97 | 48 | 20 | 0 | 11555 | 8 | 2880 | 1 | 360 | 1 | 589 vc2 | p3 | DefaultClass:Rush | 10 | 5 | 5 | 5 | 0 | 0 | 10 | 4.98 | 48 | 11 | 0 | 11555 | 0 | 848 | 0 | 106 | 0 | 173 vc2 | p4 | DefaultClass:Rush | 0 | 0 | 0 | -1 | 0 | 0 | 10 | 0 | 48 | 0 | 0 | 11555 | 0 | 0 | 0 | 0 | 0 | 0 vc1 | default_pool | DefaultClass:Medium | 0 | 0 | 0 | -1 | 0 | 0 | -1 | 0 | 48 | 0 | 0 | 11555 | 0 | 0 | 0 | 0 | 0 | 0 vc2 | default_pool | DefaultClass:Medium | 0 | 0 | 0 | -1 | 0 | 0 | -1 | 0 | 48 | 0 | 0 | 11555 | 0 | 0 | 0 | 0 | 0 | 0 vc1 | p1 | DefaultClass:Rush | 20 | 5 | 5 | 5 | 3 | 7 | 3 | 7.98 | 48 | 16 | 768 | 11555 | 8 | 2656 | 1 | 332 | 1 | 543 (6 rows) 该视图在CN和DN上均有效，DN上CPU、内存和IO为本DN资源消耗情况，CN上CPU、内存和IO为集群内所有DN上资源消耗的累加和； estimate_mem仅在动态负载管理情况下CN上有效，显示资源池估算内存记账情况； IO监控信息仅在enable_logical_io_statistics开启时才会记录； 各字段说明详见GS_RESPOOL_RESOURCE_INFO。 查询资源池的资源限额和资源历史使用情况。 1 SELECT * FROM GS_RESPOOL_RESOURCE_HISTORY ORDER BY timestamp DESC; 得到的结果视图如下： 1 2 3 4 5 6 7 8 9 timestamp | nodegroup | rpname | cgroup | ref_count | fast_run | fast_wait | fast_limit | slow_run | slow_wait | slow_limit | used_cpu | cpu_limit | used_mem | estimate_mem | mem_limit | read_kbytes | write_kbytes | read_counts | write_counts | read_speed | write_speed -------------------------------+--------------+--------------+---------------------+-----------+----------+-----------+------------+----------+-----------+------------+----------+-----------+----------+--------------+-----------+-------------+--------------+-------------+--------------+------------+------------- 2022-03-04 09:41:57.53739+08 | vc1 | p2 | DefaultClass:Rush | 10 | 0 | 0 | -1 | 0 | 0 | 10 | 9.97 | 48 | 20 | 0 | 11555 | 0 | 2320 | 0 | 290 | 0 | 474 2022-03-04 09:41:57.53739+08 | vc1 | p1 | DefaultClass:Rush | 20 | 5 | 5 | 5 | 3 | 7 | 3 | 7.98 | 48 | 16 | 768 | 11555 | 0 | 1896 | 0 | 237 | 0 | 387 2022-03-04 09:41:57.53739+08 | vc2 | default_pool | DefaultClass:Medium | 0 | 0 | 0 | -1 | 0 | 0 | -1 | 0 | 48 | 0 | 0 | 11555 | 0 | 0 | 0 | 0 | 0 | 0 2022-03-04 09:41:57.53739+08 | vc1 | default_pool | DefaultClass:Medium | 0 | 0 | 0 | -1 | 0 | 0 | -1 | 0 | 48 | 0 | 0 | 11555 | 0 | 0 | 0 | 0 | 0 | 0 2022-03-04 09:41:57.53739+08 | vc2 | p4 | DefaultClass:Rush | 0 | 0 | 0 | -1 | 0 | 0 | 10 | 0 | 48 | 0 | 0 | 11555 | 0 | 0 | 0 | 0 | 0 | 0 2022-03-04 09:41:57.53739+08 | vc2 | p3 | DefaultClass:Rush | 10 | 5 | 5 | 5 | 0 | 0 | 10 | 4.99 | 48 | 11 | 0 | 11555 | 0 | 880 | 0 | 110 | 0 | 180 2022-03-04 09:41:27.335234+08 | vc2 | p3 | DefaultClass:Rush | 10 | 5 | 5 | 5 | 0 | 0 | 10 | 4.98 | 48 | 11 | 0 | 11555 | 0 | 856 | 0 | 107 | 0 | 175 该监控信息来自资源池监控历史表，enable_user_metric_persistent开启时每30秒记录一次； 该表数据保存时间由GUC参数user_metric_retention_time控制； 各字段说明详见GS_RESPOOL_RESOURCE_HISTORY。

分析处理 在您采取措施处理问题前，首先需要判断影响CPU或带宽占用率高的进程是正常进程还是异常进程。不同类型的进程状态需要做不同处理。 正常进程分析处理建议 如果您的操作系统是Windows 2008/Windows 2012，请检查内存大小，建议内存配置在2GB或以上。 检查后台是否有执行Windows Update的行为。 检查杀毒软件是否正在后台执行扫描操作。 核对云服务器运行的应用程序中是否有对网络和CPU要求高的需求，如果是，建议您修改带宽。 如果 云服务器配置 已经比较高，建议考虑云服务器上应用场景的分离部署，例如将数据库和应用分开部署。 异常进程分析处理建议 如果CPU或带宽利用率高是由于病毒、木马入侵导致的，那么需要手动结束进程。建议的处理顺序如下： 使用商业版杀毒软件或安装微软安全工具Microsoft Safety Scanner，在安全模式下扫描病毒。 安装Windows最新补丁。 使用MSconfig禁用所有非微软自带服务驱动，检查问题是否再次发生，具体请参考：如何在Windows中执行干净启动。 若服务器或站点遭受DDOS攻击或CC攻击等，短期内产生大量的访问需求。 您可以登录管理控制台执行以下操作： 查看Anti-DDOS攻击是否开启，并检查防护策略是否配置合适；如未配置，请参考：设置防护策略。 查看CC防护策略是否开启，并检查防护策略是否配置合适；如未配置，请参考：配置CC防护策略。

监控IoTDA服务 单击IoTDA服务名称，可在右侧区域查看当前用户IOTDA服务下全部实例及全部实例的资源空间。 监控IoTDA服务某一实例： 单击任一实例名称，然后单击“仪表盘”页签，可查看当前实例下需要重点关注的关键资源或指标。 单击任一实例名称，然后单击“指标”页签，可查看当前实例下IOTDA上报的全量指标数据曲线。 单击任一实例名称，然后单击“资源空间”页签，可查看当前实例下的资源空间。

概述 您可以通过以下方式查看监控指标： 在ModelArts控制台查看监控指标：您在可ModelArts总览页或各模块资源监控页签查看ModelArts监控指标。 在AOM控制台查看ModelArts所有监控指标：ModelArts上报的所有指标都保存在AOM中，用户可以通过AOM服务提供的指标消费和使用的能力来进行指标消费。设置指标阈值告警、告警上报等，都可以直接在AOM控制台查看。 使用Grafana查看AOM中的监控指标：使用Grafana等可视化工具来查看与分析，Grafana支持灵活而又复杂多样的监控视图和模板，为用户提供基于网页仪表面板的可视化监控效果，使用户更加直观地查看到实时资源使用情况。 父主题： 资源监控

为主机配置安装Agent插件 E CS 会上报基础监控指标和操作系统监控指标，其中基础监控指标是ECS云服务本身上报的指标，但是这类指标的采集周期大部分是5分钟周期，另一种则是操作系统安装了 CES Agent插件上报的监控指标，即操作系统监控指标，这类指标由CES上报，在采集精度上更精准，粒度也更精细，为1分钟采集周期，监控场景的覆盖也更全面，因此一般建议用户购买ECS资源后安装Agent插件。 如何安装Agent插件？ 首先需要从操作系统上区分一下，目前有Windows和Linux两种操作系统，安装Agent的方式有所区别： Windows类型机器安装Agent 只能使用手动安装，目前在CES的主机监控列表页面有用户安装指南，可进行参考。 直接单击单台资源“未安装”即可弹出操作指导，根据操作指南登录机器后使用安装命令进行插件安装即可。 图1 安装插件指引 官网文档也可参考安装Agent（Windows）。 Linux类型机器安装Agent Linux类型的机器目前安装Agent支持单台安装和批量安装。 目前部分机器支持在CES页面直接一键安装，或者在购买ECS的页面直接支持开启监控安装Agent。 支持一键安装的机器可直接在页面单击安装按钮进行安装。 图2 一键安装 部分机器还可支持在购买时直接开启监控，默认安装Agent。 图3 开启详细监控 Linux不支持一键安装的机器，可以进行手动安装，手动安装包括单台安装和批量安装两种方式。单台安装直接单击安装图标后可弹出安装指引。 图4 安装插件指引 除了单台安装，Linux机器还支持批量安装Agent插件，具体请参考批量安装Agent。 除上述方法以外，CES还支持批量在界面实现对已支持一键安装的机器进行批量安装，无需登录机器或者单台安装，更高效、便携，推荐用户使用该种方式进行安装。 图5 安装&升级插件 安装完成Agent，可以在主机监控列表页进行查看，“插件状态”列显示“运行中”状态的即为插件安装成功。 图6 插件状态

带宽使用率高问题分析 如果是正常业务访问以及正常应用进程导致的带宽使用率高，需要升级服务器的带宽进行解决。如果是非正常访问，如某些特定IP的恶意访问，或者服务器遭受到了CC攻击。或者异常进程导致的带宽使用率高。可以通过流量监控工具nethogs来实时监测统计各进程的带宽使用情况，并进行问题进程的定位。 使用nethogs工具进行排查 执行以下命令，安装nethogs工具。 yum install nethogs -y 安装成功后可以通过netgos命令查看网络带宽的使用情况。 nethogs命令常用参数说明如下： -d：设置刷新的时间间隔，默认为1s。 -t：开启跟踪模式。 -c：设置更新次数。 device：设置要监测的网卡，默认是eth0。 运行时可以输入以下参数完成相应的操作： q：退出nethogs工具。 s：按发送流量大小的顺序排列进程列表。 r：按接收流量大小的顺序排列进程列表。 m：切换显示计量单位，切换顺序依次为KB/s、KB、B、MB。 执行以下命令，查看指定的网络端口每个进程的网络带宽使用情况。 nethogs eth1 回显参数说明如下： PID：进程ID。 USER：运行该进程的用户。 PROG RAM ：进程或连接双方的IP地址和端口，前面是服务器的IP和端口，后面是客户端的IP和端口。 DEV：流量要去往的网络端口。 SENT：进程每秒发送的数据量。 RECEIVED：进程每秒接收的数据量。 终止恶意程序或者屏蔽恶意访问IP。 如果确认大量占用网络带宽的进程是恶意进程，可以使用kill PID命令终止恶意进程。 如果是某个IP恶意访问，可以使用iptables服务来对指定IP地址进行处理，如屏蔽IP地址或限速。 使用 Web应用防火墙 防御CC攻击 若服务遭受了CC攻击，请在Web应用防火墙控制台开启CC安全防护。Web应用防火墙的使用指导请参见配置CC防护策略。

CPU占用率高问题定位 远程登录云服务器。 执行以下命令查看当前系统的运行状态。 top 系统回显样例如图1所示。 图1 回显信息 查看显示结果。 命令回显第一行：20:56:02 up 37 days，1 user, load average: 0.00, 0.01, 0.05的每个字段含义如下： 系统当前时间为20:56:02，该云服务器已运行37天，当前共有1个用户登录， 最近1分钟、最近5分钟和最近15分钟的CPU平均负载。 命令回显第三行：CPU资源总体使用情况。 命令回显第四行：内存资源总体使用情况。 回显最下方显示各进程的资源占用情况。 在top页面，可以直接输入小写“q”或者在键盘上按“Ctrl+C”退出。 除了直接输入命令，您还可以单击VNC登录页面屏幕右上角的“Input Command”，在弹出的对话框中粘贴或者输入相应命令，单击“Send”。 在top运行中常用的内容命令如下： s：改变画面更新频率。 l：关闭或开启第一部分第一行top信息的表示。 t：关闭或开启第一部分第二行Tasks和第三行Cpus信息的表示。 m：关闭或开启第一部分第四行Mem和 第五行Swap信息的表示。 N：以PID的大小的顺序排列进程列表。 P：以CPU占用率大小的顺序排列进程列表。 M：以内存占用率大小的顺序排列进程列表。 h：显示命令帮助。 n：设置在进程列表所显示进程的数量。 通过ll /proc/PID/exe命令可以查看每个进程ID对应的程序文件。

CPU使用率高问题处理 对于导致CPU使用率高的具体进程，如果确认是异常进程，可以直接通过top命令终止进程。对于kswapd0进程导致的CPU使用率高的问题，则需要对应用程序进行优化，或者通过增加内存进行系统规格的升级。 kswapd0是系统的虚拟内存管理程序，如果物理内存不够用，系统就会唤醒kswapd0进程，由kswapd0分配磁盘交换空间用作缓存，因而占用大量的CPU资源。 使用top命令终止CPU占用率高的进程 您可以直接在top运行界面快速终止相应的异常进程。操作步骤如下： 在top命令运行的同时，按下小写的“k”键。 输入要终止进程的PID。 进程的PID为top命令回显的第一列数值。例如，要终止PID为52的进程，直接输入“52”后回车。 操作成功后，会出现如图2所示信息，按回车确认。 图2 操作成功示例 kswapd0进程占用导致CPU使用率高 可通过以下步骤排查进程的内存占用情况。 通过top命令查看kswapd0进程的资源使用。 如果kswapd0进程持续处于非睡眠状态，且运行时间较长，可以初步判定系统在持续的进行换页操作，可以将问题转向内存不足的原因来排查。 通过vmstat命令进一步查看系统虚拟内存的使用情况。 如果si和so的值也比较高，说明系统存在频繁的换页操作，系统物理内存不足。 si：每秒从交换区写到内存的大小，由磁盘调入内存。 so：每秒写入交换区的内存大小，由内存调入磁盘。 对于内存不足问题，可以通过free、ps等命令进一步查询系统及系统内进程的内存占用情况，做进一步排查分析。 临时可通过在业务空闲期重启应用或者系统释放内存。 如果要从根本上解决内存不足的问题，需要对服务器内存进行扩容，扩大内存空间。如果不具备扩容的条件，可通过优化应用程序，以及配置使用大页内存来进行缓解。

请求示例 批量下载监控数据，设置起止时间，实时数据，统计方式为max, 指定资源id列表 https://eihealth.cn-north-4.myhuaweicloud.com/v1/{project_id}/metric-data/batch-stat-metric-data { "from_time" : 1234567891011, "to_time" : 1234567891012, "period" : "real_time", "method" : "max", "resource_ids" : [ 123456789 ] }