2014年4月27日日曜日

(合理的な)理由

先月、髪を切りにいった時の美容師さんとの会話にて。結婚する合理的な理由て無いなと話をしていた。

美容師さん自身は既婚でありお子さんもいるので、まぁ話半分でもあり、間違いなくそっち側へ話を向けるほうが無難ではある。(未婚者にやたら「いいもんだよ」とすすめてもしょうがないだろうし、その場合言葉の端々から滲み出る優越感は隠せないだろうしねぇ)

・・とは思いつつも、やはり自分の場合には合理的な理由はない。
 家を継がなきゃというのはないし、世間体を気にするというのもないし、、。

「既婚者でなければ資格が与えられない」なにかの場合のみかな。
例えばフリーメイソンに入るとか。(と思ったら、どうも独身者でもいいのね。。)

まー、そういうのを一切考えなくても、ただ単にマネーパワーが全然足りない気がする。それが全てではないけど、ないと間違いなく困るよね。

2014年4月23日水曜日

gce をほんのすこしだけおさわり

GCEをすこーし触ってみた。一般提供開始前に使える状態にはあったけどずーっと放置していた。

https://cloud.google.com/ へいく
上部の Go to my console をクリック、Google Developer Console へ。

自分の場合はまえ作るだけで終わったプロジェクトが残ってたのでまずはお掃除。プロジェクトを削除し、心機一転、新しいプロジェクトを作成した。

課金の設定が必要だったのでぽちぽちと入力。種類は individual。(この時点では英語表示で利用していた)

コンソールが多言語対応しているということなので、日本語で利用。 気に食わなかったら英語に戻すつもり。
英語、スペイン語、ポルトガル語、中文(台灣)、日本語が選べる。

コンソールは、作成したプロジェクトから Compute Engine をクリックすればよい。
「VM インスタンス」=> 「新しいインスタンス」からさくさくとインスタンスは起動できる。
AWSでいうRegionという区分けは無い(?)ようで、インスタンス起動時に「ゾーン」から us-centralか、europe-west か、asia-east かを選ぶ。それぞれ a,b がある模様。

マシンタイプは慣れてないのでなにがなんなのかさっぱりわからない。スペックが表示されるからよいものの、まちがってハイスペックなのを起動しそうではある。すぐ止めればよいか。
ブートソースはいまんとこ選択肢が少ない。 debian と backports-debian の違いはなんだろう。rhel は別に課金されるんだろうか。

起動後は gcutil というのを利用し SSH。なのでまず gcutil を入れねばならんのだった。SSH鍵は実行時によきに計らってくれるので親切。
katsuji@testgce:~$ uptime
 16:57:13 up 25 min,  1 user,  load average: 0.00, 0.01, 0.05
katsuji@testgce:~$ cat /proc/version
Linux version 3.2.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.54-2
ps とってみると xen なんちゃらみたいなのはいないみたいなのでKVMか、と思ったらFAQにあった。
https://developers.google.com/compute/docs/faq?hl=ja#whatisgooglecompute

↑みるまえに slabbed-or-not というのを使ってみていた。
katsuji@testgce:~/slabbed-or-not$ ./slabbed-or-not
Not running under any known container type
Hypervisor: KVM
後発ならではの利点をふんだんに生かすのだろうな、と何となく思う。

コンソールの日本語表示は、エフェメラル/静的 と書くならエフェメラル/スタティックでよいんじゃないの、と思う箇所があったり。グラフ表示で 1hour, 1day となっていたりするので要所は抑えて対応してる感じかな。
「新しいインスタンス」クリック後に
Create a new instance  Show advanced options 
とでてきたりもしている。

かるく触ってみたあとに思ったのが、コンソールは
Google "Developers Console"
なんだよね。Developer でない身にとってはなんとなく居心地わるい感じ。Developer でないのに使ってスミマセン><的な。。

しばらくはどこぞのだれかの事例をあれこれみて楽しむことにしよう。

2014年4月21日月曜日

2014年4月19日土曜日

EC2 で Redis を使うなら HVM AMI で使うと幸せかも

ご存知のとおり、Redis latency problems troubleshooting には
「EC2ではforkがとっても遅い」旨書かれている。EC2というよりはXenの issue。
これ =>  bug 1815 - Xen fork() system call is to slow 

