パフォーマンス

サーバー負荷履歴:24時間・7日・30日(5分ごとに収集)

Load Average (1m)
1.51
CPU
5.1%
RAM
31.3%
ESTABLISHED
57
プロセス
3 / 445
この期間は個々の測定値ではなく、1時間ごとの平均を表示しています。
Load Average
CPU
メモリ
ネットワーク (KB/s)
ディスク I/O (KB/s)
TCP 接続
ディスクと上限 (%)
MySQL
直近の測定時のプロセス 00:40
プロセスCPU %RAM %
falco 7.4 5.6
mysqld 4.4 7.3
crowdsec 2.6 15.6
apache2 1.4 4.5
fail2ban-server 0.7 17.1
当日のピーク時のプロセス 11.10 08:20 · load 2.74
プロセスCPU %RAM %
apache2 18.0 9.3
mysqld 12.8 14.0
clamd 8.9 14.3
falco 6.2 11.0
suricata 2.8 18.4

Prometheus と Grafana なしで見る負荷の履歴

top が答えるのは今この一秒についての問いですが、実際に問われるのはたいてい昨夜のことです。なぜ午前三時にすべてが止まり、そして勝手に戻ったのか。その時点ではもう見るものが残っていません。どこにも記録されていないからです。かといって一台の VPS のために Prometheus と Grafana を立てるのも、それ自体が問題になります。観測する側のスタックが、観測される側のサーバーより重くなってしまうからです。

コレクターが五分ごとにデータベースへ一行ずつ書き足し、このページはそこから直近 24 時間を描きます。load average、I/O wait を分けて示した CPU 使用率、RAM と swap、ネットワークの受信と送信、ディスクの読み書き、確立済みの TCP 接続、プロセス、パーティションの使用量、inode とファイルディスクリプタの上限に対する割合、MySQL の接続数。すべて一つのページに、同じ時間軸で並ぶので、同時に起きた事柄が目で見て分かります。

これらのグラフは対で読むとよいでしょう。CPU が落ち着いているのに I/O wait が高いなら、サーバーはディスクを待っているのであり、コアを増やしても意味がありません。一度上がったきり零に戻らない swap は、いま静かに見えてもメモリのピークがすでに過ぎたことを語っています。百パーセントに近づいたファイルディスクリプタは、実際に too many open files が出る数時間前の姿です。そして多くのサーバーでは、空き容量よりずっと先に inode が尽きます。