gitlab 安装问题

安装方式：

  1. 通过百度离线下载功能下载gitlab的rpm（这样下载速度回快些）
  2. 安装rpm
  3. 修改配置文件

测试：

出现问题如下：

刚安装好就出现这样的问题，太让人不解了（关键是在不同的机器上用相同的方式安装，有时候就是好的）

经过N翻折腾，无果，还是直接去代码里面调试吧；

信息1： pre-receive hook

信息2： The project you were looking for could not be found.

在目录 /opt/gitlab 中搜索关键字： The project you were looking for could not be found.

发现文件： /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/git_access.rb  修改此文件：

重新测试，不报错了，而且提交成功了。先这样吧

由于ruby实在一点儿也不了解，没法debug，遂在z.cn买了一半ruby的入门书

纠结的进程关系

进程P起了两个进程p1和p2，然后wait(p1); p1通过管道写数据到p2；当p2工作异常后，p1写给p2的数据不能被处理，导致管道阻塞了p1；当发现p2异常后，试图kill -9 杀死p2；纠结出现了：

P当前只wait(p1),对于p2的死不做任何反应，由于暂时没人为p2收尸，p2只能处于<defunct>状态，虽然p2已经注定了死亡的命运，但是p1和p2之间的管道依然存在（还没被销毁，可见，p2的资源是需要P来回收的），p1将不会得到任何异常通知，依然在等待； 于是乎，出现了循环等待了。

解决办法倒是比较简单，把P给kill了就行了；只是这个状态比较纠结

gitlab 里面的runsvdir 居然能把进程的错误写到进程名上，如下（省的你看不见？）：

nginx+fpm 之长连接问题

长连接避免了每次请求都重新建立连接，理论上是好事儿，欣然用之；后发现nginx偶尔会报如下错误：

而且有同事A反应，调用同事B的接口时，收到了200响应码，但是没有收到响应的其他数据，而且确认不是因为超时所致；同事B反馈说，接口执行正常，应该有数据返回，而且确认接口执行速度很快，日志为证。

双方说的都对，事实却是如此，我试图模拟这种情况的出现，模拟办法：

让接口输出响应码后，直接杀死fpm进程，nginx果然报出了几乎一样的错误；但是实际场景中，没有发现fpm猝死的任何蛛丝马迹，也找不到fpm会在响应头输出之后就猝死的理由；

按照以前的风格，我将通过看源码、调试等方式查个水落石出，现在不想了，先把长连接关掉试试吧；（凭啥直接怀疑长连接？凭直觉）

现在，长连接关了有一周时间了，没有再出现类似错误；还有好多更重要的事情要做，先不纠结这个了；服务器端建立连接的代价也没有大到不可以接受，先这样吧！

wordpress 环境搭建

WordPress 环境搭建需要安装： PHP、Mysql、Apache（当然nginx+fpm也行）

源代码编译安装很拽吗？不，我不喜欢，全部yum安装。

安装的mysql5.1，不支持utf8mb4；

添加yum源：

这个yum源有好些很新的东西，如：php7，好吧，也体验下php7

原本WordPress使用的httpd，需要的.htaccess都在，基本不需要设置，只注意修改:

其实yum安装挺方便的。

卸载后低版本的mysql后，安装高版本的mysql，数据会被保留，包括数据库的密码

php gd 库编译

前言

。。。

安装依赖

安装devel的时候会自动安装相应的lib的，所以这样就行；gd支持的更多的libvpx  libxpm  这些用不到，就不编译进去了

编译

完事儿会有一个gd.so

 

当有了gd.so后，在其他机器上就没有必要再编译了，直接copy gd.so 自然不好使，因为依赖的库文件可能没有，需要：

注意，这里是不需要devel的

gitlab 备份恢复与迁移

这里只介绍使用rpm包方式安装时的备份恢复与迁移

转载： http://segmentfault.com/a/1190000002439923

