How to run PostgreSQL 11 in Linux on ARM

我们选择的系统是一个运行在AArch64芯片架构上的CentOS 7.5。

[root@ecs-arm-0005 ~]# uname -a
Linux ecs-arm-0005 4.14.0-49.el7a.aarch64 #1 SMP Tue Apr 10 17:22:26 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux

[root@ecs-arm-0005 ~]# cat /etc/centos-release
CentOS Linux release 7.5.1804 (AltArch)

这台服务器拥有8颗ARMv8(Huawei Kunpeng 916 2.4GHz)的芯片,和29GB的内存,并不是很大的机器。

[root@ecs-arm-0005 ~]# cat /proc/cpuinfo | grep processor|wc -l
8

[root@ecs-arm-0005 ~]# cat /proc/meminfo | grep MemTotal
MemTotal:       29756224 kB

这台服务器有两块磁盘,一块是系统盘vda,一块是超高IO的数据盘vdb。vdb还没有创建文件系统,自然也没有挂载点。

[root@ecs-arm-0005 ~]# lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
vdb    253:16   0  100G  0 disk
vda    253:0    0   40G  0 disk
├─vda2 253:2    0 39.8G  0 part /
└─vda1 253:1    0  244M  0 part /boot/efi

将vdb格式化为ext4格式的文件系统,挂载到/data目录中。作为后续Pg数据库的数据文件存储位置。

[root@ecs-arm-0005 ~]# mkfs -t ext4 /dev/vdb
mke2fs 1.42.9 (28-Dec-2013)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
6553600 inodes, 26214400 blocks
1310720 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=2174746624
800 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
    4096000, 7962624, 11239424, 20480000, 23887872

Allocating group tables: done
Writing inode tables: done

[root@ecs-arm-0005 ~]# mkdir /data
[root@ecs-arm-0005 ~]# mount /dev/vdb /data
[root@ecs-arm-0005 ~]# df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs         15G     0   15G   0% /dev
tmpfs            15G     0   15G   0% /dev/shm
tmpfs            15G   22M   15G   1% /run
tmpfs            15G     0   15G   0% /sys/fs/cgroup
/dev/vda2        40G  1.6G   36G   5% /
/dev/vda1       244M  8.6M  236M   4% /boot/efi
tmpfs           2.9G     0  2.9G   0% /run/user/0
/dev/vdb         99G   61M   94G   1% /data

如果要保证在操作系统重新启动的时候,vdb还会自动挂载到/data目录下,还需要修改/etc/fstab文件,此处不赘述。

因为Pg for ARM的版本并没有发布实现编译好的二进制安装包(实际上也有,但是是比较古老的9.2版本),因此首先我们下载PostgreSQL数据库最新版本11.3的源码。通过编译源码手动安装。

如果在下述过程中发现报错:configure: error: no acceptable C compiler found in $PATH,则表示没有安装gcc编译器,需要通过yum install gcc gcc-c++命令来事先安装。
如果在下述过程中发现报错:configure: error: readline library not found,则表示没有安装readline-devel包,需要通过yum install readline-devel命令来事先安装。
如果在下述过程中发现报错:configure: error: zlib library not found,则表示没有安装zlib-devel包,需要通过yum install zlib-devel命令来事先安装。

总结一下就是需要事先安装以下依赖包。

yum install gcc gcc-c++ readline-devel zlib-devel

从configure到make install都是标准的Linux下编译源码安装的步骤。如果一切正常,在第一步时不会显示任何error,在第二步最后会显示:All of PostgreSQL successfully made. Ready to install.字样。

$ ./configure
$ make
$ su
# make install

成功安装完毕以后,因为我们使用的是默认配置,因此PostgreSQL软件被安装到/usr/local/pgsql目录中。

[root@ecs-arm-0005 postgresql-11.3]# ls -l /usr/local/pgsql
total 16
drwxr-xr-x 2 root root 4096 Jun  4 16:01 bin
drwxr-xr-x 6 root root 4096 Jun  4 16:01 include
drwxr-xr-x 4 root root 4096 Jun  4 16:01 lib
drwxr-xr-x 6 root root 4096 Jun  4 16:01 share

