Greenplum中的gpperfmon数据库

0    303    2

Tags:

👉 本文共约22392个字,系统预计阅读时间或需85分钟。

简介

gpperfmon 数据库是一个专用数据库,包含查询状态和系统指标的可选的性能管理数据库,Greenplum segment 主机上的数据收集代理程序将查询和系统统计信息保存在这个数据库中。

gpperfmon_install管理工具创建名为gpperfmon的数据库, 并启用运行在Greenplum数据库Master和Segment节点上的数据收集代理。 运行在节点上的数据收集代理会从节点上收集查询状态,还包括诸如CPU和内存使用量等系统指标。 Master节点上的代理周期性的(通常15秒)从节点代理上收集数据并更新gpperfmon数据库。 用户可以查询gpperfmon数据库来查看查询和系统指标。

gpperfmon 数据库通过 gpperfmon_install 命令行工具创建。 这个工具然后创建 gpmon 数据库角色并启用 master 和 segment 主机上的数据收集代理 程序。更多关于该工具使用和数据收集代理配置的信息,请参考 Greenplum 数据库工具指南 中的 gpperfmon_install 参考手册。

gpperfmon 数据库由三组表组成。它们分别用于在不同阶段捕捉查询和系统状态信息。

  • _now 系列表存储当前系统指标,例如活动查询等。
  • _tail 系列表用于在数据保存到 _history 系列表之前暂存数据。 _tail 系列表仅供内部使用,不提供用户查询。
  • _history 系列表用于存储历史数据。

_now 和 _tail 表的数据存储为文本文件,保存在 master 主机 文件系统中,通过外部表在 gpperfmon 数据库中访问。history 系列表 是 gpperfmon 数据库的常规内存表。只有运行超过一定时间(默认是 20 秒)的查询才会 保存到历史数据表中。你可以通过设置 $MASTER_DATA_DIRECTORY/gpperfmon/conf/gpperfmon.conf 中的 min_query_time 参数来修改这个门限值。设置为 0 将会保存所有查询历史信息。

Note: gpperfmon 不支持 ALTER SQL 命令。 ALTER 查询不会被记录在 gpperfmon 历史查询表中。

历史查询表按月进行分区。关于移除老分区的信息,请参见 历史查询表分区保留

该数据库包含以下几类表:

  • database_* 系列表存储一个 Greenplum 数据库实例的查询负载信息。
  • diskspace_* 系列表存储磁盘 空间指标。
  • logalert* 系列表存储 pg_log 中的错误和警告消息。
  • queries_* 系列表存储高级查询 状态信息。
  • segment_* 系列表存储 Greenplum 数据库 segment 实例的内存分配和统计信息。
  • socketstats* 系列表存储一个 Greenplum 数据库实例中 socket 使用统计指标信息。 注意: 这些表为将来使用保留,当前没有填充信息。
  • system_* 系列表存储系统工具程序指标。

gpperfmon 数据库还包含下列视图:

  • dynamic_memory_info 视图展示每个主机中所有 segments 的汇总, 以及每个主机中 动态内存使用量。
  • memory_info 视图展示来自 system_history 和 segment_history 表的每个主机的内存信息.

历史查询表分区保留

gpperfmon 数据库中的 历史查询 表按月进行分区。分区 在需要时会以两个月为增量自动添加。

$MASTER_DATA_DIRECTORY/gpperfmon/conf/gpperfmon.conf 配置文件中的 partition_age 参数可以设置为要保留的每月最大分区数。添加新分区时,将自动 删除早于指定值的分区。

partition_age 的默认值是 0, 这意味着管理员必须手动删除 不需要的分区。

警报日志处理和日志轮换

当 gp_gperfmon_enable 服务期配置参数设置为 true 时, Greenplum 数据库 syslogger 会把警报消息写到一个 .csv 文件中。该文件位于 $MASTER_DATA_DIRECTORY/gpperfmon/logs 目录。

通过修改 postgresql.conf 文件中的 gpperfmon_log_alert_level 服务期配置参数,可以将写入日志消息级别设置为 none, warning, error, fatal, 或者 panic。默认的消息基本是 warning。

日志存储的目录可以通过设置 $MASTER_DATA_DIRECTORY/gpperfmon/conf/gpperfmon.conf 配置文件中的 log_location 配置变量来改变。

syslogger 每 24 小时,或在当前日志文件达到或超过 1MB 时轮换警报日志。

