元RX-7乗りの適当な日々 このページをアンテナに追加 RSSフィード Twitter

RX-7(FD3S)WRX STI関連のキーワードで検索されて来られた方へ。
右サイドのカテゴリ『』をクリックすると関連する項目だけが表示されます。
日々の写真は『Flickr』で公開しています。

2013/07/29

by T a k

Linuxサーバがディスク容量不足になった!何か消さねば!ってなった時にどう対処するか


とりとめもなく書いてみる。主にルーキー向けです。

サーバの運用とかやっていると、不定期ではあるが、たまにタイトルのような話題に直面します。

まぁ、それが起こるのは一旦良いとして、みんなこういう時、どうやって調べているのだろう?

とりあえず、僕がどうやってるか書いてみます。


何はともあれ現状確認

みんな大好き"df"コマンドです。細かい説明は省きますが、各パーティション・ファイルシステムごとにディスクの使用状況を確認。

# df -h
Filesystem          サイズ  使用  残り 使用% マウント位置
/dev/sda3             130G   88G   36G  72% /
/dev/sda1             494M   23M  447M   5% /boot
tmpfs                  12G     0   12G   0% /dev/shm

正確とは言いませんが、だいたいどのパーティションにどのくらい容量が空いているかが確認できます。


どのディレクトリ配下の容量が大きいか確認

"du"コマンドは、各ディレクトリ/ファイルの確認ができますが、そのまま実行すると再帰的なディレクトリまですべて表示して追いづらくなるので、"--max-depth=1"(1階層分を表示)とかオプションを付けて、少しずつ絞り込んでいくようにします。

# du -h --max-depth=1 /
0       /proc
8.0K    /mnt
95M     /etc
8.0K    /selinux
8.0K    /misc
264K    /dev
84G     /var
3.6G    /usr
2.4M    /opt
36M     /sbin
8.0K    /srv
16K     /lost+found
624K    /home
219M    /lib
2.1M    /root
12M     /boot
8.0K    /media
7.7M    /bin
36M     /tmp
18M     /lib64
0       /sys
88G     /

↑の例では、ルートパーティション("/")に対して、"du"コマンドを発行していますが、ファイル/ディレクトリの量によっては時間がかかるかもしれません。また、実行時間中、ディスクI/Oも発生させることになるので、その辺はいい感じで調整して実行しましょう。

↑では、"/var"以下に大きなファイルがありそうなことがわかったので、次は同様のコマンドを"/var"に対して実行する・・・みたいな感じでやっていくと、デカいファイルのありかが突き止められそうですね。


少し絞り込めたら、後は容量を見て確認

"du"コマンドの出力結果をsortしてもいいのですが、今回はサイズの大きなファイルを探すということで、"find"コマンドの"-size"オプションを使ってファイルサイズベースでの絞り込みをします。↓のような感じ。