接下来创建postgres用户,而不要使用root用户管理数据库。

# adduser postgres
# passwd postgres

之前我们在/data目录下挂载了100GB的高速IO数据盘,所以下面我们将PostgreSQL数据库的数据文件存储位置指定到/data目录下,并初始化数据库。

# mkdir /data/pgsql/data
# chown postgres /data/pgsql/data
# su - postgres
$ /usr/local/pgsql/bin/initdb -D /data/pgsql/data

初始化数据库的正常显示如下。

[postgres@ecs-arm-0005 ~]$ /usr/local/pgsql/bin/initdb -D /data/pgsql/data
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.

The database cluster will be initialized with locale "en_US.UTF-8".
The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "english".

Data page checksums are disabled.

fixing permissions on existing directory /data/pgsql/data ... ok
creating subdirectories ... ok
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting dynamic shared memory implementation ... posix
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... ok
syncing data to disk ... ok

WARNING: enabling "trust" authentication for local connections
You can change this by editing pg_hba.conf or using the option -A, or
--auth-local and --auth-host, the next time you run initdb.

Success. You can now start the database server using:

    /usr/local/pgsql/bin/pg_ctl -D /data/pgsql/data -l logfile start

数据库初始化结束以后显示的最后一条命令,告知了如果要启动数据库应该使用的命令。

[postgres@ecs-arm-0005 ~]$ /usr/local/pgsql/bin/pg_ctl -D /data/pgsql/data -l logfile start
waiting for server to start.... done
server started

至此,PostgreSQL 11.3在CentOS 7.5 on ARM上的安装和运行宣告完成。

[postgres@ecs-arm-0005 ~]$ psql
psql (11.3)
Type "help" for help.

postgres=# \db
       List of tablespaces
    Name    |  Owner   | Location
------------+----------+----------
 pg_default | postgres |
 pg_global  | postgres |
(2 rows)

Compare PostgreSQL Standard Statistics Views with Oracle Dynamic Performance (V$) Views

Oracle数据库的性能视图几乎可以说是最引以为骄傲的功能,在那样细粒度的采样统计强度下,依然保持卓越的性能,基于这些性能数据采样之后形成的AWR,更是Oracle DBA分析数据库性能问题的最重要手段之一。

那么在誉为最接近Oracle的开源数据库PostgreSQL中,如果要诊断性能问题,又有哪些视图可以使用呢?作为Oracle DBA,在学习PostgreSQL的时候,不可避免地会将PostgreSQL和Oracle进行比较。

以下SQL命令,在mydb=#提示符下的均为在PostgreSQL中执行的,在SQL>提示符下的均为在Oracle中执行的。

先看一下在PostgreSQL中存在那些统计信息视图。PostgreSQL中数据字典的命名还是很规范的,所有统计信息基本上都以pg_stat_开头。

mydb=# select relname from pg_class where relname like 'pg_stat_%';
             relname              
----------------------------------
 pg_statistic
 pg_stats
 pg_stat_all_tables
 pg_stat_xact_all_tables
 pg_stat_sys_tables
 pg_stat_xact_sys_tables
 pg_stat_user_tables
 pg_stat_xact_user_tables
 pg_statio_all_tables
 pg_statio_sys_tables
 pg_statio_user_tables
 pg_statio_all_indexes
 pg_statio_sys_indexes
 pg_statio_user_indexes
 pg_statio_all_sequences
 pg_statio_sys_sequences
 pg_statio_user_sequences
 pg_stat_activity
 pg_stat_replication
 pg_stat_database
 pg_stat_database_conflicts
 pg_stat_user_functions
 pg_stat_xact_user_functions
 pg_stat_archiver
 pg_stat_bgwriter
 pg_stat_all_indexes
 pg_stat_sys_indexes
 pg_stat_user_indexes
 pg_statistic_relid_att_inh_index
(29 rows)

