代入すると次のようになります。1884であることを確かめると、確かに漸化式とLinuxで行われている計算が一致することがわかります。15も同様に確認できます。漸化式を用いて更新されています。tickごとに計算されています。約7時間ごとにloadavgが上昇する現象の原因です。mackerel-agentは1分ごとにメトリックを収集するために、プラグインのプロセスを開いています。loadavgの再計算が5秒ぴったりから少しだけずれているために、mackerel-agentがメトリック収集を始めるタイミングとloadavgの再計算のタイミングが定期的に一致するのです。1000の環境では、loadavgは5.001秒ごとに更新されます。重なる現象が6時間57分ごとに起きるのです。この周期でloadavgが上がってもよいはずですが、mackerel-agentのメトリック収集タイミングと0.012秒ずつずれていくのが無視できません。60秒の倍数となるのはさらに4倍、つまり6時間57分周期で、mackerel-agentのメトリック収集のタイミングとぴったり重なります。エントリー冒頭のグラフを見ると、確かに6時間57分の周期で高さの揃ったピークが立っていることがわかります。このピークの1時間44分前後で小さなピークが立っているところがあるのも見て取れます。250であることに由来する現象です。loadavgの更新間隔はなぜぴったり5秒間隔の更新ではないのでしょうか。Linuxの中では様々なプロセスが独自の周期で処理を行っています。5秒間隔で処理を行うようなプロセスがあると、loadavgの再計算タイミングとぴったり一致することが起こる可能性があります。意図せずタイミングが合致してloadavgが上昇する現象が起きるのを防ぐために、周期を5秒から少しずらしているのです。この経緯は、5*HZに1足すことになったパッチのコミットメッセージや、メーリングリストを読むとわかります。Linuxにおけるloadavgの更新間隔は、意図的に5秒から少しずれています。この少しのずれが溜まっていき、約6時間57分の周期で60秒の倍数となります。mackerel-agentは60秒ごとにプラグインのプロセスを開いており、このタイミングがloadavgの再計算タイミングと合う現象が周期的に起こります。これが、mackerel-agentを入れるとloadavgが定期的に上昇する現象の原因です。この現象は、collectdやTelegrafなど、他のモニタリングツールでも報告されています。hours本現象について説明されたブログです。collectdを用いた環境で同じ現象が起きています。processの数が計算に入っている理由が歴史的な経緯を追って説明されています。係数の和が1であることを確かめることができます。加重平均であるための必要条件です。区別する必要があります。あり、x86では100と決まっています。増え方で見ることができます。なるようにするための処理です。ならない問題が指摘されて、プロセス数が増えているときだけ切り上げする形になっています。詳しくはパッチやメーリングリストを参照してください。読者になるバナーとお問い合わせセールスに関するお問い合わせ料金や支払い方法など気なることがあれば、ぜひお気軽にお問い合わせ下さい!お問い合わせ無料トライアルMackerelに興味をもっていただけましたか?まずは無料トライアルで実際にMackerelを使ってみてください。Ltd.スターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。