# find /var -size +100M -exec ls -lh {} \;
-rw-r--r-- 1 daemon daemon 155M  7月 29 11:59 /var/log/hoge/activity/activity.log.2013-07-29
-rw-r--r-- 1 daemon daemon 218M  7月 18 02:00 /var/log/httpd/rewrite_log.20130717.gz
-rw-r--r-- 1 daemon daemon 123M  7月 17 02:00 /var/log/httpd/rewrite_log.20130716.gz
-rw-r--r-- 1 daemon daemon 230M  7月 28 02:00 /var/log/httpd/rewrite_log.20130727.gz
-rw-r--r-- 1 daemon daemon 230M  7月 23 02:00 /var/log/httpd/rewrite_log.20130722.gz
-rw-r--r-- 1 daemon daemon 230M  7月 26 02:00 /var/log/httpd/rewrite_log.20130725.gz
-rw-r--r-- 1 daemon daemon 1.2G  7月 29 11:59 /var/log/httpd/rewrite_log
-rw-r--r-- 1 daemon daemon 206M  7月 20 02:00 /var/log/httpd/rewrite_log.20130719.gz
-rw-r--r-- 1 daemon daemon 229M  7月 27 02:00 /var/log/httpd/rewrite_log.20130726.gz
-rw-r--r-- 1 daemon daemon 208M  7月 24 02:00 /var/log/httpd/rewrite_log.20130723.gz
-rw-r--r-- 1 daemon daemon 223M  7月 21 02:00 /var/log/httpd/rewrite_log.20130720.gz
-rw-r--r-- 1 daemon daemon 211M  7月 19 02:00 /var/log/httpd/rewrite_log.20130718.gz
-rw-r--r-- 1 daemon daemon 239M  7月 29 02:00 /var/log/httpd/rewrite_log.20130728.gz
-rw-r--r-- 1 daemon daemon 196M  7月 29 11:59 /var/log/httpd/fuga-access_log
-rw-r--r-- 1 daemon daemon 228M  7月 25 02:00 /var/log/httpd/rewrite_log.20130724.gz
-rw-r--r-- 1 daemon daemon 237M  7月 22 02:00 /var/log/httpd/rewrite_log.20130721.gz
-rw-r--r-- 1 daemon daemon 161M  7月 22 02:00 /var/log/foobar/foobar-access_log.20130721.gz
-rw-r--r-- 1 daemon daemon 150M  7月 21 02:00 /var/log/foobar/foobar-access_log.20130720.gz
-rw-r--r-- 1 daemon daemon 140M  7月 20 02:00 /var/log/foobar/foobar-access_log.20130719.gz
-rw-r--r-- 1 daemon daemon 143M  7月 19 02:00 /var/log/foobar/foobar-access_log.20130718.gz
-rw-r--r-- 1 daemon daemon 142M  7月 24 02:00 /var/log/foobar/foobar-access_log.20130723.gz
-rw-r--r-- 1 daemon daemon 163M  7月 29 02:00 /var/log/foobar/foobar-access_log.20130728.gz
-rw-r--r-- 1 daemon daemon 147M  7月 18 02:00 /var/log/foobar/foobar-access_log.20130717.gz
-rw-r--r-- 1 daemon daemon 154M  7月 25 02:00 /var/log/foobar/foobar-access_log.20130724.gz
-rw-r--r-- 1 daemon daemon 230M  7月 29 11:59 /var/log/foobar/foobar-access_log
-rw-r--r-- 1 daemon daemon 156M  7月 28 02:00 /var/log/foobar/foobar-access_log.20130727.gz
-rw-r--r-- 1 daemon daemon 155M  7月 27 02:00 /var/log/foobar/foobar-access_log.20130726.gz
-rw-r--r-- 1 daemon daemon 156M  7月 26 02:00 /var/log/foobar/foobar-access_log.20130725.gz
-rw-r--r-- 1 daemon daemon 156M  7月 23 02:00 /var/log/foobar/foobar-access_log.20130722.gz

特定のディレクトリ以下に対して、"-size +100M"を付けることで、ファイルサイズが100MB以上のものだけを抽出しています。こんな感じで結構あぶりだせました。

あとは内容を確認しながら、要らないものであればザックザクと消していきましょう。


とまぁ、簡単に書くとこんな感じですが、もっとエレガントなやり方があれば教えてくださいませ。

それでは! =͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́


追記

コメントを頂戴いたしました。

matsuuさんからコメントいただきました。

これはまさにその通りですね!アレコレ気にする前にnice/ioniceで優先度下げてしまえは、ごもっとも。

あと、本文でも少し言及していますが、duコマンドもsortした方が楽ですね。僕は結果表示が10〜20前後くらいまでなら、チャチャっと実行して、得意の目grepかましてしまう悪いクセがありまして・・・エヘヘ


Linuxシステム[実践]入門 (Software Design plus)

Linuxシステム[実践]入門 (Software Design plus)

2013/07/27

Transcend Low-Voltage 204pin DDR3L-1333 4GBメモリ (TS512MSK64W3N)


少し前に妻のノートPCの増設用のメモリを買った。

タイトルの通り、Transcendの低電圧(1.35V)動作の204pinメモリ。DDR3L-1333(PC3L-10600)で4GBのモデル。(一応)信頼のTSラインです。(TS512MSK64W3N)



少し前に僕が買ったときは、3,280円だったのだが、昨今の高騰により、10日前に4000円台となり、2日前からは5,480円で販売されている・・・。


それはさておき、この手のメモリは買って中身を空けるまでどのチップメーカーが採用されているのかわからない(調べ方があれば教えてください)。上記のAmazonのページでは、Hynix製のチップを使っているように見える。