pg_stat_activity
该视图显示了连接入一个Cluster下所有数据库的会话的统计信息,每个会话一行记录,类似于Oracle中的V$SESSION视图。
pg_stat_activity.query字段直接显示了该会话正在执行的SQL或者上次执行的SQL语句文本。在Oracle中检查一个会话正在执行的SQL语句文本,则需要通过V$SESSION和V$SQL视图Join才可以。
pg_stat_activity.pid字段直接显示了该会话在操作系统上的进程ID,这样通过top命令看到的繁忙操作系统进程,可以很简单地通过该字段定位,来作进一步的诊断。在Oracle中则需要通过V$SESSION和V$PROCESS视图Join才可以。

pg_stat_archiver
该视图始终只有一条记录,显示了负责一个cluster下所有数据库的重做日志(PostgreSQL中称为WAL file)归档进程的统计信息,记录项比较简单。last_archived_wal和last_archived_time分别显示了最近一次归档的文件名和最近一次归档时间。
类似于Oracle中的V$ARCHIVE_DEST_STATUS。由于PostgreSQL中的归档实现实在是太简单了,所以几乎跟Oracle没有太多可比性。

pg_stat_bgwriter
该视图始终只有一条记录,显示了负责一个cluster下所有数据库的后台写进程的统计信息,也就是在操作系统中看到的postgres: writer process。该进程每隔bgwriter_delay初始化参数定义的间隔(默认200ms)会唤醒,将Buffer Pool中修改过的页写入到磁盘。跟Oracle的后台进程DBWR非常相仿。
在Oracle中没有专门记录DBWR进程的性能视图,V$BGPROCESS视图也同样没有提供类似的信息,但是在V$SYSSTAT却记录了DBWR的统计信息,这部分跟pg_stat_bgwriter中记录的信息相仿。Oracle 11gR2中有超过600项的统计信息记录在V$SYSSTAT视图中。

SQL> select NAME,VALUE from v$sysstat where upper(name) like '%DBWR%';

NAME                                                                  VALUE
---------------------------------------------------------------- ----------
flash cache insert skip: DBWR overloaded                                  0
DBWR checkpoint buffers written                                     1564210
DBWR thread checkpoint buffers written                                    0
DBWR tablespace checkpoint buffers written                             2852
DBWR parallel query checkpoint buffers written                            0
DBWR object drop buffers written                                        324
DBWR transaction table writes                                         81619
DBWR undo block writes                                               485016
DBWR revisited being-written buffer                                       0
DBWR lru scans                                                            0
DBWR checkpoints                                                       4158
DBWR fusion writes                                                        0

12 rows selected.

pg_stat_database
该视图对于每个database显示一行记录,PostgreSQL中的Cluster类似于Oracle的一个Instance,一个Cluster下可以创建多个database。
该视图中记录了每个数据库提交了多少事务,回滚了多少事务,读了多少数据块,查询、插入、更新、删除了多少记录(在PostgreSQL中用Tuple这个奇怪的词表示跟Row相同的概念),产生过多少死锁。总之这是一个数据库级别相对很简单的统计信息。
但是,在Oracle中还真没有与此类似的性能视图,实际上Oracle没有一个视图简单地记录了一个Schema下面总共查询或者DML了多少条记录,但是却有DBA_TAB_MODIFICATIONS这样的视图详细记录每一张表的DML数量。查询了多少数据?可能Oracle认为这个数字是太不重要了,或者说实在是太大了,完全没必要记录。
对于事务级别的统计,同样可以在Oracle的V$SYSSTAT视图中查询包含“ROLLBACK”和“COMMIT”字样的统计值,远比PostgreSQL中记录地要更多样。

pg_stat_all_tables/pg_stat_sys_tables/pg_stat_user_tables
在PostgreSQL的统计信息视图中,all表示一个数据库下所有的表,sys表示所有的系统表,user表示所有用户创建的表,这三个配套的视图我们放在一起看。以下类似的也相同。
该视图对于每张表显示一条记录,显示了一张表上进行过多少全表扫描,多少索引扫描,查询、插入、更新、删除过多少记录,表中现在有多少记录,表的分析时间等。
在Oracle中表的分析信息存储在DBA_TABLES中,而对于每个表上DML的信息如前所述,可以从DBA_TAB_MODIFICATIONS视图中查询,而经历过怎样的IO则又可以从V$SEGSTAT视图中查询。好吧,实际上,在Oracle中根本也不关注一个表上读取过多少记录这样的数字,所以在PostgreSQL中但凡跟Tuple相关的统计值在Oracle中都找不到对应的记录。对于Oracle来说,IO都以Block为单位,所以读取一条记录还是读取一个块,在IO消耗上没有区别。而至于对于返回记录数等的优化,则归结到SQL层面,那则可以通过V$SQLSTAT等一系列视图作更详细的分析。

