アカウント類 はてな: 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
77web
sho_ssk_
shoheimitani
sgash708
shibuyamizuho
l2hyunwoo
makihiro
sullis
chencmd
memory1994
daisukeshinoku
ttskch
jakevdp
garrettdimon
smashingmag
marcduiker
irinanazarova
mza
afnizarnur
deanohume
brettharned
colly
jonyablonski
![あわせてよみたい Mackerel サー バ監視[ 実践] 入門 http://gihyo.jp/book/2017/978‑4‑7741‑9213‑0 Mackerel でみる Linux](https://files.speakerdeck.com/presentations/6a1738a5df534eab832f68b88f6249b2/slide_89.jpg){kind=link}