Transcend DDR3L-1333(1.35V) SO 2R/256Mx8/CL9 4GB

で、購入。こんなパッケージで届きます。


Transcend DDR3L-1333(1.35V) SO 2R/256Mx8/CL9 4GB

パッケージを開けて中身を見てみると、、、おお、チップメーカーはHynix製ではなく、SAMSUNG製でありました。

最近のロットはSAMSUNG製のチップが選ばれている模様。もちろん、買ったロットによってチップメーカーが異なる可能性もあります。ハイ。


VAIO Type S 基盤

妻のノートPCの裏蓋を開けると、、、オンボードのメモリチップはSAMSUNG製でした!一致。

オンボードのメモリも、Low VoltageなDDR3L-1333の4GBメモリなので、無事デュアルチャネル動作しております。


・・・といった、ただのログエントリでございました。

それでは! =͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́


2013/07/25

「著名人ブログページ」に載せてもらえることになりました


大変ありがたい話ですが、はてなブログの「著名人ブログページ」に載せてもらえることになりました。光栄です!

ちなみに、ここしかありえないですが「エンジニア」カテゴリに入れていただきました。


f:id:rx7:20130725002611p:image:w480


参考リンク



Thanks!! 7000000views!!

エントリの内容とは全く無関係ですが、本ブログがの累計PVが700万に到達しました!いつもありがとうございます。

600万PV到達(d:id:rx7:20120919:p1)から、約11ヶ月での到達でした。(ペースが落ちてまいりました・・・。今、約711万PVなので、到達からしばらく経ってはいますが。。。)

2013/07/24

by justgrimes

AWSの上位ネットワークまわりについて


昨日から、色々調べ始めています。今日はAWSの上位ネットワークまわり。特に東京リージョン(Asia Pacific (Tokyo) Region)。

現時点の情報のスナップショットとしてログがわりに残しておきます。


ASN (AS番号)

まず、以下のサイトで調べてみると、、、

f:id:rx7:20130724195324p:image:w480


この通り、Amazonが取得しているASNは10個ほど見受けられますが、中身を見ていくと、このうちAS16509にほぼ集約されていることがわかります。

AS16509に接続されているBGPのPeerの数は現時点で、v4が158、v6が10となっています。(公開情報のみ)

Peerの内訳は以下のリンク先から確認できます。


ざっくり確認するなら、上記サイトで公開されている以下のグラフも参考になります。

f:id:rx7:20130724195325p:image:w480


ただし、このASNはAWS(Amazon)全体で使われているものなので、東京リージョンに絞って調べてみます。


Amazon EC2 東京リージョンの上位ネットワーク

昨日のエントリ「AWSのPublic IPアドレスの一覧」で、2013/5時点でのAmazon EC2の東京リージョンで使われているPublic IPアドレスは以下となっているようです。

175.41.192.0/18 (175.41.192.0 - 175.41.255.255)
46.51.224.0/19 (46.51.224.0 - 46.51.255.255)
176.32.64.0/19 (176.32.64.0 - 176.32.95.255)
103.4.8.0/21 (103.4.8.0 - 103.4.15.255)
176.34.0.0/18 (176.34.0.0 - 176.34.63.255)
54.248.0.0/15 (54.248.0.0 - 54.249.255.255)
54.250.0.0/16 (54.250.0.0 - 54.250.255.255)
54.238.0.0/16 (54.238.0.0 - 54.238.255.255)

↑の全セグメントに対して、隣接しているBGP PeerのASNを調べてみると、(公開情報のみとなりますが)以下のような感じでした。

54.238.0.0/17
54.250.192.0/18
AS2516
AS2914
AS3491
AS6453
AS6939
54.248.0.0/17AS2516
AS2914
AS6453
AS6939
上記以外のセグメント
(ほとんどのセグメントがココ)
AS2516
AS2914
AS3491
AS6453

このように、セグメントによって、やや違ったりするものの、以下が隣接する事業者となるようです。(つまりネットワーク距離的なお隣さんですね。)


また、上記は公開されているBGP Peerしか挙げていませんので、他に引いている細かい回線状況はわからないのと、ピア以降の正確な経路については、それぞれのセグメントによって微妙に異なってたりするので、細かく知りたい場合は地道に調べる必要があります。

