アカウント類 はてな: i d : p a p i x Twitter: @ _ _ p a p i x _ _ GitHub: p a p i x CPAN: P A P I X ブログ: h t t p s ? : / / p a p i x . h a t e n a ( b l o g . ( c o m | j p ) | d i a r y . j p ) / 趣味はPerl と, ( 交通機関を利用した) 旅行など 去年JGC 修行を完遂しました, 折を見てSFC も修行したい...
ドアベレー ジ｣ 5 は5 分間平均( 一般に, u p t i m e や w コマンドでは1/5/15 分平 均のロー ドアベレー ジが見れる) さっくり言えば, ｢ システム全体の負荷の様子｣ を示す 実行待ちプロセス数と, I/O 待ちプロセス数の合計 = CPU 等に余裕があれば, すぐに実行されるプロセス数
バ上で動作するアプリケー ションやミドルウェアの負荷が 高まれば u s e r の割合が増える アプリケー ションやミドルウェアによるI/O がディスクのI/O 性 能に追いつかない場合, i o w a i t が増える Xen やKVM などの仮想化環境を使っていて, その負荷が高まれ ば s t e a l や g u e s t なども見る必要がある
CPU 利用率を可視化/ 蓄積し, 日頃から傾向を掴んでおくことが 大事( 後述) また, CPU 利用率が低い(= i d l e が多い) ことは, それもまた一種の 問題である CPU 利用率が低い = サー バを効率的に利用できていない ｢ 負荷低すぎはもはや障害じゃないのか｣ http://mikeda.hatenablog.com/entry/2015/02/01/195102
s e d + b u f f e r s + c a c h e d + f r e e = t o t a l を前提とする 意味 total 物理メモリの総容量 used 利用している物理メモリの容量 cached ペー ジキャッシュに使われている物理メモリの容量 buffers バッファに使われている物理メモリの容量 free 利用されてない物理メモリの容量
ペー ジキャッシュ( c a c h e d ) とバッファ( b u f f e r s ) のために積極的に利用される アプリケー ションによってメモリが必要になった時に開放され る そのため, " メモリの利用率" を考えるなら, u s e d / t o t a l で 考える必要がある Linux kernel 3.14 以降では, M e m A v a i l a b l e というパラメー タがあ る 開放不可能な c a c h e d / b u f f e r s も考慮されている
w a p t o t a l , s w a p u s e d , s w a p c a c h e d がある スワップは多くの場合HDD/SSD 上に作られる 物理メモリに比べて速度が遅いため, スワップの発生 = パフォ ー マスの低下と言える 特にWeb サー ビスが稼働するサー バでは, 基本的に｢ スワップは発生 させない｣ ように意識するべき メモリの利用量が漸増している場合, メモリリー クなど発生してい ないか調査する必要がある
ク帯域の利用状況を表す t x が送信, r x が受信, 単位は K B / 秒 ちなみに t x は t r a n s m i t , r x は r e c e i v e のことらしい これもまた, インフラ提供者によってネットワー ク帯域に上限が定 められている クラウドの場合, 更に課金額にも影響が出る
ディスクとその使用量を表す s i z e はディスクの最大容量, u s e d はディスクの使用量 例えばRDBMS が動くサー バでは, デー タが蓄積される毎に u s e d が 増えていく 言うまでもなく, ディスクの空き容量がなくなると書き込めな くなるので, その前に最大容量を増やす必要がある また, ミドルウェアなどのログの書き込みでも u s e d が増えて いく
の見どころ ディスクの空き容量をすぐに増やせない場合も有り得るので, ある 程度の利用率を越えたら警告するようにしておく 定期的に u s e d の増加量を確認し, 警告が出て, 危険な領域に達 する前に最大容量を増やせるのがベスト u s e d が急激に増えている場合, Web サー ビスやミドルウェアのロ グの出力設定を変更している場合などもある ログがより詳細に出るようになって, 大量のログがディスク上 に保存されている状態
タスコー ドは100 の位ごとにまとめられる. A c c e s s R a t e も同様 Access Rate 1 分間辺りのステー タスコー ドの割合 Latency A v e r a g e ... リクエストにかかった秒数( レイテンシ) の平均 9 0 P e r c e n t i l e ... レイテンシの下位90% の秒数 9 5 P e r c e n t i l e ... レイテンシの下位95% の秒数 9 9 P e r c e n t i l e ... レイテンシの下位99% の秒数
Web サー ビスへのアクセス数が増えれば, T o t a l C o u n t が増 えていく A c c e s s R a t e デプロイ後など, バグがあれば H T T P 5 x x P e r c e n t a g e が上昇 しがち L a t e n c y 高負荷によって, CPU 利用率が増えたり, IOPS が上限に達した 場合, レイテンシに影響が出て来る
- m a c k e r e l - p l u g i n というヘルパー がある https://mackerel.io/ja/docs/entry/advanced/go‑mackerel‑ plugin とはいえ, フォー マット(Sensu のフォー マットと同じ) が同じであれ ば, Shell Script やPerl, Ruby などで実装しても構わない 公式のプラグインリポジトリ以外にも, ユー ザがそれぞれプラグイ ンをGitHub などで公開していることがある
: / / b l o g . h a t e n a . n e . j p / r e g i s t e r Web アプリケー ションエンジニア5 人(+ アルバイト) で開発中 3 人が京都オフィス, 2 人が東京オフィスのリモー ト体制 インフラはAWS もちろんMackerel も活用中
i n s t a l l ... ライブラリインストー ルにかかった時間 d e p l o y _ u p d a t e ... ファイルの配布にかかった時間 r e s t a r t ... プロセス再起動にかかった時間 可視化することで問題点を洗い出し, 改善することができる 詳しくは: はてなブログのデプロイを約6 倍高速化したはなし http://this.aereal.org/entry/2016/12/16/170000
ネットワー ク周りの技術の入門 にも有用 MIPS の上にEdgeOS が載っている EdgeOS はVyatta( ネットワー ク機器向けDebian ベー スのLinux OS) の派生版 故に, G O O S = l i n u x , G O A R C H = m i p s l e でビルドすれば, m a c k e r e l - a g e n t やGo 製のMackerel プラグインが動く! Perl も5.14.2 が入っている 他, "Raspberry Pi" の上で動かすなどの手もある
papix
ymtdzzz
ivargrimstad
mizoguchicoji
fukubaka0825
krpk1900
happymana
taro28
mikik0
oheyadam
watanave
javiergs
geeforr
speakerdeck
soudai
caitiem20
maggiecrowley
maltzj
erikaheidi
bryan
ddemaree
morganepeng
thoeni
tammielis
![あわせてよみたい Mackerel サー バ監視[ 実践] 入門 http://gihyo.jp/book/2017/978‑4‑7741‑9213‑0 Mackerel でみる Linux](https://files.speakerdeck.com/presentations/6a1738a5df534eab832f68b88f6249b2/slide_89.jpg){kind=link}