Sumzap Engineering Blog

サムザップのエンジニアブログです。技術情報や会社のエンジニア文化などを日々発信していきます。

サムザップのエンジニアブログです。
技術情報や会社のエンジニア文化などを日々発信していきます。

Sumzap Engineering Blog

長期運用タイトルにおけるAssetBundleビルド時間短縮の為のTips

title_image

はじめに

弊社の長期運用タイトル「戦国炎舞 -KIZNA-」では、ビルド時間が短くなるようにAssetBundleのビルドは差分ビルドで行うようにしています。
しかし、差分ビルドしているにも関わらず、「メモリ不足」と「AssetBundleのビルド時間が長い」問題が発生していました。
今回は、この問題を解決した方法について書きたいと思います。
長期運用中のタイトルで同じような事象が発生したら、今回の対応内容が参考になれば幸いです。

ビルド環境について

AssetBundleビルドはMac Pro上にJenkinsを構築して自動ビルドを行うようにしています。
下記、ビルドマシンのスペックになります。

【ビルドマシンのスペック】
Mac Pro(Late 2013)
OS:macOS Sierra

このAssetBundleビルドマシンが1号機と2号機とあり、下記の区別で使用しています。

ビルドマシン1号機:主に本番用ビルドで使用。使用していない時は開発用ビルドで使用。
ビルドマシン2号機:開発用ビルドで使用。

ビルドマシン1号機はリリース当初から使用しているとの事だったので、6年以上使っているマシンです。
今回は、本番で使用しているビルドマシン1号機のジョブに問題が発生していました。

発生していた問題

ビルドマシン1号機の発生していた問題は2つありました。
1. 偶に「メモリ不足」でビルドが止まるときがある
2. AssetBundleビルド時間が開発用ビルドのビルドマシン2号機よりも長い

使用可能なメモリ容量を増やす

メモリ不足でビルドが止まるときがある問題については、使用可能なメモリ容量を増やすことで解決しました。

1. 現在使用中のメモリ容量を確認する

アクティビティモニターの「メモリ」タブで確認できます。

アクティビティモニター_メモリ

当初は物理メモリ64GBのうち、キャッシュされたファイルが40GB以上を占めていました。
この場合、実際に使用できるのは20GBもないことになり、これがメモリ不足となっている原因でした。
圧縮されて確保されるメモリが多少は増えるとは言え、他のアプリケーションもあるので実際にUnityが使えたメモリ容量は少なかったです。

キャッシュされたファイルに不要なものをピックアップして、使用できるメモリを解放してあげれば良さそうかも…?

って事で、不要なキャッシュされたファイルを確認してみました。

2. 不要なキャッシュされたファイルを確認する

キャッシュされたファイルには、Finderでoptionキーを押しながら[移動] > [ライブラリ]で開き、その中のCachesディレクトリに入っているようです。
ファイルサイズでソートすると、運用が長く、Unityのバージョンアップを複数回しているためか、Unity関連っぽいものが複数ありました。

現在のUnityバージョンで使用していないものは全て不要そうなので、現在のUnityバージョンで使用しているCacheがどれか確認してみました。

3. 現在のUnityバージョンで使用しているCacheがどれか確認する

使用しているCacheを確認するには、UnityのPreferencesを開きます。

Unity_Preferences_Cache

このGI Cacheの「Cache Folder Location」を見るとCaches/com.unity3d.UnityEditorを使用していることが分かります。

それ以外のUnityEditor関連のCacheは不要そうなので、念のため更新日も確認しつつ、不要なCacheを削除するだけです。

結果(不要なCacheを削除したあとの結果の部分)

物理メモリ64GBのうち、キャッシュされたファイルが40GB以上を占めていたものが…

アクティビティモニター_メモリ改修後

10GB未満まで減らすことができました!

コレでメモリ不足で止まることはなくなりました!
が、ビルド時間が長い…

こちらが実際にビルドした時のパイプラインです。

対応前

大体3.5h〜4.5hくらい…長すぎる…

したがって、またビルド中にアクティビティモニターを確認します。

CPU使用率を下げる

1. CPU使用率を確認する

アクティビティモニターの「CPU」タブで確認できます。
ビルド中のCPU使用率とビルドしていない時のCPU使用率を確認したところ、ビルドしていない時にも関わらず60%以上使用している状態になっていました。
CPU使用率に影響してそうなものは下記でした。

  • TmLoginMgr:ウイルスバスター関連。今はウイルスバスターを使っていないので止める。
  • mdworker:Spotlight関連。検索する時に必要なindexを書き込むものっぽい。Spotlightは使うことがあるので、今回は止めない。
  • kernel_task:名前的に止めるとマズそう。おそらく、冷却のファンとか。

2. TmLoginMgrを止める

TmLoginMgrは強制終了しても勝手に再起動してしまうので、必要がない場合はアンインストールする必要があります。

3. mdworkerを止める場合

Spotlightを使わない場合は、下記のようにして止めても良いかもしれないです。

$ sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.metadata.mds.plist

下記で起動出来ます。

$ sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.metadata.mds.plist

メール関連がSpotlight止めると問題があるっていう情報もあったので、止める場合は確認を念入りにした方が良さそうです。
参考:mds_stores、mdworker、mdsプロセスを停止させた方法【酷暑のmacに最適です】 | mac野郎なのか

結果(CPU使用率を削減したあとの結果)

ビルドしていない時にも関わらず60%以上使用していたものが…

対応後_CPU

一桁未満まで減らすことができました!

コレでビルドに使えるCPUが確保できました!

最終結果

対応前と対応後の比較がこちらになります。

【対応前】
対応前

【対応後】
対応後

比較画像を比べて分かる通り、3時間ほど時間短縮しています。
※差分量などにより、多少ビルド時間は前後します

使用可能なメモリ領域を確保してあげて、不要なCPU使用率を減らす事で、ビルド時間を短くすることに成功しました。
今回の対応内容的に、長期で使っているほど起こりうるものかと思います。
差分ビルド入れるなどして対策入れている長期運用のプロジェクトで同じような事象が発生したら、今回の対応内容が参考になれば幸いです。

Windowsは明示的にアンインストーラ返してApp削除するけど、Macのアプリケーション削除は普通のファイルと同じようにゴミ箱に持っていって、ゴミ箱を空にするだけだから、消しきれないで残っちゃうのかもしれない…
って、思いました。