例えば、現時点ではてなブログのサイトが属する"54.249.0.0/19"のセグメントは、現時点では以下のような感じになっています。


f:id:rx7:20130724195326p:image:w480


Peering Database (AS16509)

上記サイトの"Exchange Point ASN IP Address Capacity"で各IX事業者との接続状況が確認できます。(以下、上記サイトより勝手に抜粋)

NOTA 16509 198.32.124.193 20000 Mbps
Equinix Ashburn 16509 206.126.236.68 30000 Mbps
SIX 16509 206.81.80.147 20000 Mbps
Equinix Seattle 16509 198.32.134.41 10000 Mbps
Equinix Palo Alto 16509 198.32.176.36 20000 Mbps
Equinix Vienna, VA 16509 198.32.190.23 10000 Mbps
INEX LAN1 16509 193.242.111.50 20000 Mbps
Equinix Ashburn 16509 206.126.236.35 30000 Mbps
Equinix New York 16509 198.32.118.102 10000 Mbps
NYIIX 16509 198.32.160.64 20000 Mbps
Equinix Singapore 38895 202.79.197.87 20000 Mbps
Equinix Tokyo 16509 203.190.230.53 20000 Mbps
Equinix Los Angeles 16509 206.223.123.35 10000 Mbps
Equinix Dallas 16509 206.223.118.110 10000 Mbps
Equinix Chicago 16509 206.223.119.98 10000 Mbps
Equinix San Jose 16509 206.223.116.177 10000 Mbps
Telx Atlanta 16509 198.32.132.95 10000 Mbps
SOX 38895 198.32.141.150 10000 Mbps
AMS-IX 16509 195.69.146.100 30000 Mbps
Equinix Hong Kong 16509 119.27.63.37 10000 Mbps
Terremark - NAP do Brasil 16509 198.32.122.83 1000 Mbps
Telx New York 16509 206.126.115.37 10000 Mbps
DE-CIX Frankfurt 16509 80.81.194.152 40000 Mbps
LINX Juniper LAN 16509 195.66.225.175 40000 Mbps
France-IX 16509 37.49.236.118 20000 Mbps
NetNod Stockholm 16509 194.68.123.47 10000 Mbps
NetNod Stockholm 16509 195.245.240.47 10000 Mbps
LINX Extreme LAN 16509 195.66.237.175 10000 Mbps
CoreSite - Any2 Los Angeles 16509 206.223.143.146 10000 Mbps
PTT-SP 16509 187.16.217.20 10000 Mbps
MIX-IT 16509 217.29.66.117 10000 Mbps
AMS-IX 16509 195.69.146.217 30000 Mbps
Equinix Sydney 16509 202.167.228.131 10000 Mbps
Equinix Paris 16509 195.42.144.162 10000 Mbps
PIPE Networks Sydney 16509 218.100.2.152 10000 Mbps
SGIX 38895 218.100.70.36 10000 Mbps
LONAP 16509 5.57.80.8 10000 Mbps
NetNod Stockholm 16509 195.69.119.47 10000 Mbps
NetNod Stockholm 16509 194.68.128.47 10000 Mbps
ESPANIX 16509 193.149.1.108 10000 Mbps
MyIX 38895 218.100.44.155 1000 Mbps
DE-CIX Frankfurt 16509 80.81.195.152 40000 Mbps
JPNAP Tokyo 16509 210.173.176.188 20000 Mbps
Equinix Singapore 38895 202.79.197.215 20000 Mbps
NYIIX 16509 198.32.160.244 20000 Mbps
KINX 16509 192.145.251.160 10000 Mbps
BBIX 16509 218.100.6.52 10000 Mbps
AMS-IX Hong Kong 16509 103.247.139.10 10000 Mbps

このうち、日本国内にありそうなIXは、以下でしょうか。(見落としているかも)

ちなみに、PeeringDBのリンク先を見ると、そのIXにどういった他事業者が接続しているかが確認できます。(もちろんDBに公開されている情報のみ、ですが。)


また、"Facility Name ASN City Country"のところの「JP」がついているものを抽出すると、、、

