今年5月入主新公司担任架构师，作为敢为人先的技术人，新官上任三把火，各种更新公司的技术架构，期间踩了不少的坑，闲暇时间，便记录一下自己的踩坑之旅。这次讲一下版本库服务器gitlab的内存优化。
首先个人感觉，gitlab还是一个相当吃内存的应用。从官方推荐配置中也不难看出，要想获得流畅的使用体验至少4G双核，才玩的开，所以建议部署gitlab的服务器最好要这个配置。
介绍一下我使用的服务器的情况，我们版本库放在一台8核8G的公网服务器上，这是一台测试服务器，配置凑合，公司人又不是太多，我想跑gitlab应该ok。这台服务器上已经部署了很多nginx 服务、tomcat服务，还有mysql、pgsql数据库应用，以及之前版本库应用gitweb，等等杂七杂八还是很乱的。考虑规避未知的环境风险和未来的迁库，我优先考虑Docker容器来承载gitlab服务，以期减少后期的运维难度。
经过一番搜索找到了一个start较多的gitlab镜像，还是中文的，棒棒的！然后写了一个docker-compose编排文件，配置很简单，因为gitlab已经集成了http-server、dabase、还有监控、邮件、ssh等服务，只需要配好gitlab服务就OK。然后很顺利的启动了容器。
一切正常，风平浪静。经过简单测试也没什么问题，第二天周一上午，同事们纷纷开始往新的git仓库上迁移，使用了两天，虽然不是特别快，还OK。但是第三天， 访问gitlab web面板就特别慢，考虑到是测试服务器，带宽较小，加上开发工作比较繁忙，也没太注意。不就一个同事告诉服务器内存炸掉了！8G交换内存用掉了70%，我草，这是什么鬼？赶紧排查，发现tomcat服务居高不下吃掉了一半的内存。其次就是gitlab的进程占的内存。紧急关掉了daoker容器，内存就下来了，java进程内存占用也下来了。我感觉很奇怪？gitlab是ruby开发的，使用的是nginx server,跟tomcat应该半毛钱关系也没有啊。再说了tomcat是宿主机的服务，gitlab的服务都在容器里，应该不会相互影响。
一切都不能想当然！
所以，我首先进入了tomcat的http-server配置中查看，看到开启了一个端口为8080的web服务，至于这个服务干嘛的，我也不知到，同事也不清楚，只知道是客户的，我也不能轻易干掉或修改tomcat服务，就简单的限制了一下他JVM最大内存配置，重启docker容器，内存呼呼往上涨，而且随着我操作界面，直升不降。确定一定是容器影响到了宿主机里的tomcat服务。查看tomcat日志，发现了大量访问错误的日志。
这下可以确定了是容器里的服务访问到了tomcat，8080服务。
上网上查了一下gitlab的文档，才知道，gitlab内置的nginx只是代理转发服务器默认监听80端口，转发到内置的unicorn服务器，而内置的才是ruby真正的server,默认监听了8080。
这下我知道为什么了，我启动docker 时映射了80->到本地6666 443到4443，而8080未做映射， 我用箭头表示服务转发的流程：
gitlab客户端web请求 -> 宿主机Nginx：80 -> 域名指向：宿主机：6666 -> 容器中Nginx:80 -> 宿主机tomcat:8080
就是这样经过几次转发，服务最终被请求到了tomcat:8080，所以每次gitlab-docker容器启动后，tomcat就会居高不下。
解决办法：
修改gitlab的配置文件：gitlab.rb 位置在容器中的/etc/gitlab/config 如果你也用容器应该会和我一样把他挂在到本地。在配置文件中找到
unicorn['port']将其修改为不和宿主机冲突的端口号。如下：
### Advanced settings
# unicorn['listen'] = '127.0.0.1'
unicorn['port'] = 8081
重新编排docker-compose docker-composer up -d
服务完全起来后发下tomcat服务的内存占用果然没有上来，符合预期，同时，unicorn服务的进程内存占用去搞不下，看了一下，居然同时起了14个worker进程。继续优化unicorn服务。
再次打开gitlab.rb找到unicorn相关配置项：
其中包括：
unicorn['worker_processes'] ## worker进程数
unicorn['worker_memory_limit_min'] ##worker最小内存
unicorn['worker_memory_limit_max'] ##worker最大内存
根据你的使用人数和服务器配置，酌情减少这些配置。
再次重新编排服务，服务完全启动后，服务器内存稳定在2.7G，整个服务大约占了2G。Nice!!