如果单条错误消息包含一个长 SQL 语句或者长堆栈信息时,轮换日志文件可能超过 1MB。 此外,syslogger 会分批处理错误消息,每个日志记录过程分别对应一个单独的分块。日志块的 大小取决于操作系统; 例如,在 Red Hat Enterprise Linux 系统中, 它是 4096 字节。如果许多 Greenplum 数据库会话同时生成错误消息,则在检查文件大小并触发日志轮换之前, 日志文件可能会显着增长。

gpperfmon 数据收集过程

当 Greenplum 数据库启用 gpperfmon 支持下启动时, 它将创建一个 gpmmon 代理进程。 gpmmon 然后在 Greenplum 数据库集群的 master 主机和每个 segment 主机上启动一个 gpsmon 代理进程。Greenplum 数据库的 postmaster 进程监视 gpmmon 进程并在需要时重启该进程;gpmmon 进程监视和在需要时重启 gpsmon 进程。

gpmmon 进程以循环方式运行,并按一个可配置间隔检索 gpsmon 系列进程聚合的数据,并将其添加到 _now 和 _tail 外部数据库表 的数据文件, 然后存入 _history 常规内存数据库表中。

Note: gpperfmon 中的 log_alert 表流程不同于此,因为警报消息 由 Greenplum 数据库系统 logger 发送,而不是通过 gpsmon 发送。参见 警报日志处理和日志轮换 了解更多信息。

$MASTER_DATA_DIRECTORY/gpperfmon/conf/gpperfmon.conf 配置文件中的 两个配置参数控制着 gpmmon 被触发的频度:

  • quantum 参数是以秒为单位的频率, gpmmon 依此频率向 segment 节点的 gpsmon 代理进程请求数据,并将获取到的数据添加到 _now 和 _tail 外部表数据文件中。 quantum 参数的有效设定值是 10, 15, 20, 30, 以及 60. 默认值是 15.
  • harvest_interval 参数是以秒为单位的频率, 依此频率将 _tail 表中的数据移动到 _history 表中。 harvest_interval 至少是 30. 默认值为 120.

参见 Greenplum 数据库工具指南 中的 gpperfmon_install 管理工具 参考手册, 查阅 gpperfmon 配置参数完整列表。

以下步骤描述了,当 gpperfmon 支持启用时,数据从 Greenplum 数据库进入 gpperfmon 的流程。

  1. 在执行查询时, Greenplum 数据库查询调度程序和查询执行程序进程以 UDP 报文形式发送查询状态消息。 gp_gpperfmon_send_interval 服务器配置变量决定数据库发送这些消息的频率。 默认为每秒发送一次。
  2. 每个主机上的 gpsmon 进程接收 UDP 报文, 合并并汇总所包含的数据, 并添加其他主机指标,例如 CPU 和内存使用率。
  3. gpsmon 进程继续累积数据,直到它们从 gpmmon 接收到转储命令为止。
  4. gpsmon 进程通过发送其累积的状态数据和日志警报到一个 gpmmon 事件侦听线程来响应 dump 命令。
  5. gpmmon 事件处理程序将指标保存到 master 主机的 $MASTER_DATA_DIRECTORY/gpperfmon/data 目录下的 .txt 文件。

在每一个 quantum 间隔 (默认为 15 秒), gpmmon 执行以下步骤:

  1. 发送一个 dump 命令到 gpsmon 进程。

  2. 收集和转换 .txt 文件(保存在 the $MASTER_DATA_DIRECTORY/gpperfmon/data 目录中) 为 .dat 外部数据文件, 支持通过 gpperfmon 数据库中的 _now 和 _tail 外部表访问。

    例如, 磁盘空间指标被添加到 diskspace_now.dat 和 _diskspace_tail.dat 带分隔符的文本文件中. 这些文本文件经由 gpperfmon 数据库中的 diskspace_now 和 _diskspace_tail 表访问.