Oracle在视图层面从Table概念和Segment概念上做了详细的区分,看似复杂,实际清晰而且详尽,而在PostgreSQL中则混为一谈了,当然在PostgreSQL中通过后面会谈到的pg_statio_系列视图又对表和索引上的IO统计信息进行了记录。

pg_stat_xact_all_tables/pg_stat_xact_sys_tables/pg_stat_xact_user_tables
该系列视图与上述相仿,只是增加了xact前缀,xact表示transaction,统计的是当前会话对于表操作的信息,这部分信息通常还没有更新到pg_stat_all_tables视图中。
在Oracle中由于性能数据的抓取粒度是如此之细,所以并未区分当前会话还是已经结束的会话,要知道V$SEGSTAT中的信息几乎是real-time在更新的。所以,在Oracle中无需此类视图。

pg_stat_all_indexes/pg_stat_sys_indexes/pg_stat_user_indexes
该视图对于每个索引显示一条记录,显示的信息如下:

mydb=# select * from pg_stat_all_indexes where relname='t1';   
 relid | indexrelid | schemaname | relname | indexrelname | idx_scan | idx_tup_read | idx_tup_fetch 
-------+------------+------------+---------+--------------+----------+--------------+---------------
 24604 |      24613 | public     | t1      | t1_index     |        3 |        58960 |         47817
(1 row)

可见记录的信息非常简单,就是一个索引上进行过多少次扫描,通过这个索引扫描读取了多少记录,返回了多少记录。
在Oracle中,由于索引是Segment的一种,因此类似的统计信息都可以从V$SEGSTAT中获取。

pg_statio_all_tables/pg_statio_sys_tables/pg_statio_user_tables
pg_statio_all_indexes/pg_statio_sys_indexes/pg_statio_user_indexes

这两部分放在一起描述,具有statio前缀的视图显示的是表或索引在数据块级别的IO统计信息,而stat前缀的视图(如前面看到的)则显示的是表或索引在记录级别的IO统计信息。以pg_statio_all_indexes为例:

mydb=# select * from pg_statio_all_indexes where relname='t1';
 relid | indexrelid | schemaname | relname | indexrelname | idx_blks_read | idx_blks_hit 
-------+------------+------------+---------+--------------+---------------+--------------
 24604 |      24613 | public     | t1      | t1_index     |           150 |          453
(1 row)

显示了读取过多少个数据块,这些读取中有多少数据块是直接命中缓存的。
在Oracle中是我们提到了多次的V$SEGSTAT视图。

pg_statio_all_sequences/pg_statio_sys_sequences/pg_statio_user_sequences
PostgreSQL对sequence上的IO独立给出了一系列视图,PostgreSQL中的sequence跟Oracle中的sequence概念基本一致,为存储序列号等的字段生成序列值。
该视图对于每个序列显示一条记录,显示的信息如下:

mydb=# select * from pg_statio_all_sequences;
 relid | schemaname |   relname    | blks_read | blks_hit 
-------+------------+--------------+-----------+----------
 24614 | public     | users_id_seq |         1 |        3
(1 row)

非常简单,显示了读取过多少个数据块,多少数据块的读取是直接命中缓存的。
在Oracle中,由于序列是系统自身对象的一部分,因此如果要诊断跟序列相关的问题,通常要依赖等待事件,比如“enq: SQ – contention”或者“row cache lock”,另外在V$ROWCACHE视图中存储了与序列相关的整体统计值。

SQL> select PARAMETER,GETS,GETMISSES from v$rowcache where PARAMETER='dc_sequences';

PARAMETER                              GETS  GETMISSES
-------------------------------- ---------- ----------
dc_sequences                           2145         54

