2026/04/03 23:42

課題：本番環境でディスク容量が不足しています。

RSS: https://news.ycombinator.com/rss

要約▶

Japanese Translation:

記事では、4 GB RAMと40 GBの Hetzner サーバーで NixOS を動かしていた環境が、2 つの設定ミスによりディスク容量を使い果たしたケースを説明しています。まず、Nix ストア（

/nix/store

）と Plausible Analytics の ClickHouse データベースが約 23 GB を消費し、

nix-collect-garbage

が空き領域を確保できず、ジャーナルログのみがクリーンアップ可能でした。Nix ストアを別の 15 GB ボリュームに移動したことで使用量はほぼ半分になりましたが、重いダウンロード時にはディスク使用率が 100 % に達していました。次に、2.2 GB のファイルダウンロードが失敗した原因は、nginx が応答を一時ファイルにバッファリングしていたこと（デフォルトの

proxy_max_temp_file_size

は 1024 m）でした。

lsof +L1

を実行すると、削除済みファイルで約 14.5 GB が nginx に保持されていることが確認でき、問題を裏付けました。バッファリングを無効化（

proxy_buffering off; proxy_max_temp_file_size 0;

）することでダウンロード失敗は解消し、一時ファイルの使用も排除されました。これらの変更後、Grafana のメトリクスが改善し、ディスク使用率は約 20 % 程度に落ち着き、再び急激な増加は起こりませんでした。本投稿では、Nix ストアの移動と nginx バッファリング設定の正しい調整の両方が、小規模ホスティング環境でダウンタイムを防ぎ、保守コストを削減するために不可欠だったことを強調しています。

本文

昨晩、シンプルなサーバーを立ち上げました。
顧客がデジタル版「Kanjideck」のファイルをダウンロードできるようにしたものです。
サーバーは NixOS（4 GB RAM、40 GB ディスク）を動作させた小型の Hetzner マシン上にホストしています。
この中でダウンロード可能なファイルの一つは 2.2 GB です。

構成は次の通りです。

静的ファイルを配信する Haskell プログラム（認可処理付き）
nginx のリバースプロキシがリクエストを Haskell プログラムへ転送

最初にパニック

ファイルがようやく利用可能になったと発表して数分も経たないうちに、数百人の顧客が一斉にサーバーを訪れました。
ログはスクリーンから飛び散り、あるメッセージが何度も繰り返し表示されることに気付きました。

Mar 31 20:43:03 mogbit kanjideck-fulfillment[2528300]: user error
(Unexpected reply to: MAIL "<...> at kanjideck.com",
Expected reply code: 250, Got this instead: 452 "4.3.1 Insufficient system storage\r\n")

誰もファイルにアクセスできず、メールでの報告が殺到しました。
Grafana では 40 GB / 40 GB（すなわち

/dev/sda

が 100 % 使用）という状態でした。
スペースを早急に確保しないとメールサーバーも書き込み不能になりかねません。

du -sh

を実行すると、最大の二つの原因が判明しました。

パス	サイズ
`/var/lib/` （Plausible Analytics, clickhouse データベース）	8.5 GB
`/nix/store` （サーバー構成・インストール・実行ファイル）	15 GB

これらを削除することにしました。

Nix ストアのクリア

最初の試み：

$ nix-collect-garbage -d

結果：

removing old generations of profile /nix/var/nix/profiles/system
error: opening lock file '/nix/var/nix/profiles/system.lock': No space left on device

Nix ストアはデバイス上に空きが無いのでクリアできませんでした。
まずスペースを確保する必要がありました。

ログの削減

$ journalctl --vacuum-time=1s

これで十分なスペースが確保され、再度 Nix ストアをクリーンアップできます。

ClickHouse データベースの縮小

system.query_log

テーブルを truncate しようとしました：

$ clickhouse-client -q "TRUNCATE TABLE system.query_log"

結果：

Received exception from server (version 24.3.7):
Code: 243. DB::Exception:
Cannot reserve 1.00 MiB, not enough space.

再び空きが無くなりました。

Nix ストアを別ボリュームにマウント