だがしかし、paravirtual でのみ測ったものではないのかな?と思ったのでHVMとで比較してみたところ、これからはHVMだね(ニッコリ という結果だった。
現行世代でparavirtual/HVMが選べる場合は、HVMがよいでしょう。
https://aws.amazon.com/amazon-linux-ami/instance-type-matrix/ 

こんなのも。  Forking time in Xen 

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html
をみると、
With HVM virtualization, the guest VM runs as if it were on a native hardware platform, except that it still uses PV network and storage drivers for improved performance.
と書かれているので、EC2でいう「HVM」はXenでの厳密な区分でいう「PVHVM」にあたるんだろう。=> http://wiki.xen.org/wiki/Xen_Overview#Guest_Types

これでもう「EC2だとfork遅いから云々」というのは過去のものになる(なりつつある)かな。まだまだ(旧世代のも含め) paravirtualでの利用は多いんだろうけど。

EC2 にかぎらず、AWS自体が前の知識のままでいると置いてかれるので、定期的に「前のあれ今やってみるとどうなるかなー」と試してみると良いかんじね。

その後ぐぐってみると、2012年11月の時点で検証してる人いたので、「なにを今更・・・」感はある。。これ。
Benchmarking the new AWS M3 instances with Redis
この場合は m2.2xlarge と m3.2xlarge の比較。
stackoverflow にも。
Best EC2 setup for redis server

それはさておき、つぎのように実施した。

環境
・リージョン: Oregon
・EC2 m3.2xlarge (当初m3.mediumでやってたけどトロいので変更)
・AMI
 amzn-ami-hvm-2014.03.1.x86_64-ebs (ami-383a5008)
 amzn-ami-pv-2014.03.1.x86_64-ebs (ami-043a5034)
・Redis 2.8.8
  ソースから make ; make install していれただけ
  redis.conf は 次のとおり. diff元はtar玉に入っていたもの。

$ diff  redis.conf /usr/local/etc/redis.conf
37c37
< daemonize no
---
> daemonize yes
103c103
< logfile ""
---
> logfile /usr/local/var/redis/redis.log
187c187
< dir ./
---
> dir /usr/local/var/redis

・m3.2xlarge なんで今回きにしなくていいんだけど vm.overcommit_memory を 1にしておいてもよい


準備
・てきとうにデータを投入(キー数1億. メモリ使用量が8G強)

その1
・bgsave 後に redis-cli info してでてくる latest_fork_usec を確認
・繰り返し

その2
・起動
・停止
・をひたすら繰り返し、ログにでてくる DB loaded from disk を確認

その1結果
HVM: 4900us 弱 (5ms 弱)
paravirtual: 1840000us 強 (1.8s 強)

* コマンドラインで叩いた場合、paravirtualだと「もっさり感」がある。


その2結果
HVM: 94s
paravirtual: 114s


ほか
・slave作成時もHVMが高速なんじゃないかな
・インスタンスストア使わずにルートボリュームに dump.rdb おいてたので、インスタンスストア使うとその2は違ってくるかも
・redis-cli --latency -h `host` -p `port` をしておいてもよかった


その1結果詳細
HVM:
Background saving started
used_memory_human:8.30G
latest_fork_usec:4838
db0:keys=100000000,expires=0,avg_ttl=0

Background saving started
used_memory_human:8.30G
latest_fork_usec:4730
db0:keys=100000000,expires=0,avg_ttl=0

Background saving started
used_memory_human:8.30G
latest_fork_usec:4827
db0:keys=100000000,expires=0,avg_ttl=0

Background saving started
used_memory_human:8.30G
latest_fork_usec:4734
db0:keys=100000000,expires=0,avg_ttl=0

Background saving started
used_memory_human:8.30G
latest_fork_usec:4871
db0:keys=100000000,expires=0,avg_ttl=0

Background saving started
used_memory_human:8.30G
latest_fork_usec:4855
db0:keys=100000000,expires=0,avg_ttl=0

Background saving started
used_memory_human:8.30G
latest_fork_usec:4852
db0:keys=100000000,expires=0,avg_ttl=0

Background saving started
used_memory_human:8.30G
latest_fork_usec:4833
db0:keys=100000000,expires=0,avg_ttl=0

Background saving started
used_memory_human:8.30G
latest_fork_usec:4858
db0:keys=100000000,expires=0,avg_ttl=0

Background saving started
used_memory_human:8.30G
latest_fork_usec:4808
db0:keys=100000000,expires=0,avg_ttl=0

paravirtual:
Background saving started
used_memory_human:8.30G
latest_fork_usec:1844786
db0:keys=100000000,expires=0,avg_ttl=0

Background saving started
used_memory_human:8.30G
latest_fork_usec:1844741
db0:keys=100000000,expires=0,avg_ttl=0

Background saving started
used_memory_human:8.30G
latest_fork_usec:1843755
db0:keys=100000000,expires=0,avg_ttl=0

Background saving started
used_memory_human:8.30G
latest_fork_usec:1842669
db0:keys=100000000,expires=0,avg_ttl=0

Background saving started
used_memory_human:8.30G
latest_fork_usec:1847125
db0:keys=100000000,expires=0,avg_ttl=0

Background saving started
used_memory_human:8.30G
latest_fork_usec:1845629
db0:keys=100000000,expires=0,avg_ttl=0

Background saving started
used_memory_human:8.30G
latest_fork_usec:1845080
db0:keys=100000000,expires=0,avg_ttl=0

Background saving started
used_memory_human:8.30G
latest_fork_usec:1844727
db0:keys=100000000,expires=0,avg_ttl=0

Background saving started
used_memory_human:8.30G
latest_fork_usec:1845251
db0:keys=100000000,expires=0,avg_ttl=0

Background saving started
used_memory_human:8.30G
latest_fork_usec:1849802
db0:keys=100000000,expires=0,avg_ttl=0


その2結果詳細
HVM:
DB loaded from disk: 94.132 seconds
DB loaded from disk: 93.905 seconds
DB loaded from disk: 93.713 seconds
DB loaded from disk: 94.064 seconds
DB loaded from disk: 93.946 seconds
DB loaded from disk: 94.087 seconds
DB loaded from disk: 94.007 seconds
DB loaded from disk: 94.474 seconds
DB loaded from disk: 94.197 seconds
DB loaded from disk: 93.898 seconds

paravirtual:
DB loaded from disk: 115.066 seconds
DB loaded from disk: 113.277 seconds
DB loaded from disk: 113.989 seconds
DB loaded from disk: 114.039 seconds
DB loaded from disk: 114.327 seconds
DB loaded from disk: 113.247 seconds
DB loaded from disk: 114.156 seconds
DB loaded from disk: 114.122 seconds
DB loaded from disk: 114.245 seconds
DB loaded from disk: 118.952 seconds


おまけ
MBP Mid 2012 での結果. latest_fork_usecだけ.
latest_fork_usec:4225
latest_fork_usec:4409
latest_fork_usec:4322
latest_fork_usec:4616
latest_fork_usec:4328
latest_fork_usec:4300
latest_fork_usec:4447
latest_fork_usec:4253
latest_fork_usec:4216

2014年4月8日火曜日

OpenSSL の件

Heartbleed Bug
とゆーので賑わってたのだけど、そもそも自分は

ハートビート拡張がなんなのか知らない

という・・・ orz

各ディストリビューションでの対応は〜〜みたいなエントリはボコボコ立ってるので、ハートビート拡張とわなんぞや、OpenSSLでやらかした missing bounds check でここがこ〜なってるからやばいのよね、みたいなくわしい解説をしてるとこをちゃんとみておきたい。一方GnuTLSだとこうなってる、とかも。

こういうソフトウェアのCIってどうやってるんだろうね。

 
RFC6520
https://tools.ietf.org/html/rfc6520

1.0.1f と 1.0.1g の diff とってみたものの、、うーん、なんだこれ。

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0160
のとおり、素直にgit.openssl.orgでdiffみればいいか。


関連サイト追記:
Theo 様からのお言葉
http://undeadly.org/cgi?action=article&sid=20140408063423


2014年4月7日月曜日

ウェブスケールシーコー

Web Scale SQL
http://webscalesql.org/

米FacebookやGoogle、Twitterなどが独自のMySQL拡張「Web Scale SQL」を開発へ
http://sourceforge.jp/magazine/14/03/28/163000

素敵な協業。
FAQみると、MySQL Community release のブランチでありフォークではないと書いてある。

「MySQL」と一口に言っても、MySQL, Percona Server, MariaDB と、
この WebScaleSQLとあって、選ぶに悩む人々が増えるのかもしれない。
MariaDBは 10.0で独自路線になりつつあるからまた違うか。
そういえば Drizzle ってどうなってんだろう。

去年は
 グーグルがMySQLを切り捨ててMariaDBを採用
とゆーのがあったんだけど、しれっとMariaDBからWebScaleSQLへの移行とかしちゃってるんだろうか。だろうねきっと。

2014年4月6日日曜日

種類の違う難しさ

とある件で正しいと思える情報源に行き着くのがなかなかどうしてむつかしい。

余計に手間やつうしんパケットの無駄が発生してる感があり、
今後スケールできるのかなーと。今の自分が考える事柄ではないものの。

しばらくは(ワーストケースだと、ずっと)本来注力するところ意外に多くの時間を割かないといけないのかもしれない。
この、異質な難しさと気持ち悪さを解消、あるいは軽減しないとな。

「慣れだよ、慣れ」で済ますのもなんだしな。。

2014年4月4日金曜日

Project Euler 再開することにした

前の職場のわけしがやってるのに触発されたので、前ちょこっとやって放置したProject Eulerを再開することにした。

日々コードを書くおしごとではないので、時間を増やす意味もあり。

まずはわけしが解いてるとこまで追いつかねば・・・