月€8のVPS 1台に、cron登録の自動処理を60本と、Webサイトを4つ同居させて41日間動かした実測値をそのまま公開します。CPUもメモリも余っていて、実際に詰まったのは別のところでした。
使っているサーバーの中身
Contabo(アジア・シンガポール拠点)のVPSを月€8.00で契約しています。スペックと環境は以下のとおりです。
CPU : 4コア メモリ : 7,941MB ディスク: 72GB OS : Ubuntu 24.04 Web : Apache 2.4 言語 : PHP 8.3 DB : MariaDB
この1台の上に、cronに登録した自動処理が60本と、Webサイトが4つ(WordPress 2つ、Node.jsアプリ2つ)が同居しています。専用サーバーを分けたりはしていません。全部同じ箱の中です。
60本の内訳
- SNSの自動運用:50本
- YouTube関連:13本
- ブログ記事の自動生成・投稿:3本
この内訳を単純に足すと60本を超えます。1本が複数の役割にまたがっていたり、数え方が重複していたりするためで、どれがどこに対応するのかは自分でも正確に把握できていません。cronのエントリ数として60本、という数字だけが確かなところです。
41日間、無停止で動いた
そのときのリソース使用状況です。
- メモリ:7,941MB中 1,442MB(残り約6.3GB)
- ディスク:72GB中 22%
- load average:1.34 / 1.76 / 1.92(4コアに対して)

load averageは4コアに対して最大でも1.92なので、コアが埋まりきってはいません。メモリに至っては8割以上が空いたままです。「自動処理を60本も動かしている」と言うと重そうに聞こえますが、実際の数字はこれです。
同時に動いているPythonプロセスは2つだけだった
理由がはっきりしたのは、稼働中のPythonプロセスを数えたときでした。60本あっても、同時に動いていたのはたった2つです。
cronは実行時刻を24時間に散らしてあります。60本という数字は「登録数」であって「同時実行数」ではありません。ここを混同すると、必要なスペックを何倍にも見積もってしまいます。
台数やスペックを決めるときに見るべきは、cronの本数ではなく同時に走る本数です。散らせるものを散らしておけば、1台に載る量は本数から想像するより多くなります。
唯一、素直に載らなかったのがffmpeg
例外は動画生成です。ffmpegはCPUを使い切ろうとするので、そのまま走らせると動画の書き出し中に同じサーバーのWebサイトが遅くなりました。cronを散らす対策では解決しません。1本でCPUを持っていくからです。
ffmpegを制限なしで実行し、書き出し中に同居しているWebサイトのレスポンスを落としました。自動処理側が正常に完走していても、外から見えるサイトが遅くなるので、影響としてはこちらのほうが厄介です。
いま入れている対策は、実行コマンドの前にこれを付けるだけです。
taskset -c 0-1 nice -n 10 ffmpeg ...
taskset -c 0-1… 使うコアを0番と1番の2つに限定するnice -n 10… 優先度を下げ、他の処理に先を譲らせる
4コアのうち2コアをffmpegに割り当てず残しておくことで、動画の書き出し中でもWebサイトが重くならなくなりました。追加費用はゼロ、コマンドの頭に一言足すだけです。
本当のボトルネックはサーバーではなかった
ここまでの数字を並べると分かるとおり、この構成で先に限界が来たのはCPUでもメモリでもディスクでもありません。実際に詰まったのは、各サービスのレート制限でした。
サーバー側にはまだ6.3GBのメモリと2コア分の余力があります。それでも本数を増やせないのは、投稿やAPI呼び出しの回数に外側から上限がかかるからです。スケールさせたいときに買うべきものが、サーバーではなかったというのがこの41日で一番はっきりした点です。
分かっていないこと
- 41日を超えて何日まで無停止でいけるのかは、まだ分かりません。単に41日時点で観測した値です。
- cron 60本と内訳の数字が一致しない件は、未整理のままです。
- 今の余力(メモリ6.3GB、2コア)で自動処理をあと何本載せられるかは、レート制限が先に来るため試せていません。
- 月€8・4コア・7,941MBのVPS 1台で、cron 60本とWebサイト4つを41日間無停止で運用できました。
- メモリは1,442MBしか使っておらず、load averageは4コアに対して1.34/1.76/1.92でした。
- 60本あっても同時に動いていたPythonプロセスは2つ。実行時刻を24時間に散らしているためです。
- ffmpegだけは例外で、
taskset -c 0-1 nice -n 10で2コアに限定し優先度を下げないと、同居サイトが遅くなりました。 - 限界を決めたのはサーバー性能ではなく、各サービスのレート制限でした。




