當前參與交付的語音識別產品服務，算法模塊基于經典的Kaldi，算法中的一部分運行在GPU之上。
算法團隊采用的是聲學模型+語言模型的1-pass方案。這個方案的特點在于，語言模型數據文件（HCLG文件）的大小，和訓練語料的豐富程度正相關，即語言文本的語料越多，經過訓練、轉換后得到的語言模型文件越大。
經過數據團隊一段時間的努力，當前項目使用的語言模型，已經達到了 XX GB的規(guī)模。
這對我負責交付的算法服務組件帶來了全方位的挑戰(zhàn)：

• 版本構建，耗時接近30分鐘。
• 安全掃描，耗時接近30分鐘，運氣不好的話，可能會上升至1小時+。
• 版本上傳軟件倉庫，耗時至少10分鐘。
• 版本部署，耗時約30分鐘。
• 服務啟動，耗時5分鐘，其中主要時間都用來解析、加載語言模型文件。

平時在開發(fā)的部署環(huán)境上遠程調試業(yè)務時，需要反復給服務打補丁、重啟，由于啟動時間耗時在5分鐘，因此調試效率很低。受限于硬件規(guī)格，調試效率低的問題一直沒有很好的解決方法，于是開發(fā)小伙伴們只好忍著。

但終于有一天的晨會上，開發(fā)小伙伴向我抱怨，現在調試算法服務時效率非常低，啟動程序時，至少需要兩次，等待10分鐘，才能將程序運行起來。小伙伴們反復驗證，發(fā)現打補丁之后，第一次啟動算法服務時一定會啟動失敗。小伙伴反饋的這個信息，一開始我并沒有放在心上，但事后證明這是一個大的疏忽。

后來，我交付的一個需求，代碼在本地使用UT用例驗證完畢，進入在環(huán)境上做功能驗證的環(huán)節(jié)。這時由于需要反復的對環(huán)境打補丁、重啟服務，修復遠程調試過程中發(fā)現的問題，同樣的，我也遇到了小伙伴反饋的現象。不過這個現象被我誤判斷為網絡問題，因為那段時間網絡特別差，經常斷網，導致控制臺程序隨機斷開，這也會導致服務啟動不成功。
網絡的問題很好修復，并且持續(xù)的時間比較短。而我自己UT做的相對比較充分，因而花在遠程調試的時間比較短，因此業(yè)務需多次啟動的問題，對我的困擾不大。于是，這個多次啟動的問題被我輕易放過了。

版本轉測試之后，測試同事反饋兩個現象：

• 在配置中心修改配置后，無法自動生效。
• 測試同事部署新版本之后，需要至少需要啟動兩次，才能把服務正常運行起來。

這兩個現象都很奇怪。
對于第一個現象，我們基于基礎平臺來交付業(yè)務，很多產品的服務都使用這套框架，而我們團隊內部其它的服務也使用了這套框架，都沒有遇到過在配置中心修改配置后不生效的現象。
對于第二個現象，正常情況下，使用部署工具完成算法服務的部署之后，算法服務本身是應該處于運行狀態(tài)的。但測試同學發(fā)現使用最近的版本安裝完成之后，算法服務經常處于啟動失敗的狀態(tài)。而手工啟動時，至少需要兩次啟動，才能啟動成功。

測試同事是在做性能壓力測試的準備工作時觀察到的前述現象，雖然暫時不會阻塞性能測試，但本著懷疑一切、不能放過問題的精神，測試同事提交了問題單，要求盡快解決。于是，現在不能當成偶然事件放過了，需要認真對待，否則必然影響版本發(fā)布。

對于測試同事反饋的第一個問題，為便于后續(xù)的說明，這里先介紹一下配置管理的實現方案。
配置管理服務，包括配置中心和cnfg_agent。

• 配置中心集中部署，提供Web界面供用戶管理、維護應用服務的配置項和值。
• cnfg_agent和業(yè)務服務組件同機部署，使用相同的運行賬號，定時從配置中心服務讀取配置項和值，并寫入本地文件，由業(yè)務服務組件讀取。

經過觀察測試同事的環(huán)境，有如下發(fā)現：

• 環(huán)境上的cnfg_agent進程沒有處于運行狀態(tài)。手工啟動cnfg_agent后，在配置中心修改的配置值，可以被cnfg_agent正常同步至本地。由此可以確認cnfg_agent自身的業(yè)務功能是正常的。
• 兩次啟動算法服務后，發(fā)現cnfg_agent進程消失了，因此需要確認cnfg_agent消失的原因。

聯系配置管理服務的技術支持同學，了解到cnfg_agent的工作原理。

• cnfg_agent安裝過程中，安裝腳本會自動定義一個cron任務。
• 在cron任務的腳本代碼中，會主動檢查cnfg_agent進程是否存在，如不存在，則拉起cnfg_agent進程。