Equinix Tokyo (TY2) 16509 Tokyo JP
Telepark Dojima Building 2 16509 Osaka JP

東京と大阪に1つずつIX接続ポイントがあると記載があります。以下にPeeringDBのリンクを記載しておきます。(もちろんDBに公開されている情報のみ、ですが。)


今日はこの辺まで。(ちょっと中途半端なので、気が向いたらシリーズ化します。)

それでは! =͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́



まとめ


2013/07/23

by revedavion.com

AWSのPublic IPアドレスの一覧


たまに調べるのでメモ的に。2013年5月24日時点でのAWSの公開情報です。尚、ソースはAWSのフォーラム。


Amazon EC2

後述のネットワークで割り当てられているパブリックIPアドレス(EC2分のみ、CloudFrontは除く)ですが、スクリプトを書いて計算してみたら、"4,177,920"個という数字が出てきました。

実際に使われている数は、ネットワークアドレスやら何やらで、もうちょっと少ないとは思いますが、約417万個ものグローバルIPアドレスを保有しているといった計算になります。


US East (Northern Virginia)
72.44.32.0/19 (72.44.32.0 - 72.44.63.255)
67.202.0.0/18 (67.202.0.0 - 67.202.63.255)
75.101.128.0/17 (75.101.128.0 - 75.101.255.255)
174.129.0.0/16 (174.129.0.0 - 174.129.255.255)
204.236.192.0/18 (204.236.192.0 - 204.236.255.255)
184.73.0.0/16 (184.73.0.0 - 184.73.255.255)
184.72.128.0/17 (184.72.128.0 - 184.72.255.255)
184.72.64.0/18 (184.72.64.0 - 184.72.127.255)
50.16.0.0/15 (50.16.0.0 - 50.17.255.255)
50.19.0.0/16 (50.19.0.0 - 50.19.255.255)
107.20.0.0/14 (107.20.0.0 - 107.23.255.255)
23.20.0.0/14 (23.20.0.0 - 23.23.255.255)
54.242.0.0/15 (54.242.0.0 - 54.243.255.255)
54.234.0.0/15 (54.234.0.0 - 54.235.255.255)
54.236.0.0/15 (54.236.0.0 - 54.237.255.255)
54.224.0.0/15 (54.224.0.0 - 54.225.255.255)
54.226.0.0/15 (54.226.0.0 - 54.227.255.255)
54.208.0.0/15 (54.208.0.0 - 54.209.255.255)
54.210.0.0/15 (54.210.0.0 - 54.211.255.255)
54.221.0.0/16 (54.221.0.0 - 54.221.255.255)

US West (Oregon)
50.112.0.0/16 (50.112.0.0 - 50.112.255.255)
54.245.0.0/16 (54.245.0.0 - 54.245.255.255)
54.244.0.0/16 (54.244.0.0 - 54.244.255.255)
54.214.0.0/16 (54.214.0.0 - 54.214.255.255)
54.212.0.0/15 (54.212.0.0 - 54.213.255.255)
54.218.0.0/16 (54.218.0.0 - 54.218.255.255)

US West (Northern California)
204.236.128.0/18 (204.236.128.0 - 204.236.191.255)
184.72.0.0/18 (184.72.0.0 - 184.72.63.255)
50.18.0.0/16 (50.18.0.0 - 50.18.255.255)
184.169.128.0/17 (184.169.128.0 - 184.169.255.255)
54.241.0.0/16 (54.241.0.0 - 54.241.255.255)
54.215.0.0/16 (54.215.0.0 - 54.215.255.255)
54.219.0.0/16 (54.219.0.0 - 54.219.255.255)

EU (Ireland)
79.125.0.0/17 (79.125.0.0 - 79.125.127.255)
46.51.128.0/18 (46.51.128.0 - 46.51.191.255)
46.51.192.0/20 (46.51.192.0 - 46.51.207.255)
46.137.0.0/17 (46.137.0.0 - 46.137.127.255)
46.137.128.0/18 (46.137.128.0 - 46.137.191.255)
176.34.128.0/17 (176.34.128.0 - 176.34.255.255)
176.34.64.0/18 (176.34.64.0 - 176.34.127.255)
54.247.0.0/16 (54.247.0.0 - 54.247.255.255)
54.246.0.0/16 (54.246.0.0 - 54.246.255.255)
54.228.0.0/16 (54.228.0.0 - 54.228.255.255)
54.216.0.0/15 (54.216.0.0 - 54.217.255.255)
54.229.0.0/16 (54.229.0.0 - 54.229.255.255)
54.220.0.0/16 (54.220.0.0 - 54.220.255.255)

