外付けSSDを使ったらVMWareの動作速度が飛躍した

外付けSSDを使ったらVMWareの動作速度が飛躍した

外付けSSDを使ったらVMWareの動作速度が飛躍した

Fusion DriveはVMを動かすのに向いていない。SSDを買おう。

どうもTAKUYAです。拙作のInkdropというノートアプリでは、Windows版・Linux版をビルドするためにmacOS上でVMWareを使用しています。しかし、特にWindowsのバーチャルマシンが死ぬほど重いという問題がありました。何かするたびにマウスポインタが砂時計になり、ほとんど使い物になりませんでした。

なのでこれまではAWSのEC2でWindowsインスタンス(m5.large)を利用してビルドしていました。でもこの方法だとビルドの際に毎回インスタンスを起動・終了する必要がありますし、たまに終了し忘れたりしました。EC2のコストは時間単位でかかる($0.124/h)ので、落ち着いて使用できないという問題もあり、とてもストレスフルでした。

VMWareのパフォーマンスを解決するために、ネットで見つかる様々な方法を試しましたが、微妙か全然効果が無いものばかりでした。設定をいじくるだけでは解決できないと諦めました。原因はI/Oの遅さということは分かっていたので、外付けSSDを取り付けてみたところやっと解決しました。自分のiMacはFusion Driveを搭載していますが、これがVMと著しく相性が悪いようです。本稿では、VMWareのパフォーマンス問題を解決するために行った事をシェアしたいと思います。

Fusion Driveでのパフォーマンス

Windowsに搭載されているツールwinsat を実行してディスクのランダムアクセス速度を計測しました:

λ winsat disk -drive c -write -ran
Windows システム評価ツール
> 実行中: 機能の列挙 ''
> 実行時間 00:00:00.00
> 実行中: 記憶域の評価 '-drive c -write -ran'
> 実行時間 00:00:14.98
> Disk Random 16.0 Write 1.95 MB/s
> 合計実行時時間 00:00:15.39λ winsat disk -drive c -read -ran
Windows システム評価ツール
> 実行中: 機能の列挙 ''
> 実行時間 00:00:00.00
> 実行中: 記憶域の評価 '-drive c -read -ran'
> 実行時間 00:00:10.97
> Disk Random 16.0 Read 1.57 MB/s
> 合計実行時時間 00:00:11.05

読み込み速度は 1.95 MB/s、書き込み速度は 1.57 MB/sでした。遅すぎますね。

アプリのビルドにかかる時間は7m 37.9sでした。待ち時間が苦痛です。

SSDでのパフォーマンス

C:\WINDOWS\system32>winsat disk -drive c -write -ran
Windows System Assessment Tool
> Running: Feature Enumeration ''
> Run Time 00:00:00.00
> Running: Storage Assessment '-drive c -write -ran'
> Run Time 00:00:00.42
> Dshow Video Encode Time 0.00000 s
> Dshow Video Decode Time 0.00000 s
> Media Foundation Decode Time 0.00000 s
> Disk Random 16.0 Write 332.60 MB/s
> Total Run Time 00:00:00.58C:\WINDOWS\system32>winsat disk -drive c -read -ran
Windows システム評価ツール
> 実行中: 機能の列挙 ''
> 実行時間 00:00:00.00
> 実行中: 記憶域の評価 '-drive c -read -ran'
> 実行時間 00:00:00.20
> Dshow ビデオ エンコード時間 0.00000 s
> Dshow ビデオ デコード時間 0.00000 s
> メディア ファンデーション デコード時間 0.00000 s
> Disk Random 16.0 Read 444.36 MB/s 8.2
> 合計実行時時間 00:00:00.25

読み込み速度は 332.60 MB/s に向上、書き込み速度も 444.36 MB/sに。素晴らしい!今の所、通常の操作でポインタが砂時計になって無意味に待たされることもなく快適に使用できています。

アプリのビルド時間は 4m 50.2sで、約3 m改善しました。まだ遅いですが、悪くないですね。

VMWareの設定で気をつけるところ

自分のケースでVMのI/O速度に大きく関わっていたのは、Hard DiskセクションのBus typeという設定項目でした。ここをIDEからSCSIに変更したところ、かなり改善しました。

外付けSSDをThunderboltで取り付ける

今回のために購入したデバイスは、WD BLACK SN750 NVMe 500GB (¥13,169):

それとThunderbolt 3に対応したSSDの外付けケース(TREBLEET社製) (¥14,899):

開封します。

SSDをケースに取り付けます:

そしてiMacに接続。なんの問題もなく動作しました。速度もバッチリ。

素晴らしい。他プラットフォームのビルドのためだけにもう一台コンピュータを購入する必要がなくなって良かったです。

SSDは結構発熱するので注意。あと、ケースのThunderboltコネクタ部分の接触が不安定で、動かすとすぐにアンマウントされてしまう点がネック。ハズレを引いたかもしれない。しかし安くない代物なので、その辺はしっかり作り込んでほしいところではある。自分はiMacのスタンドの後ろ部分にマジックテープで取り付けた。次にiMacを買う時はFusion DriveではなくSSDにしたい。

