アップロード中にブラウザがクラッシュ？安定転送のための修正

ブラウザがアップロード中にクラッシュする場合、原因はほぼ常にタブのメモリ圧迫です。Chromeはおよそ2〜4GBのプライベートメモリを超えるタブを終了させ、10GBのファイルを単一のBlobオブジェクトに読み込む転送サービスはその上限を大きく超えます。解決策：File APIの slice() メソッドを介してファイルをチャンクでストリーミングするサービスを使う（最新のものはほとんどそうしています）、アップロード前に他のすべてのタブを閉じる、fetch/XHRにフックする拡張機能を無効にする、バッテリー駆動のノートパソコンではなくデスクトップでアップロードする。Firefoxは通常、ChromiumよりもメモリオーバーヘッドなしにFile APIの大容量ストリームを処理します。

ブラウザがアップロードでクラッシュする理由

2つのアーキテクチャ的事実が衝突します。第一に、すべてのブラウザタブは独自のメモリ上限を持つ別プロセスです。Chromeは64ビットシステムで各レンダラープロセスを約4GBに制限し、その後OOMキラーが介入します。第二に、JavaScriptでファイルをアップロードする素朴な方法は、File オブジェクト全体を fetch ボディに渡すことですが、ブラウザはしばしば送信前にメモリにバッファリングしようとします。

よく作られた転送サービスはこれを決してしません。File.slice(start, end) でファイルを読み取り、5〜20MBのチャンクごとにBlobを生成し、そのチャンクをアップロードしてから解放します。メモリはファイルサイズに関係なく、約 chunkSize * concurrency バイトに制限されたままです。

500MBの進行状況で問題なく開始したアップロードが、2GBでタブが灰色になる場合、サービスは送信前にすべてを読み込んでいます。別のサービスか別のアプローチを選んでください。

他のタブを積極的に閉じる

Chromeは一部のグループ化されたタブで単一のレンダラープロセスを共有します（サイト分離で変わりますが、メモリ圧迫はシステムレベルで依然として共有されます）。4KでYouTubeを再生する2番目のタブ、Figmaが読み込まれた3番目のタブ、800MBのRAMを消費するNotionの4番目のタブ、これらが積み重なります。8GBのRAMと12個のタブを開いたノートパソコンでの10GBアップロードは、火遊びです。

大容量アップロードを開始する前に、Chromeを完全に終了し、転送サービスのタブだけで再オープンします。アクティビティモニタ（macOS）またはタスクマネージャー（Windows）で、その単一タブでブラウザが2GB未満を使用していることを確認する必要があります。

拡張機能を無効にする

広告ブロッカー、プライバシー拡張機能、パスワードマネージャー、ネットワーク分析ツール（uBlock Origin、Privacy Badger、LastPass、HTTP Toolkit）はすべて、ネットワークリクエストに注入します。ほとんどは問題を引き起こしません。一部、特に古いコードを持つものは、リクエストボディをバッファリングして検査するため、ストリーミングアップロードを無効化しメモリを消費します。

シークレットウィンドウでテストします（拡張機能はデフォルトで無効）。シークレットでアップロードが正常に完了すれば、拡張機能が問題です。1つずつ有効にして犯人を見つけます。

GPUが弱い場合はハードウェアアクセラレーションを無効にする

古いノートパソコン、Intel UHD 620などの統合GPUを持つものは、プログレスバーの更新とファイル読み取りバッファを同時にレンダリングする際にクラッシュすることがあります。Chromeの設定 > システム > 「使用可能な場合はハードウェアアクセラレーションを使用する」をオフに切り替えられます。これは他のすべての滑らかさを失いますが、メモリ制約のあるシステムで大容量アップロードを安定化させます。

同様に、アップロードタブのChromeの「メモリセーバー」モードを無効にしてください。アップロード中の圧迫下でタブを退避させることが知られています。タブをピン留めするか、明示的に除外します。

超大容量ファイルではFirefoxに切り替える