在每一个 harvest_interval (默认为 120 秒), gpmmon 对每一个 _tail 文件执行以下步骤:

  1. 重命名 _tail 为一个 _stage 文件.

  2. 创建一个新的 _tail 文件.

  3. 把数据从 _stage 文件追加进 _tail 文件.

  4. 允许一个 SQL 命令吧数据从 _tail 外部表插入进相应的 _history 表中.

    例如, _database_tail 外部表的内容被插进 database_history 常规 (内存) 表中.

  5. Deletes the _tail file 在内容被加载进数据库表中后,删除 _tail 文件。

  6. 收集所有 $MASTER_DATA_DIRECTORY/gpperfmon/logs 目录下的 gpdb-alert-*.csv 文件 (除了 syslogger 已经打开并正在写入的最新文件) 到单个文件 alert_log_stage 中.

  7. 把 alert_log_stage 文件内容加载进 gpperfmon 数据库的 log_alert_history 表中。

  8. 清空 alert_log_stage 文件.

gpperfmon 数据库每表中的内容

以下主题分别描述 gpperfmon 数据库每表中的内容。

database_* 表

database_* 表存储一个 Greenplum 数据库实例的工作负载信息。这里一共有三张表,每张表都具有相同的结构(列):

  • database_now 是一个外部表,其数据文件位于 $MASTER_DATA_DIRECTORY/gpperfmon/data. 从数据采集代理程序获得数据以后,自动提交到 database_history 表之前,当前查询工作负载数据存储在 database_now 表中。
  • database_tail 是一个外部表, 其数据文件位于 $MASTER_DATA_DIRECTORY/gpperfmon/data. 它是一个过渡表,当数据已经从 database_now 中清除,但还没有提交到 database_history 表中时,暂存在这里。它通常仅包含数据几分钟时间。
  • database_history 是一个常规表, 用于存储历史查询工作负载数据。 它已预先设置为按月分区。 分区会根据需要以两个月为增量自动添加。
类型说明
ctimetimestamp该行的创建时间.
queries_totalint采集数据时,Greenplum 数据库中的查询总数量.
queries_runningint采集数据时,活动的查询数量.
queries_queuedint采集数据时,资源组或资源队列中处于等待状态的查询数量(与当前使用的资源管理器相关).

diskspace_* 表

diskspace_* 表存储磁盘空间指标。

  • diskspace_now 是一个外部表, 其数据文件位于 $MASTER_DATA_DIRECTORY/gpperfmon/data. 在数据从 gpperfmon 数据采集代理程序获得数据以后,自动提交到 diskspace_history 表之前, 当前磁盘空间指标数据存储在 database_now 表中。
  • diskspace_tail 是一个外部表, 其数据文件位于 $MASTER_DATA_DIRECTORY/gpperfmon/data. 它是一个过渡表,当数据已经从 diskspace_now 中清除,但还没有提交到 diskspace_history表中时,暂存在这里。它通常仅包含数据几分钟时间。
  • diskspace_history 是一个常规表, 用于存储历史磁盘空间指标。 它已预先设置为按月分区。 分区会根据需要以两个月为增量自动添加。
类型说明
ctimetimestamp(0) without time zone磁盘空间测量时间.
hostnamevarchar(64)磁盘空间测量对应的主机名称.
Filesystemtext磁盘空间测量对应的文件系统名称.
total_bytesbigint文件系统的总字节数.
bytes_usedbigint文件系统中已使用字节数.
bytes_availablebigint文件系统中可用的字节数.

interface_stats_*

interface_stats_* 表存储 一个 Greenplum 数据库实例在每个活动网络接口上 的通信统计指标。

这些表为将来使用保留,当前没有填充信息。

一共有三张 interface_stats 表, 它们具有相同的结构(列):

  • interface_stats_now 是一个外部表, 其数据文件位于 $MASTER_DATA_DIRECTORY/gpperfmon/data.
  • interface_stats_tail 是一个外部表, 其数据文件位于 in $MASTER_DATA_DIRECTORY/gpperfmon/data. 它是一个存储接口统计指标的过渡表,当数据已经从 interface_stats_now 中清除,但还没有提交到 interface_stats_history表中时,暂存在这里。 它通常仅包含数据几分钟时间。
  • interface_stats_history 是一个常规表, 用于存储历史接口统计指标。 它已预先设置为按月分区。 分区会根据需要以两个月为增量自动添加。
