varnish 2.x → 4.x 移行したら遅くなった(ベンチ的に)
varnish 2.1.5 を単一サイトでちょっと使ってました。
んで、まぁちゃんと使うならきちんと新しいバージョンにしたいよね、と思い
4系にバージョンアップ。
移行前：varnish 2.1.5 (CentOS 6 epelで入るもの)
移行後：varnish 4.0.3 (varnish 公式サイトのyumリポジトリから入るrpm)
あくまでもabを使った簡易的なベンチマークですが以下のような感じ。
varnish 4
Server Software: Apache
Server Hostname: 127.0.0.1
Server Port: 80
Document Path: /
Document Length: 9033 bytes
Concurrency Level: 900
Time taken for tests: 0.744 seconds
Complete requests: 6000
Failed requests: 0
Write errors: 0
Total transferred: 57683104 bytes
HTML transferred: 55778775 bytes
Requests per second: 8065.35 [#/sec] (mean)
Time per request: 111.588 [ms] (mean)
Time per request: 0.124 [ms] (mean, across all concurrent requests)
Transfer rate: 75721.76 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 48 5.1 50 55
Processing: 28 58 13.8 61 104
Waiting: 0 31 12.0 30 68
Total: 74 106 13.1 109 154
dockerのイメージを壊した話。
dockerで遊んでいたところ。
/bin/bash: error while loading shared libraries: /lib64/libtinfo.so.5: invalid ELF header
むむむ。
何も出来なくなった。
ここで、dockerのイメージ管理について簡単に説明。
詳細は http://enakai00.hatenablog.com/entry/20140420/1397981156 とかで。
ざっくり言うと、100GBくらいの巨大なファイルの中にベースとなるOSのイメージと、
各コンテナのイメージ差分が格納されている。(はず)
[root@docker-host ~]# ls -aldh /var/lib/docker/devicemapper/devicemapper/data -rw------- 1 root root 100G Jul 17 14:55 /var/lib/docker/devicemapper/devicemapper/data
先ほどの記事に倣ってマウントしてみる。
今回はdc934b46cab6を。
[root@docker-host ~]# docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
dc934b46cab6 centos:6-build-test2 "/bin/bash -l" 9 days ago Exited (127) 20 hours ago prickly_colden
e3992f5f8eac centos:6-build-test2 "/bin/bash -l" 2 weeks ago Exited (130) 2 weeks ago elegant_jang
[root@docker-host ~]# cat /var/lib/docker/devicemapper/metadata/dc934b46cab6618f155c5d298bfb5b0ec67960e4c3889b2076c9c42ab749d554
{"device_id":162,"size":10737418240,"transaction_id":497,"initialized":false}
[root@docker-host ~]# ls -ald /dev/mapper/docker-*
lrwxrwxrwx 1 root root 7 Jun 29 20:03 /dev/mapper/docker-252:3-13370648-pool -> ../dm-0
[root@docker-host ~]# device_id=162
[root@docker-host ~]# size=10737418240
[root@docker-host ~]# pool=docker-252:3-13370648-pool
[root@docker-host ~]# dmsetup create myvol --table "0 $(($size / 512)) thin /dev/mapper/$pool $device_id"
[root@docker-host ~]# mount /dev/mapper/myvol /mnt
[root@docker-host ~]# mount | grep -F /dev/mapper/myvol
/dev/mapper/myvol on /mnt type ext4 (rw)
[root@docker-host ~]# df -h /mnt
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/myvol 9.9G 702M 8.7G 8% /mntマウント出来たのでdockerの中のファイルがどうなってしまったのか見てみる。
[root@docker-host ~]# chroot /mnt/rootfs/ /bin/bash /bin/bash: error while loading shared libraries: /lib64/libtinfo.so.5: invalid ELF header [root@docker-host ~]# ls -al /mnt/rootfs/lib64/libtinfo.so.5 lrwxrwxrwx 1 root root 15 Jun 16 04:19 /mnt/rootfs/lib64/libtinfo.so.5 -> libtinfo.so.5.7 [root@docker-host ~]# ls -al /mnt/rootfs/lib64/libtinfo.so.5.7
- rwxr-xr-x 1 root root 135896 Aug 19 2010 /mnt/rootfs/lib64/libtinfo.so.5.7
むむむ。。
ちなみにこれがホスト環境側のファイル。
[root@docker-host ~]# cat -A /lib64/libtinfo.so.5.7 | head -n1 | cut -b1-120 ^?ELF^B^A^A^@^@^@^@^@^@^@^@^@^C^@>^@^A^@^@^@@M-H@C0^@^@^@@^@^@^@^@^@^@^@M-(^T^B^@^@^@^@^@^@^@^@^@@^@8^@^F^@@^@^^^@^]^@^A
ELFヘッダも確認できる正常なファイル。
ということで、dockerの中のファイルが壊れてしまったことは確認できたのだがこれ以上どうしようもないようだ。
ファイルの変更された日を知りたい。
lsで表示される日時や、mtimeは偽装が可能。
悪いことされたファイルについては、ctimeを見るほうが良い。
と思ってたのだけれども、、、、、
chmodしてもctimeが更新されるのね。
日記
書いて無さ過ぎ。
まだまだハマるよ。(環境依存文字)
むむむむむむむ。
http://snowland.net/nucleus/item/3355
カッコ株はiso-2022-jpにありませんよ。
って話。よく使われる文字だけ変換テーブルに掛けるべか。
って、思ったんだけど、
http://route477.net/d/?date=20110119
お、、、、
もっと簡単な方法がある。String#encodeにオプションを渡すと、不正なバイト列の扱いを指定することができる。
例えば以下のようにすると、不正なバイト列や変換が未定義のバイト列は適当な記号で置き換えられる。
html = open(url, "r:euc-jp").read.encode("utf-8", :invalid => :replace, :undef => :replace)
これでこの件も解決かなぁ。