Asia Pacific (Singapore)
175.41.128.0/18 (175.41.128.0 - 175.41.191.255)
122.248.192.0/18 (122.248.192.0 - 122.248.255.255)
46.137.192.0/18 (46.137.192.0 - 46.137.255.255)
46.51.216.0/21 (46.51.216.0 - 46.51.223.255)
54.251.0.0/16 (54.251.0.0 - 54.251.255.255)
54.254.0.0/16 (54.254.0.0 - 54.254.255.255)
54.255.0.0/16 (54.255.0.0 - 54.255.255.255)

Asia Pacific (Sydney)
54.252.0.0/16 (54.252.0.0 - 54.252.255.255)
54.253.0.0/16 (54.253.0.0 - 54.253.255.255) 

Asia Pacific (Tokyo)
175.41.192.0/18 (175.41.192.0 - 175.41.255.255)
46.51.224.0/19 (46.51.224.0 - 46.51.255.255)
176.32.64.0/19 (176.32.64.0 - 176.32.95.255)
103.4.8.0/21 (103.4.8.0 - 103.4.15.255)
176.34.0.0/18 (176.34.0.0 - 176.34.63.255)
54.248.0.0/15 (54.248.0.0 - 54.249.255.255)
54.250.0.0/16 (54.250.0.0 - 54.250.255.255)
54.238.0.0/16 (54.238.0.0 - 54.238.255.255)

South America (Sao Paulo)
177.71.128.0/17 (177.71.128.0 - 177.71.255.255)
54.232.0.0/16 (54.232.0.0 - 54.232.255.255)
54.233.0.0/18 (54.233.0.0 - 54.233.63.255)

GovCloud
96.127.0.0/18 (96.127.0.0 - 96.127.63.255)

Amazon CloudFront

54.230.0.0/16
54.239.128.0/18
54.240.128.0/18
204.246.164.0/22
204.246.168.0/22
204.246.174.0/23
204.246.176.0/20
205.251.192.0/19
205.251.249.0/24
205.251.250.0/23
205.251.252.0/23
205.251.254.0/24
216.137.32.0/19 

参考リンク


追記

ネットワークまわりのエントリってことで、続きを書いた。



まとめ


2013/07/22

書籍: Web開発の基礎徹底攻略


という書籍が出ます。

その中で、僕が過去にWEB+DB PRESSで寄稿したクラウドの基本記事が、少し手直しして収録されています。


以下の目次を見てもらえればお分かりの通り、基本的にはWebエンジニア向けの基礎的な内容です。まだ新卒1〜2年目くらいのエンジニアで、これから経験値を積んでいく過程で、ザッとWeb開発や言語、設計、OSSアーキテクチャの概要を掴むのには良い書籍だと思います。


■特集1
[新人時代に押さえておきたい]Web技術まるごと整理
言語、何が違うの? サーバの役割分担って? いま流行りのクラウドって?

■特集2
コーディングの基礎知識
10年後も役立つ習慣を身につける!

■特集3
[身につけたい良い設計の基礎知識]はじめての設計
変化に強い構造・読みやすいコード・適切な分割

■特集4
データベース&SQL入門
集めたデータを自在に操るための基本の基本

■特集5
クラウド時代のインフラ知識
Webエンジニアが知るべきネットワークやサーバのしくみ

■一般記事
Twitter時代の技術者コミュニケーション術

参考リンク


2013/07/19

Amazonでオライリー洋書のKindle版の一部が0円で販売中...!!


会社の人に教えてもらったのですが、AmazonのKindleストアオライリー洋書(Kindle版)の一部が「0円」で販売されています。

f:id:rx7:20130719184016p:image:w480


Amazon.co.jp - Kindleストア > Kindle洋書 > ”O’Reilly” (価格の安い順)


↑のリンクは"価格の安い順"に並べ替えていますので、現時点(2013/07/19 18:30)で100冊程度の書籍が0円で表示されていますね。

