docker 容器中的 postgresql 启动缓慢

Question

我们使用 postgresql 构建了一个 debian docker 镜像来运行我们的一项服务。数据库供内部容器使用，不需要端口映射。我相信它是通过apt-getDockerbuild 文件安装的。

我们经常停止和启动这个服务，数据库启动慢是一个性能问题。虽然是空​​的，但在我们第一次启动 docker 镜像时，似乎需要 20 多秒才能接受连接。日志如下：

2019-04-05 13:05:30.924 UTC [19] LOG:  could not bind IPv6 socket: Cannot assign requested address
2019-04-05 13:05:30.924 UTC [19] HINT:  Is another postmaster already running on port 5432? If not, wait a few seconds and retry.
2019-04-05 13:05:30.982 UTC [20] LOG:  database system was shut down at 2019-04-05 12:57:16 UTC
2019-04-05 13:05:30.992 UTC [20] LOG:  MultiXact member wraparound protections are now enabled
2019-04-05 13:05:30.998 UTC [19] LOG:  database system is ready to accept connections
2019-04-05 13:05:30.998 UTC [24] LOG:  autovacuum launcher started
2019-04-05 13:05:31.394 UTC [26] [unknown]@[unknown] LOG:  incomplete startup packet
2019-04-19 13:21:58.974 UTC [37] LOG:  could not bind IPv6 socket: Cannot assign requested address
2019-04-19 13:21:58.974 UTC [37] HINT:  Is another postmaster already running on port 5432? If not, wait a few seconds and retry.
2019-04-19 13:21:59.025 UTC [38] LOG:  database system was interrupted; last known up at 2019-04-05 13:05:34 UTC
2019-04-19 13:21:59.455 UTC [39] [unknown]@[unknown] LOG:  incomplete startup packet
2019-04-19 13:21:59.971 UTC [42] postgres@postgres FATAL:  the database system  is starting up
[...]
2019-04-19 13:22:15.221 UTC [85] root@postgres FATAL:  the database system is starting up
2019-04-19 13:22:15.629 UTC [38] LOG:  database system was not properly shut down; automatic recovery in progress
2019-04-19 13:22:15.642 UTC [38] LOG:  redo starts at 0/14EEBA8
2019-04-19 13:22:15.822 UTC [38] LOG:  invalid record length at 0/24462D0: wanted 24, got 0
2019-04-19 13:22:15.822 UTC [38] LOG:  redo done at 0/24462A8
2019-04-19 13:22:15.822 UTC [38] LOG:  last completed transaction was at log time 2019-04-05 13:05:36.602318+00
2019-04-19 13:22:16.084 UTC [38] LOG:  MultiXact member wraparound protections are now enabled
2019-04-19 13:22:16.094 UTC [37] LOG:  database system is ready to accept connections
2019-04-19 13:22:16.094 UTC [89] LOG:  autovacuum launcher started
2019-04-19 13:22:21.528 UTC [92] root@test LOG:  could not receive data from client: Connection reset by peer
2019-04-19 13:22:21.528 UTC [92] root@test LOG:  unexpected EOF on client connection with an open transaction

有什么解决这个启动问题的建议吗？

编辑：有些人请求 dockerfile，这里是相关的行

RUN apt-get update \
 && apt-get install -y --force-yes \
    postgresql-9.6-pgrouting \
    postgresql-9.6-postgis-2.3 \
    postgresql-9.6-postgis-2.3-scripts \
    [...]

# Download, compile and install GRASS 7.2
[...]

USER postgres
# Create a database 'grass_backend' owned by the "root" role.
RUN /etc/init.d/postgresql start \
&& psql --command "CREATE USER root WITH SUPERUSER [...];" \
&& psql --command "CREATE EXTENSION postgis; CREATE EXTENSION plpython3u;" --dbname [dbname] \
 && psql --command "CREATE EXTENSION postgis_sfcgal;" --dbname [dbname] \
 && psql --command "CREATE EXTENSION postgis; CREATE EXTENSION plpython3u;" --dbname grass_backend

WORKDIR [...]

workdir 后的文件结尾，这意味着我猜数据库没有正确关闭

回答我停止正常的PostgreSQL里面的泊坞窗安装。现在启动快了 15 秒。感谢回复

Answer 1

考虑到database system was not properly shut down; automatic recovery in progress肯定会解释启动缓慢的那一行，请不要杀死服务，发送停止命令并等待它正常关闭。

请注意，如果停止需要很长时间，系统可能会终止该进程，如果仍有连接（可能来自您的应用程序），则在 postgresql 的情况下会发生这种情况。如果您断开所有连接而不是停止，则 postgresql 应该能够相对较快地停止。

还要确保在关闭之前停止容器内的 postgresql 服务。

TCP 将延迟连接一段时间，如果您在没有正确停止内部服务的情况下快速连续启动和停止，这将解释您为什么端口不可用的错误，通常该服务可以在我的机器上快速连续启动/停止，如果没有任何东西与之相关。

我的机器上 3 个 postgresql 的启动-停止周期（我有 2 个大小合适的数据库）

$ time bash -c 'for i in 1 2 3; do /etc/init.d/postgresql-11 restart; done'
 * Stopping PostgreSQL 11 (this can take up to 92 seconds) ...                        [ ok ]
 * /run/postgresql: correcting mode
 * Starting PostgreSQL 11 ...                                                         [ ok ]
 * Stopping PostgreSQL 11 (this can take up to 92 seconds) ...                        [ ok ]
 * /run/postgresql: correcting mode
 * Starting PostgreSQL 11 ...                                                         [ ok ]
 * Stopping PostgreSQL 11 (this can take up to 92 seconds) ...                        [ ok ]
 * /run/postgresql: correcting mode
 * Starting PostgreSQL 11 ...                                                         [ ok ]

real    0m1.188s
user    0m0.260s
sys     0m0.080s