PostgreSQL 10.1 手册_部分 III. 服务器管理_第 29 章 监控磁盘使用_29.1. 判断磁盘用量

本文涉及的产品
云原生数据库 PolarDB MySQL 版,Serverless 5000PCU 100GB
云原生数据库 PolarDB PostgreSQL 版,企业版 4核16GB
推荐场景:
HTAP混合负载
云原生数据库 PolarDB MySQL 版,通用型 2核4GB 50GB
简介: 29.1. 判断磁盘用量 每个表都有一个主要的堆磁盘文件,大多数数据都存储在其中。如果一个表有着可能会很宽(尺寸大)的列, 则另外还有一个TOAST文件与这个表相关联, 它用于存储因为太宽而不能存储在主表里面的值(参阅第 66.2 节)。

29.1. 判断磁盘用量

每个表都有一个主要的堆磁盘文件,大多数数据都存储在其中。如果一个表有着可能会很宽(尺寸大)的列, 则另外还有一个TOAST文件与这个表相关联, 它用于存储因为太宽而不能存储在主表里面的值(参阅第 66.2 节)。如果有这个附属文件,那么TOAST表上会有一个可用的索引。 当然,同时还可能有索引和基表关联。每个表和索引都存放在单独的磁盘文件里 — 如果文件超过 1G 字节,甚至可能多于一个文件。这些文件的命名原则在第 66.1 节中描述。

你可以以三种方式监视磁盘空间:使用表 9.84中列出的SQL函数、使用oid2name模块或者人工观察系统目录。SQL函数是最容易使用的方法,同时也是我们通常推荐的方法。本节剩余的部分将展示如何通过观察系统目录来监视磁盘空间。

在一个最近清理过或者分析过的数据库上使用psql,你可以发出查询来查看任意表的磁盘用量:

SELECT pg_relation_filepath(oid), relpages FROM pg_class WHERE relname = 'customer';

 pg_relation_filepath | relpages
----------------------+----------
 base/16384/16806     |       60
(1 row)

每个页通常都是 8K 字节(记住,relpages只会由VACUUMANALYZE和少数几个 DDL 命令如CREATE INDEX所更新)。如果你想直接检查表的磁盘文件,那么文件路径名应该有用。

要显示TOAST表使用的空间,我们可以使用一个类似下面这样的查询:

SELECT relname, relpages
FROM pg_class,
     (SELECT reltoastrelid
      FROM pg_class
      WHERE relname = 'customer') AS ss
WHERE oid = ss.reltoastrelid OR
      oid = (SELECT indexrelid
             FROM pg_index
             WHERE indrelid = ss.reltoastrelid)
ORDER BY relname;

       relname        | relpages
----------------------+----------
 pg_toast_16806       |        0
 pg_toast_16806_index |        1

你也可以很容易地显示索引的尺寸:

SELECT c2.relname, c2.relpages
FROM pg_class c, pg_class c2, pg_index i
WHERE c.relname = 'customer' AND
      c.oid = i.indrelid AND
      c2.oid = i.indexrelid
ORDER BY c2.relname;

       relname        | relpages
----------------------+----------
 customer_id_indexdex |       26

我们很容易用下面的信息找出最大的表和索引:

SELECT relname, relpages
FROM pg_class
ORDER BY relpages DESC;

       relname        | relpages
----------------------+----------
 bigtable             |     3290
 customer             |     3144

本文转自PostgreSQL中文社区,原文链接:29.1. 判断磁盘用量