类型说明
interface_namestring接口名称. 例如: eth0, eth1, lo.
bytes_receivedbigint接收字节数.
packets_receivedbigint接收报文数.
receive_errorsbigint接收数据时,发生的错误数.
receive_dropsbigint接收数据时,丢弃报文的次数.
receive_fifo_errorsbigint接收数据时,FIFO (先进先出) 错误发生的次数.
receive_frame_errorsbigint接收数据时,帧错误发生的次数.
receive_compressed_packetsint接受的压缩格式报文数.
receive_multicast_packetsint接受的多播报文数.
bytes_transmittedbigint传输字节数.
packets_transmittedbigint传输报文数.
transmit_errorsbigint数据传输时,发生的错误数.
transmit_dropsbigint数据传输时,丢弃报文的次数.
transmit_fifo_errorsbigint数据传输时,FIFO (先进先出) 错误发生的次数.
transmit_collision_errorsbigint数据传输时,碰撞错误发生的次数.
transmit_carrier_errorsbigint数据传输时,载波错误发生的次数.
transmit_compressed_packetsint传输的压缩格式报文数.

log_alert_*

log_alert_* 表存储 pg_log 错误和警报.

参考 警报日志处理和日志轮换 了解关于配置 gpperfmon 系统 logger 的更多信息.

一共有三张 log_alert 表, 所有这些表具有相同的列:

  • log_alert_now 是一个外部表,它的数据存储在 $MASTER_DATA_DIRECTORY/gpperfmon/logs 目录下的 .csv 文件中。 在数据从 gpperfmon 代理自动提交到 log_alert_history 表期间, 当前的 pg_log 错误和警报数据在 log_alert_now 中。.
  • log_alert_tail 是一个外部表,它的数据存储在 $MASTER_DATA_DIRECTORY/gpperfmon/logs/alert_log_stage 中. 这是一个过渡表,当数据已经从 log_alert_now 中清除,但还没有提交到 log_alert_history 中时,暂存在这里。该表包括所有警报日志中的记录, 但最新的除外。它通常仅包含数据几分钟时间。
  • log_alert_history 是一个常规表,用于存储数据库范围内的历史错误和警告数据。 它已预先设置为按月分区。分区会根据需要以两个月为增量自动添加。
类型说明
logtimetimestamp with time zone此日志的时间戳
logusertext查询的用户
logdatabasetext查询的用户
logpidtext进程 ID
logthreadtext线程号
loghosttext主机名或 IP 地址
logporttext端口号
logsessiontimetimestamp with time zone会话时间戳
logtransactioninteger事务 ID
logsessiontext会话 ID
logcmdcounttext命令数量
logsegmenttextSegment 编号
logslicetextSlice 编号
logdistxacttext分布式事务
loglocalxacttext本地事务
logsubxacttext子事务
logseveritytext日志级别
logstatetext日志状态
logmessagetext日志信息
logdetailtext详细信息
loghinttext提示信息
logquerytext查询内容
logquerypostext查询位置
logcontexttext上下文信息
logdebugtext调试
logcursorpostext光标位置
logfunctiontext函数信息
logfiletext源代码文件
loglinetext源代码行
logstacktext堆栈信息

queries_* 表

queries_* 系列表存储高级查询状态信息.

tmid, ssid 和 ccnt 列是唯一标识特定查询的组合键.

一共有三张查询表,所有查询表都具有相同的列:

  • queries_now 是一个外部表, 其数据文件位于 $MASTER_DATA_DIRECTORY/gpperfmon/data. 在数据从 gpperfmon 代理自动提交到 queries_history 表期间, 当前查询状态存储在 queries_now 中。
  • queries_tail 是一个外部表, 其数据文件位于 $MASTER_DATA_DIRECTORY/gpperfmon/data. 它是一个过渡表。当数据已经从 queries_now 中清除,但还没有提交到 queries_history 时,查询状态数据保存在这里。它通常仅包含数据几分钟时间.
  • queries_history 是存储历史查询状态数据的常规表。 它被预定义为按月进行分区. 分区会根据需要以两个月为增量自动添加。