Firefoxは歴史的にChromiumよりも厳しいメモリ予算でFile APIを処理します。Chromeで繰り返しクラッシュする10GBアップロードで、Firefoxは同じジョブを問題なく完了することがよくあります。よく作られたサービスでは違いは大きくありません（両方ともチャンクストリーミングを問題なく処理します）が、理想的でない実装のサービスでは、Firefoxの保守的なメモリモデルの方が寛容です。

macOSのSafariも大容量アップロードに信頼でき、ただしiOS Safariはバックグラウンドタブを積極的に終了させる点に注意してください。

タブをピン留めして前面に保つ

バックグラウンドタブは、メモリ圧迫下で最初に退避されます。アップロードタブを前面に保ちます。30分間別のウィンドウに切り替えて戻り、タブがリロードされていることに気づくのは避けてください。Chromeの「破棄された」タブは戻ったときに灰色のプレースホルダーを表示し、進行中のアップロードは死んでいます。

macOSでは caffeinate -s を使うか、アップロード中にWindowsの省電力スリープを無効にします。スリープ中のノートパソコンはWebSocketとXHR接続を閉じ、すべてのサービスがクリーンに再開できるわけではありません。

バッテリー駆動のノートパソコンではなくデスクトップからアップロードする

バッテリー駆動のノートパソコンはCPUとRAMを積極的に絞ります。macOSの「低電力モード」とWindowsの「バッテリーセーバー」はどちらもバックグラウンドタスクの優先度を下げ、AES暗号化とネットワーク書き込みを行うブラウザタブにとってはストールを意味します。

電源に接続します。バッテリーセーバーモードを無効にします。ノートパソコンにCPUパフォーマンスプロファイルの選択肢がある場合（Dell Power Manager、Lenovo Vantage）、期間中は「パフォーマンス」に設定します。

開始前にブラウザを再起動する

Chrome、Firefox、Edgeはすべて、長いセッションでゆっくりとメモリをリークします。40個のタブを開いたり閉じたりして2日間開いていたブラウザは、アップロードページを開く前から2GBのゾンビメモリを抱えている可能性があります。完全に終了し（macOSでは Cmd+Q、ウィンドウを閉じるだけではない、Windowsではタスクバーを右クリック > 終了）、再オープンします。

チャンクサイズをハードウェアに合わせる

チャンクサイズを設定できるサービス（ほとんどできませんが、rcloneなどの一部のCLIツールはできます）では、小さいチャンクはより少ないメモリを使用します。4つの並行ワーカーで5MBチャンクは、任意の時点で20MBのバッファです。4つのワーカーで100MBチャンクは400MBです。4GBのマシンでは、違いが重要です。

ウェブベースのサービスはデフォルトを選択し、通常はチャンクあたり5〜20MB範囲で、これは合理的です。しかしカスタムスクリプトは時々「より速く行く」ために大きなチャンクをデフォルトにし、小さなマシンで失敗します。

アップロード中にアクティビティモニタでRAMを確認する

アップロード中、ブラウザプロセスのメモリを監視します。macOSアクティビティモニタ：メモリタブ、ブラウザ名でフィルタ。Windowsタスクマネージャー：詳細タブ、「メモリ（プライベートワーキングセット）」でソート。

正常なチャンクアップロードは、進行状況に関係なく数百MBのブラウザメモリで安定します。アップロード進行状況と共にメモリが線形に増加する場合（10GBファイルの50パーセントで5GBに達する）、サービスはすべてをバッファリングしています。それがバグです。別のサービスを見つけてください。

大容量ブラウザアップロード向けに構築されたサービスを使う

よく設計された転送サービスは、暗号化用のWeb Workerプール、制限されたメモリ、失敗したチャンクへの明示的な再試行を備えたチャンクアップロードを使用します。HexaTransferはWeb Workerで File.slice() を介してファイルを読み取り、チャンクごとにAES-256-GCMで暗号化し、50MBを送信する場合でも転送あたり10GBの上限を送信する場合でも、ブラウザメモリを数百MB以下に抑えます。これは、ブラウザがすでに一日中扱っている他のすべてに対処しているときに重要です。

hexatransfer.comでお試しください — 無料、登録不要、最大10GB。