Reduce memory usage

[YamatoSecurity]

Hayabusaが結構メモリを使用していることに気づいたので、13.7 GBのデータに対して様々のHayabusaバージョンを比較してみました。
最近、沢山のメモリを使用しているだけではなくて、解析が終わったら（ファイルを保存している間は）メモリ使用が急に数GB増えまてしまいます。

バージョン	スキャンが100%の時点	スキャンが終わったら(ファイル保存している間)	Unique検知数	処理時間	出力されるファイルのサイズ	備考欄
1.8.0-dev (mimalloc導入後)	約 10 GB	約 18 GB	742	28分	1.3 GB
1.8.0-dev (mimalloc導入前)	約 10 GB	約 16.6 GB	742	40分	1.3 GB	JSON, JSONL機能やDetailsをJSONオブジェクトとして出力する機能の作成のため一部ベクトルは作成しているがそこまで都度初期化しているためそこまで大きなメモリ利用にはつながらない……はず。EIDフィルタを無効にしたので、処理時間が33分から40分になった。
1.7.0	約 11 GB	約 16.8 GB	741	33 分	1.3 GB	メトリクスオプションとhtmlレポート機能の追加のみのためオプションを付けなければメモリ利用量には影響なし
1.6.0	約 12.3 GB	約 19.6 GB	741	34 分	1.5 GB	json、jsonL形式出力機能( #654 #694) オプションを付けていなければメモリ利用量には影響なし
1.5.0	約 12 GB	約 19.5 GB	738	34 分	1.5 GB	profile機能(#165) profileのエイリアスから実際のデータに置き換えるために一旦データを持つ必要があるためメモリ利用量が上がると思われる
1.4.3	約 5.7 GB	約 7.7 GB	738	35 分	2.0 GB	VC再頒布パッケージ対応のため個々ではメモリ利用量が大きく上がる要因はなさそう
1.4.2	約 5.7 GB	約 7.7 GB	738	35 分	2.0 GB	#479 並列処理の改善の導入。解析後、一旦4.8GBに落ちるが、その後7.7GBに徐々に増える。
1.4.1	約 5.9 GB	約 5 GB	738	35 分	2.5 GB	解析後にメモリが4.7GBに落ちるが、その後5GBに徐々に上がる。detailsが指定されていない場合は全フィールドを抽出するための可能性がある。EIDフィルタがデフォルトで有効になってので、5分速くなる。
1.4.0	約 5.7 GB	約 4.6 GB	745	40 分	2.4 GB	恐らく誤検知が出ているので検知数が一番多い
1.1.0	約 3.9 GB	約 2.7 GB	733	40 分	1.6 GB

1.4.2で初めて解析後にメモリが急に増えます。
1.5.0でメモリ利用量が倍以上なります。

検証する際はhayabusa-sample-evtxとWindowsイベントログのベースラインファイルhttps:/NextronSystems/evtx-baseline/releases/download/v0.7/all-evtx.tgzの両方が入っているディレクトリを対象にしたら良いと思います。

[kazuminn]

書き出すときにsortで並び替える実装になってますが、「ソートのアルゴリズム次第で空間計算量は、落とせそうだな」と思います。

[hitenkoku]

@YamatoSecurity Releaseを見て各機能でメモリ利用量が大きくなりそうなところがないかを備考欄に書いてみました。私が作ったところで余計なcloneとかをしていないかどうか並行して確かめてみますね。

バージョン	備考欄
1.8.0-dev	JSON, JSONL機能やDetailsをJSONオブジェクトとして出力する機能の作成のため一部ベクトルは作成しているがそこまで都度初期化しているためそこまで大きなメモリ利用にはつながらない……はず
1.7.0	メトリクスオプションとhtmlレポート機能の追加のみのためオプションを付けなければメモリ利用量には影響なし
1.6.0	json、jsonL形式出力機能( #654 #694) オプションを付けていなければメモリ利用量には影響なし
1.5.0	profile機能(#165) profileのエイリアスから実際のデータに置き換えるために一旦データを持つ必要があるためメモリ利用量が上がると思われる
1.4.3	VC再頒布パッケージ対応のため個々ではメモリ利用量が大きく上がる要因はなさそう
1.4.2	#479 並列処理の改善の導入。解析後、一旦4.8GBに落ちるが、その後7.7GBに徐々に増える。
1.4.1	解析後にメモリが4.7GBに落ちるが、その後5GBに徐々に上がる。detailsが指定されていない場合は全フィールドを抽出するための可能性がある。(#606) EIDフィルタがデフォルトで有効になってので、5分速くなる。
1.4.0	約 5.7 GB
1.1.0	約 3.9 GB

[fukusuket]

ご参考まで修正後バージョンと以前のバージョンでベンチマークをとってみました。
1.8.0-devが、1.5.0以降ではスピード、メモリ使用量ともに一番良いパフォーマンスでした🚀

ベンチマーク結果
(以下メモリ使用量には、OSなど常時アプリの使用メモリ量も含むため、Hayabusaが使っている実際のメモリは以下結果から-3.3GB程度)

バージョン	メモリ使用量(平均)	メモリ使用量(最大)	Unique検知数	処理時間	出力されるファイルのサイズ	備考欄
1.8.0-dev	7.11 GB	10.07 GB	145	00:13:15.955	576.5 MB
1.7.2	7.76 GB	13.03 GB	145	00:14:55.626	576.5 MB
1.7.1	7.57 GB	13.02 GB	145	00:14:54.227	576.5 MB
1.7.0	7.49 GB	12.92 GB	145	00:14:42.070	576.5 MB
1.6.0	7.40 GB	12.69 GB	145	00:14:39.477	576.5 MB
1.5.0	7.18 GB	12.81 GB	145	00:14:37.316	578.4 MB
1.4.3	5.82 GB	7.40 GB	145	00:14:20.190	782.6 MB
1.4.2	5.82 GB	7.41 GB	145	00:14:21.482	782.6 MB
1.4.1	5.76 GB	6.87 GB	145	00:14:14.849	874.4 MB

ベンチマーク環境

• OS: Windows 10 Home edition
• Hard: Memory 16GB , Core 8, laptop
• Data: こちらの6.1 GBデータ
• PowerShell v7(Get-Counterを使うため)

ベンチマーク取得手順

1. hayabusa.exe -u でルール最新化
2. RAMMapでファイルキャッシュクリア
3. 以下PowerShell(v7必須)でパフォーマンスカウンタ取得(メモリ、CPU)

Get-Counter -Counter "\Memory\Available MBytes",  "\Processor(_Total)\% Processor Time" -Continuous | ForEach {
     $_.CounterSamples | ForEach {
         [pscustomobject]@{
             TimeStamp = $_.TimeStamp
             Path = $_.Path
             Value = $_.CookedValue
         }
     }
 } | Export-Csv -Path PerfMonCounters.csv -NoTypeInformation

5. hayabusa.exe -d <ディレクトリ> -o out.csv
6. 結果をまとめ

↑ベンチマーク結果をbenchmark.zipに添付