类型说明
ctimetimestamp该行的创建时间.
tmidint特定查询的时间标识符. 与特定查询关联的所有记录具有相同的 tmid.
ssidint与 gp_session_id 关联的会话 ID. 与特定查询关联的所有记录具有相同的 ssid.
ccntint与 gp_command_count 关联的命令号. 与特定查询关联的所有记录具有相同的 ccnt.
usernamevarchar(64)发出查询的 Greenplum 角色名称.
dbvarchar(64)查询的数据库名称.
costint在此版本中未实现.
tsubmittimestamp查询的提交时间.
tstarttimestamp查询的开始时间.
tfinishtimestamp查询的结束时间.
statusvarchar(64)查询状态 — start, done, or abort.
rows_outbigint查询输出的行数.
cpu_elapsedbigint执行该查询的全部 segments 的全部进程的 CPU 时间 (单位: 秒). 它是从数据库系统中所有活动的主 segments 获取的 CPU 时间总和。请注意,如果查询运行时间短于 quantum 的值,则该值记录为 0。 即使查询运行时间大于 min_query_time 值, 但是低于 quantum 的值, 也会记录为 0。
cpu_currpctfloat当前执行此查询的所有进程的 CPU 平均百分比。 对在每个 segment 上运行的所有进程的百分比求平均值, 然后计算所有这些值的平均值来获得该指标。当前的 CPU 平均百分比在 history 数据和 tail 数据中始终为零。
skew_cpufloat显示该查询在系统中的处理偏斜量。 当一个 segment 对查询执行的处理量不成比例时,就会发生处理 / CPU 偏斜。 此值是此查询所有 segment 中 CPU% 度量的方差系数乘以 100。 例如,.95 的值表示为 95。
skew_rowsfloat显示系统中的行偏斜量。 当一个 segment 产生的查询行数不成比例时,就会发生行偏斜。 该值是该查询所有 segment 的 rows_in 指标的方差系数乘以100。 例如,.95 的值显示为 95。
query_hashbigint在此版本中未实现.
query_texttext该查询的 SQL 文本.
query_plantext查询计划文本. 在此版本中未实现.
application_namevarchar(64)应用程序的名称.
rsqnamevarchar(64)如果基于资源队列的资源管理方案被使用,则此列为资源队列的名称.
rqppriorityvarchar(64)如果基于资源队列的资源管理方案被使用, 则此列为查询优先级 — max, high, med, low, 或 min.

segment_* 表

The segment_* 包含 Greenplum 数据库 segment 实例的内存分配统计信息。 它跟踪每个特定 segment 实例上全部 postgres 进程的内存消费数量, 以及由当前资源管理方案(基于资源组或基于资源队列)设置的每个 segment 可用的剩余内存数量. 参见 Greenplum 数据库管理员指南 了解更多关于资源管理方案的详细信息.

一共有三张 segment 表, 每张表都具有相同的结构(列):

  • segment_now 是一个外部表, 其数据文件位于 $MASTER_DATA_DIRECTORY/gpperfmon/data. 在数据从 gpperfmon 数据采集代理程序获得以后,自动提交到 segment_history 表之前, 当前系统使用指标数据存储在 segment_now 表中。
  • segment_tail 是一个外部表, 其数据文件位于 $MASTER_DATA_DIRECTORY/gpperfmon/data. 它是一个内存分配信息的过渡表,当数据已经从 segment_now 中清除,但还没有提交到 segment_history 表中时,暂存在这里。 它通常仅包含数据几分钟时间。
  • segment_history 是一个常规表, 用于存储历史内存分配指标。 它已预先设置为按月分区。 分区会根据需要以两个月为增量自动添加。

每个特定 segment 实例通过 hostname 和 dbid (gp_segment_configuration 系统目录表中的 segment 唯一标识) 定义.

类型说明
ctimetimestamp(0)(without time zone)该行的创建时间.
dbidintsegment ID (gp_segment_configuration 中的 dbid).
hostnamecharvar(64)segment 主机名称.
dynamic_memory_usedbigint当前 segment 上分配给查询进程的动态内存数量(单位: 字节).
dynamic_memory_availablebigint在到达当前资源管理方案(基于资源组或基于资源队列)设置限制前,segment 上还可分配的动态内存数量(单位: 字节).

参见 memory_info 视图和 dynamic_memory_info 视图了解更多主机上内存分配汇总和使用信息.

本人提供Oracle(OCP、OCM)、MySQL(OCP)、PostgreSQL(PGCA、PGCE、PGCM)等数据库的培训和考证业务,私聊QQ646634621或微信dbaup66,谢谢!
AiDBA后续精彩内容已被站长无情隐藏,请输入验证码解锁本文!
验证码:
获取验证码: 请先关注本站微信公众号,然后回复“验证码”,获取验证码。在微信里搜索“AiDBA”或者“dbaup6”或者微信扫描右侧二维码都可以关注本站微信公众号。

标签:

Avatar photo

小麦苗

学习或考证,均可联系麦老师,请加微信db_bao或QQ646634621

您可能还喜欢...

发表回复