例えば、、、 "JavaScript", "Learning Perl", "Scaling MongoDB", "97 Things Every Programmer Shoulds Know", "HACKER & PAINTERS", "Test Driven Infrastructure with Chef" などなど。これはほんの一例。

※ ご購入前に販売価格は必ずお確かめください。


追記 (2012/07/20 1:00)

一部を除いて、今は0円祭りは終わってしまっている模様です・・・。



他にも、昨日から始まった楽天のkoboの対抗施策(全電子書籍30%引き)か、現在AmazonのKindleストアでは、ほぼ全ての電子書籍(Kindle版)で、30%のポイントが還元されるようになっています。これはすごい。

(ちなみに、koboのキャンペーンは7/21の〜9:59までのようです。Kindleストアも同時期開催かも?)


それでは! =͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́

2013/07/04

Chef Server(ver.10系)のDB(CouchDB)の不要データを掃除してディスク容量を確保する


Chef Serverのバージョン10系では、バックエンドのデータベースとしてCouchDBが採用されていますが、このCouchDBは、ドキュメント更新時に古いものを上書きせず、常に新しいリビジョンとして登録しなおす特徴があります。

CouchDB は、ドキュメントを更新するときに元のドキュメントを上書きすることはせず、元のドキュメントと同一の _id を持ち、新しい _rev ID を持ったドキュメントをデータベース・ファイルの末尾に新しく作成します。この種のストレージ・システムはディスクスペースを消費するため、ディスクスペースを空けるためには定期的に圧縮を行う必要があります。

Document revisions - Couchdb Wiki

ということで、Chef Server(バージョン10系)を長く運用して使っていると、古いデータがどんどん蓄積されていくので、定期的にCompactionを行うのが良さそうです。


やり方

で、肝心のやり方ですが、以下のOpscodeのドキュメントにあります。


が、せっかくなので試して書いておきましょう。日本語でw

まずは、現状を確認してみます。

# ll -h /var/lib/couchdb/1.0.1
total 11G
drwxrwx--- 4 couchdb couchdb 4.0K 2013-07-04 14:17 ./
drwxrwx--- 3 couchdb couchdb 4.0K 2012-01-27 04:07 ../
-rw-rw-r-- 1 couchdb couchdb  11G 2013-07-04 14:11 chef.couch
drwxrwxr-x 2 couchdb couchdb 4.0K 2012-02-01 20:40 .chef_design/
-rw-rw-r-- 1 couchdb couchdb   23 2013-07-01 20:32 couch.uri
drwxrwxr-x 2 couchdb couchdb 4.0K 2012-01-27 04:07 .delete/
-rw-rw-r-- 1 couchdb couchdb 4.1K 2012-01-27 04:07 _users.couch

この中の"chef.couch"ってファイルがDBの実体ファイルですね。11GBほどあります。

CouchDBはRESTfulなHTTP APIが提供されているので。そちらを叩いてオペレーションします。

$ curl http://localhost:5984
{"couchdb":"Welcome","version":"1.0.1"}

例えば、これはDBのバージョン情報。


$ curl http://localhost:5984/chef
{"db_name":"chef","doc_count":25683,"doc_del_count":753,"update_seq":94233,"purge_seq":0,"compact_running":false,"disk_size":11334766699,"instance_start_time":"1372678339122342","disk_format_version":5,"committed_update_seq":94233}

こんな感じで、Chefで使われているDBの領域の情報が確認できます。

では、ここからが本題。

Compaction(圧縮)のオペレーションはとても簡単で、以下をコマンド実行する(APIをキックする)だけです。(API経由なので当然ですがオンラインで実行できます。)


$ curl -H "Content-Type: application/json" -X POST http://localhost:5984/chef/_compact
{"ok":true}

Compactionが始まると、↑な感じで「"ok":true」が返されます。


$ curl http://localhost:5984/chef
{"db_name":"chef","doc_count":25683,"doc_del_count":753,"update_seq":94233,"purge_seq":0,"compact_running":true,"disk_size":11334766699,"instance_start_time":"1372678339122342","disk_format_version":5,"committed_update_seq":94233}

