Hatena::ブログ(Diary)

独りの超電波プログラマ このページをアンテナに追加 RSSフィード Twitter

2014-10-09

[] サーバが死んだ

https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1264075.html

Rescueで起動するとこれとそっくりな症状。なんと糞タイムリーな。

Welcome to Debian GNU/Linux jessie/sid!

[ 3.012374] <30> systemd[1]: Inserted module 'autofs4'

[ 3.038538] <30> systemd[1]: Set hostname to <debian>

[ 3.062844] <27> systemd[1]: Failed to create root cgroup hierarchy:

Invalid argument

[ 3.063076] <27> systemd[1]: failed to allocate manager object: Invalid

argument

以下復帰するために試した手順についてメモ。

試行錯誤でやって、なんとか動いた手順、というだけなので、恐らく正しい手順ではない。

  • grubdebianのrescueではなく、普通のやつを起動パラメータを修正して起動する。
    • eを押して修正モードに
    • linux ..... quietのquietを消してinit=/bin/bashにする。これでsystemdが走る前にbashに移れる
  • ファイルシステムがreadonlyで特に何もできないので、

# mount -o remount,rw /

これで書き込み可能に。

多分何度も失敗しながらやり直すことになるので、セットアップのコマンドをシェルスクリプトに保存しておく。emacsは動かなかったけど、jedは動いた。

#!/bin/sh

mount -o remount,rw /

/etc/init.d/networking start

ifconfig eth0 (server ip address) netmask (netmask)

route add default gw (gw ip address)

hostname broken

/etc/init.d/ssh start

これでネットにつながって、sshdが立ち上がる。nameserverの設定はやらなくても大丈夫だった。

あとは必要なサービスを動かす

/etc/init.d/nginx start

/etc/init.d/supervisor start

これでなんとかそれっぽく動くところまで持ってくることができるようになった。

systemdの208で起きる問題らしいので、バックアップが終わり次第ダメ元での215を入れようかと思う。

https://bbs.archlinux.org/viewtopic.php?id=176171

VPSとの相性でも起きる問題らしいので、cloudcore側に解決して欲しい問題なんだが、全く相手にしてくれなかった。腹立たしい。

追記:

上記の状態でapt-getは使えるようになったので、systemdの215を試してみるも直らず。

systemdをダウングレードするか別のinitを使うか迷って結局sysvinitにすることにした。dselectからsysvinit選ぶ。systemdの色々削るけど、めげずに選ぶ。再起動したら普通に動いた。

2014-07-09

[] wiki-db新サイト設置メモ

自分用のメモ

  • アプリを別ディレクトリからコピーして編集
    • settings.py
    • manage.py
    • urls.py
    • uwsgi.ini
    • wsgi.py
  • nginxのポート転送を設定
  • db作成。create database (name) default character set utf-8;
  • app/(name)/manage.py syncdb
  • couchdbのテーブル作成

2014-05-09

[][] feedparser置き換え

2chnaviのサービスを運用するにあたって、リソースボトルネックは何かというと、実はCPUが一番きつい。HDDと違って足りなかったら遅くなるだけでよかったんだけど、流石に全てのフィードをとってパースするのに1時間以上かかるのは、1万以上のRSSがあるとはいえ遅すぎる。

http://d.hatena.ne.jp/kudzu/20120403/1333449336

にも書いたけど、原因はfeedparserの実装が糞遅いから。涙がでるほど遅い。

で、ちょっと調べてたらspeedparserというfeedparserとある程度互換があるfeedparserの実装があったので、試してみた。

https://github.com/jmoiron/speedparser

pypiでパッケージがあったので、pip install speedparserで入れた。

てきとうに2chnaviに登録してあるrssを100ほどdlしてみて、2つのパーサが生成するオブジェクトのフィールドを比べてみたところ、更新日時の解釈が若干違うけど、url、コンテンツ、タイトルなどは割と互換に見える(追記:コンテンツはfeedparserのほうがタグの正規化などを行ってしまうため、完全マッチはできなかった。SANITIZE_HTML=0でも同様)。100くらいしかまだ試してないから、もしかしたらエンコーディングとか色々と細かいところで気が利かないのかもしれんけど。

参考までに速度を一部載せておくと、

5.380 vs 172.251 index.html?xml.15

4.532 vs 1421.450 rss.1

2.985 vs 122.598 index.rdf.21

11.675 vs 910.587 index.html?xml.5

1.524 vs 131.796 index.rdf.6

3.764 vs 487.475 index.rdf.12

5.577 vs 593.087 index.rdf.36

3.477 vs 276.774 index.rdf.43

14.047 vs 7256.265 index.rdf.23

3.561 vs 90.582 index.html.1

4.213 vs 806.865 index.rdf.5

