cd ../../../ をなんとかしました

おはようございます。ライトノベル好きのツチノコです。年末年始に読むライトノベルは決めましたか?

さてansibleのplaybookを書いていたりすると、ディレクトリ構造が深くなりがちです。
作業中に深いディレクトリから浅いディレクトリへ移動するときにめんどいのでなんとかしました。
・cd ../../../ などで上がろうとすると、いくつ上がるんだっけとか、間違って ./ や …/ と typo する
・popd しようとしても移動先ディレクトリがスタックに入ってるとは限らない

watanabe-k@deploy:~/openstack-playbook/roles/image/templates/etc/glance/rootwrap.d$ pwd
/home/watanabe-k/openstack-playbook/roles/image/templates/etc/glance/rootwrap.d
watanabe-k@deploy:~/openstack-playbook/roles/image/templates/etc/glance/rootwrap.d$ # ここから openstack-playbook/roles に cd したい

.bashrc に以下のfunctionを定義します。

# .bashrc
function upto() {
    if [ $# -eq 0 ]; then
        cd ~
    else
        ptn=$(echo -n $1 | sed -e 's/\/$//g;s/\//\\\//g;')
        exp='s/\(.*'$ptn'[^/]*\/\).*/\1/g'
        dir=$(pwd)"/"
        cd $(echo $dir | sed -e "$exp")
    fi
}

function upto_completion() {
    COMPREPLY=( $(compgen -W "$(pwd|sed -e 's/\// /g')" ${COMP_WORDS[COMP_CWORD]} ) )
}
complete -F upto_completion upto

これでカレントディレクトリのパスの一部を指定して、そのディレクトリにcdするコマンドuptoができました。

$ upto pathの一部

こんな感じで使えます。

watanabe-k@deploy:~/openstack-playbook/roles/image/templates/etc/glance/rootwrap.d$ upto roles
watanabe-k@deploy:~/openstack-playbook/roles$

補完も効きます(候補がsortされるけど・・・)

watanabe-k@deploy:~/openstack-playbook/roles/image/templates/etc/glance/rootwrap.d$ upto [tab][tab]
etc                 glance              home                image               openstack-playbook  roles               rootwrap.d          templates           watanabe-k

部分一致にも対応してます。

watanabe-k@deploy:~/openstack-playbook/roles/image/templates/etc/glance/rootwrap.d$ upto openstack
watanabe-k@deploy:~/openstack-playbook$

べんり。

p.s. 華麗なる探偵アリス&ペンギンおもしろいですね

ping! pong! pang!

pingでsearchをかけるといろいろと出てくるpingライクなコマンド

みんなどんな役割を持っているんだろうか。

いわずと知れたpingのように各プロトコルで応答の確認を行うコマンドであり、

fping,httpingなど監視ツールと組み合わせて利用されることも多いんだと思いますが、

普段使いできそうなコマンドはあるのでしょうか。

さっそく、調べてみました。

fping:
複数のipにping
ioping:
簡易的なディスクレイテンシーモニタリング
omping:
マルチキャストとユニキャストで応答確認
hping:
icmp,udp,tcpなどいろんなパケットを生成し応答確認
arping:
イーサネットレベルの応答確認
2ping:
特定の2ホストでどちら側のホストに問題があるのか確認できる。
httping:
httpレスポンス詳細が確認できる。

結果、下記の三つのコマンドは覚えておいても損はないかなと思いました。

一つずつ確認していきます。

  1. httpingはウェブサーバで遅延しているときにどの部分で遅延が発生しているのかが確認できる。
  2. arpingはipバッティングがないかどうかの確認ができる
  3. iopingは実運用下の中でディスクのレイテンシーの悪化状況を確認できる。

1.httping

$ httping www.example.com -S
PING www.example.com:80 (/):
connected to 198.51.100.20:80 (201 bytes), seq=0 time= 1.91+ 0.73+100.70+ 26.30+ 0.01=129.64 ms
connected to 198.51.100.20:80 (201 bytes), seq=1 time= 0.76+ 0.65+ 21.46+ 0.04+ 0.01= 22.91 ms
connected to 198.51.100.20:80 (201 bytes), seq=2 time= 0.82+ 0.61+ 42.42+ 0.04+ 0.01= 43.89 ms
connected to 198.51.100.20:80 (201 bytes), seq=3 time= 0.78+ 0.73+ 24.18+ 0.04+ 0.01= 25.73 ms
connected to 198.51.100.20:80 (201 bytes), seq=4 time= 0.82+ 0.65+ 25.85+ 0.05+ 0.01= 27.38 ms
connected to 198.51.100.20:80 (201 bytes), seq=5 time= 1.04+ 0.69+ 25.32+ 0.03+ 0.01= 27.08 ms
connected to 198.51.100.20:80 (201 bytes), seq=6 time= 0.98+ 0.62+ 27.20+ 0.03+ 0.01= 28.83 ms
connected to 198.51.100.20:80 (201 bytes), seq=7 time= 0.82+ 0.60+ 23.96+ 0.03+ 0.01= 25.41 ms

--- http://www.example.com/ ping statistics ---
8 connects, 8 ok, 0.00% failed, time 7672ms
round-trip min/avg/max = 22.9/41.4/129.6 ms

名前解決が完了するまでの時間
+サーバへ接続するまでの時間
+リクエストがサーバに受け付けられるまでの時間
+サーバが最初のデータをスタートするまでの時間
+データの転送が完了しコネクションがクローズされるまでの時間
=合計

がわかります。

これでどこの部分で遅延が発生しているのかが具体的にわかるようになります。

2.arping

$ sudo arping -I eth1 -b 198.51.100.20
ARPING 198.51.100.20 from 172.16.0.1 eth1
Unicast reply from 198.51.100.20 [A1:36:9D:27:D5:38] 0.686ms
Unicast reply from 198.51.100.20 [A1:36:9D:27:D5:39] 0.632ms
Unicast reply from 198.51.100.20 [A1:36:9D:27:D5:38] 0.648ms
Unicast reply from 198.51.100.20 [A1:36:9D:27:D5:39] 0.651ms
Unicast reply from 198.51.100.20 [A1:36:9D:27:D5:38] 0.637ms
Unicast reply from 198.51.100.20 [A1:36:9D:27:D5:39] 0.642ms
Unicast reply from 198.51.100.20 [A1:36:9D:27:D5:38] 0.635ms
Unicast reply from 198.51.100.20 [A1:36:9D:27:D5:39] 0.651ms

このようにIPのconflictの確認が可能です。

このコマンドを運用に組み込んでIPバッティングを防いだりできます。


3.ioping

$ ioping /data/file1
4.0 KiB from /data/file1 (ext4 /dev/md0): request=1 time=102 us
4.0 KiB from /data/file1 (ext4 /dev/md0): request=2 time=185 us
4.0 KiB from /data/file1 (ext4 /dev/md0): request=3 time=196 us
4.0 KiB from /data/file1 (ext4 /dev/md0): request=4 time=207 us
4.0 KiB from /data/file1 (ext4 /dev/md0): request=5 time=208 us
4.0 KiB from /data/file1 (ext4 /dev/md0): request=6 time=203 us
4.0 KiB from /data/file1 (ext4 /dev/md0): request=7 time=233 us
4.0 KiB from /data/file1 (ext4 /dev/md0): request=8 time=244 us
4.0 KiB from /data/file1 (ext4 /dev/md0): request=9 time=204 us
4.0 KiB from /data/file1 (ext4 /dev/md0): request=10 time=210 us

--- /data/file1 (ext4 /dev/md0) ioping statistics ---
10 requests completed in 9.3 s, 5.0 k iops, 19.6 MiB/s
min/avg/max/mdev = 102 us / 199 us / 244 us / 36 us

このように実稼働環境においてレイテンシーの変化を確認し増強のタイミングを見極めることができます。

ちなみに、pong2というOpenGLを利用した3Dゲームがあります。

3Dのピンポンゲームです。aptでサクっと入ります。画面はこんな感じ^^

pong2

今までありがとう「ifconfig」

ifconfigを含むnet-toolsが非推奨になって久しいようですが、

rhel7系からnet-toolsはおさらばとなります。
※手動で入れれば使えますが。

今思えば、ifconfig君

あなたと出会ってからこの十数年、あなたを打たなかった日はありません。

雨の日も風の日もいつも一緒だったね。

あなたがいつもいてくれたから私も輝けたんだといます。

これから私は新しいiproute2君と歩んでいくことになりますが、あなたのことは決して忘れることはないでしょう。

ifconfig君に幸あれ

P.S.
ついつい ifco[tab]ってやっちゃうのはご愛嬌です。

ということでnet-toolsとiproute2の対応表一覧です。自分の備忘録として残しておきます。

net-tools iproute2
ifconfig ip l (ip link)
ifconfig -a ip a show (ip addr show)
ifconfig eth0 up ip link set eth0 up
netstat ss
netstat -i ip -s link
netstat -l ss -l
netstat -r ip r (ip route)
route [add|del] ip route [add|del]
route -n ip route show
arp -n ip n (ip neighbor)

heartbeat+pacemakerなどで利用する仮想IPはipaddr2を利用しています。

そもそもifconfigではこのコマンドで設定されたIPは表示されません。rhel6系であってもip addr showで確認しなくてはいけません。

開発、オペレーションする側みんながこの違いを認識し共有することがミスを防ぐことになります。

ページキャッシュの詳細確認と削除方法

 

余裕があるんだけどメモリがswapに入ってしまう現象が少なからずあると思います。

だいたい

echo 1 > /proc/sys/vm/drop_caches

このようにしてページキャッシュを削除しますが、キャッシュ全体を削除してしまうので、
どうしても特定のファイルのキャッシュだけ削除したいという要求が出てきます。

そんなのときに便利なツールがlinux-ftoolです。

使ってみます。

# yum -y install mercurial
# hg clone https://code.google.com/p/linux-ftools/
# cd linux-ftool
# ./configure && make install

こちらでインストールは完了です。
早速試してみます。/tmpディレクトリへ移動し適当にファイルを作成しキャッシュを消費させ、
ページキャッシュの情報を覗いてみます。覗くのはlinux-fincoreコマンドを利用します。

# cd /tmp

# free -m
total used free shared buffers cached
Mem: 996 473 523 0 3 23
-/+ buffers/cache: 446 550
Swap: 0 0 0

# dd if=/dev/zero of=/dev/testfile bs=1M count=200

# free -m
total used free shared buffers cached
Mem: 996 679 317 0 3 223
-/+ buffers/cache: 451 544
Swap: 0 0 0

※200Mほどキャッシュを消費したのがわかりますね。

ではキャッシュを確認してみましょう。

# linux-fincore --pages=false --summarize --only-cached /tmp/*
filename size total_pages min_cached page cached_pages cached_size cached_perc
-------- ---- ----------- --------------- ------------ ----------- -----------
/tmp/testfile 209,715,200 51,200 0 51,200 209,715,200 100.00
---
total cached size: 209,715,200

※testfileというファイルでまるまる200Mのキャッシュが利用されていることがわかります。

さて次に削除です。削除にはlinux-fadviseというコマンドを利用します。

# linux-fadvise /tmp/testfile POSIX_FADV_DONTNEED
Going to fadvise /tmp/testfile as mode POSIX_FADV_DONTNEED
offset: 0
length: 209715200
mode: POSIX_FADV_DONTNEED
WIN

# free -m
total used free shared buffers cached
Mem: 996 474 522 0 3 23
-/+ buffers/cache: 446 549
Swap: 0 0 0

# linux-fincore --pages=false --summarize --only-cached /tmp/*
filename size total_pages min_cached page cached_pages cached_size cached_perc
-------- ---- ----------- --------------- ------------ ----------- -----------
---
total cached size: 0

削除されたことがわかるかと思います。

こちらのツール類の詳細は下記URLから確認できます。
https://code.google.com/p/linux-ftools/
基本的にはPOSIX_FADV_DONTNEED以外は使う機会が思い浮かびません。^^;

利用用途としては必要のないログなどでキャッシュが肥大化していないか確認して、
その肥大化している問題とならなさそうなページキャッシュを手動で削除する
ってところになるんだろうと思います。