さっきとは違って、「"compact_running":true」に変わっています。ここがtrueの間は、圧縮処理が走っていることを意味します。これがfalseになると処理が終了したってことになります。


$ curl http://localhost:5984/chef
{"db_name":"chef","doc_count":25683,"doc_del_count":753,"update_seq":94233,"purge_seq":0,"compact_running":false,"disk_size":232009829,"instance_start_time":"1372678339122342","disk_format_version":5,"committed_update_seq":94233}

終わったみたいですね。実行時間は↑の規模で1〜2分くらいだったでしょうか。さっきと比べて、"disk_size"がガクンと落ちています。


# ll -h /var/lib/couchdb/1.0.1
total 222M
drwxrwx--- 4 couchdb couchdb 4.0K 2013-07-04 14:27 ./
drwxrwx--- 3 couchdb couchdb 4.0K 2012-01-27 04:07 ../
-rw-rw-r-- 1 couchdb couchdb 222M 2013-07-04 14:25 chef.couch
drwxrwxr-x 2 couchdb couchdb 4.0K 2012-02-01 20:40 .chef_design/
-rw-rw-r-- 1 couchdb couchdb   23 2013-07-01 20:32 couch.uri
drwxrwxr-x 2 couchdb couchdb 4.0K 2013-07-04 14:25 .delete/
-rw-rw-r-- 1 couchdb couchdb 4.1K 2012-01-27 04:07 _users.couch

実体ファイルのサイズを確認すると、222MBになりました。

元が11GBだったので、およそ98%ほどカットされましたw

(ずっとCompactionを実行していなかったのがバレますね、これw)


書き込みの負荷がほぼ限界に達しているデータベース・ノードに対して圧縮を行うのは避けるべきです。なぜなら、もし書き込みがいつまでも終わらなければ、圧縮プロセスは書き込みに追い付くことができず、最後はディスクスペースを使い切ってしまうからです。

圧縮は、書き込み負荷が限界に達していないときに行う必要があります。なお、読み込み負荷は圧縮プロセスには影響しません。CouchDB のこのような動作はクライアントへの影響を最小限に抑えるためで、データベースをオンライン状態に保って読み取りと書き込みに対して完全に機能するようになっています。書き込み負荷が限界に達しているときにデータベースの圧縮を完了できないのは、設計上の制約です。したがって、オフピーク時に圧縮をスケジュールするのが妥当な解決策です。

クラスタ環境では、任意のノードで書き込み負荷を下げてから圧縮を実行し、レプリケーションが完了したら書き込み負荷を元どおりに戻すといった対応が可能です。

Compaction - Couchdb Wiki

CouchDBのWikiにも、こんな注意が書かれていますので、実行タイミングは計画的に。

というか、Chef Serverがここまで負荷的にシビアになることは、相当大規模な環境下でchef-clientをデーモン化している場合とかになるんでしょうね。

それでは! =͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́


入門Chef Solo - Infrastructure as Code

入門Chef Solo - Infrastructure as Code

Instant Chef Starter

Instant Chef Starter


オススメ (一部は、最近読んでいる本とも言う)
Chef実践入門 ~コードによるインフラ構成の自動化 (WEB+DB PRESS plus) クラウド Amazon EC2/S3のすべて~実践者から学ぶ設計/構築/運用ノウハウ~ [Web開発者のための]大規模サービス技術入門 ―データ構造、メモリ、OS、DB、サーバ/インフラ (WEB+DB PRESS plusシリーズ) エキスパートのためのMySQL[運用+管理]トラブルシューティングガイド [24時間365日] サーバ/インフラを支える技術 ~スケーラビリティ、ハイパフォーマンス、省力運用 Linux-DB システム構築/運用入門 (DB Magazine SELECTION) キャパシティプランニング ― リソースを最大限に活かすサイト分析・予測・配置 スケーラブルWebサイト 実践ハイパフォーマンスMySQL 第3版 ウェブオペレーション ―サイト運用管理の実践テクニック (THEORY/IN/PRACTICE) SQLアンチパターン インターネットのカタチ―もろさが織り成す粘り強い世界― ハイパフォーマンス ブラウザネットワーキング ―ネットワークアプリケーションのためのパフォーマンス最適化 Linuxの教科書―ホントに読んでほしいroot入門講座 (IDGムックシリーズ)