Hetzner が追加容量のインスタンスを提供しないため、別途ボリュームを購入しました。

ファイルシステム作成：
```
mkfs.ext4 -L nix /dev/sdb
```
NixOS Wiki の手順でストアを移動し、以下の宣言的設定を追加：

fileSystems."/nix" = {
  device        = "/dev/disk/by-label/nix";
  fsType        = "ext4";
  neededForBoot = true;
  options       = [ "noatime" ];
};

再起動後、

/nix/store

は新しいボリューム上に移動し、ルートディスクはようやく十分な空きが確保されました。
Grafana の赤い表示も消え、エラーメッセージのストリームも止まりました。
ファイルシステム使用率は 50 % 前後（ユーザーが 2.2 GB ファイルをダウンロードすると約 60–65 %）にとどまりました。

Nginx の根本原因調査

大容量ファイルのダウンロードバグ

ユーザーから、2.2 GB ファイルが途中で停止し完了できないという苦情が寄ってきました。

proxy_max_temp_file_size

を確認すると、デフォルトは 1024 m です。
これを 5000 m に増やすと、2.2 GB ファイルの配信に成功しました。

高負荷時のディスクスペース急上昇

その日の後半、ディスク使用率が一瞬で 100 % に戻りました。

lsof +L1

を使ってリンクが切れたまま開かれているファイルを調べました。

$ lsof +L1 | grep nginx

結果は 14.5 GB の削除済みファイルが nginx に保持されていることを示しました（一時プロキシバッファ）。

サイズ合計：

$ lsof +L1 | awk '/nginx/ {sum += $7} END {print sum/1024/1024/1024 " GiB"}'
 14.5528 GiB

これらは nginx がレスポンスをディスクにバッファリングしているために作成された一時ファイルです。

プロキシ設定の修正

Nginx の設定を次のように更新しました：

"<...>.kanjideck.com" = base {
  "/" = {
    proxyPass = "http://127.0.0.1:" + toString(ports.kanjideck-fulfillment) + "/";
    extraConfig = ''
      proxy_buffering off;
      proxy_max_temp_file_size 0;
    '';
  };
};

nginx をリロードすると、Grafana は即座に改善し、サーバーは再び軽量化。ディスク使用率は 20 % にまで低下しました。

結論

サーバーは起動後約 20:40 〜 23:00 の最初の二時間、アクセスリクエストに応答できませんでした。
大容量（2.2 GB）のファイルはダウンロードできず、他のファイルは利用可能でした。
これら両方の問題は nginx リバースプロキシの設定ミスによるものでした：
- ```
proxy_max_temp_file_size
```
  が大きいファイルに対して低すぎた
- バッファリングが有効だったため、ディスク上に大量の一時バッファが蓄積

プレッシャーの下ではこうした細部を見落としやすく、経験があればパニックや「空き容量不足」のエラーを回避できたでしょう。

同じ日のほかのニュース

一覧に戻る →

2026/04/08 3:09

**プロジェクト・グラスウィング：AI時代における重要ソフトウェアの保護**

## Japanese Translation: Project Glasswingは、AWS、Microsoft、Google、Cisco、Apple、Broadcom、JPMorgan Chase、NVIDIA、Palo Alto Networks、およびLinux Foundationを含む主要なクラウド・ソフトウェア・金融企業を結集し、Anthropicの未公開Claude Mythos Preview AIを用いて高重大性のソフトウェア脆弱性を発見・修正することを目的としています。Mythos PreviewはすでにOpenBSD、FFmpeg、およびLinuxカーネルで重要なバグを検出し、その後メンテナがパッチを適用しました。Anthropicはパートナー向けに最大1億ドルの使用クレジットと、オープンソースセキュリティグループへの追加400万ドルの寄付を提供しており、40社以上の組織もモデルアクセスを受け取ります。参加者は90日以内に調査結果を公開し、ベストプラクティスを共有し、脆弱性開示、自動パッチング、安全な開発ライフサイクル、およびサプライチェーンセキュリティに関する推奨事項を策定する予定です。このイニシアチブは米国政府担当者と協力してツールの攻撃および防御機能を評価し、最終的には独立した組織が業界・公共部門全体で継続的な大規模サイバーセキュリティ作業を調整する可能性があります。研究プレビュー後、AnthropicはMythos PreviewをClaude API、Amazon Bedrock、Google Vertex AI、およびMicrosoft Foundry経由で参加者に対し1百万トークンあたり25ドル／125ドルで提供する予定です。