相关实践学习
使用PolarDB和ECS搭建门户网站
本场景主要介绍基于PolarDB和ECS实现搭建门户网站。
阿里云数据库产品家族及特性
阿里云智能数据库产品团队一直致力于不断健全产品体系,提升产品性能,打磨产品功能,从而帮助客户实现更加极致的弹性能力、具备更强的扩展能力、并利用云设施进一步降低企业成本。以云原生+分布式为核心技术抓手,打造以自研的在线事务型(OLTP)数据库Polar DB和在线分析型(OLAP)数据库Analytic DB为代表的新一代企业级云原生数据库产品体系, 结合NoSQL数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
相关文章
|
2月前
|
存储 关系型数据库 MySQL
服务器数据恢复—同友存储raid5磁盘阵列数据恢复案例
服务器数据恢复环境: 某市教育局同友存储,存储中有一组由数块磁盘组建的raid5阵列,存储空间划分若干lun。每个lun中有若干台虚拟机,其中有数台linux操作系统的虚拟机为重要数据。 服务器故障: raid崩溃导致存储无法启动。
服务器数据恢复—同友存储raid5磁盘阵列数据恢复案例
|
12天前
|
存储 运维 Oracle
服务器数据恢复—S5300存储raid5磁盘阵列数据恢复案例
服务器存储数据恢复环境: 华为S5300存储中有一组由16块FC硬盘组建的RAID5磁盘阵列(包含一块热备盘)。 服务器存储故障: 该存储中的RAID5阵列1块硬盘由于未知原因离线,热备盘上线并开始同步数据,数据同步到50%左右时另外一块硬盘离线,同步失败,raid5阵列瘫痪,上层lun不可用。
服务器数据恢复—S5300存储raid5磁盘阵列数据恢复案例
|
10天前
|
SQL 监控 关系型数据库
实时计算 Flink版操作报错合集之在设置监控PostgreSQL数据库时,将wal_level设置为logical,出现一些表更新和删除操作报错,怎么办
在使用实时计算Flink版过程中,可能会遇到各种错误,了解这些错误的原因及解决方法对于高效排错至关重要。针对具体问题,查看Flink的日志是关键,它们通常会提供更详细的错误信息和堆栈跟踪,有助于定位问题。此外,Flink社区文档和官方论坛也是寻求帮助的好去处。以下是一些常见的操作报错及其可能的原因与解决策略。
|
1月前
|
数据挖掘 数据库
服务器数据恢复—服务器raid磁盘故障离线导致阵列瘫痪的数据恢复案例
服务器数据恢复环境: 一台某品牌DL380服务器中3块SAS硬盘组建了一组raid。 服务器故障: RAID中多块磁盘出现故障离线导致RAID瘫痪,其中一块硬盘状态指示灯显示红色。服务器上运行的数据库在D分区,备份文件存放在E分区。由于RAID瘫痪,D分区无法识别,E分区可识别但是拷贝文件报错。管理员重启服务器,导致RAID中先离线的硬盘上线并开始同步数据,同步没有完成管理员意识到有问题,于是就强制关机了,之后就没有再动过服务器。
服务器数据恢复—服务器raid磁盘故障离线导致阵列瘫痪的数据恢复案例
|
5天前
|
存储 Unix API
iSCSI SAN环境中的服务器如何获得新分配的磁盘卷
iSCSI SAN环境中的服务器如何获得新分配的磁盘卷
|
1月前
|
存储 算法 小程序
服务器数据恢复—OceanStor 5800存储磁盘阵列数据恢复案例
服务器存储数据恢复环境: 华为OceanStor 5800存储,该存储中有一组由10块硬盘组建的raid6磁盘阵列,供企业内部使用,服务器安装linux操作系统+EXT3文件系统,划分2个lun。 服务器存储故障: 管理员发现存储中raid6磁盘阵列不可用,于是将原raid6阵列中的磁盘作为成员盘重新分配raid,并对raid进行初始化。初始化进行到40%左右时,管理员意识到问题,于是强行终止初始化,部分数据已经被破坏,而且不可逆。 导致服务器存储中数据丢失的原因是raid失效,管理员将raid6阵列中的9块硬盘作为成员盘来重新分配riad5阵列,并进行了长时间的初始化操作,这个过程对原始数
|
1月前
|
存储 运维 Oracle
服务器数据恢复—MSA2000存储中raid5磁盘阵列数据恢复案例
服务器存储数据恢复环境: 某品牌MSA2000服务器存储中有一组由8块SAS硬盘组建的raid5磁盘阵列,其中包含一块热备盘。分配了6个LUN,均分配给HP-Unix小机使用。磁盘分区由LVM进行管理,存放的数据主要为Oracle数据库及OA服务端。 服务器存储故障: 服务器存储raid5阵列中有两块硬盘先后离线,服务器瘫痪,无法正常访问lun。
服务器数据恢复—MSA2000存储中raid5磁盘阵列数据恢复案例
|
1月前
|
存储 数据挖掘
服务器数据恢复—EMC存储raid5磁盘阵列崩溃的数据恢复案例
一台EMC某型号存储由于存储中raid5阵列出现故障导致服务器崩溃,由于数据涉密,需要工程师到现场恢复数据。 服务器数据恢复工程师到现场后对数据进行检测,经过检测发现服务器崩溃是由于raid中某些硬盘掉线所导致。将所有磁盘编号后取出,硬件工程师对所有磁盘进行检测后没有发现有硬盘存在物理故障,也没有坏道。数据恢复工程师将所有磁盘以只读方式做扇区级的全盘镜像,镜像完成后将所有磁盘还原到原存储中,后续的数据分析和数据恢复操作都基于镜像文件进行,避免对原始磁盘数据造成二次破坏。
服务器数据恢复—EMC存储raid5磁盘阵列崩溃的数据恢复案例
|
2月前
|
运维 数据挖掘
服务器数据恢复—RAID5磁盘阵列2块盘离线的数据恢复案例
服务器中有一组由多块硬盘组建的raid5磁盘阵列,服务器阵列中2块硬盘先后掉线导致服务器崩溃。
服务器数据恢复—RAID5磁盘阵列2块盘离线的数据恢复案例
|
2月前
|
弹性计算 监控 安全
【阿里云弹性计算】ECS实例监控与告警系统构建:利用阿里云监控服务保障稳定性
【5月更文挑战第23天】在数字化时代,阿里云弹性计算服务(ECS)为业务连续性提供保障。通过阿里云监控服务,用户可实时监控ECS实例的CPU、内存、磁盘I/O和网络流量等指标。启用监控,创建自定义视图集中显示关键指标,并设置告警规则(如CPU使用率超80%),结合多种通知方式确保及时响应。定期维护和优化告警策略,利用健康诊断工具,能提升服务高可用性和稳定性,确保云服务的卓越性能。
119 1