因此，即便是cnfg_agent由于自身的原因退出運行，理論上講，應該很快被定時運行的cron任務檢測到異常，并自動啟動，不應該出現cnfg_agent長時間處于離線狀態(tài)的現象。

進一步檢查測試同事提供的環(huán)境，發(fā)現一個新的現象。如前所述，cnfg_agent和業(yè)務組件同機部署，使用了相同的操作系統(tǒng)的賬號。檢查測試環(huán)境的主機，發(fā)現業(yè)務賬號恰好沒有創(chuàng)建cron任務的權限，這意味著安裝cron定時任務的操作一定失敗。因此當cnfg_agent進程退出后，沒有定時任務來檢測、并重新拉起cnfg_agent進程。這可以解釋為什么cnfg_agent消失后不能自動恢復運行。

于是，在測試環(huán)境上，手工給業(yè)務賬號增加創(chuàng)建、執(zhí)行cron任務的權限，并增加cnfg_agent的cron任務。之后嘗試多次重啟算法服務，發(fā)現cnfg_agent雖然會退出運行，但很快就會被cron任務拉起。
因此cnfg_agent進程退出后無法恢復運行的問題，可以使用本方法臨時規(guī)避。

繼續(xù)分析。

檢查cnfg_agent的日志文件，在啟動算法服務的時間點，找到了cnfg_agent退出運行的日志記錄。
對于我們提供的信息，配置管理服務的技術支持同學給出的答案是，cnfg_agent退出運行，通常只在操作系統(tǒng)重啟時才有可能會遇到。

按照這個答復，檢查/var/log/messages，居然真的找到了操作系統(tǒng)重啟的日志記錄，同時觀察到了內核crash的記錄。檢查時間點，發(fā)現啟動算法服務、cnfg_agent退出運行，這三件事的時間點相同。

這時，基本可以把算法服務第一次啟動失敗、cnfg_agent退出運行、操作系統(tǒng)重啟，這三件事情關聯在一起分析。

聯系操作系統(tǒng)專家，在其協(xié)助下，順利的找到了操作系統(tǒng)重啟的原因。原來是出現了內核crash現象，并且在出現問題的一臺主機上提取到了內核crash的相關記錄。
我們當前部署算法服務的主機，基于CentOS定制，安裝了kdump工具。操作系統(tǒng)專家依據kdump生成的crash信息，找到兩類原因：

• 主機的內存不足，觸發(fā)內核crash。
• GPU驅動的代碼中存在一處bug，申請內存后，沒有對指針判空，當申請內存失敗時，C庫返回的是空指針，這時GPU驅動的代碼直接操作這個指針，觸發(fā)了空指針異常，進而導致內核crash。

這兩個原因都和內存相關。
和操作系統(tǒng)專家、基礎設施專家交流后，依據他們的建議，選擇一臺存在問題的主機，提交擴充規(guī)格的申請，將內存放大一倍。再復現操作，發(fā)現算法服務只需一次即可正常啟動。

經反復重試后，確認：

• 內核不再crash。
• cnfg_agent不會出現重啟現象。
• 算法服務只需一次即可啟動。由于擴充規(guī)格后，CPU數量蠻多，現在啟動算法服務的時間也縮短了。

因而有理由推斷：

• cnfg_agent的意外重啟現象，和cnfg_agent自身的質量無關，和操作系統(tǒng)重啟強相關。
• 操作系統(tǒng)的重啟現象，主要由內核crash導致。
• 而內核crash現象，目前看和算法服務所在主機的硬件規(guī)格過低相關。
• 擴充規(guī)格后，一切問題現象全部消失。

將前述定位的信息同步給測試同事，經過討論之后，測試同事基本認可分析結論。
大家達成一致結論：

• 對于硬件規(guī)格不足的問題，同意調整測試環(huán)境中主機的規(guī)格，繼續(xù)執(zhí)行其余的驗證。
• 對于GPU驅動中存在的問題，需要算法同事介入，驗證高版本的GPU驅動是否解決了相關的問題。
• 假如高版本的GPU驅動解決了問題，涉及到的版本升級、版本部署包、安裝指導等的更新，暫時先放在任務清單。

后記：
升級硬件規(guī)格之后，操作系統(tǒng)內核crash的現象不再出現。但前述描述的原因和現象之間的關系，個人感覺還是有點牽強。比如在重啟應用時，這時系統(tǒng)其實處于空載狀態(tài)，內存占用率、顯卡的內存占用率，實際上比較低，但內核仍然會出現crash事件，比較怪異。由于不具備分析內核、驅動類故障的技能和經驗，并且無法獲得操作系統(tǒng)專家進一步的協(xié)助，因此本事件暫時放一放。

如下是kdump相關的帖子：文章來源地址http://www.zghlxwxcb.cn/news/detail-775120.html

• centos配置kdump捕獲內核崩潰
• CentOS7配置kdump

到了這里，關于ASR項目實戰(zhàn)-交付過程中遇到的內核崩潰問題的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網！