2026/04/08 0:03

「月のフライバイ」

## Japanese Translation: オリオン宇宙船は、NASA のアーテミス II ミッションに乗組みされ、2026年4月6日に月を周回しながら一連の写真を撮影しました。クルー（パイロット・ビクター・グローバー、指揮官リード・ウィスメン、ミッションスペシャリストジェレミー・ハーネスとクリスティーナ・コック（さらにカナダ宇宙機関のアストロノート・ハーネス））はオリオンの窓から、EDT 18:41に地球沈没、ET 19:22に地球昇起、および月面の詳細な映像を記録しました。1枚の画像ではオリオンの前景から月と地球の両方が同時に写っており、別のクローズアップは周回の終盤（約3:41）に撮影されました。ハーネスは観測期間中に窓2にカメラシャードを装着し、いくつかのショットでは日食時に太陽が月面を背光し、左端で太陽が昇り、ほぼ1時間続いたシーケンスの終わりまで撮影されました。午後2:19には画像の左半分が月表面で満たされました。オリオン自体は複数の写真で日光を浴び、その輪郭が宇宙空間に浮かぶ姿が際立っています。この改訂された要約は、将来の設計への影響について推測的な結論を避けつつ、すべての主要ポイントを網羅しています。

2026/04/08 4:44

S3ファイル

## Japanese Translation: Andy Warfield のチームは **S3 Files** を構築しました。これは、ユーザーが Amazon S3 バケットまたはプレフィックスを EC2、コンテナ、または Lambda 上の NFS スタイルネットワークファイルシステムとしてマウントできるシステムです。この設計では EFS がステージングに使用されます。ファイル変更はローカルで書き込まれ、その後約 60 秒ごとに自動的に S3 に *コミット* されます（起動時には手動コミット制御はありません）。複数のクライアントが同じオブジェクトを修正した場合、conflict‑resolved コピーが lost+found ディレクトリに保持されます。メタデータは遅延でハイドレーションされ、小さなファイルは即時ロードされ、大きなファイルは読み込み時にストリーミングされるため、数百万オブジェクトを持つバケットでも迅速にマウントできます。大規模な連続読み取りはローカルキャッシュをバイパスし、並列 GET を介して直接 S3 にアクセスすることで、クライアントあたり約 3 GB/s の速度を実現し、多数のクライアントにわたって拡張可能です。システムは S3 の IAM ポリシー、オブジェクトの不可変性、および命名セマンティクスを保持しつつ、完全な NFS スタイルファイル操作（パーミッション、原子リネーム、ディレクトリトラバーサル）を公開します。ただし、S3 にはネイティブなリネームがないため、リネーム操作は高コストであり、有効な POSIX ファイル名にマッピングできないキーはマウントから除外されます。 Warfield の以前の **S3 Tables** と **S3 Vectors** に関する研究は、構造化データ・ベクトル・ファイルを S3 で一等のプリミティブとして扱うというより広範な戦略を示しています。UBC でのゲノム研究では、大規模データセットをローカルファイルシステムとオブジェクトストア間で移動する際の苦労が明らかになり、この統一アクセスレイヤーへの動機付けとなりました。ベータ版からの早期フィードバックは、パフォーマンス制限（例：5,000 万オブジェクトを超えるマウントに対する警告）、コミットウィンドウ、および問題キーの処理方法を形作っています。目標は Amazon のデータレイクポートフォリオを拡張し、開発者が配管よりもドメインロジックに集中できるようにすることであり、エンタープライズ向けにはデータサイエンス、機械学習、メディア処理などで、コストの高いマイグレーションや新しいツールを必要とせずにローカルとオブジェクトストアへのアクセスを統一することで恩恵をもたらします。

**課題：** *本番環境でディスク容量が不足しています。*