Skip to content

Instantly share code, notes, and snippets.

@ieee0824

ieee0824/冴えないサーバーの調べ方.md Secret

Last active September 14, 2017 10:00
Show Gist options
  • Star 7 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save ieee0824/ec107069280893fe053a91532db3befd to your computer and use it in GitHub Desktop.
Save ieee0824/ec107069280893fe053a91532db3befd to your computer and use it in GitHub Desktop.
Download ZIP
冴えないサーバーの育て方
Raw
冴えないサーバーの調べ方.md

よくわからんがサーバーがエラい重い時の調べ方

最近のコンピューター速くなったとはいえ富豪的な使い方をしていると計算機のリソースを使い切って遅くなることがある。
本当は重くなる前に対策を打つべきだがなってしまったものは仕方が無いので調べ方を書く。
障害は感覚で対処しては行けないちゃんと計測して原因を調べて対処しよう。

冴えないサーバーのリソースを状態を確認する

1. LoadAverage(LA)を確認する

w, uptime, htop を使うと調べることができる
LoadAverageが core数 * 2 を超えていると何か怪しいと思えば良い

$ w
 13:53:30 up  1:54,  1 user,  load average: 0.00, 0.01, 0.05
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
masato.y pts/0    192.168.25.37    13:53    1.00s  0.05s  0.00s w

$ uptime 
 13:53:58 up  1:55,  1 user,  load average: 0.00, 0.01, 0.05

htop

htopはGUIっぽい見た目をしてるので感覚的にわかりやすがデフォルトで入ってるとは限らないので注意
負荷の大きいプロセスを順番に並べたりしてくれるので便利

2017-09-01 14 19 56

LAが跳ね上がる要因

  • CPUを長い時間専有しているプロセスがある
  • メモリが足りない
  • IO待ちが多い

つまりこれらを調べられるとLAを健全な状態に持っていける

2. 空きメモリを調べる

free コマンドで調べることができる

$ free
              total        used        free      shared  buff/cache   available
Mem:       16432052     1818384     2750096       37296    11863572    14015960
Swap:         90108        2944       87164

この例だと free 2GBのように見えるがLinuxはbuffer+cacheとして空き領域が確保されるので11GBくらいである
メモリが足りなくなるとHDDにswapするのでIO速度が落ちてLAが跳ね上がる

3. CPU使用率を確認する

vmstat で確認できる

$ vmstat
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0   2944 2750004 1267000 10596696    0    0     0     4    0    1  0  0 99  0  0

procの項目：

  • r　…　実行可能で、「実行キュー」に入っているプロセスの数。
  • b　…　本来は実行可能なプロセスであるが、I/O待ちなどの何らかの理由で待ちとなっているプロセスの数

bの数が大きいとI/O負荷等が大きいことが予想される。 rが大きいとCPUの負荷が大きく、ユーザに遅いと感じさせている可能性がある。

systemの項目：

  • in 1秒当たりの割り込みの回数
  • cs 1秒当たりのコンテキストスイッチの回数

cpuの項目：

  • us　…　ユーザーが使用したCPUの割合（%）
  • sy　…　システムが使用したCPUの割合（%）
  • id　…　CPUアイドル時間の割合(100 - us - sy)（%）
  • wa　…　IO待ち時間

4. ディスクI/O使用率を取得する

vmstat -d で取得できる

$ vmstat -d
disk- ------------reads------------ ------------writes----------- -----IO------
       total merged sectors      ms  total merged sectors      ms    cur    sec
loop0      0      0       0       0      0      0       0       0      0      0
loop1      0      0       0       0      0      0       0       0      0      0
loop2      0      0       0       0      0      0       0       0      0      0
loop3      0      0       0       0      0      0       0       0      0      0
loop4      0      0       0       0      0      0       0       0      0      0
loop5      0      0       0       0      0      0       0       0      0      0
loop6      0      0       0       0      0      0       0       0      0      0
loop7      0      0       0       0      0      0       0       0      0      0
vda   285260   1176 7122208  589416 2987684 6247818 267234313 88951600      0   2347
vdb      123      0    4464      24      0      0       0       0      0      0
dm-0  285582      0 7077490  665888 8408361      0 267139704 792282628      0   2348
dm-1     165      0    6752     336    820      0    6560   41884      0      3

read/writeの項目：

  • total　…　読み書きに成功した総数
  • ms　…　読み書きに使用した時間

5. inodeの使用率を調べる

df -i で調べることができる。
Linuxのファイルシステム上でファイルとかディレクトリを管理するためのデータをinodeという。
サイズの小さいファイルが大量にあるとディスク容量はあるがファイルの書き込みに失敗することがある。
基本的にIfree, IUseを気にかけておけば良い。

$ df -i
Filesystem                      Inodes  IUsed   IFree IUse% Mounted on
udev                           2049300    421 2048879    1% /dev
tmpfs                          2054006    509 2053497    1% /run
/dev/mapper/VolGroup00-lv_root 8274240 545604 7728636    7% /
tmpfs                          2054006      1 2054005    1% /dev/shm
tmpfs                          2054006      3 2054003    1% /run/lock
tmpfs                          2054006     16 2053990    1% /sys/fs/cgroup
/dev/vda1                       124928    300  124628    1% /boot
Raw
冴えないネットワークの調べ方.md

基本的なこと

ネットワークのデバッグの基本は下のレイヤーか見ていくことです
OSI参照モデルはレイヤーわけはやり過ぎなのでTCP/IPのレイヤーを頭に置いておくと良いでしょう

ネットワークデバッグの流れ

  1. 物理層はつながっているか (アプリケーションエンジニアは余り気にすることでもないかもしれない)
    • LANケーブルの断線接続ミスが無いか
    • nicが死んでないか
    • nicのFWがおかしくないか
  2. 自分のサーバーのIPアドレスが正しいか？
  3. 接続先サーバーの名前を引けるか
    • dig example.com +short とかで調べることができる
  4. 接続先サーバーにpingが飛ぶか？
    • 時々セキュリティの観点でICMPを閉じてる場合があるのでその場合はpingが届かないこともあるが不具合ではない
  5. サーバーアプリケーションは動作をしているか
    • ps auxww とかを使って調べよう
    • アプリケーションがlistenしているportはlsofとかを使うと調べられる
  6. クライアント側から見た時サーバーアプリケーションの対象ポートは開いているのか？
    • mysqlの場合はクライアント環境から telnet example.com 3306 とかで調べることができる
Raw
冴えないプロセスの調べ方.md

プロセスを調べる

プロセスを全部表示する

$ ps auxww

プロセスを名前で検索する

$ ps auxww | grep ${PROCESS_NAME}

例えばmysqlを見たい時

$ ps auxww | grep mysq[l]

調べたプロセス一覧のpidのみ取得する

$ ps auxww -eo pid,command | grep ${PROCESS_NAME} | awk '{print $1}'

例えばmysqlの例

$ ps auxww -eo pid,command | grep mysq[l] | awk '{print $1}'

任意の名前のプロセスを殺す

$ ps auxww -eo pid,command | grep ${PROCESS_NAME} | awk '{print $1}' | xargs kill
@bananaumai
Copy link

ネットワークデバッグに関しては合わせて読みたい

http://made.livesense.co.jp/entry/2016/05/10/083000

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment