nori's tech days: 4月 2009

2009年4月29日水曜日

どのくらいエラーが起こるか？

WSDM09 key note.より
Sort 1 TB of data without parity: ends up "mostly sorted"とのこと。1999年の時点で1TBをソートする必要があったらしい。

pixivではpage一覧をスクロールすることができる。この青いやつがスクロールだ。普通ならページへのジャンプをカチカチやっていく必要があるのだが、googleの検索結果と違ってpixivでは順位に意味が無いので、必須であろう。

第30回スクローリングの小細工を思い出した。

カテゴリわけするなら、「取り扱う全体の量が多くひとつの範囲指定ウィジットではまかないきれないケースを取り扱うための工夫」といえるだろう。

git

gitでremoteのbranchを持ってきたり、remoteにbranchを持っていったり。効率的かどうかは知りませんが。

もっていく場合：


% git push <remote-repo> <local-branch>

持ってくる場合：


% git fetch <local-branch> <remote-repo:remote-branch>

2009年4月28日火曜日

体感速度

この絵の出所はここpixivのロードの速さに逝きそうになった。

facebookは、重いとかいうレベルじゃない。ブラクラ級。いったいどうなってんじゃ。
はてな：重い。スターとかコメントのイメージのロードが遅いんだよ。ダサい。しかもよくとまってるし。
mixi: 若干重い。でもとまることは珍しい。
google: ほんとに海の向こうにあるのか？！

よく見ると、pixivではすべての画像が読み込まれるのはちょっと時間がかかっている。でもレイアウトが変わらないから重さを感じさせないのかもしれない。

googleさんに尋ねてみました。

code zine

月間3億PVのサーバーってどうなってるの？ pixiv管理者に聞いた

アクセス解析データを公開-part5@開発者のブログ

ライブドアとGのサーバランニングコスト

[JOB BOARD] ライブドア社にてWebサービスを基盤から支える、とんがった技術者を募集

今は何人ぐらいでどれくらいのサーバを見られているのでしょうか

勤務は三交代制で、朝、昼、夜になっています。これは常に変わらないので、私の場合は朝の勤務を続けています。各チームは10名前後なので、全体では30人くらいのチーム体制になります。サーバは全部で7,800台となっています。

google コンテナ７台か。もちろん、誰のコンテンツをおいているかによって顧客対応の有無があるので単純比較できません。サクラが１万台ホストしている話の時もそうでしたが。

月にマシン１台あたり2万円の売り上げだと考えると20K x 7.8k = 160m, 1億6千万の売り上げ。まあ、台数が多ければもうちょっと安くなるとしても100mはくだらないだろう。だとすると3m/人月。2m/人月で仕事を請ける開発系より給料負荷比がよさそうですね。

しかし20k jpy/per machineの売上って、8k/per machineのコストだよね。diskはすべてのマシンに1Tはないだろうし、いくらなんでも80Gはありそう。一番高いケースで1Gあたり800jpy、まあありそうなのは200jpyとかか？。正確な数値と出典を忘れたけどgoogleは1Gあたり$1を切っていたと思うから、一人当たりの台数がそのまま利いているのだろう。土地代も安いだろうし。電気代はよくわかりません。

ステルス田代砲

techcrunchの記事「Time Magazine、4Chanによる乗っ取り行為を華麗にスルー」

内容を紹介しているブログによると、

time.comが投票に使っているurlは


       http://www.timepolls.com/contentpolls/Vote.do
          ?pollName=time100_2009&id=1883924&rating=1

をhttp getする仕組みで、なーんの認証もかかっていなかったらしい。

そこで


        http://fun.qinip.com/gen.php?id=1883924
                     &rating=1&amount=160

というurlをspamとしてどっかのページに埋め込み、踏んだ人が最低レーティングの1を160回投票するように仕向けた。

ratingは1~100の%だったのだが、値の範囲チェックが行われておらず（！）、そのうちマイナスのratingをvoteするようにした。その結果mootは300%をもらって、ほかの候補者には全部マイナスを投票。さすがにtime.comも気づいて、md5sumをつけるようにした。

Shortly afterward, Time.com changed the protocol to attempt to authenticate votes by requiring that a key be appended to the poll submission URL that consisted of an MD5 hash of the URL + a secret word (AKA ‘the salt’).

でもすぐにそのsaltが投票用のflashアプリの中にハードコードされていることがばれてしまい、自動投票botは再び機能し始めた。

shortly afterward, one of the members discovered that the ’salt’, the key to authenticating requests, was poorly hidden in Time.com’s voting flash application and could be extracted.

Mooterのscreen shot。ちゃんとguiがあるよ。

これを使って10,000,000票を投じたらしい。
先のspam linkを踏んだクラインといるIP１つから300票投票でき、また「串」を経由することでその数を増やした。

2009年4月27日月曜日

名前の秘密

昔、新卒さんに（関数だか、ファイル名だかで）「かっこいい名前無いですか？」と聞かれて、それは質問がよろしくないと諭したが、無視されたことを思い出した。

tsurezuregusa.comより

徒然草　第百十六段　

寺院の号、さらぬ万の物にも、名を付くる事、昔の人は、少しも求めず、たゞ、ありのまゝに、やすく付けけるなり。この比は、深く案じ、才覚をあらはさんとしたるやうに聞ゆる、いとむつかし。人の名も、目慣れぬ文字を付かんとする、益なき事なり。

何事も、珍しき事を求め、異説を好むは、浅才の人の必ずある事なりとぞ。

■ 現代語訳　

　お寺の名前や、その他の色々な物にも名前を付けるとき、昔の人は、何も考えずに、ただありのままに、わかりやすく付けたものだ。最近になって、よく考えたのかどうだか知らないが、小細工したことを見せつけるように付けた名前は嫌らしい。人の名前にしても。見たことのない珍しい漢字を使っても、まったく意味のないことである。

　どんなことでも、珍しいことを追求して、一般的じゃないものをありがたがるのは、薄っぺらな教養しかない人が必ずやりそうなことである。

2009年4月25日土曜日

Web + DBは森田さん特集？

Web + DBは森田さん特集かと一瞬思った。ダンコガイのインタビューはあるし、連載は始めているし。

kindleをamazonが出したのは、amazonだからインパクトがでかいのでしょう。著作物の流通経路を持っているという意味で。ほかの会社のハードはどうでもいいです。注目は、iPod/iTuneの関係にkindle/amazonがなるかどうかです。

2009年4月24日金曜日

扇風機の季節

RAIDの乗っているマシンに扇風機の風を直撃するようにしたら温度が10度下がった。そして静かになった。

2009年4月22日水曜日

自動生成のunittestの力を感じるとき

サンプルを大量に持っていてfileのvalidatorを書くとき。

こんな感じでサンプルを集積してあるdirからテストケースを生成。どんなにアドホックなことをしても、このテストを通れば、正しいサンプルを必ずpassするvalidatorであることが確信できる。あとはこれにfuzzingしてあげればかなりのqualityを持つことになる。


#!/usr/bin/python
if __name__ == '__main__':
  header = '''\
#!/usr/bin/env python
# -*- coding: us-ascii -*-
# vim: syntax=python
#
# Copyright 2006-2009 Noriyuki Hosaka bgnori@gmail.com
#


#WARNING!
#DO NOT EDIT THIS FILE.
#THIS FILE IS AUTO GENERATED.

import unittest
from bglib.record.snowietxt import Validator

class SnowietxtTest(unittest.TestCase):
'''
  t = '''\
  def test_%s(self):
    f = open('%s')
    v = Validator(f)
    h = v.validate()
    self.assertEqual(h.hexdigest(),
                     '%s')
'''

  import sys
  import tempfile
  from subprocess import call

  f = tempfile.TemporaryFile()
  try:
    call('sha1sum bglib/record/snowietxt/*.txt', shell=True, stdout=f)
    f.seek(0)
    xs = [line.split() for line in f.readlines()]
  finally:
    f.close()

  print header
  for i, x in enumerate(xs):
    print t%(i, x[1], x[0])

2009年4月21日火曜日

後始末

方針が決まったのであとはただ作業。

普通に考えて、プロセス間通信でもしない限りmemory上のキャッシュはプロセス単位で閉じたものになる。ここにもこう書いてある。

each process builds up its own in-memory cache.

httplibで304と200が混じったのは、cacheに中身が入ったapache instanceに処理してもらえたかどうかなのだろう。

mpm.conf of /etc/httpd/conf.d
TheardLimitを1000にするのは怖くてできない。fileがそこまでたくさん作れる保証が無い。kernelの.configをいじればいいのだろうけど。


<IfModule worker.c>
StartServers         1
MinSpareThreads     16
MaxSpareThreads     32
MaxRequestsPerChild  0
ThreadLimit        512
ThreadsPerChild    512
MaxClients         512
</IfModule>

結果。
測定中にロードグラフを眺めると、CPU負荷はほとんど上がらずにNetworkのsentだけが100%の状態になる。

20%くらい改善したかな？

-c 300なら大丈夫。


[nori@asama]~/Desktop/work/srvtest% ab -n 100000 -c 300 "http://image.backgammonbase.com/image?gnubgid=4HPwATDgc%2FABMA%3AMAAAAAAAAAAA&height=300&width=400&css=minimal&format=png"
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking image.backgammonbase.com (be patient)
Completed 10000 requests
Completed 20000 requests
Completed 30000 requests
Completed 40000 requests
Completed 50000 requests
Completed 60000 requests
Completed 70000 requests
Completed 80000 requests
Completed 90000 requests
Finished 100000 requests


Server Software:        Apache/2.2.3
Server Hostname:        image.backgammonbase.com
Server Port:            80

Document Path:          /image?gnubgid=4HPwATDgc%2FABMA%3AMAAAAAAAAAAA&height=300&width=400&css=minimal&format=png
Document Length:        17877 bytes

Concurrency Level:      300
Time taken for tests:   158.133125 seconds
Complete requests:      100000
Failed requests:        0
Write errors:           0
Total transferred:      1828222590 bytes
HTML transferred:       1789024272 bytes
Requests per second:    632.38 [#/sec] (mean)
Time per request:       474.399 [ms] (mean)
Time per request:       1.581 [ms] (mean, across all concurrent requests)
Transfer rate:          11290.32 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        3   94  84.1     93    3106
Processing:   113  378  18.2    379    1060
Waiting:        2   93  10.4     95     405
Total:        120  473  86.5    473    3956

Percentage of the requests served within a certain time (ms)
  50%    473
  66%    474
  75%    474
  80%    474
  90%    474
  95%    474
  98%    474
  99%    475
 100%   3956 (longest request)

350にすると破綻の兆しでてくる。とはいえ、変更前の312よりはマシ。


[nori@asama]~/Desktop/work/srvtest% ab -n 100000 -c 350 "http://image.backgammonbase.com/image?gnubgid=4HPwATDgc%2FABMA%3AMAAAAAAAAAAA&height=300&width=400&css=minimal&format=png"
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking image.backgammonbase.com (be patient)
Completed 10000 requests
Completed 20000 requests
Completed 30000 requests
Completed 40000 requests
Completed 50000 requests
Completed 60000 requests
Completed 70000 requests
Completed 80000 requests
Completed 90000 requests
Finished 100000 requests


Server Software:        Apache/2.2.3
Server Hostname:        image.backgammonbase.com
Server Port:            80

Document Path:          /image?gnubgid=4HPwATDgc%2FABMA%3AMAAAAAAAAAAA&height=300&width=400&css=minimal&format=png
Document Length:        17877 bytes

Concurrency Level:      350
Time taken for tests:   158.20219 seconds
Complete requests:      100000
Failed requests:        0
Write errors:           0
Total transferred:      1827205440 bytes
HTML transferred:       1788094492 bytes
Requests per second:    632.83 [#/sec] (mean)
Time per request:       553.071 [ms] (mean)
Time per request:       1.580 [ms] (mean, across all concurrent requests)
Transfer rate:          11292.10 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        4  119 245.5    102    9104
Processing:   121  426  78.2    410    1831
Waiting:        2  103  26.2    102     719
Total:        128  545 262.3    512   10024

Percentage of the requests served within a certain time (ms)
  50%    512
  66%    513
  75%    514
  80%    514
  90%    516
  95%    716
  98%    821
  99%   1025
 100%  10024 (longest request)

2009年4月20日月曜日

ボトルネックは？

ばかもん・・・。すげー時間の無駄をした。

100BASE-TXでの最高速度は理論値では100Mbp、バイトにすると100/8=12.5MByte/s、つうことは、


Transfer rate:          11299.41 [Kbytes/sec] received

より早くなりようが無い。もはや100Mbpsでは帯域が足りない。逆に帯域が太くなることは無いから、自宅に箱をおいている間は回線速度に合わせて設定するのが正しいでしょうね。

gyaoでの測定結果、まあくだりだけなんですけど。


32.699Mbps
38.55Mbps

sokudo.jp


下り受信速度: 38Mbps(38.0Mbps,4.76MByte/s)
上り送信速度: 39Mbps(39.5Mbps,4.9MByte/s)

画像ファイル１枚30KByteと見込むと、150request/sしか捌けないので、それ以上にサーバを設定しようとすることは無駄！ 200request/s捌ければ十分でしょう。200 request/sしても99%までフラット。ということは、これで最低限の目標はクリアできている。あとは負荷を小さくしたり、レスポンスタイムを短くしたり、メモリ消費を減らしたりかな。mem_cacheとforkの関係をはっきりさせておかないとね。


[nori@asama]~/Desktop/work/srvtest% ab -n 100000 -c 200 "http://image.backgammonbase.com/image?gnubgid=4HPwATDgc%2FABMA%3AMAAAAAAAAAAA&height=300&width=400&css=minimal&format=png"
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking image.backgammonbase.com (be patient)
Completed 10000 requests
Completed 20000 requests
Completed 30000 requests
Completed 40000 requests
Completed 50000 requests
Completed 60000 requests
Completed 70000 requests
Completed 80000 requests
Completed 90000 requests
Finished 100000 requests


Server Software:        Apache/2.2.3
Server Hostname:        image.backgammonbase.com
Server Port:            80

Document Path:          /image?gnubgid=4HPwATDgc%2FABMA%3AMAAAAAAAAAAA&height=300&width=400&css=minimal&format=png
Document Length:        17877 bytes

Concurrency Level:      200
Time taken for tests:   157.993912 seconds
Complete requests:      100000
Failed requests:        0
Write errors:           0
Total transferred:      1827335546 bytes
HTML transferred:       1788205609 bytes
Requests per second:    632.94 [#/sec] (mean)
Time per request:       315.988 [ms] (mean)
Time per request:       1.580 [ms] (mean, across all concurrent requests)
Transfer rate:          11294.78 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        2   66  15.3     66    3043
Processing:    36  248 137.6    239    9197
Waiting:        1  116 137.7    111    9067
Total:         40  315 137.7    312    9225

Percentage of the requests served within a certain time (ms)
  50%    312
  66%    320
  75%    325
  80%    336
  90%    351
  95%    359
  98%    362
  99%    363
 100%   9225 (longest request)

キャパの２分探索

いろいろパラメータを変えてみて気づいた点は、リクエストが多いと遅くなることは避けられない。ただ、requestの50%と99%が同じ時間でserveされないのはまずいだろう。


[nori@asama]~/Desktop/work/srvtest% ab -n 100000 -c 500 "http://image.backgammonbase.com/image?gnubgid=4HPwATDgc%2FABMA%3AMAAAAAAAAAAA&height=300&width=400&css=minimal&format=png"
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking image.backgammonbase.com (be patient)
Completed 10000 requests
Completed 20000 requests
Completed 30000 requests
Completed 40000 requests
Completed 50000 requests
Completed 60000 requests
Completed 70000 requests
Completed 80000 requests
Completed 90000 requests
Finished 100000 requests


Server Software:        Apache/2.2.3
Server Hostname:        image.backgammonbase.com
Server Port:            80

Document Path:          /image?gnubgid=4HPwATDgc%2FABMA%3AMAAAAAAAAAAA&height=300&width=400&css=minimal&format=png
Document Length:        17877 bytes

Concurrency Level:      500
Time taken for tests:   157.941379 seconds
Complete requests:      100000
Failed requests:        0
Write errors:           0
Total transferred:      1827475512 bytes
HTML transferred:       1788411849 bytes
Requests per second:    633.15 [#/sec] (mean)
Time per request:       789.707 [ms] (mean)
Time per request:       1.579 [ms] (mean, across all concurrent requests)
Transfer rate:          11299.41 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        1  254 1150.4     68   45071
Processing:    17  526 477.7    394   17148
Waiting:        2  401 476.2    261   17019
Total:         28  781 1270.6    464   46283

Percentage of the requests served within a certain time (ms)
  50%    464
  66%    716
  75%    722
  80%    724
  90%    735
  95%   3239
  98%   3471
  99%   4502
 100%  46283 (longest request)

[nori@asama]~/Desktop/work/srvtest% ab -n 100000 -c 250 "http://image.backgammonbase.com/image?gnubgid=4HPwATDgc%2FABMA%3AMAAAAAAAAAAA&height=300&width=400&css=minimal&format=png"
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking image.backgammonbase.com (be patient)
Completed 10000 requests
Completed 20000 requests
Completed 30000 requests
Completed 40000 requests
Completed 50000 requests
Completed 60000 requests
Completed 70000 requests
Completed 80000 requests
Completed 90000 requests
Finished 100000 requests


Server Software:        Apache/2.2.3
Server Hostname:        image.backgammonbase.com
Server Port:            80

Document Path:          /image?gnubgid=4HPwATDgc%2FABMA%3AMAAAAAAAAAAA&height=300&width=400&css=minimal&format=png
Document Length:        17877 bytes

Concurrency Level:      250
Time taken for tests:   157.889007 seconds
Complete requests:      100000
Failed requests:        0
Write errors:           0
Total transferred:      1827087422 bytes
HTML transferred:       1788003384 bytes
Requests per second:    633.36 [#/sec] (mean)
Time per request:       394.723 [ms] (mean)
Time per request:       1.579 [ms] (mean, across all concurrent requests)
Transfer rate:          11300.75 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        2   68  42.9     68    3070
Processing:    24  325  53.9    329    4198
Waiting:        2  194  54.3    199    4062
Total:         30  393  69.7    401    6914

Percentage of the requests served within a certain time (ms)
  50%    401
  66%    401
  75%    401
  80%    401
  90%    401
  95%    401
  98%    401
  99%    401
 100%   6914 (longest request)

[nori@asama]~/Desktop/work/srvtest% ab -n 100000 -c 175 "http://image.backgammonbase.com/image?gnubgid=4HPwATDgc%2FABMA%3AMAAAAAAAAAAA&height=300&width=400&css=minimal&format=png"
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking image.backgammonbase.com (be patient)
Completed 10000 requests
Completed 20000 requests
Completed 30000 requests
Completed 40000 requests
Completed 50000 requests
Completed 60000 requests
Completed 70000 requests
Completed 80000 requests
Completed 90000 requests
Finished 100000 requests


Server Software:        Apache/2.2.3
Server Hostname:        image.backgammonbase.com
Server Port:            80

Document Path:          /image?gnubgid=4HPwATDgc%2FABMA%3AMAAAAAAAAAAA&height=300&width=400&css=minimal&format=png
Document Length:        17877 bytes

Concurrency Level:      175
Time taken for tests:   157.923406 seconds
Complete requests:      100000
Failed requests:        0
Write errors:           0
Total transferred:      1827328929 bytes
HTML transferred:       1788230915 bytes
Requests per second:    633.22 [#/sec] (mean)
Time per request:       276.366 [ms] (mean)
Time per request:       1.579 [ms] (mean, across all concurrent requests)
Transfer rate:          11299.78 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        1   66   4.2     67      73
Processing:    18  209  33.4    207    4130
Waiting:        2   75  34.2     73    3994
Total:         22  275  33.4    274    4187

Percentage of the requests served within a certain time (ms)
  50%    274
  66%    277
  75%    279
  80%    281
  90%    284
  95%    286
  98%    287
  99%    289
 100%   4187 (longest request)
[nori@asama]~/Desktop/work/srvtest% ab -n 1000 -c 10 "http://image.backgammonbase.com/image?gnubgid=4HPwATDgc%2FABMA%3AMAAAAAAAAAAA&height=300&width=400&css=minimal&format=png"
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking image.backgammonbase.com (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Finished 1000 requests


Server Software:        Apache/2.2.3
Server Hostname:        image.backgammonbase.com
Server Port:            80

Document Path:          /image?gnubgid=4HPwATDgc%2FABMA%3AMAAAAAAAAAAA&height=300&width=400&css=minimal&format=png
Document Length:        17877 bytes

Concurrency Level:      10
Time taken for tests:   1.582884 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      18307218 bytes
HTML transferred:       17914922 bytes
Requests per second:    631.76 [#/sec] (mean)
Time per request:       15.829 [ms] (mean)
Time per request:       1.583 [ms] (mean, across all concurrent requests)
Transfer rate:          11294.57 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    3   0.9      3       6
Processing:     7   11   1.4     12      16
Waiting:        0    3   1.1      3       6
Total:          7   15   0.6     15      19

Percentage of the requests served within a certain time (ms)
  50%     15
  66%     15
  75%     15
  80%     15
  90%     15
  95%     16
  98%     16
  99%     17
 100%     19 (longest request)

Apacheのチューニング

HostNameLookupsをoffにして再計測

結論：
HostNameLookupsは重い。
ていうか、そもそもにこの機能、いらないんじゃない？少なくともonlineでlookupする意味がわからない。logを解析するなんてバッチか裏方の仕事だから、リアルタイムで知る必要はそれほど無いのでは？

毎秒1000リクエストは現状の設定でのキャパを超えている。160m secで応答する範囲がキャパ。まずは２分探索してみよう。


[nori@asama]~/Desktop/work/srvtest% ab -n 100000 -c 100 "http://image.backgammonbase.com/image?gnubgid=4HPwATDgc%2FABMA%3AMAAAAAAAAAAA&height=300&width=400&css=minimal&format=png"
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking image.backgammonbase.com (be patient)
Completed 10000 requests
Completed 20000 requests
Completed 30000 requests
Completed 40000 requests
Completed 50000 requests
Completed 60000 requests
Completed 70000 requests
Completed 80000 requests
Completed 90000 requests
Finished 100000 requests


Server Software:        CherryPy/2.3.0
Server Hostname:        image.backgammonbase.com
Server Port:            80

Document Path:          /image?gnubgid=4HPwATDgc%2FABMA%3AMAAAAAAAAAAA&height=300&width=400&css=minimal&format=png
Document Length:        17877 bytes

Concurrency Level:      100
Time taken for tests:   158.198941 seconds
Complete requests:      100000
Failed requests:        0
Write errors:           0
Total transferred:      1827006003 bytes
HTML transferred:       1787990744 bytes
Requests per second:    632.12 [#/sec] (mean)
Time per request:       158.199 [ms] (mean)
Time per request:       1.582 [ms] (mean, across all concurrent requests)
Transfer rate:          11278.11 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0   35  11.0     37      51
Processing:    38  122 156.4    119   10326
Waiting:       11   51 158.2     39   10249
Total:         50  157 155.9    157   10346

Percentage of the requests served within a certain time (ms)
  50%    157
  66%    157
  75%    157
  80%    157
  90%    157
  95%    158
  98%    160
  99%    161
 100%  10346 (longest request)
[nori@asama]~/Desktop/work/srvtest% ab -n 100000 -c 1000 "http://image.backgammonbase.com/image?gnubgid=4HPwATDgc%2FABMA%3AMAAAAAAAAAAA&height=300&width=400&css=minimal&format=png"
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking image.backgammonbase.com (be patient)
Completed 10000 requests
Completed 20000 requests
Completed 30000 requests
Completed 40000 requests
Completed 50000 requests
Completed 60000 requests
Completed 70000 requests
Completed 80000 requests
Completed 90000 requests
Finished 100000 requests


Server Software:        Apache/2.2.3
Server Hostname:        image.backgammonbase.com
Server Port:            80

Document Path:          /image?gnubgid=4HPwATDgc%2FABMA%3AMAAAAAAAAAAA&height=300&width=400&css=minimal&format=png
Document Length:        17877 bytes

Concurrency Level:      1000
Time taken for tests:   158.458777 seconds
Complete requests:      100000
Failed requests:        0
Write errors:           0
Total transferred:      1827084829 bytes
HTML transferred:       1788031055 bytes
Requests per second:    631.08 [#/sec] (mean)
Time per request:       1584.588 [ms] (mean)
Time per request:       1.585 [ms] (mean, across all concurrent requests)
Transfer rate:          11260.10 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0  502 3078.7     64   93077
Processing:    16  663 875.5    403   57571
Waiting:        2  540 873.5    278   57445
Total:         36 1165 3251.3    656   94293

Percentage of the requests served within a certain time (ms)
  50%    656
  66%    724
  75%    733
  80%   1235
  90%   1308
  95%   3456
  98%   8803
  99%   9725
 100%  94293 (longest request)

素直にab使いましょう

abを試してみた。-cは2000とか指定できない。socket: Too many open files (24)とかいわれる。１プロセスで開けるファイル数の上限ですね。


[nori@asama]~/Desktop/work/srvtest% ab -n 10000 -c 1000 "http://image.backgammonbase.com/image?gnubgid=4HPwATDgc%2FABMA%3AMAAAAAAAAAAA&height=300&width=400&css=minimal&format=png"
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking image.backgammonbase.com (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Finished 10000 requests


Server Software:        Apache/2.2.3
Server Hostname:        image.backgammonbase.com
Server Port:            80

Document Path:          /image?gnubgid=4HPwATDgc%2FABMA%3AMAAAAAAAAAAA&height=300&width=400&css=minimal&format=png
Document Length:        17877 bytes

Concurrency Level:      1000
Time taken for tests:   16.769288 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      183094715 bytes
HTML transferred:       179189661 bytes
Requests per second:    596.33 [#/sec] (mean)
Time per request:       1676.929 [ms] (mean)
Time per request:       1.677 [ms] (mean, across all concurrent requests)
Transfer rate:          10662.53 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0  384 1444.2     15    9044
Processing:    16  527 1345.5    249   13746
Waiting:        2  483 1338.4    207   13641
Total:         36  911 2249.5    291   16760

Percentage of the requests served within a certain time (ms)
  50%    291
  66%    338
  75%    359
  80%    445
  90%   1121
  95%   3472
  98%  10609
  99%  10766
 100%  16760 (longest request)


[nori@asama]~/Desktop/work/srvtest% ab -n 100000 -c 1000 "http://image.backgammonbase.com/image?gnubgid=4HPwATDgc%2FABMA%3AMAAAAAAAAAAA&height=300&width=400&css=minimal&format=png"
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking image.backgammonbase.com (be patient)
Completed 10000 requests
Completed 20000 requests
Completed 30000 requests
Completed 40000 requests
Completed 50000 requests
Completed 60000 requests
Completed 70000 requests
Completed 80000 requests
Completed 90000 requests
Finished 100000 requests


Server Software:        Apache/2.2.3
Server Hostname:        image.backgammonbase.com
Server Port:            80

Document Path:          /image?gnubgid=4HPwATDgc%2FABMA%3AMAAAAAAAAAAA&height=300&width=400&css=minimal&format=png
Document Length:        8000 bytes

Concurrency Level:      1000
Time taken for tests:   153.415229 seconds
Complete requests:      100000
Failed requests:        93798
   (Connect: 0, Length: 93798, Exceptions: 0)
Write errors:           0
Total transferred:      1762203438 bytes
HTML transferred:       1723165770 bytes
Requests per second:    651.83 [#/sec] (mean)
Time per request:       1534.152 [ms] (mean)
Time per request:       1.534 [ms] (mean, across all concurrent requests)
Transfer rate:          11217.28 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0  394 2550.5     66   93080
Processing:    11  632 764.4    400   68442
Waiting:        2  516 762.5    280   68308
Total:         31 1027 2701.3    665   93725

Percentage of the requests served within a certain time (ms)
  50%    665
  66%    706
  75%    719
  80%   1246
  90%   1276
  95%   3391
  98%   4271
  99%   9680
 100%  93725 (longest request)

mem_cache(2)

muninにデータがプロットされた。

0時はmem_cacheなし

1200はmem_cacheあり

違い

ロードが減った。

context switch減った

reset大量発生。

割り込み大量発生

1)と2)は、scriptにrequestが流れないので当然。問題は3)と4)で、これらは何だろう？
あとはTrafficがハードやOSでの上限に到達していないかとかがポイントかな。

計算機パワーを買う時代

計算機パワーは、ハードとしての計算機をかって作るものから、「かってくる」ものへ。

大規模インフラ個人運用：AWS+Hadoopの成功例
AWSが招く大規模インフラ個人運用の時代

つまり、大手じゃなければインフラの面でスケーリングできるWebサービスができないなんて時代は終わりつつあるのだ。重ねていうけれどもこれはスゴイことだと思う。

AWSの登場と隆盛は、別の副作用をもたらしている。AWSのユーザー数の伸びに呼応してアメリカでは中小のサーバーハウジング会社の商売が成り立たなくなっているのだ。ただでさえ成長の終わったサーバーハウジング、ホスティング業界であるが、既に過当競争で単価が下がりきったところにAWSの登場である。そのために、小さな会社は合併したり買収したりと生き残るのに必死である。もちろん、この波は日本にも早晩やってくるので、日本においてもこの業界の再編がドラスティックに行われることはかなり蓋然性が高いと思う。

ディスクが絡んで並列性が無い処理とか、文句を言われるくらいに極度に重いとか、レガシーでJavaの実装が無いとか。並列化の抽象からもれる領域はどうなるのか。プラットフォームとして依存することの意味は？

古の大学計算機センターなるものは時間課金で、その上限を超えて計算したい人がほかの人のアカウントをクラックしたとかしないとか。

error

約27000件のリクエストには何がおきたのだろう。


[nori@housyou]/var/log/httpd% grep "Connection reset" error_log | wc
  49529  891522 6686455
[nori@housyou]/var/log/httpd% grep "Connection reset" error_log | wc
  76195 1371510 10286365

一方、クライアント側では最初のほうのエラーはこうだ。


Exception in thread Thread-36:
Traceback (most recent call last):
  File "/usr/lib64/python2.4/threading.py", line 442, in __bootstrap
    self.run()
  File "/usr/lib64/python2.4/threading.py", line 422, in run
    self.__target(*self.__args, **self.__kwargs)
  File "run.py", line 16, in make_test_request
    r = conn.getresponse()
  File "/usr/lib64/python2.4/httplib.py", line 872, in getresponse
    response.begin()
  File "/usr/lib64/python2.4/httplib.py", line 336, in begin
    version, status, reason = self._read_status()
  File "/usr/lib64/python2.4/httplib.py", line 294, in _read_status
    line = self.fp.readline()
  File "/usr/lib64/python2.4/socket.py", line 325, in readline
    data = recv(1)
error: (104, 'Connection reset by peer')

しばらくするとDNSが引けていないようだ。


Exception in thread Thread-97:
Traceback (most recent call last):
  File "/usr/lib64/python2.4/threading.py", line 442, in __bootstrap
    self.run()
  File "/usr/lib64/python2.4/threading.py", line 422, in run
    self.__target(*self.__args, **self.__kwargs)
  File "run.py", line 15, in make_test_request
    conn.request('GET', '/image?gnubgid=4HPwATDgc%2FABMA%3AMAAAAAAAAAAA&height=300&width=400&css=minimal&format=png')
  File "/usr/lib64/python2.4/httplib.py", line 810, in request
    self._send_request(method, url, body, headers)
  File "/usr/lib64/python2.4/httplib.py", line 833, in _send_request
    self.endheaders()
  File "/usr/lib64/python2.4/httplib.py", line 804, in endheaders
    self._send_output()
  File "/usr/lib64/python2.4/httplib.py", line 685, in _send_output
    self.send(msg)
  File "/usr/lib64/python2.4/httplib.py", line 652, in send
    self.connect()
  File "/usr/lib64/python2.4/httplib.py", line 620, in connect
    socket.SOCK_STREAM):
gaierror: (-2, 'Name or service not known')

mem_cache

image.backgammonbase.comにmem cacheを設定してみた。昨日やったurlopen攻撃ではキャッシュにはいってさえいれば負荷が上がらなくなったようだ。connectionをたくさん張られる場合はちょっとわからない。keep alive周りとかも調べないといけない。とはいえ、性能の問題が自分のアプリからapacheの問題に「すり替わった」ことは大きい。すでにある解決策を流用できるわけだから。


    <IfModule mod_cache.c>
        <IfModule mod_cache.c>
            CacheEnable mem /image
            MCacheSize 300000
#           KByte, 300MByte = 30KB x 10,000 entry
            MCacheMaxObjectCount 12323
            MCacheMaxObjectSize 30000
#           Byte
            MCacheRemovalAlgorithm LRU
        </IfModule>
    </IfModule>

2009年4月19日日曜日

計測してみた

image.backgammonbase.comがどのくらいの負荷に耐えられるかをテストしてみた。pythonのurllib.urlopenをthread.start_new_threadでガン呼び（300 thread per process)
で、そのprocessをsh上で &;をつけてへろへろ大量発生させた。ログを見る限り、500 requestくらいが限界で、それ以上はやたらと遅れるか、処理落ちするかのどっちかだろう。あまり細かく見ていないのでなんともいえないが。本当にサーバがボトルネックなのかどうかも検証しないといけないし。emobile側からたたいているので、emobileが遅いのかもしれないし、ルータがアレなのかもしれない。ひとつの手としてはLAN上で同じスクリプトでたこ殴りにしてみてどうなるかだろうなぁ。結果が変わるようならネットワークに原因があるし、そうでないならサーバだ。

2009年4月18日土曜日

VNC+VMware

VNCの窓なかにVMwareが動いていて、VMwar上でnetwork installが進行中。それをフレッシュネスバーガーでハンバーガーを食べながら眺めている。変過ぎ。

ともあれ、これでi386カーネルをいきなりNotePCでBuildしなくてすむようになる。

2009年4月17日金曜日

脱線

Eventually Consistentねえ。今のところは関係なさそうだが、概念的には面白そう。OMOさんが翻訳したのが結果整合性とのこと。

関係ないかもしれないが、ぼんやり思うのは、ネットワーク上にマシンがいっぱいあって、それらがデータベースを形作っている状況を考える。ネットワークを構成しているマシンm台のうち、n台にたいして書き込みが完了すれば拡散することを期待しても問題が無いのだろうか？拡散に失敗する確率εは？とか、ネットワークの構造つまり書き込みを受けたマシンがとなりのマシンに伝言ゲームするとしたら？とか。データベースというよりルーティングテーブルに近いなぁ。

psycoをpackageした

psycoをpython 2.4.3に対してpackageした。ここにある。life gameとかやってみたけど、はやくなっているかどうかいまいちわからない。

2009年4月16日木曜日

slotsとsetattr

__slots__を使うと__setattr__を上書き定義できない気がするのだが気のせい？
__slots__で指定したアトリビュート名でアクセスできない。普通は__dict__だが、__slots__していると__dict__は存在しない。たとえばDecimalだとこんな感じ。何が問題かというと、__new__の中で初期化ができなくなる。その部分はclass変数でフラグしてごまかしたとしても、今度は__setattr__が実装できない。


In [33]: d.__
d.__abs__           d.__doc__           d.__mod__           d.__radd__          d.__rpow__
d.__add__           d.__eq__            d.__module__        d.__rdiv__          d.__rsub__
d.__class__         d.__float__         d.__mul__           d.__rdivmod__       d.__rtruediv__
d.__cmp__           d.__floordiv__      d.__ne__            d.__reduce__        d.__setattr__
d.__copy__          d.__getattribute__  d.__neg__           d.__reduce_ex__     d.__slots__
d.__deepcopy__      d.__hash__          d.__new__           d.__repr__          d.__str__
d.__delattr__       d.__init__          d.__nonzero__       d.__rfloordiv__     d.__sub__
d.__div__           d.__int__           d.__pos__           d.__rmod__          d.__truediv__
d.__divmod__        d.__long__          d.__pow__           d.__rmul__

なにがほしいかというと、


In [16]: d.__slots__
Out[16]: ('_exp', '_int', '_sign', '_is_special')

なるときには


d.__values__[0] == d._exp

な__values__のようなものがほしい。

__slots__と__setattr__で検索したらこんなのが見つかった。


class _Flag(object):
    __slots__ = ('Normalize', 'SplitAlpha', 'SplitDigit',
                 'SplitSymbol', 'MorphAnalyse', 'Ngram',
                 'Delimited', 'EnableSuffixSearch',
                 'DisableSuffixSearch', 'WithStore', 'WithVacuum')

    def __init__(self):
        s = lambda x,y: object.__setattr__(self, x, y)
        s('Normalize',    _sen.SEN_INDEX_NORMALIZE)
        s('SplitAlpha',   _sen.SEN_INDEX_SPLIT_ALPHA)
        s('SplitDigit' ,  _sen.SEN_INDEX_SPLIT_DIGIT)
        s('SplitSymbol' , _sen.SEN_INDEX_SPLIT_SYMBOL)
        s('MorphAnalyse', _sen.SEN_INDEX_MORPH_ANALYSE)
        s('Ngram',        _sen.SEN_INDEX_NGRAM)
        s('Delimited',    _sen.SEN_INDEX_DELIMITED)
        s('EnableSuffixSearch',  _sen.SEN_INDEX_ENABLE_SUFFIX_SEARCH)
        s('DisableSuffixSearch', _sen.SEN_INDEX_DISABLE_SUFFIX_SEARCH)
        s('WithStore',    _sen.SEN_INDEX_WITH_STORE)
        s('WithVacuum',   _sen.SEN_INDEX_WITH_VACUUM)
    
    def __getattr__(self, name):
        raise AttributeError

    def __setattr__(self, name, value):
        raise AttributeError

なるほど、superで代入しちゃうのね。newではsuperでobjectのsetattrが呼ばれるが、そとから使うとderiveしたクラスのsetattrが呼ばれるということか。

2009年4月14日火曜日

タイトルがむちゃくちゃでは？

ソースコード・リテラシーのススメ
第15回　udevを読む
よい記事だと思うが、タイトルがひどい。設定ファイルなんですけど、読んでるのは。
カーネル解読室のような内容ならともかくねぇ・・・。

設定ファイルも、漫然とコピーして編集するのではなく、ソフトのコンセプトを理解したうえで書きたいのになぁ。個人的にはmuninの設定方式とが好きだ。ひどい例は挙げない。いくらでもあるだろうし。

Rich UI Webapps with TurboGears 2 and Dojo

Rich UI Webapps with TurboGears 2 and Dojo
MVCのVをbrowserにjsで乗せちゃいましょうという話？

Click To Play

2009年4月13日月曜日

VMwareの脆弱性

VMware全製品に脆弱性、ゲストOSから任意のコードを実行される恐れ

Xenの本を読んだ範囲では、効率ためにローレベルのリソースをゲストOSに解放していた（ハイパーバイザ経由でどうのこうの）気が・・・。VMwareがどうなんだか知らないけど。攻撃側の手数は増やせても、完全に安全になるわけじゃなかったはず。だからゲストのルート権限をとられたら基本的で駄目。

VMWareってどういう構造しているのでしょうね・・・。

rsync

だー、やっぱりdistroをmirrorすると200GBは必要なようだ。portsとbootable imageはlocalにmirrorしておきたいのだが、どれがどれだか。


[nori@housyou]/usr/local/repos/distro/FreeBSD% rsync rsync://ftp.tw.FreeBSD.org/
home            home
big             big
FreeBSD         Taiwan Primary FreeBSD Site (200G)
OpenBSD         Taiwan OpenBSD Site
NetBSD          Taiwan NetBSD Site
FreeSBIE        Taiwan FreeSBIE Site
DragonFlyBSD    Taiwan DragonFlyBSD Site

ちなみにcentosは280GB


/dev/mapper/Titan-centos--mirror
                      337G  280G   41G  88% /usr/local/repos/distro/centos

うーむ。bearoffとgit publicをshrinkして作業用に作ったusr/local/tempを消しせば足りるかなあ。distro関係はどうせコピーなんでぶっ壊れてもいいし、たまにしか使わないだろうから1TBの外付けにしてraidの上から追い出すのも手だなぁ。

pythonがrubyにまけるたった一つの理由

The Fortran プログラミング言語シリーズ　第3回配本

C++ は流行りましたが Objective-C は流行りませんでした。
Lisp は流行りましたが、Prolog は流行りませんでした。
Java は流行りましたが、Eiffel は流行りませんでした。
C# は流行りましたが、Delphi は流行りませんでした。
そして COBOL は流行りましたが、Fortran は流行りませんでした。

あなたには、これらから流行の法則がわかるでしょうか。

そうです。名前です。名前の長さなのです。

そーだったのか、pythonは名前が長すぎたのか！

iPartition

Mac OS XのPatition utilityのiPartitionを買ってみた。下回りはまあunixのutilityだろーけど、UIとその他の操作性に価値があるとみて購入。

使ってみた感じ：すばらしい。
作業をぜんぶキューにつんで一括実行。賢いデザインです。

サイズを変えたpartitionをOS付属のdisk utilityでscanしたらerrorがでた。動いてはいるのだが。きっとメタ情報に不整合が生じたのだろう。

2009年4月11日土曜日

わたしがPythonがよいと思う理由

「ソフトウェアは工業製品ではない」、Rubyのまつもと氏が講演

「ソフトウェアは書くものであって、読むことの重要性は、あまり意識していなかった人が多いのではないか。しかし、ソフトウェア開発においてキーボードを叩いている時間は短いのです。むしろ考える時間、読んでいる時間が長い」

中略

　人間にフォーカスするため、まつもと氏は言語設計を「唯一の正解がなく、1つには決まらない。とても非理系的なこと」だと話す。

pep8、和訳

Guido の重要な洞察のひとつは、コードは書かれる頻度よりも、読まれる頻
度のほうが高いということだ。ここで提供されるガイドラインは、コードの
可読性を高め、広範囲の Python コードに一貫させることを、意図されてい
る。PEP 20 [6] が述べるとおり「読みやすさがたいせつなのよ」である。

python/rubyが人間にfoucusした言語なら、C/assemblyはマシンやハードウェアに、lispは計算にfocusした言語だろう。ゆえにhardについて知りたいとおもうなら、C/Assemblyは割けて通れないし、計算に関して理解したいと思うならlispは避けて通れない。sqlやprologもちょっと違うがそれぞれのジャンル（それぞれ検索、推論）で特化しているのでそのジャンルに関して理解したいなら避けて通れない。

おまけ：

「80歳になっても毎日プログラムを書いていたい」と講演を締めくくった。

まだ80才じゃないですが、和田先生ですかね。

SSD, pxe boot

2009年4月9日木曜日

gitのid/checksumをsourceに埋め込む

GitPythonを使えばできそう。


import git
repo = git.Repo('.')
repo.commits(max_count=1)[0].id

とかすればHEADのidが取れる。あとはsetup.pyで埋め込み作業をするscriptを書けばいい。

commitからpathを取り出すにはtreeをvisitする必要があるらしい。


In [72]: x.tree.values()[1]
Out[72]: <git.Tree "4aadc5ae113b32e77b531d6854f1a2c13f9b6e63">

In [73]: x.tree.values()[1]
Out[73]: <git.Tree "4aadc5ae113b32e77b531d6854f1a2c13f9b6e63">

In [74]: x.tree.values()[1].values()
Out[74]:
[<git.Tree "5e8a390852602cec130d67e247c559a9723bfb4f">,
 <git.Tree "878a888769dd62d505d841b7895f49bde8c4dbca">,
 <git.Tree "7ee2b27fa1f0495016811fc447e4691af94c80e0">,
 <git.Tree "0e524c2147893adf6497bcf3d069a8d666c52f07">,
 <git.Tree "876089c38a02f1a00a7da44df3763360dbf97bbd">,
 <git.Blob "82f6b1bf3630c66755a1aab3613547a2b180193f">,
 <git.Tree "488f70c7fc0df9ee7428f4cfb003edf873222e7f">,
 <git.Tree "9a88b0832766d9330577c59e584fd93691b1285f">,
 <git.Tree "b354bd3049e868b59dbc261fa3083eeae1ae7b5a">]

In [75]: x.tree.values()[1].values()[0].values()
Out[75]:
[<git.Blob "44876c571d4a9b2381e04cae6f3b05d7cd0513a7">,
 <git.Blob "82f6b1bf3630c66755a1aab3613547a2b180193f">]

In [76]: x.tree.values()[1].values()[0].values()[0]
Out[76]: <git.Blob "44876c571d4a9b2381e04cae6f3b05d7cd0513a7">

In [77]: x.tree.values()[1].values()[0].values()[0].basename
Out[77]: 'rating.py'

values()よりitems()を使ったほうがいい。


In [91]: t.items()
Out[91]:
[('stat', <git.Tree "5e8a390852602cec130d67e247c559a9723bfb4f">),
 ('protocol', <git.Tree "878a888769dd62d505d841b7895f49bde8c4dbca">),
 ('encoding', <git.Tree "7ee2b27fa1f0495016811fc447e4691af94c80e0">),
 ('doc', <git.Tree "0e524c2147893adf6497bcf3d069a8d666c52f07">),
 ('gui', <git.Tree "876089c38a02f1a00a7da44df3763360dbf97bbd">),
 ('__init__.py', <git.Blob "82f6b1bf3630c66755a1aab3613547a2b180193f">),
 ('model', <git.Tree "488f70c7fc0df9ee7428f4cfb003edf873222e7f">),
 ('depot', <git.Tree "9a88b0832766d9330577c59e584fd93691b1285f">),
 ('image', <git.Tree "b354bd3049e868b59dbc261fa3083eeae1ae7b5a">)]

あとはcommit objectのstatsからpathを取り出すか。


In [117]: cx = repo.commits()

In [129]: c = cx[9]

In [130]: s = c.stats

In [131]: s.files
Out[131]: {'src/encoding/gnubgid.py': {'deletions': 4, 'lines': 8, 'insertions': 4}}

うーん、これだとcommitに関してiterateしてstatsのpathをmatchするかぁ・・・。だるいなぁ。

git-blameですね。


[nori@asama]~/Desktop/work/bglib/git% git blame VERSION
58850f89 (Noriyuki Hosaka 2009-04-09 02:49:06 +0900 1) 0.0.4

しかしGitPythonからだとうまく動かない。なにが悪いのだろう？interfaceとしてcommitの指定が必須なんですけど？！


In [193]: git.Blob.blame?
Type:           instancemethod
Base Class:     <type 'instancemethod'>
String Form:    <bound method type.blame of <class 'git.blob.Blob'>>
Namespace:      Interactive
File:           /usr/lib/python2.4/site-packages/git/blob.py
Definition:     git.Blob.blame(cls, repo, commit, file)
Docstring:
    The blame information for the given file at the given commit

    Returns
        list: [git.Commit, list: [<line>]]

ああ、勘違い。commitを決めないと、fileを指定できないじゃないか・・・。

2009年4月8日水曜日

apacheのaccesslog

今まで半年あまりのimageのアクセスログは２５万件（外部からのみ。)


[nori@housyou]/var/log/httpd/backgammonbase% grep -v '192.168' image-access.log | grep -v crawl | grep -v 'msn' | grep -v 'rate-limited' | wc
 252569 2525921 42242483

formからpositionを作ってくれたと思われるのは175件。おもったより多かったかもしれない。まだまだ宣伝が足りないですが。


[nori@housyou]/var/log/httpd/backgammonbase% grep -v '192.168' image-access.log | grep -v crawl | grep -v 'msn' | grep -v 'rate-limited' | grep "GET /form?gnubgid=" | wc
    175    1750   31318

/の下の外部からのアクセスの9割方はsearch engineのbotなのだが・・・人間が引き起こしたと思われるアクセスを見てみることにした。

よくわからないgit repositoryのアクセス。linux kernelのほかはopencvのミラーとかかな。


fw.konami.co.jp - - [08/Apr/2009:20:26:16 +0900] "GET /mirror/linux-2.6-allstable/sound/pci/hda/patch
_analog.c HTTP/1.0" 200 139298
fw.konami.co.jp - - [08/Apr/2009:20:26:16 +0900] "GET /favicon.ico HTTP/1.0" 404 359

トロールテックの中の人がimage.backgammonbase.comを使ってくれたらしい。うれしい。


62.70.27.104 - - [08/Apr/2009:20:43:56 +0900] "GET /image?gnubgid=AAAAbdsGAAAAAA%3AcAkgAAAAAAAA&forma
t=png&width=400&css=minimal&height=300 HTTP/1.1" 301 496

逆引きの結果


[nori@asama]~/Desktop/work/tonic/bygit% dig -x 62.70.27.104

; <<>> DiG 9.3.4-P1 <<>> -x 62.70.27.104
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 11735
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;104.27.70.62.in-addr.arpa.     IN      PTR

;; AUTHORITY SECTION:
104.27.70.62.in-addr.arpa. 8004 IN      SOA     tharsis.troll.no. hostmaster.troll.no. 2009022200 28800 7200 2419200 86400

;; Query time: 0 msec
;; SERVER: 192.168.2.65#53(192.168.2.65)
;; WHEN: Wed Apr  8 21:30:34 2009
;; MSG SIZE  rcvd: 106

2009年4月6日月曜日

googleの情報工場

写真がCnetで公開された。cnetの記事

チェックしている人がいた。

マザーボードは、gigabyteのもので、型番が同一なもののこのページで参照できる。
写真を比較すればわかるが、各種端子が省略されている。当然のことだ。余計なものがつけば余計なコストがかかり、余計な電力を消費する。天下のgoogleといえど、スクラッチから設計を起こすことをせずに、既存のデザインを元にサーバ専用ということでマイナーチェンジを行ったと考えたほうが正しいだろう。

動画

工場にしか見えないです。同時に世界一の計算機資源をもっているのはgoogleかなぁと思った。コンテナ１個に1200台くらい入っていて、250kWの電力を喰うそうな(100V交流供給だと2kAとかそのへん？一般家庭100軒分？・・・つまりマンション１棟分くらい電気を喰う)。コンテナはよくわからないけど１００個以上は軽くありそう。1000個はもっているだろうな10,000個もっているかどうかは知らないが。電力発電所を作ることまじめに考えるわけだ。

ここのマシンはethernetで結合されているように見える。RJ45の口ともうひとつなんかの口がついているだけだ。

cnetの記事
Googleのサーバーが公開された

比較：
地球シミュレータ
一言付け加えておくと、計算機の方向性が異なるので、単純比較できない面がある。地球シミューレタのほうがgのサーバ郡（コンピュータの群れであって、１つのコンピュータと呼ぶのはどうかなぁ・・・）よりノード間の結合がはるかに太くつくられていて、はっきりとそこにカネをかけているといっていい。

まだ東工大のTsubameのほうがちかいかな？それでもInfiniBandだしなぁ。。。

さて、電力についてもう一言。素材産業が持つ発電能力、1990年とちょっと古いが、規模は変わらないだろうから参考にはなるだろう。新日鉄君津製鉄所では60万キロワットの自家発電能力を有している。250kw x 1000 = 25万キロワットなので、googleが自家発電を考えることがどうして自然かがよくわかる。

別に鉄を圧延のためにあっためるのに使うわけじゃなくて計算に使うためにこんだけ電気を使えるのだからその規模がいかにすさまじいかよくわかる。冷却に水を使っている点でも製鉄業とgoogleは変わらないなぁ・・・。エネルギー消費の観点から製鉄産業の進化速度とコンピューティングの進化速度を比較すると面白いかもしれない。

hgことはじめ

pythonの次のコード管理ツールがhgになったらしいので、試すことにした。「俺的」にはgitを選んだのだが、まあ、pythonで実装されていて、pythonicなデザインなhgがpythonの管理ツールに選ばれたのは必然かな。

分散バージョン管理Git/Mercurial/Bazaar徹底比較@ atmarkitとかman pageをへろへろ読む。clone/pull/pushは概念レベルでは同じようですね。なれの問題かなぁ。てきとうなレポジトリをcloneしていじってみますか。

奥地さん曰くgitのマージは「ばか」らしい。hgはどうなんでしょうね。

2009年4月4日土曜日

distcc over ssh (port forwarding)

ssh自体の処理が重いので、ありがたみがいまいち。ファイル転送を含めてバッチでやってもらわないと駄目だなぁ。


[nori@asama]~% tail /var/log/distccd.log
distccd[6003] (dcc_r_file_timed) 313718 bytes received in 47.879848s, rate 6kB/s
distccd[6003] (dcc_collect_child) cc times: user 0.069989s, system 0.013997s, 4760 minflt, 0 majflt
distccd[6003] cc ipc/ipcns_notifier.c on localhost completed ok
distccd[6003] job complete
distccd[6004] (dcc_check_client) connection from 192.168.2.80:46321
distccd[6004] compile from inode.c to .tmp_inode.o
distccd[6001] (dcc_check_client) connection from 192.168.2.80:46322
distccd[6001] compile from sem.c to .tmp_sem.o
distccd[6003] (dcc_check_client) connection from 192.168.2.80:46323
distccd[6003] compile from maccess.c to .tmp_maccess.o

かなり古いPostだが、[distcc] SSH encryption overheadで議論されている。

オマケ。

There is still the possibility of security problems such as tmpfile
races allowing local attacks, but it's a smaller exposure.

If the source goes across a hostile network without integrity checks,
then people might try tricks like

#include "/etc/passwd"

うわぁ。chrootみたいなことをして~distccd/buildの下に/をつくるようなトリックが必要かもね。rsyncするかもしくはgitのrefを指定するとかができればもっとよいが。

2009年の環境

NotePCをSSDで再生。長らく貸していたemobileを使うことに。結構快適だろう。CentOSにしたおかげでwindowsXPよりかなり軽い。日本語変換のお馬鹿さはそもそもにxpのそれを使い込んでいないのでいまのところあまり気にならない。sshの鍵もすべて更新したので、安全で快適なリモートログインライフを送れるだろう。

あとはdistcc over sshとかか。

2009年4月3日金曜日

yum update

いやはや、パッケージの数がお馬鹿です。

2009年4月2日木曜日

ルータのログ

Apr 2 12:10:10 localhost XR-Filter: SPI_ppp0 IN=ppp0 OUT=eth2 MAC= SRC=114.48.190.95 DST=192.168.2.64 LEN=60 TOS=00 PREC=0x00 TTL=55 ID=53423 CE DF PROTO=TCP SPT=59670 DPT=80 SEQ=1547633778 ACK=0 WINDOW=5840 SYN URGP=0
Apr 2 12:10:10 localhost XR-Filter: SPI_ppp0 IN=ppp0 OUT=eth2 MAC= SRC=114.48.190.95 DST=192.168.2.64 LEN=60 TOS=00 PREC=0x00 TTL=55 ID=60270 CE DF PROTO=TCP SPT=59671 DPT=80 SEQ=1559903793 ACK=0 WINDOW=5840 SYN URGP=0

このパケット・接続はどうなってるんだ？114.48.190.95はemobileで外からたたいたときに、emobileの端末に振られたIP addr。ブロックされているような気がする。

やっぱりブロックされてた。orz

2009年4月1日水曜日

HTTP再設定

うまく動かない。VirtualHostなapacheを複数IPで動かして、そこへNATしている。どれが原因だかよくわからない・・・。

現象としては、internet側から見ることができない。LANからは見えている。dnsは引けている。internetからNATしたときは192.168.2.64へ、localは192.168.2.65になる。

NameVirtualHost

NameVirtualHost ディレクティブは、名前ベースのバーチャルホストを利用してリクエストを受け付ける IP アドレスを指定します。これは、普通は名前ベースのバーチャルホストアドレスです。ただし、ファイアーウォールや他のプロキシがリクエストを受け付け、違う IP アドレスのサーバにフォワードするという場合は、リクエストを提供したいマシン上の物理インターフェースの IP アドレスを指定する必要があります。複数のアドレスで複数の名前ベースのバーチャルホストを指定する場合は各アドレスに対してディレクティブを書いてください。

リクエストを提供したいマシン上の物理インターフェースIPのアドレスを指定する必要があります。ということはaliasは駄目ってこと？aliasの存在意義を考えるとありえない。英語はちなみにこうなっている。

With the NameVirtualHost directive you specify the IP address on which the server will receive requests for the name-based virtual hosts. This will usually be the address to which your name-based virtual host names resolve. In cases where a firewall or other proxy receives the requests and forwards them on a different IP address to the server, you must specify the IP address of the physical interface on the machine which will be servicing the requests. If you have multiple name-based hosts on multiple addresses, repeat the directive for each address.

192.168.2.200にsshすると大丈夫だが、192.168.2.65にsshするとだめ。100以下のaddrにforwardできていないのだろうか？

あとはhousyouのfirewallの設定がおかしい、という線だが、DNSが引けているのでそれはないだろう。まいったなこりゃ。


[nori@housyou]/etc/httpd% /usr/sbin/httpd -S
VirtualHost configuration:
192.168.2.64:80        is a NameVirtualHost
         default server tonic-water.com (/etc/httpd/conf.d/vhosts/tonic-water.com/tonic-water.com.conf:2)
         port 80 namevhost tonic-water.com (/etc/httpd/conf.d/vhosts/tonic-water.com/tonic-water.com.conf:2)
         port 80 namevhost www.tonic-water.com (/etc/httpd/conf.d/vhosts/tonic-water.com/www.conf:1)
         port 80 namevhost git.tonic-water.com (/etc/httpd/conf.d/vhosts/tonic-water.com/git.conf:1)
         port 80 namevhost photo.tonic-water.com (/etc/httpd/conf.d/vhosts/tonic-water.com/photo.conf:1)
         port 80 namevhost buildbot.tonic-water.com (/etc/httpd/conf.d/vhosts/tonic-water.com/buildbot.conf:1)
         port 80 namevhost backgammonbase.com (/etc/httpd/conf.d/vhosts/backgammonbase.com/backgammonbase.com.conf:2)
         port 80 namevhost www.backgammonbase.com (/etc/httpd/conf.d/vhosts/backgammonbase.com/www.conf:2)
         port 80 namevhost bd.backgammonbase.com (/etc/httpd/conf.d/vhosts/backgammonbase.com/bd.conf:1)
         port 80 namevhost image.backgammonbase.com (/etc/httpd/conf.d/vhosts/backgammonbase.com/image.conf:2)
         port 80 namevhost wxpygammon.org (/etc/httpd/conf.d/vhosts/wxpygammon.org/top.conf:1)
         port 80 namevhost www.wxpygammon.org (/etc/httpd/conf.d/vhosts/wxpygammon.org/www.conf:1)
         port 80 namevhost dtd.wxpygammon.org (/etc/httpd/conf.d/vhosts/wxpygammon.org/dtd.conf:1)
         port 80 namevhost download.wxpygammon.org (/etc/httpd/conf.d/vhosts/wxpygammon.org/download.conf:1)
192.168.2.65:80        is a NameVirtualHost
         default server pa.housyou.tonic-water.com (/etc/httpd/conf.d/vhosts/tonic-water.com/PowerActPro.conf:1)
         port 80 namevhost pa.housyou.tonic-water.com (/etc/httpd/conf.d/vhosts/tonic-water.com/PowerActPro.conf:1)
         port 80 namevhost munin.housyou.tonic-water.com (/etc/httpd/conf.d/vhosts/tonic-water.com/munin.conf:1)
         port 80 namevhost stat.houysou.tonic-water.com (/etc/httpd/conf.d/vhosts/tonic-water.com/webalizer.conf:6)
         port 80 namevhost distro.tonic-water.com (/etc/httpd/conf.d/vhosts/tonic-water.com/yum.conf:1)
         port 80 namevhost trac.housyou.tonic-water.com (/etc/httpd/conf.d/vhosts/tonic-water.com/trac.conf:1)
         port 80 namevhost svn.housyou.tonic-water.com (/etc/httpd/conf.d/vhosts/tonic-water.com/svn.conf:12)
         port 80 namevhost yum.backgammonbase.com (/etc/httpd/conf.d/vhosts/backgammonbase.com/yum.conf:1)
wildcard NameVirtualHosts and _default_ servers:
_default_:80           Sorry (/etc/httpd/conf.d/sorry.conf:2)
Syntax OK

CentOS 5.3到来

CentOSの5.3がミラーのソースに使っているrikenにrsyncされたようだ。なのでmy mirrorにrsyncする。


[CentOS-mirror] ftp.riken.jp is ready for Centos 5.3 (experimental 10GbE connection to WAN)
Hi

FTP.RIKEN.JP is now ready for CentOS 5.3 (except for iso-DVDs which
are now under rsyncing). So official CentOS mirrors can try to rsync to

rsync://ftp.riken.jp/centos/5.3/
rsync://ftp.riken.jp/centos

This server (ftp.riken.jp) has been connected at 10 Gbps to WAN
http://www.sinet.ad.jp/topology
which many academic sites (universities and research institutes) in Japan
are connected.

This is the first experimental connection at 10 Gbps of this server.
I can not expect what will be happen. So please try it at your own risk.

I have checked all the md5sums for iso CD images of i386 and X86_64
and they are OK.

Regards,
Takashi Ichihara (RIKEN)

DNS設定も終わったことだしrsyncをかけることに。朝まで取り終わらないだろうから、今日はもう終わりにすべし。

DNS設定やり直し

http://www.maradns.org/tutorial/dangling.htmlを読んでなえる。そもそもにnic足す必要ないじゃん。:0すればいいのだから。まあ、内向きと外向きでhardを分けるということで。内向きにはIPを２つ付与してあげました。２つ目のNICは将来的にはslaveが導入されたときにslaveのnetworkにつなぐのに使ってあげましょう。

/usr/share/doc/initscripts-8.45.19.1.EL/sysconfig.txtをへろへろ見ていくと、
こんな部分があって、


/etc/sysconfig/network-scripts/ifcfg- and
/etc/sysconfig/network-scripts/ifcfg-::

  The first defines an interface, and the second contains
  only the parts of the definition that are different in a
  "alias" (or alternative) interface.  For example, the
  network numbers might be different, but everything else
  might be the same, so only the network numbers would be
  in the alias file, but all the device information would
  be in the base ifcfg file.

  The items that can be defined in an ifcfg file depend on the
  interface type.  The really obvious ones I'm not going to
  bother to define; you can figure out what "IPADDR" is, I
  think...  :-)

これにしたがって、/etc/sysconfig/network-scriptsに設定を追加。


-rw-r--r-- 5 root root 277 Mar 31 09:22 ifcfg-eth0
-rw-r--r-- 3 root root 257 Apr  1 01:08 ifcfg-eth1
-rw-r--r-- 1 root root 122 Apr  1 01:09 ifcfg-eth1:0
-rw-r--r-- 1 root root 122 Apr  1 01:10 ifcfg-eth1:1

な感じ。再起動して確認。


[nori@housyou]/etc% /sbin/ifconfig
eth0      Link encap:Ethernet  HWaddr 00:19:DB:62:B9:9F
          inet addr:192.168.2.64  Bcast:192.168.2.255  Mask:255.255.255.0
          inet6 addr: fe80::219:dbff:fe62:b99f/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1487 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3466 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:201929 (197.1 KiB)  TX bytes:622530 (607.9 KiB)
          Interrupt:21 Base address:0xa800

eth1      Link encap:Ethernet  HWaddr 00:90:CC:EF:8C:3F
          inet6 addr: fe80::290:ccff:feef:8c3f/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3822 errors:0 dropped:0 overruns:0 frame:0
          TX packets:25 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:306202 (299.0 KiB)  TX bytes:1608 (1.5 KiB)
          Interrupt:17 Base address:0xec00

eth1:0    Link encap:Ethernet  HWaddr 00:90:CC:EF:8C:3F
          inet addr:192.168.2.65  Bcast:192.168.2.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Interrupt:17 Base address:0xec00

eth1:1    Link encap:Ethernet  HWaddr 00:90:CC:EF:8C:3F
          inet addr:192.168.2.66  Bcast:192.168.2.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Interrupt:17 Base address:0xec00

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:1525 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1525 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:2084924 (1.9 MiB)  TX bytes:2084924 (1.9 MiB)

さらに、maradnsの設定をやり直す。http://www.maradns.org/tutorial/dangling.htmlを読むが、


ipv4_bind_addresses = "192.168.1.1"
chroot_dir = "/etc/maradns"
recursive_acl = "192.168.1.0/24"
upstream_servers = "192.168.1.2"

が設定ファイルの文法として間違っていて、http://www.maradns.org/faq.html#upstream_dを読むと、


ipv4_bind_addresses = "192.168.1.1"
chroot_dir = "/etc/maradns"
recursive_acl = "192.168.1.0/24"
upstream_servers = {}
upstream_servers["."] = "192.168.1.2"

と書かねばならない。


[nori@housyou]/etc% dig @192.168.2.65 blog.tonic-water.com

; <<>> DiG 9.3.4-P1 <<>> @192.168.2.65 blog.tonic-water.com
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2585
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;blog.tonic-water.com.          IN      A

;; ANSWER SECTION:
blog.tonic-water.com.   900     IN      CNAME   ghs.google.com.
ghs.google.com.         900     IN      A       72.14.235.121

;; Query time: 12 msec
;; SERVER: 192.168.2.65#53(192.168.2.65)
;; WHEN: Wed Apr  1 01:42:09 2009
;; MSG SIZE  rcvd: 79

これでめでたくLANでprimary dnsに192.168.2.65を指定すればほしいものが引けるようになった。

登録: 投稿 (Atom)

あわせてよんでみます？

FriendFeed widget

JBL rating

ブログ アーカイブ

アクセス解析

pretty print