3.599 vs 542.688 index.rdf.34

1.437 vs 432.654 index.html

6.362 vs 1437.406 index.rdf.42

3.384 vs 272.167 index.html?xml.8

5.521 vs 1194.197 index.rdf.47

3.104 vs 143.062 index.rdf.28

3.376 vs 152.067 index.html?xml.12

4.367 vs 872.829 index.rdf.2

14.783 vs 9165.716 talk?feed=rss2

6.751 vs 980.692 index.rdf.19

1.984 vs 205.695 index.html?xml.18

3.122 vs 225.296 index.rdf.18

36.107 vs 19888.307 index.html.4

3.402 vs 316.764 index.rdf.54

2.829 vs 226.778 index.rdf.32

4.423 vs 1081.482 index.rdf.3

5.801 vs 1916.120 index.html.2

25.172 vs 6872.890 gamble?feed=rss2

4.735 vs 846.101 index.rdf.15

11.688 vs 6284.851 pc?feed=rss2

3.572 vs 374.356 index.rdf.7

3.788 vs 377.102 index.rdf.53

4.442 vs 795.737 index.rdf.4

27.751 vs 18444.048 manga?feed=rss2

3.590 vs 524.870 index.rdf.14

2.967 vs 221.017 index.rdf.48

3.441 vs 568.598 index.rdf.20

2.940 vs 303.711 index.rdf.13

8.368 vs 3125.123 index.html?feed=rss2

4.147 vs 139.066 index.html?xml.2

8.120 vs 1324.849 index.rdf.40

3.152 vs 133.390 index.rdf.52

3.258 vs 290.415 index.rdf.44

7.013 vs 96.820 rss

2.808 vs 181.106 index.rdf.22

2.967 vs 233.972 index.rdf.50

3.104 vs 421.921 index.rdf.39

6.247 vs 1839.871 index.rdf.29

2.168 vs 89.000 index.html?xml.19

2.829 vs 178.847 index.rdf.16

2.832 vs 161.458 index.rdf.51

2.636 vs 186.148 index.rdf.24

15.118 vs 7562.889 feed.3

3.090 vs 253.103 index.rdf.10

2.158 vs 205.923 index.html?xml.9

2.976 vs 229.955 index.rdf.1

3.398 vs 446.549 index.rdf.31

3.053 vs 276.134 index.rdf

1.991 vs 169.961 index.html?xml.3

11.469 vs 1167.462 index.html?xml.1

3.876 vs 626.648 index.rdf.30

5.847 vs 1982.844 index.html.3

2.025 vs 167.217 index.html?xml.17

3.242 vs 147.577 index.html?feed=rss2.2

16.571 vs 10932.801 sports?feed=rss2

2.047 vs 70.548 index.html?xml

3.254 vs 276.725 index.rdf.41

1.998 vs 158.414 index.html?xml.11

1.994 vs 210.396 index.html?xml.14

3.120 vs 258.864 index.html?feed=rss2.1

15.106 vs 8625.756 index.html?xml.7

4.855 vs 1182.983 feed.1

1.979 vs 160.850 index.html?xml.16

3.355 vs 428.056 index.rdf.35

11.931 vs 1417.789 feed.4

3.353 vs 307.679 index.rdf.45

3.776 vs 474.214 index.rdf.8

1.795 vs 50.013 index.html?xml.4

10.671 vs 6183.113 music?feed=rss2

3.641 vs 310.649 index.rdf.38

speedparserはclean_html=False、feedparserはfeedparser.PARSE_MICROFORMATS = 0を設定。

単位はmsecで、左がspeedparser、右がfeedparser。正確な数字をとるために何度も回したりとかはしてないけど、別にそんなことしなくても余裕でわかるくらい差が出てる。

ざっくりspeedparserが数十-数百倍くらい速い。feedparserがいかに遅いかよくわかると思う。

もう少しtestcase追加してunittest全部通したらdeployしてみようかと思う。

追記:

一時間以上かかってたクロールが3分もかからなくなった。

しかもその3分の大部分がいくつか返事が返ってこないフィードの待ち時間で、過半数はあっという間に終わってた。

f:id:kudzu:20140510034137p:image

右端のところが新しいparserを使ったところで、見ての通り、ピークが100%にいかなくなってる。互換性の問題で移植できなかった部分はfeedparserのままにしておいたせいで多分まだ高めになってる。その処理自体はioのほうがボトルネックになるから、気にしなくていいかな、と思って放置してる。

追記2:

f:id:kudzu:20140510035521p:image

べ、別に都合のいい部分だけ切り抜いたわけじゃないんだからね、ということでピークがすぎる部分も載せてみる。ピークが小さくなった上に、圧倒的に短くなってるのがよくわかると思う。