Gitlab 创建备份

使用Gitlab一键安装包安装Gitlab非常简单, 同样的备份恢复与迁移也非常简单. 使用一条命令即可创建完整的Gitlab备份:

使用以上命令会在/var/opt/gitlab/backups目录下创建一个名称类似为1393513186_gitlab_backup.tar的压缩包, 这个压缩包就是Gitlab整个的完整部分, 其中开头的1393513186是备份创建的日期.

Gitlab 修改备份文件默认目录

你也可以通过修改/etc/gitlab/gitlab.rb来修改默认存放备份文件的目录:

/mnt/backups修改为你想存放备份的目录即可, 修改完成之后使用gitlab-ctl reconfigure命令重载配置文件即可.

Gitlab 自动备份

也可以通过crontab使用备份命令实现自动备份:

加入以下, 实现每天凌晨2点进行一次自动备份:

Gitlab 恢复

同样, Gitlab的从备份恢复也非常简单:

Gitlab迁移

迁移如同备份与恢复的步骤一样, 只需要将老服务器/var/opt/gitlab/backups目录下的备份文件拷贝到新服务器上的/var/opt/gitlab/backups即可(如果你没修改过默认备份目录的话). 但是需要注意的是新服务器上的Gitlab的版本必须与创建备份时的Gitlab版本号相同. 比如新服务器安装的是最新的7.60版本的Gitlab, 那么迁移之前, 最好将老服务器的Gitlab 升级为7.60在进行备份.

gitlab 安装

gitlab安装 有麻烦的方法： https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/install/installation.md

也有简单的方法： https://about.gitlab.com/downloads/#centos6

yum安装或者脚本安装实在太慢，即使走代理也很慢； 当然，可以:

如果不小心断网又得从来，不可取。

俺的办法是： 用百度的离线下载功能先把rpm： https://packages.gitlab.com/gitlab/gitlab-ce  下载下来，百度离线下载几分钟就能搞定，然后，再从百度下载rpm，再然后：

安装完成后有提示接下来该怎么做，我建议你接下来不要着急配自己的nginx，而是直接enable  rpm中自带的nginx

配置文件基本只有一个： /etc/gitlab/gitlab.rb

修改完直接：

根本不用stop start;

注意：千万不要stop的时候reconfigure，这样总是出错，start状态下直接reconfigure还挺快的

 

配置见下篇

 

大并发下的死锁

一直不觉得什么样的代码逻辑才会在小并发下没问题，而在大并发下有问题，今天终于见到了。

今天做一个压力测试，刚刚开始，程序就无法响应了；小伙伴说，重启一个服务吧，我说，还是查查为啥吧，于是发现如下问题：

环境介绍：

  1. 数据库连接池，限制最多100个链接
  2. 代码中有一个方法设置了同步（无法多个线程同时执行到该代码，锁等待）
  3. JAVA多线程环境

代码逻辑为：

  1. begin 事务
  2. 执行同步方法
    1. 同步方法中可以需要执行sql语句，需要一个空闲的数据库连接（该逻辑比较深，不太容易注意到），如果获取不到数据库连接，就等待（如果非要加一个期限的话，实际上是无限期）
  3. 执行其他sql查询
  4. 结束

当100个请求同时执行到步骤1的时候，其中一个线程抢先进入了同步方法，但是不幸的是，虽然抢先进入了同步方法，但由于数据库连接已耗尽，只好等待；但是现在其它线程拿着数据库连接却由于等待在同步方法外而无法释放数据库连接，于是，死锁出现。。。

debug过程

由于bug是在高并发下出现的，不宜单步调试，只能从出错的状态中去分析。

第一步： jstack $pid

…. (有N多线程的堆栈就出来了）

第二步： 分析堆栈

很多线程被block，推测：应该有个线程（的堆栈）和别人不太一样； 果然如此

第三步： 参照堆栈和代码，分析得到结果

 

解决办法：

。。。