OS升级到RHEL 7.6后,GitLab遇到了PostgreSQL问题

时间:2019-06-21 05:20:32

标签: postgresql gitlab gitlab-ce

我们最近升级了操作系统:

$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.6 (Maipo)

升级后,我们在GitLab(主要是Postgres)方面面临很多问题。

我们的GitLab经过docker化,即GitLab(及其所有内部服务,包括PostgreSQL)都在单个容器中运行。容器没有自己的glibc,因此它使用的是操作系统中的容器。

  

错误:由于语句超时而取消语句

     

声明:
                    SELECT relnamespace :: regnamespace作为schemaname,                     relname作为relname,                     pg_class中的pg_total_relation_size(oid)个字节,其中relkind ='r';

超时消息连续出现,这导致用户访问GitLab时遇到502错误。

我检查了数据库上设置的语句超时。

gitlabhq_production=# show statement_timeout;
 statement_timeout
-------------------
 1min
(1 row)

我不知道该怎么做。这可能是默认设置。这是postgres的问题吗?这是什么意思?我能做些什么来解决这个问题?

编辑:

已检查pg_stat_activity,并且由于较早地重新引导了服务器,因此没有看到任何锁定。相同的查询现在可以正常运行,但我们会间歇性地看到此问题。

运行\d pg_class检查表是否使用任何索引,并检查字符串列。

gitlabhq_production=# \d pg_class
         Table "pg_catalog.pg_class"
       Column        |   Type    | Modifiers
---------------------+-----------+-----------
 relname             | name      | not null
 relnamespace        | oid       | not null
 reltype             | oid       | not null
 reloftype           | oid       | not null
 relowner            | oid       | not null
 relam               | oid       | not null
 relfilenode         | oid       | not null
 reltablespace       | oid       | not null
 relpages            | integer   | not null
 reltuples           | real      | not null
 relallvisible       | integer   | not null
 reltoastrelid       | oid       | not null
 relhasindex         | boolean   | not null
 relisshared         | boolean   | not null
 relpersistence      | "char"    | not null
 relkind             | "char"    | not null
 relnatts            | smallint  | not null
 relchecks           | smallint  | not null
 relhasoids          | boolean   | not null
 relhaspkey          | boolean   | not null
 relhasrules         | boolean   | not null
 relhastriggers      | boolean   | not null
 relhassubclass      | boolean   | not null
 relrowsecurity      | boolean   | not null
 relforcerowsecurity | boolean   | not null
 relispopulated      | boolean   | not null
 relreplident        | "char"    | not null
 relfrozenxid        | xid       | not null
 relminmxid          | xid       | not null
 relacl              | aclitem[] |
 reloptions          | text[]    |
Indexes:
    "pg_class_oid_index" UNIQUE, btree (oid)
    "pg_class_relname_nsp_index" UNIQUE, btree (relname, relnamespace)
    "pg_class_tblspc_relfilenode_index" btree (reltablespace, relfilenode)

是否可以为所有表重新编制索引,并且可能为alter表提供帮助?

1 个答案:

答案 0 :(得分:2)

您应检查查询是否在运行一分钟,或者是否在数据库锁后面被阻止。从后端的pg_stat_activity行可以看出这一点,该行将显示查询是否在等待锁定(state=activewait_event_typewait_event表示锁定)。

如果它是锁,请摆脱锁定事务。这可能是准备好的交易,所以也请检查一下。

如果没有错误锁,则可能是由于操作系统升级损坏了您的索引:

由于PostgreSQL使用操作系统归类,字符串上的数据库索引是按归类顺序排序的,并且由于C库中的错误修复,操作系统升级可能会(通常确实)导致归类更改,因此您应该在字符串上重建所有索引升级后的列。

您显示的语句未使用索引扫描,因此不应受到影响,但其他语句可能会受到影响。

此外,如果您使用的是Docker,则可能是您的容器使用了自己的未升级的glibc,因此您不会受到影响。