同步大文件到gitlab导致内存溢出

本文主要是介绍同步大文件到gitlab导致内存溢出，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

同步大文件到gitlab导致内存溢出

　　今天补一下3月16日的笔记。

一、问题引入

　　曾经我在防篡改监控的文章里提过，开发说不要把内网大文件上传到gitlab上【参考之前文章：https://www.cnblogs.com/windysai/p/14354460.htm

 　　当时我也就听听，想着记住有这么回事，不要做这种骚操作就行。然后某天领导下发了一个任务，叫我把内网服务器的数据备份到线上，因为担心内网服务器会崩溃，主要是担心整个esxi宿主机，上面有各种虚拟机，有几台就是走上面截图的线路进行文章发布的。

　　这个定时上传其实是以一个静态目录的方式传到gitlab上的，假设叫做：status_ljy，里面有目录：html， r， u和文件：index.html 。

　　我备份的时候，实际上进去的是status_ljy，单独一个个小目录进行备份的。为啥这么搞，因为一大个status_ljy目录异常庞大，传输到线上容易中断，而且貌似不支持断点续传的。拆分成3个目录，比整个status_ljy备份传输会好点

　　于是没考虑这么多，就运行这堆命令对备份到线上的内网目录进行压缩打包：

1 [ljy@local-123-tomcat status_ljy]$ tar -cvf html.tar.gz_20210316_bak html
2 [ljy@local-123-tomcat status_ljy]$ tar -cvf r.tar.gz_20210316_bak r
3 [ljy@local-123-tomcat status_ljy]$ tar -cvf u.tar.gz_20210316_bak u

　　留意一开始说的那个线路图，把status_ljy整个目录定时单向传输到gitlab。上面的备份命令运行完，备份文件实际上是在 status_ljy 目录里面的。问题出现了：敲一个命令，半天没有反应，我一开始还以为中毒。好不容易运行top命令，发现这台local-123的机器负载非常高，git进程把服务器资源吃光了：

 　试着连接宿主机esxi，重启这台机器，报错内存溢出：

 　　于是干脆把这机器关了，硬件设置里给它加内存，无果。。。

　　 这么多git进程，强制kill进程过一会儿又出来。想想也就是定时任务把文章传输到gitlab，再到线上这里用到。为了不增加服务器负载，就停了这个定时任务。然后手动运行同步脚本：

 　　看着就是有个index.lock文件，类比mysql异常退出，也有个lock文件，不删除无法重新启动的方法，我试着去删掉，没用！

 运行同步脚本上 git add . 卡死，不得不“ctrl + z” 强制终止。

二、原因发现及解决过程

 　　当时我还没醒觉到具体是什么原因导致的，直到登上gitlab，发现多了些备份目录：u.tar.gz_20210316_bak等。然后就很急了（因为工作日运营的人发文章同步不了会找到我），直接在gitlab的web页面上删掉这些html.tar.gz_20210316_bak，r.tar.gz_20210316_bak。。。

　　然后报错信息变了，git add 说找不到提交过的文件

查看gitlog提交日志：

14:29:33  的时候刚好是我备份完这些目录的时候，脚本自动把备份目录传到gitlab上了！！！

三、问题最终解决　　

 这句是解决问题的关键：failed to push some refs to ‘xxxxx'

 　　不得不git pull 手动同步gitlab上最新目录status_ljy下来，相当于这条单向传输给我掰过来了。原来定时脚本是从内网 ——》 gitlab，恢复得从 gitlab ——》 内网。

 　　　这个delta 3 这个日志就是把手动在gitlab删除的记录同步到内网上的

最终git 日志恢复正常，如下，删掉了误操作的文件：

四、反思+总结

　　（1）第一次知道大文件传输到gitlab上会导致服务器崩溃的

　　（2）既然是单一传输路径，按规范行动：在内网删掉大文件，然后利用定时脚本传输到gitlab上删除，而不是直接在gitlab上进行操作，把内网——》gitlab这步直接跳过，导致当前分支落后于远程分支而报错。

这篇关于同步大文件到gitlab导致内存溢出的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！