作为AI人工智能互联网公司，和算法部门对接成为常态。
一言不合就各种jni调用、内存指针地址、进程奔溃、内存泄漏..
查找问题时一般除了java自带的jdk工具还需要会：
strace(调试诊断代码),
pmap(进程内存分析),
pstack（打印正在运行的进程的栈跟踪信息）,
perf(性能瓶颈分析cpu/io或代码段==推荐比较全好用),
google-perftools(堆外内存泄漏分析)
通过perf工具帮助算法部门定位到某图像算法的瓶颈，并把性能从并发20左右提升到60
通过google-perftools把原因图像识别进程的内存从不断上涨到50G,稳定到15G。
。。。
事情还没有结束。
最核心的是：算法部门的图像识别模型有2个T\2000GB、而且随着图像识别范围的增强，数据模型越来越大。
最初来时，数据只有几百GB，而且尚未集群化部署。因此数据只在图像识别服务器上。
但随着商用化，识别服务的高可用、可伸缩部署势在必行。
此时你可能会说，直接把这些数据放到一个共享盘不就解决了？
数据大小（已经完成数据瘦身）：
确实，我们最开始也是这么想的，于是研究了阿里云的nas盘。
弄了一天一夜，在凌晨四点终于可以验证的时候，发现图像识别的性能随着并发测试，
越来越慢，只能达到10个并发，这可不是单机的数据，而是集群部署的并发数据！
随后，开始了性能瓶颈的研究，也反馈了阿里云工程师（凌晨4点阿里云工程师还是锲而不舍的陪着我们上云），
阿里云也很快给出了优化措施，调整系统的磁盘配置参数。随后进行并发测试，发现有所提升。但不明显。
在随后，我们这边的研究也有结果了，发现nas盘读取众多的小文件比较慢，而且随着并发越高，读取就越慢。
反馈阿里云工程师后，他们给了结果：nas盘是有文件锁的，io能力，并发能力有限。并推荐了几款其他的共享盘，
不过都没有通过并发测试的关卡，最后此次上云失败~！
休整一天后，重新理了一遍上云的问题，并寻找咨询各种可以支持业务的共享数据盘模式，最终由于我们的业务模式
所决定，共享数据盘达不到本地数据盘的性能要求。
转而考虑用户实时业务在本地盘进行，增量模型数据在共享盘的方式。
不过，这么大的数据量，且需要随着能进行自动增量的更新，同时又不影响现有的业务。
最开始想的是通过自己来实现数据存储与分发。
在过程中经过一系列的业务流程思考、异常情况的考虑，发现我们要解决
的问题：较大的数据中心盘、增量更新中心盘、增量更新异常时能回退版本、中心盘数据分发到其他机器本地盘、
其他机器本地盘可以自动且安稳的同步数据....
最后发现，这不就有点像我们用来做代码管理的GIT吗。
于是，运用GIT的原理与服务解决我们业务问题的实践就在此时展开。
2T的数据、可随时更新、还能有版本回退等业务场景，在Google上搜索了一下，基本上没有人这么用过，
有个解决大文件的方式其原理还是:本地中心存储引用，指向远程仓库大文件。这明显不符合我们要求。
在运用GIT的过程中还算比较顺利，只是有几个问题在使用时出现：
stackoverflow上提交的问题:https://stackoverflow.com/questions/59403597/how-to-optimize-2000gb-git-data
1、数据仓库大，初始化要半天
2、数据仓库占用是无git的2倍
3、增量数据的提交耗时也比较久，根据数据量大小在0.5-5小时左右
4、其他机器本地盘拉取数据根据提交数据量大小和仓库大小耗时也比较久
5、pull过程中由于仓库过大git经常进行GC、导致cpu高，且gc效果不大
6、增量更新过程中并发提交问题
解决:
1、通过模型数据瘦身，把不必要的数据去掉只保留算法识别要的数据。（后续还可以分仓库）
2、如上解决
3、使用比较好的磁盘，速度快很多，不过当达到3T以上且有速度要求的还是要分仓库
4、半夜或业务闲时进行数据同步、定时同步
5、把local仓库的gc配置为关闭：git config --local gc.auto 0
6、把提交权限收紧，并做好检查