1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

DRAMが無いような安いSSDのためにProxmoxの負荷を減らす

1
Last updated at Posted at 2026-08-27

初心者の備忘録的なものなので、そうなんだ~くらいのノリでお願いします🙏
万が一内容が間違っていても責任は負いかねます

1.きっかけ

キャッシュがついていない安いSSD(ADATA )を使ったproxmoxが頻繁に内部データが読み取り専用になってしまう問題が起きてた

AIで調べたらProxmoxのLXCコンテナの中でさらにDockerを動かし、その上でマイクラを動かすと、ストレージへのアクセスが何重もの層(ファイルシステム・コンテナ・仮想レイヤー)を通ることになります。これがDRAMレスSSDにとって非常に重い負荷になります。とのこと

Proxmoxはデフォルトで、パフォーマンスのグラフ用データ(RRD)などを数秒おきにディスクへ書き込んでいる。ここを少し和らげることにする

2.現状のProxmoxストレージ界隈

普通はDRAM付きの高性能なSSDを使う。Proxmox=エンタープライズという思想で作られてるから、チープなSSDを使うことは考えてないんだろう

数年前の安価なSSDに比べると、近年のSSD(特にちゃんとしたメーカーのもの)は書き換え寿命が桁違いに向上している。そのため、RRDの数秒おきの書き込み程度では、SSDが数ヶ月や1、2年で壊れるようなことは滅多になくなったそう

プロたちの意見

プロやシニアユーザーの間でも、「わざわざ設定を複雑にしてRAMディスク(tmpfs)に逃がす手間をかけるくらいなら、最初から耐久性のあるSSDや中古の企業向け(エンタープライズ向け)SSDを使えばいいじゃないか」という考え方が主流になった。設定をミスして再起動時にグラフやログが消えたりトラブルの原因になるリスクを嫌う人も多いそうな

我らパンピーの意見

とはいえ、今はSSDが高騰しているからそうも言ってられないし、
ラズベリーパイや、極端に古い・安価なSSD(今回のADATAのような構成)でどうしてもケチって運用したい場合
ログ(journald)や統計データの細かい書き込みを極限まで減らして、SSDの寿命を1日でも長く引き延ばしたい
といった人たちもいる

3.対策

ってことで少し前によく使われてた古の対策法を使うことにする
と言っても、RAMディスクを使うだけ。難しいことはない

ログ(journald)とパフォーマンス統計のデータをRAMディスクに書き込むことにする。

環境:Linux proxmox 7.0.2-6-pve #1 SMP PREEMPT_DYNAMIC PMX 7.0.2-6 (2026-05-20T08:55Z) x86_64

ログ(journald)

1. systemd-journaldの設定を変更する

この設定を間違えるとProxmoxが起動しなくなる恐れがあるので、バックアップを取って再インストールも視野に入れておくこと

システムログの保存先を「ディスク(persistent)」から「メモリ(volatile)」に変更

nano /etc/systemd/journald.conf

ファイルの中から #Storage= または Storage=... と書かれている行を探し、以下のように書き換え(コメントアウトの # を外して volatile に変更)

TOML
[Journal]
Storage=volatile

(※ volatile にすると、ログはディスク上の /var/log/journal には書き込まれず、メモリ上の /run/log/journal にのみ一時保存され、再起動時にクリアされるようになる)
変更したら、保存して終了

2. 設定を反映させるために journald を再起動する

systemctl restart systemd-journald

3. 動作確認

設定が正しく適用されているか確認

journalctl --disk-usage

ここに Archived and active journals take up ... と表示され、メモリ上(あるいは /run/...)で正常に稼働していることが確認できる

パフォーマンス統計

1. サービスの停止

pve-clusterを止めるため、Web管理画面が一時的に操作できなくなる。直接SSH推奨

systemctl stop pve-cluster
systemctl stop rrdcached

2. /var/lib/rrdcached のバックアップ(念のため)

mv /var/lib/rrdcached /var/lib/rrdcached.bak
mkdir /var/lib/rrdcached

cpではなくmv。これは新しくRAMディスクとしてマウントするにあたり、中身を空にしなくてはならないため。
元からあったデータはSSDに保存されていたもの

3. /etc/fstab に tmpfs の設定を追加する

エディタで /etc/fstab を開く

nano /etc/fstab

ファイルの末尾に、以下の1行を追加

tmpfs /var/lib/rrdcached tmpfs defaults,size=100M 0 0

これはグラフデータ用にメモリを最大100MB割り当てる設定です

保存して終了

4. マウントとサービスの再起動

設定を反映させ、サービスを再起動

mount /var/lib/rrdcached
systemctl start pve-cluster
systemctl start rrdcached

メモリ上に置いているため、Proxmox本体を再起動するとグラフの過去データはリセットされ、新しく計測し直されます。「今リアルタイムで何%か見えればいい」というご希望であれば、実用上全く問題ありません

4.なぜこれが有効か

SSDとRAMの仕組みの違い

SSD

データを保存する際、フラッシュメモリのセルに電気を流して物理的な書き換えを行います。これには「寿命(書き換え回数の限界)」があり、小さなデータを細かく書き込もうとすると、内部で余計な処理(ライトアンプリフィケーション)が発生してSSDのコントローラーに大きな負担がかる

RAM

すべてが電気信号のやり取りだけで完結するため、何万回データを書き換えても物理的な摩耗(寿命)が一切ない。 また、SSDとは比べ物にならないほどの圧倒的な高速処理が可能

Geminiによるとこういうことらしい(ほぇ~🧐)
ただし良いことばかりでもない

電源を切るとデータが吹き飛ぶ

そりゃそう。だってRAMだもの。

RAMディスクはsystemdの仕様により、メモリ上に保持されるログの容量には自動的に上限(通常はRAM総容量の数%、または数十MB〜数百MB程度)がかけられる。そのため、メモリがログでパンクしてサーバーが落ちるような心配は基本的にない。

DRAMがないSSDのDRAM代わりくらいのもんだろう

5.まとめ

今回はシステムログとパフォーマンス統計の履歴データをRAMディスクに書き込む設定をした。

こんな記事を書いておいてだけど、RAMディスクを使うと、SSDへの書き込みを丸ごとカットできるため負荷はゼロになるが、「消えて困るデータを置くにはリスクが高すぎる(定期的なバックアップ機構が必須になる)」というトレードオフがある

そのため、システム全体をRAMディスク化するような無理をするよりも、前回お話ししたような「ちゃんとしたキャッシュ付きSSDを使う」ほうが、安全性と手間の面で圧倒的にバランスが良いとされているということは記しておく

現在の私はログデータにそこまでの関心がないからこんな設定をした。今後また価値観が変わるかもしれない

マイクラの一時データをRAMディスクに書き込むようにすることもできるけど、それはやるか分からない。

(追記)
RAMディスクの設定をしたものの、結局また読み取り専用になってしまい、サーバーが止まってしまった。記事を書いた本人が効果を実感できなかったのは面目ない。なんとなく設定前よりは耐えた期間が長かったような気もするが、そもそも数年使った廉価なSSDでProxmoxを動かすこと自体無茶なのかもしれない。とはいえ、試してみる価値はあったと思う。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?