作爲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、把提交權限收緊，並做好檢查