pg_stat_user_functions/pg_stat_xact_user_functions
有xact前缀和没有前缀的区别在前面描述pg_stat_xact_all_tables系列视图时已经提过,因此放在一起描述。
该视图对于每个指定要跟踪的用户自定义函数显示一条记录,这通过初始化参数track_functions来控制,默认不开启任何跟踪,视图结构如下:

mydb=# \d pg_stat_user_functions
 View "pg_catalog.pg_stat_user_functions"
   Column   |       Type       | Modifiers 
------------+------------------+-----------
 funcid     | oid              | 
 schemaname | name             | 
 funcname   | name             | 
 calls      | bigint           | 
 total_time | double precision | 
 self_time  | double precision | 

calls字段记录了对于用户函数进行过多少次调用;
total_time字段记录了运行这个函数总共消耗了多长时间(毫秒为单位),包括调用其它函数的时间;
self_time字段记录了运行这个函数本身消耗了多长时间(毫秒为单位),不包括调用其它函数的时间。

Oracle中没有类似的视图,Oracle的关于函数或者存储过程的执行统计信息,都是详细到其中每一条SQL语句的,实际上如果像PostgreSQL这样能有一个函数或者存储过程级别的性能统计值,也是极好的。

pg_stat_replication
在设置了复制的环境中,该视图对于每个WAL sender进程(WAL sender进程负责将本机的重做日志发送到远端复制环境)显示一条记录,显示内容大致如下:

postgres=# select pid,application_name,client_addr,state,sent_location,replay_location from pg_stat_replication;
  pid  | application_name |  client_addr   |   state   | sent_location | replay_location 
-------+------------------+----------------+-----------+---------------+-----------------
 27855 | walreceiver      | 192.168.56.105 | streaming | 0/50188CE8    | 0/50188CE8
(1 row)

每个视图中都能直接显示操作系统进程ID,实在是很方便的事情。在操作系统上可以直接查看pid=27855的进程。

[root@pg1-enmotech-com ~]# ps -ef|grep 2785|grep postgres
postgres 27855  1119  0 00:45 ?        00:00:00 postgres: wal sender process postgres 192.168.56.105(57046) streaming 0/50188CE8

从操作系统的ps命令中看到实际上已经将视图中的这些字段内容更新到了该进程描述中,在进程描述中会更新一些很有用的信息(比如server进程的状态,是等待还是空闲等),这也是PostgreSQL非常方便的一个地方。

在Oracle中与PostgreSQL的复制相类似的功能是Physical Data Guard,在DG中重做日志的传输是通过归档路径来完成的,因此类似的信息可以从V$ARCHIVE_DEST_STATUS和V$MANAGED_STANDBY视图中获取。

pg_stat_database_conflicts
该视图仅对于Standby数据库有效,对于每个数据库显示一条记录,显示内容如下:

postgres=# select * from pg_stat_database_conflicts;
 datid |  datname  | confl_tablespace | confl_lock | confl_snapshot | confl_bufferpin | confl_deadlock 
-------+-----------+------------------+------------+----------------+-----------------+----------------
     1 | template1 |                0 |          0 |              0 |               0 |              0
 13051 | template0 |                0 |          0 |              0 |               0 |              0
 13056 | postgres  |                0 |          0 |              0 |               0 |              0
 16384 | mydb      |                0 |          0 |              0 |               0 |              0
 24587 | mydb_bak  |                0 |          0 |              0 |               0 |              0
(5 rows)

由于PostgreSQL的机制,在备库上的查询会跟一些诸如删除表空间、删除数据库、vacuum cleanup的操作相冲突,为了不让备库的WAL replay操作延时太久,PostgreSQL内建了强制取消当前备库上运行的查询以避免跟应用重做日志这样更重要的动作相冲突的机制。而该视图则是记录由于不同原因取消掉的查询的次数。对于每个数据库显示一条记录。
Oracle中不会出现这样的问题,因此也没有相应的视图。

总结
当然,PostgreSQL中除了这些统计信息视图之外,还有不少类似于pg_tables,pg_users这样与Oracle中的数据字典视图相仿的视图,另外还有比如pg_locks这样用于记录锁信息的诊断视图。但是仅仅用一篇文章的长度就可以将所有的统计信息视图全部介绍完毕,PostgreSQL确实是很简洁的数据库。