HTTP 502: Whoops, GitLab is taking too much time to respond.

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
云原生数据库 PolarDB PostgreSQL 版,标准版 2核4GB 50GB
云原生数据库 PolarDB MySQL 版,通用型 2核4GB 50GB
简介: 最近有台云上的服务器需要释放,然后上面跑的 gitlab 也要挪个地方,如在 docker 内运行,gitlab 镜像大约 1.56G,需占用 4G 以上的内存,因资源有限,于是借在其他的服务器上搭建环境(可用内存小于4G),然鹅启动的时候莫名出现 502,Excuse me?接着搜了一些 issue 博客上的解决方案(如修改端口、重启或 hup 某个服务)无果,后来在调整的过程中从日志里发现了一些信息。

这次排错过程主要是思路,视野打开后会觉得豁然开朗,原来这其实是个小问题[尴尬]。

1、没注重应用启动的各服务及其用途,只会简单查看 status;

2、看到错误第一时间想到的是 Baidu(没其他意思),找找 logpath 先看日志不好吗?

3、未认识到服务之间的关联关系(比如 postgresql 与 unicorn 之间),前面一直知道 unicorn 启动后没正常监听到端口,但是日志并没啥特别信息(嗯,可能是因为看错了文件)[苦笑]


 一、错误信息





二、排错过程

1、启动 unicorn 未监听端口

日志路径 :   /var/log/gitlab/unicorn/unicorn_stderr.log

PG::ConnectionBad: could not connect to server: No such file or directory
        Is the server running locally and accepting
        connections on Unix domain socket "/var/opt/gitlab/postgresql/.s.PGSQL.5432"?

  /opt/gitlab/embedded/lib/ruby/gems/2.3.0/gems/activerecord-4.2.10/lib/active_record/connection_adapters/postgresql_adapter.rb:651:in `initialize'
  /opt/gitlab/embedded/lib/ruby/gems/2.3.0/gems/activerecord-4.2.10/lib/active_record/connection_adapters/postgresql_adapter.rb:651:in `new'
  /opt/gitlab/embedded/lib/ruby/gems/2.3.0/gems/activerecord-4.2.10/lib/active_record/connection_adapters/postgresql_adapter.rb:651:in `connect'
  /opt/gitlab/embedded/lib/ruby/gems/2.3.0/gems/activerecord-4.2.10/lib/active_record/connection_adapters/postgresql_adapter.rb:242:in `initialize'
  /opt/gitlab/embedded/lib/ruby/gems/2.3.0/gems/activerecord-4.2.10/lib/active_record/connection_adapters/postgresql_adapter.rb:44:in `new'
  /opt/gitlab/embedded/lib/ruby/gems/2.3.0/gems/activerecord-4.2.10/lib/active_record/connection_adapters/postgresql_adapter.rb:44:in `postgresql_connection'

··· ···
··· ···

信息显示是因为连不上PG,所以启动 postgresql 后重启即可正常(嗯,是酱)。。

2、postgresql down

down: postgresql: 0s, normally up, want up; run: log: (pid 623) 15816094s

通过 PG 的日志路径 : /var/log/gitlab/postgresql/current 可以查看到如下信息

2018-11-01_08:18:09.49669 FATAL:  could not map anonymous shared memory: Cannot allocate memory
2018-11-01_08:18:09.49671 HINT:  This error usually means that PostgreSQL's request for a shared memory segment exceeded available memory, swap space, or huge pages. To reduce the request size (currently 4292984832 bytes), reduce PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.
2018-11-01_08:18:09.49671 LOG:  database system is shut down

也可以通过命令 `gitlab-ctl tail postgresql`,得到一样的信息,于是可以确定问题。。

This error usually means that PostgreSQL's request for a shared memory segment exceeded available memory, swap space, or huge pages. To reduce the request size (currently 4292984832 bytes), reduce PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.
2018-11-01_07:52:06.63024 LOG:  database system is shut down

于是在配置文件中对 postgresql 的 shared_buffers 和 max_connections 两项进行了限制

