[發明專利]存儲服務器的性能分析方法及裝置、電子設備

有效

• 申請號: 202010568680.2
• 申請日: 2020-06-19
• 公開（公告）號: CN111756575B
• 公開（公告）日: 2023-08-11
• 發明（設計）人: 邵立強;張旭明;王豪邁;胥昕
• 申請（專利權）人: 北京星辰天合科技股份有限公司
• 主分類號: H04L41/14
• 分類號: H04L41/14;H04L67/1097
• 代理公司: 北京康信知識產權代理有限責任公司 11240
• 代理人: 董文倩

本發明公開了一種存儲服務器的性能分析方法及裝置、電子設備。其中，該方法包括：確定存儲服務器的軟件棧架構上的多個系統服務層，其中，每個系統服務層對應有待探測的目標函數的函數標識，軟件棧架構部署在預設運行軟件環境中；基于函數標識，向預設運行軟件環境的探測內核中注入探針模塊；通過探針模塊對目標函數的運行狀態進行探測，得到目標探測信息；將目標探測信息存儲至目標緩沖區中，以分析存儲服務器的運行性能。本發明解決了相關技術中分析存儲服務器性能時，由于探測模塊無法與內核緊密集成，導致使用方式過于復雜的技術問題。

技術領域

本發明涉及服務器分析技術領域，具體而言，涉及一種存儲服務器的性能分析方法及裝置、電子設備。

背景技術

相關技術中，隨著計算機存儲技術的快速發展，存儲方式從傳統存儲漸漸轉變到分布式存儲，隨之而來的不僅僅是技術發展帶來的便利和效益，同時也面臨的一個問題就是隨著軟件架構和業務邏輯越來越復雜，若生產環境出現性能問題，工程師就需要花費大量的精力來解決生產環境上出現的存儲性能問題，需要花費工程師大量的時間和精力。造成這種問題的原因主要就是缺乏有效的定位手段和工具。

當前，用來分析存儲服務器性能的技術主要包括如下兩種類型：靜態追蹤和動態追蹤。其中，靜態追蹤包括埋點和分析dump文件兩種方式；所謂埋點就是在代碼關鍵路徑里面添加一些用來記錄性能數據或者記錄日志信息的代碼；而分析dump文件的方案為：事先在程序中添加收集當前程序運行時信息和堆棧信息后生成dump文件的功能，然后再靜態分析工具來觀察當時程序運行情況。而動態追蹤主要為：DTrace(Dynamic?Tracing，用來在生產和試驗性生產系統上找出系統瓶頸的工具)。DTrace是一個非常通用的調試平臺，它提供了一種很像C語言的腳本語言，叫做D語言，基于DTrace的調試工具都是使用這種語言編寫的，D語言支持特殊的語法用以在某個運行環境的內核函數的入口或出口設定探測模塊，也或者是在某個用戶態進程的函數入口或出口設定探測模塊。

但是當前的存儲服務器性能分析方式都存在明顯的弊端，對于靜態分析的埋點和分析dump文件的方式來說，主要存在的問題是無法預估信息收集的量，可能出現收集的太多影響程序本身運行，或者收集太少不足以分析問題的情況。并且在出現問題后再添加埋點就需要重新運行程序會導致現場破壞，所以這些方式對于在線調試是不切合實際的。而傳統的性能分析工具，如Perl的DProf、C世界里的gprof、以及其它語言和環境的性能分析器(profiler)，往往需要用特殊的選項重新編譯程序，或者以特殊的方式重新運行程序，這種需要特別處理和配合的性能分析工具，顯然并不適用在線的實時活體分析。

而對于動態分析的Dtrace方式來說，弊端是使用方式過于復雜、不方便、工具的開發移植難、輸出不夠直觀等。由于設置的探測模塊并不是程序運行環境Linux內核的一部分，沒有與內核緊密集成，因此設置的探測模塊需要不停地追趕主線內核的變化，導致追蹤成本高、學習成本高。另一個缺點是，在設置探測模塊，通常需要將“小語言”腳本(有點像D語言)動態編譯成一個Linux內核模塊的C源碼，因此經常需要在線部署C編譯器工具鏈和Linux內核的頭文件，這樣就需要大量占據客戶端內存，降低了程序運行環境的自身工作效率。

針對上述的問題，目前尚未提出有效的解決方案。

發明內容

本發明實施例提供了一種存儲服務器的性能分析方法及裝置、電子設備，以至少解決相關技術中分析存儲服務器性能時，由于探測模塊無法與內核緊密集成，導致使用方式過于復雜的技術問題。

根據本發明實施例的一個方面，提供了一種存儲服務器的性能分析方法，包括：確定存儲服務器的軟件棧架構上的多個系統服務層，其中，每個所述系統服務層對應有待探測的目標函數的函數標識，所述軟件棧架構部署在預設運行軟件環境中；基于所述函數標識，向所述預設運行軟件環境的探測內核中注入探針模塊；通過所述探針模塊對所述目標函數的運行狀態進行探測，得到目標探測信息；將所述目標探測信息存儲至目標緩沖區中，以分析所述存儲服務器的運行性能。