結論

ホストのMacがFusion Driveの場合は諦めてSSDを買おう。その費用は、VMWareの設定をいじって無駄な時間を大量に浪費する事に比べればずっと安いでしょう。

Read more

Inkdrop v6 Canary版リリースしました — 新Markdownエディタやその他新機能盛り沢山

Inkdrop v6 Canary版リリースしました — 新Markdownエディタやその他新機能盛り沢山

Inkdrop v6.0.0 Canary版リリースしました — 新Markdownエディタやその他新機能盛り沢山 こんにちはTAKUYAです。 v6.0.0 の最初の Canary バージョンをリリースしました 😆✨ v6では、アプリのコア機能の改善がたくさん盛り込まれています! * リリースノート(英語): https://forum.inkdrop.app/t/inkdrop-desktop-v6-0-0-canary-1/5339 CodeMirror 6 ベースの新しいエディタ フローティングツールバー v5ではツールバーがエディタの上部に固定されており、使っていないときもスペースを占有していました。 v6では、テキストを選択したときだけ表示されるフローティングツールバーに変わりました。 GitHub Alerts 構文のサポート Alerts の構文が正しい色と左ボーダーでハイライトされるようになりました。 ネストされたアラートや引用にも対応しています。 また、アラートタイプの入力を支援する補完機能も追加されました。 スラッシュコマンド 空行で /

By Takuya Matsuyama
AIのお陰で最近辛かった個人開発がまた楽しくなった

AIのお陰で最近辛かった個人開発がまた楽しくなった

AIのお陰で最近辛かった個人開発がまた楽しくなった こんにちは、TAKUYAです。日本語ではお久しぶりです。僕はInkdropというプレーンテキストのMarkdownノートアプリを、デスクトップとモバイル向けにマルチプラットフォームで提供するSaaSとして、かれこれ9年にわたり開発運営しています。 最近、その開発にClaude Codeを導入しました。エージェンティックコーディングを可能にするCLIのAIツールです。 最初の試行は失敗に終わったものの、徐々に自分のワークフローに馴染ませることができました。そして先日、アプリ開発がまた「楽しい」と感じられるようになったのです。これは予想外でした。 本稿では、自分がエージェンティック・コーディングをワークフローに取り入れた方法と、それが個人開発への視点をどう変えたかを共有します。 * 翻訳元記事(英語): Agentic coding made programming fun again 自分のアプリに技術的負債が山ほどあった ご想像のとおり、9年も続くサービスをメンテするのは本当に大変です。 初期の頃は新機能の追加も簡単で

By Takuya Matsuyama
個人開発を7年以上続けて分かった技術選択のコツ

個人開発を7年以上続けて分かった技術選択のコツ

個人開発を7年以上続けて分かった技術選択のコツ InkdropというMarkdownノートアプリを作り続けて7年になる。 お陰さまでその売上でずっと生活できている。 これまで個人開発でどう継続していくかについて「ユーザの退会理由をあれこれ考えない」とか「アプリの売上目標を立てるのをやめました」とか、ビジネス面あるいはメンタル面からいろいろ書いてきた。 今回は、技術面にフォーカスして、どう継続して開発していくかについてシェアしたい。 TL;DR * 最初はとにかく最速でリリースする事を最優先する * 迷ったら「ときめく方」を選べ * 程よいところで切り上げて開発を進める * 使っているモジュールがdeprecatedされるなんてザラだと覚悟する * 古いから悪いとは限らない * シンプルにしていく * 老舗から継続の秘訣を学ぶ * 運ゲー要素は排除しきれない 最初はとにかく最速でリリースする事を目標に技術選定する 開発計画とビジネス計画は切っても切り離せない。 コーディングに傾倒するあまり完璧主義に陥って結局リリース出来ないまま頓挫してしまう個人開発者は多い

By Takuya Matsuyama
子育て中の個人開発者の一日

子育て中の個人開発者の一日

子育て中の個人開発者の一日 どうもTAKUYAです。 久しぶりに生活まわりの事を書きたい。自分はInkdropというMarkdownノートアプリを売って生きている。 子供も無事順調に成長しており、あと数ヶ月で3歳になるというところで、イヤイヤ期もやっと終わりが見えてきた。 生活パターンもなんとなく定着しつつあるので、ここで一旦どんなルーティンなのか書き出してみる。ちなみに当方今年で40歳。 平日の1日の流れ * 06:30 妻と子供起床、朝食 * 07:10–30 俺起床、朝食 * 07:40 布団を畳んで子供を着替えさせる。妻はその間に化粧や通勤の準備 * 08:00 ストレッチと軽い筋トレ(腕立て50回、スクワット100回) * 08:10 妻と子供を見送る。15分前後瞑想 * 08:30 散歩 * 09:00 作業開始(カフェまたは家) * 11:00 昼飯 * 12:00 ダラダラする * 12:30 作業再開(だいたい家)

By Takuya Matsuyama