[root@V2 ~]# cat /etc/gitlab/gitlab.rb |grep -v ^$ |grep -v ^#
external_url 'http://xxx.xxx.xxx.xxx.xxx:8090'
unicorn['worker_timeout'] = 60
unicorn['worker_processes'] = 3
unicorn['listen'] = 'xxx.xxx.xxx.xxx.xxx'
unicorn['port'] = 8870
postgresql['enable'] = true
postgresql['data_dir'] = "/var/opt/gitlab/postgresql/data"
postgresql['shared_buffers'] = "256MB"   # ! **recommend value is 1/4 of total RAM, up to 14GB.**      
postgresql['max_connections'] = 200
nginx['listen_addresses'] = ['*']
nginx['listen_port'] = 8090

配置完成保存,之后更新配置,重启应用即可。

gitlab-ctl reconfigure       # 更新配置
gitlab-ctl restart           # 重启应用
gitlab-ctl status            # 查看服务状态


相关实践学习
使用PolarDB和ECS搭建门户网站
本场景主要介绍基于PolarDB和ECS实现搭建门户网站。
阿里云数据库产品家族及特性
阿里云智能数据库产品团队一直致力于不断健全产品体系,提升产品性能,打磨产品功能,从而帮助客户实现更加极致的弹性能力、具备更强的扩展能力、并利用云设施进一步降低企业成本。以云原生+分布式为核心技术抓手,打造以自研的在线事务型(OLTP)数据库Polar DB和在线分析型(OLAP)数据库Analytic DB为代表的新一代企业级云原生数据库产品体系, 结合NoSQL数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
目录
相关文章
|
Linux 开发工具
Gitlab - 安装的社区版 Gitlab-ce,解决访问网页报502-Whoops, GitLab is taking too much time to respond的问题
Gitlab - 安装的社区版 Gitlab-ce,解决访问网页报502-Whoops, GitLab is taking too much time to respond的问题
1289 0
Gitlab - 安装的社区版 Gitlab-ce,解决访问网页报502-Whoops, GitLab is taking too much time to respond的问题
Whoops, GitLab is taking too much time to respond.问题解决
Whoops, GitLab is taking too much time to respond.问题解决
548 1
Whoops, GitLab is taking too much time to respond.问题解决
|
7月前
|
Linux 应用服务中间件 网络安全
linux安装Gitlab
linux安装Gitlab
176 0
|
4月前
|
Shell Docker 容器
GitlabCI学习笔记之一:安装Gitlab和GitLabRunner
GitlabCI学习笔记之一:安装Gitlab和GitLabRunner
|
3月前
|
Docker 容器
Docker安装Gitlab和Gitlab-Runner并实现项目CICD
Docker安装Gitlab和Gitlab-Runner并实现项目CICD
|
5月前
|
Devops 持续交付 开发工具
入职必会-开发环境搭建54-GitLab下载和安装
GitLab 是一个基于 web 的 Git 仓库管理工具,提供了代码托管、版本控制、协作开发、持续集成等功能,是一个综合的 DevOps 平台。用户可以使用 GitLab 托管他们的代码仓库,并利用其丰富的功能来管理和协作开发项目。 以下是 GitLab 的一些主要特点和功能。
入职必会-开发环境搭建54-GitLab下载和安装
|
4月前
|
Ubuntu 安全 网络安全
在Ubuntu 16.04上安装和配置GitLab的方法
在Ubuntu 16.04上安装和配置GitLab的方法
82 0
|
4月前
|
存储 Ubuntu 安全
在Ubuntu 18.04上安装和配置GitLab的方法
在Ubuntu 18.04上安装和配置GitLab的方法
86 0
|
4月前
|
缓存 Kubernetes Shell
CI/CD:安装配置Gitlab Runner
CI/CD:安装配置Gitlab Runner
378 0
|
6月前
|
持续交付 开发工具 git
阿里云云效产品使用问题之在云效代码域中gitlab使用docker安装的,迁移时遇到“获取企业信息失败”,是什么原因
云效作为一款全面覆盖研发全生命周期管理的云端效能平台,致力于帮助企业实现高效协同、敏捷研发和持续交付。本合集收集整理了用户在使用云效过程中遇到的常见问题,问题涉及项目创建与管理、需求规划与迭代、代码托管与版本控制、自动化测试、持续集成与发布等方面。

相关实验场景

更多