glibc 2.15のビルドがループする（未解決）

CentOS5.8にgcc 4.7が入っている環境で、glibc 2.15をビルドしようとすると、nptlのところで延々とループしてしまう現象に遭遇した。
検索してみると、「時計が狂ってるんじゃない？アハン？」「VMだったから狂ってたよ！イエアー」みたいな感じで解決してしまっていた。
しかし、うちの場合は実マシンに直接入ってるし、dateコマンドを叩いてみても正しい時刻が返ってくる。

途方に暮れていたところ、別の検索結果から、インストール先のincludeを消すか名前を変えたら上手く行ったよ、という書き込みを発見。
/usr/localにインストールしようとしているときに、/usr/local/includeの方を参照しちゃって、まずいことになるらしい。

早速、
mv /usr/local/include /usr/local/include_org
としてconfigureしてみると、ヘッダファイルが見つからないというエラー。
そ、そうか…。

元に戻して、configureをしてから/usr/local/includeをリネーム。
すると、gd.hが見つからないというエラー。
確かに、gd.hも/usr/local/includeに入っていた。

もう一度、configure --helpを見直すと、gdのインクルードディレクトリを指定するオプションがあった。
もしかして、このために？というようなオプション。

結局、以下のような手順で問題の箇所は通過出来た。

1.ソース展開
  tar jxf glibc-2.15.tar.bz2
2.展開したディレクトリに入る
  cd glibc-2.15
3.ビルドディレクトリを作る
  mkdir -p build
4.ビルドディレクトリに移動
  cd build
5.gdのインクルードディレクトリを参照するためのシンボリックリンクを用意
  ln -s /usr/local/include /usr/local/gd
6.configure
  ../configure --disable-sanity-checks --with-gd-include=/usr/local/gd
7.インストール先のincludeディレクトリをリネーム
  mv /usr/local/include /usr/local/include_org
8.シンボリックリンクの先が居なくなってるので張り直し
  rm -f /usr/local/gd
  ln -s /usr/local/include_org /usr/local/gd
9.make
  make

しかし、その後もmakeでエラーが頻発し、もう前にも後ろにも進めないという状態。
結局諦めた。


1.そもそもの発端は、MongoDBにアクセスするC++プログラムを書きたい。
2.標準で入っているboost 1.33では、古くてビルドが通らない。
3.boost最新版がgcc4.1でビルド出来ない。
4.gcc4.7を/usr/localに入れる。
5.phpが起動しなくなった。
6./lib64に入っているlibc.so.6(glibc 2.5由来)と/usr/local/lib64/libc.so.6(glibc 2.15由来)が衝突している（後者を読んで欲しいのに、前者が読まれる）

というようなことで、いろいろ環境を立ち直らせたかったのですが、gcc4.7はまだ早すぎたようです。

結局CentOS6.2を入れ直して標準のgccのバージョンが上がれば…と期待しつつ、システムを入れ替えることにしました。
アップグレードはサポート対象外とのことで、再インストールを予定しています。とりあえずはyumからのアップデートも試してみようかと思います。成功した報告はないらしいのですが。

カラオケボックスにおける新しい体系

わたしは音痴です。

自分の下手さ加減に、こんな歌声は聞きたくないと自分が思います。

ですので自分からカラオケに行くことはないのだけど、流れ上避けられない状況というのはあります。

そういう場合、何かと理由をつけて歌うのは断るのですが、カラオケボックスでは歌うことがメインになりすぎていて、なかなか場を白けさせずにということに気を遣います。

そこで、どういう状態がベストなのか、そこから導き出された提案を書いてみます。

こんなことをカラオケボックス内でやりとりしたくないし、それこそ場が白けるので、こんなところに書いています。

まず、なぜ音痴なのか。なぜ歌を上手くしようと思わないのか。

すべての人には得手不得手があります。そりゃ、頭の回転も良くて、記憶力も抜群、運動能力も高く、ルックスも万人受け…そんな人になりたいです。

しかし、持って生まれた身体。鍛えるにしても限界があります。

池乃めだか氏にダンクシュートをしろと言っても無理なのです。

Q:誰も聞いてないよ。

A:わたしが聞いています。

Q:歌えば気持ちいいよ。声出せば気持ちいいよ。

A:だから自分の歌声を聞きたくないのです。それならさきっちょでアメマと叫びます。

Q:出せる音域の歌を歌えばいいじゃないのか。

A:歌いたい歌を歌わずにして、何が気持ちいいのでしょうか。声が出るなら高いキーの曲を歌いたいです。

Q:歌わないと楽しくないよ。

A:他の人の上手い歌を聴いているだけで十分楽しいのです。

Q:下手でもいいじゃない。

A:わたしが苦痛になってもいいというのか。

そんなこんなで、最初にも書いたとおり、カラオケボックスは一般人にとって歌う場でしかなく（オフ会とかで、歌わずに過ごす場合もありますが、それは別にして）、歌が苦手な人にとっては苦痛な空間であることが多いです。

そこで、カラオケボックスの仕組みがもう少し変われば、みんな好き勝手なことしてて楽しめるのに、とも考えました。親交を深めるという意味では、どうなのかという気もしますが、うまく変えられればいけるのではないでしょうか。

例えば、飲み屋でハンドルキーパーは割引になるように、歌声キーパー(笑)の人が居ると、キーパーは割引、歌う人も少し割引とか。（調べてみたのだけど、最近の通信カラオケは一曲当たりの単価じゃないみたいで、店舗にメリットがない？）

カラオケの曲がビートマニア・ポップン・DDRみたいになっていて同時に遊べる。（歌声でバンゲリング帝国が操作できるとか）

なかなか上手い組み合わせが思いつきませんが、カラオケというものを別のものに進化させることができれば、もっと多くの人が楽しめる場になるのではないかと、思うのです。

PostgreSQL 9.1でのパーティション全体のソートの最適化

「PostgreSQL Advent Calendar」23日目です。

PostgreSQLにはパーティショニングテーブルというものがあります。今日はそのお話。
「カラム定義が同じ複数のテーブルに、データを分割して格納できる」機能といいますか、「テーブルに親子関係を持たせられる」といいますか、詳しくは、Let's PostgreSQLを参照。（丸投げ）

拙作「ふぁぼるっく」では、バックエンドのデータベースとしてPostgreSQLを採用しています。Twitterのつぶやきデータが大量に貯まり、SSDに載りきらないため、新しいデータはSSD上のテーブルスペース、古いデータはHDD上のテーブルスペースと分けて保存しています。
そこで検索は横断的にやりたいということで、パーティショニングテーブルを使っています。
しかし、どうにも重たい。要求は新しいもの順で表示するので、SSDだけにアクセスし、データが無ければHDDを見に行くような動きをしてほしいのです。

Twitterでぼやいてみたら、9.1からは「パーティション全体のソートの最適化」が行われていることを教えてもらいました。そういえば、9.1を使っていたんだった。ということで、追試してみました。

PostgreSQLで期間ごとに区切ってパーティショニングテーブルを使っているんだけど、その期間をORDER BYに入れた場合、小さい部分の受け持ちテーブルから順に見に行ってくれたりするんだろうか？いやー、この遅さなら、見てくれてないんだろうな。
— おさ (@osapon) 12月 15, 2011

たとえば、Twitterのstatus_idの大きい順に指定件数だけ取ってきたいんだけど、古いテーブルも見てるんならやっぱり遅いよな。アプリ側で各テーブルを順に見て、指定件数分取得できるまで古いテーブルを掘り返す方が速いんだろうか。
— おさ (@osapon) 12月 15, 2011

それってアプリ側でやることじゃないよなぁ。せっかく制約も掛けて、そのテーブルに含まれるstatus_idが分かってるんだからさ。
— おさ (@osapon) 12月 15, 2011

EXPLAINの結果はどうでしょうか？ 9.1ではパーティションのORDER BYが強化されています→ bit.ly/q5jnOV RT @osapon: 期間ごとに区切ってパーティショニングテーブルを使っているんだけど、その期間をORDER BYに入れた場合…
— 日本PostgreSQLユーザ会 (@PostgreSQL_JP) 12月 15, 2011

@PostgreSQL_JP 9.1を使っているんですが、他のテーブルとJOINしたりしてるので、そのせいか全テーブルを見に行っちゃってるんですよね。条件減らして、JOINしなければうまくソートしてくれました。もう少しSQLを調整してみます。
— おさ (@osapon) 12月 15, 2011

@osapon なるほどなるほど。他のテーブルも含めた絞り方がキーなんですね。
— 日本PostgreSQLユーザ会 (@PostgreSQL_JP) 12月 15, 2011

PostgreSQL.1の「パーティション全体のソートの最適化」が無効になる条件判明。SELECT a.*,b.* FROM A JOIN B ON ～ WHERE B.hoge ORDER BY A.idでB.hogeにインデックスが無い時。うー、その項2値しか入らないんよ。
— おさ (@osapon) 12月 15, 2011

試してみた環境はPostgreSQL9.1.2、テーブル構成はこんな感じ。

CREATE TABLE t_parent
(
id smallint NOT NULL, -- 社員番号
kind smallint NOT NULL, -- 役職
fullname text NOT NULL, -- 名前
CONSTRAINT t_parent_pkey PRIMARY KEY (id )
)
WITH (
OIDS=FALSE
);
ALTER TABLE t_parent
OWNER TO postgres;
COMMENT ON COLUMN t_parent.id IS '社員番号';
COMMENT ON COLUMN t_parent.kind IS '役職';
COMMENT ON COLUMN t_parent.fullname IS '名前';

CREATE TABLE t_child10
(
-- 継承 from table t_parent:  id smallint NOT NULL,
-- 継承 from table t_parent:  kind smallint NOT NULL,
-- 継承 from table t_parent:  fullname text NOT NULL,
CONSTRAINT t_child10_pkey PRIMARY KEY (id ),
CONSTRAINT id_chk_1 CHECK (id >= 10 AND id < 20)
)
INHERITS (t_parent)
WITH (
OIDS=FALSE
);
ALTER TABLE t_child10
OWNER TO postgres;

CREATE INDEX t_child10_kind_idx
ON t_child10
USING btree
(kind );

CREATE TABLE t_child20
(
-- 継承 from table t_parent:  id smallint NOT NULL,
-- 継承 from table t_parent:  kind smallint NOT NULL,
-- 継承 from table t_parent:  fullname text NOT NULL,
CONSTRAINT t_child20_pkey PRIMARY KEY (id ),
CONSTRAINT id_chk_2 CHECK (id >= 20 AND id < 30)
)
INHERITS (t_parent)
WITH (
OIDS=FALSE
);
ALTER TABLE t_child20
OWNER TO postgres;

CREATE INDEX t_child20_kind_idx
ON t_child20
USING btree
(kind );

INSERT INTO t_child10 VALUES (10, 1, '社長');
INSERT INTO t_child10 VALUES (11, 2, '部長A');
INSERT INTO t_child10 VALUES (12, 2, '部長B');
INSERT INTO t_child10 VALUES (16, 3, '課長A');
INSERT INTO t_child10 VALUES (19, 4, '社員A');
INSERT INTO t_child20 VALUES (25, 2, '部長C');
INSERT INTO t_child20 VALUES (23, 3, '課長B');
INSERT INTO t_child20 VALUES (27, 3, '課長C');
INSERT INTO t_child20 VALUES (24, 4, '社員B');
INSERT INTO t_child20 VALUES (26, 4, '社員C');
INSERT INTO t_child20 VALUES (28, 4, '社員D');

親テーブルt_parent、子テーブルt_child10、t_child20。
主キーはそれぞれidの社員番号。t_child10はidが10代、t_child20は20代という制約が付いている。
そのほか、kindの役職にインデックスを張っている。

このとき

EXPLAIN (COSTS OFF) SELECT *
FROM t_parent
WHERE id >= 15
ORDER BY id
LIMIT 2

とidが15以上の者、id順で上位2件を取得すると
Limit
  ->  Result
        ->  Merge Append
              Sort Key: public.t_parent.id
              ->  Index Scan using t_parent_pkey on t_parent
                    Index Cond: (id >= 15)
              ->  Index Scan using t_child10_pkey on t_child10 t_parent
                    Index Cond: (id >= 15)
              ->  Index Scan using t_child20_pkey on t_child20 t_parent
                    Index Cond: (id >= 15)
となる。このMerge Appendが最適化が行われた状態。

つぎに

EXPLAIN (COSTS OFF) SELECT *
FROM t_parent
WHERE kind = 2
ORDER BY id
LIMIT 2

とkindが2の者、id順で上位2件を取得すると
Limit
  ->  Sort
        Sort Key: public.t_parent.id
        ->  Result
              ->  Append
                    ->  Index Scan using t_parent_pkey on t_parent
                          Filter: (kind = 2)
                    ->  Index Scan using t_child10_kind_idx on t_child10 t_parent
                          Index Cond: (kind = 2)
                    ->  Index Scan using t_child20_kind_idx on t_child20 t_parent
                          Index Cond: (kind = 2)
となり、全テーブルを見に行くようになってしまいました。

（追記9:53 ANALYZEかけたらMerge Appendになりました。）

いろいろ試してみたのですが、テーブルの設計がかなり物を言うようです。あとは頻繁にANALYZEをかける必要がありそう。
実際に使用している環境では、一つのテーブルが数千万行、また正規化しまくっていてJOINでつないでいるテーブルも数百万行あり、 「パーティション全体のソートの最適化」が行われませんでした。

プランナが賢くなるまで、もう少し辛抱のようです。

24日目はt_motookさんの「SQLFeatureNotSupportedException - JDBC4.0 API の中で未実装のもの」です。

zabbixで外部チェックアイテムを作る

（この記事はzabbix 1.8を対象としたものです。2.0以降では、下記パラメータの1番目にホスト名というのがありません）
サーバの状態監視にはzabbix！
便利すぎます。結構負荷高いのが難点だけど、余裕があったら監視用サーバを立てるのもありかなと思う。

普段はテンプレートをそのまま適用して、動いていないサービスのアイテムだけ解除していく使い方をしているのだけど、テンプレートで用意されていない物を監視したいときに、外部チェックアイテムを作成して対応した。

　アイテムのタイプ：外部チェック
　キー：get_queue_count.sh[fav_queue]
などとする。

このとき、zabbix_server.confのExternalScriptsに、キーで指定したスクリプトのパスを書いておく。

そしてスクリプト側。[ ]で括られた部分がパラメータとして渡されるのだけど、パラメータの1番目にホスト名が自動的に付けられる。
上の例だと、実際に呼ばれるコマンドは
　get_queue_count.sh hostname fav_queue
みたいに。

なので、スクリプト側では、それを考慮しておく必要がある。
　#/bin/bash
　/usr/bin/mongo --quiet --eval="db.$2.count()" favlook
という感じで、ホスト名は無視した。

PostgreSQL9.1betaでpg_upgradeしてみた。

PostgreSQL9.1のベータを試用しているんだけど、beta2からCATALOG_VERSION_NOが変わっていてバイナリ差し替えが出来なかったので、pg_upgradeを試してみた。今回はbeta1からbeta3への移行。
（9.0から9.1betaのときは、9.0のファイルが壊れまくっていてpg_upgradeが動かなかった）

まずpg_upgradeを-cオプション付きで実行。
最低限の環境が合っているか確認する。
このとき、移行元のシステムは動作していて構わない。移行先のシステムは停止させておく。

[postgres@srv ~]$ /usr/local/pgsql91b3/bin/pg_upgrade -c -b /usr/local/pgsql91b1/bin -B /usr/local/pgsql91b3/bin -d /usr/local/pgsql91b1/data -D /usr/local/pgsql91b3/data -p 50911 -P 50913
（pg_upgradeは移行先のものを使うこと）
環境が異なっているとカレントディレクトリにログが吐き出されるので、それを見てライブラリの差違をなくす。

チェックが終わったら、移行元、移行先の両システムを停止させて-cオプション無しでpg_upgradeを実行。
このときはまったのが、ログインロールにdefault_tablespaceの設定がある場合。
環境としてはroleAというロールがspaceBのオーナーであり、default_tablespace='spaceB'となっている。

pg_upgradeは
1.移行先にロールを作成
2.ロールに付属するALTERを実行
3.テーブルスペースを作成
の流れて進んでいく。
このとき、2番の処理で ALTER ROLE ロール名 SET default_tablespace='テーブルスペース'; が実行されて「そんなテーブルスペースはない」と怒られてしまう。
では先にテーブルスペースを作れば良いのかと、移行先にロールとテーブルスペースを作ってしまうと、1番の処理で「既にロールがある」と怒られてしまう。
ロールは作らず、テーブルスペースのオーナーをpostgresにしておいても同様に「既にテーブルスペース（以下略）。

結局、一時的にdefault_tablespaceを解除して実行した。
pg_dumpのときみたいに、CREATE系を先に実行して、ALTER系をあとで実行するとか出来ませんかね？

あと、pg_upgradeがエラーで中止されると、移行元システムの/data/global/pg_controlがpg_control.oldにリネームされて再実行できなくなるので、面倒だがpg_controlにリネームする必要がある。
これは再実行させないためなんでしょうかね？　どうせ移行先にロールがあったら失敗するのに、と思ってみたり。

移行中にpg_upgradeの進捗が分からないのも難点。
残り時間までは必要無いので、対象ファイルがいくつあって、現在どこまで進んだのかが分かるだけでも気が楽だと思う。
停止時間を長くしたくない場合は、アプリ側で更新処理を停めて、pg_dump | psqlを流した方が参照だけでも出来るのでpg_upgradeよりマシかも。

やつを見に行ってきた

水都大阪2009の会場をぶらついてきました。
ウワサのやつが居た。
でかい。
水上バスと比較してこの大きさ。

おさのおすすめついたったー

フォローすべき"ついたったー"みたいな企画を見かけたのでマネしてみる。
個人的には「ついったらー」って言いたいんだけど、みんたついたったーっていうね。

以下アルファベット順
DCasakura バーチャルネットアイドル・朝倉なんとかの人。ぴりりと辛みのきいたPOSTが心地よい。
horioka (´ω｀)の人。本人はBOTじゃないと言っているが、わたしは80%ぐらいの確率でBOTだと思っている。(´ω｀)で世界征服を企んでいるに違いない。
inva1id わたしのTLに一番最初に組み込まれた変態クラスタの人。最近はおとなしくなって、面白クラスタに移行しようとしているようだ。
kaji2 料理クラスタの人。TLからすると悠々自適な生活を送っておられるように見える。憧れのまなざし。
koizuka ニコニコ動画の人。わたしの年代からすれば、Bio_100%の人といった方が分かりやすい。当時の憧れを持ったままフォローすると、おっさんギャグクラスタの深みにはまっていすぎて、思い描いていた何かが壊れる。
lib110ka 図書館雑記の人。図書館や本に関して興味があるので、フォローしておくと、ふむふむというつぶやきが見られる。
risyu_ いつもお昼ご飯が遅い人。仕事が大変そうです。お昼ぐらいはのんびり出来ると良いなと祈っております。
uilab 大学生クラスタの人。人の恋路を見るのはニヤニヤできていいですね。良い結果になることを祈っております。
vanillate ちわわの人。あとカメラクラスタ。最近かわいくなった、アイコンが。いやTLもかわいい感じのする人。
ということで、9人。
基本的に感性の合う人しかフォローしないので（合わなかったらRemoveしたり）、わたしのフォロワーは全部おすすめではあるのですが。印象に残っている人をピックアップしてみました。
フォロワー全員に、一行コメントを付けていく企画をすればいいのか。

つーか、フォロワーにメモを付けられるサービスでも作るか。

わんくま勉強会初参加

わんくま同盟の大阪勉強会 #30に参加してきました。


>「PowerShell ver2について　～ついにWindowsサーバー管理環境の主流へ～」by むたぐち lv1くま～
PowerShellのv1が発表された頃、事務所のVirtualServerを管理するために使おうとしたことがありました。
しかし、オブジェクトが名前空間に別れていないので、全部出てくるわ、サンプルはあるのにまとまっているページが見つからないわで挫折し、WSHに逃げました。
今後は標準搭載されていくようなので、使いやすくなりそうです。


>「スマートフォン勉強会出張版」by ながくらえいるさん lv1くま～
スマートフォン欲しいね！
なんで日本の各社が出すスマートフォンは、通信方式を合わせただけで、SMSとか使えないんだろうね。
最近のiPhoneでやっと出来るようになったみたいですが、まわりがauなので、auも頑張って欲しいです。
スマートフォンだけauの庭の外とか嫌すぎます。


>ライトニングトーク Yalabさん
Gitいいよって話。
わたしはTortoiseGitが出始めた頃に試してみました。TortoiseGitが安定していなかったのと、分散リポジトリが、出先で作業することがないので必要に迫られなかったことで、SubVersionを使い続けています。
仕事場はVisualSourceSafe。データベースがすぐ壊れるのをなんとかして欲しいです。一度一からちゃんと自社で作り直した方が良いんじゃないでしょうか？


>ライトニングトーク みるぽんさん
大阪は怖いところですねー。


>ライトニングトーク fuhdukiさん
おすすめ同人ゲームの話。
コミケ行ってた頃は、絨毯爆撃とかしていたのですが、作る側に回ったりとかして、あまり遊ぶことが少なくなりました。
Flashゲームとか時間つぶしには良さそうです。


>「C++0x むーぶせまんちくす」by Cryoliteさん lv2くま～
仕事ではC++を使ったのが１年以上前なので、すごい懐かしい。
仕事し始めるまではC++オンリーだったんですが、仕事始めてからCとVBになって、会社始めてからはWeb周りが多いです。
プライベートで参加しているo2onはC++なのですが、なかなか思い切った変更が入れられないので、ちまちました修正が多い。
たまには便利になったC++でがっつり書いて脳汁出したいですな。


>「ループ書いたら負けかなと思っている」by uskzさん lv2くま～
なんというか…「コンパイラってすごいね！」違うのかな？
別の意味で脳汁出ました。数学をしっかりやってると、このあたりのはなしが面白くなるんでしょうなぁ。


>「IPnutsではじめよう　快適？PCルータ構築」by しおんぐさん lv1くまー
バトルフィールド ベトナムをプレイしていた頃に、サーバを立てたことがあって、そのときは大量のアクセスがやってきて、すぐにルータがパンクしました。
ある程度パワーのあるマシンが余ってると、ルーターにしちゃうのも良さそうですね。

>ライトニングトーク ちゅきさん
仮想化の話。VirtualPCを使っていたときは、まあ便利だなー、程度の感想でしたが、VirtualServerを触ると、こりゃ便利だと思いますね。

>ライトニングトーク CH3COOH(酢酸)さん
やっぱりスマートフォン欲しいよー。
しかし普段の携帯ですらあんまり使っていないので、ネットしたいためだけに２回線もつというのにすごい抵抗が。
auの庭の中にいるスマートフォンを…（やっぱりそれか）


>ライトニングトーク 山下康成＠京都府向日市さん
端末は複数持つけど、回線は一本にまとめるってのも手段の一つですね。
２回線目は趣味と割り切るしかないのかなぁ。


>ライトニングトーク るーごんさん
ポケモンむずかしい。自分でプレイしてるか、子供がいる家庭なら、親も覚えられるんですかねぇ。

>ライトニングトーク ？？？さん
ごめんなさい、名前が思い出せない。
ムーンウォークのやり方について。
ツルツルの床じゃないと難しそうですね。あと、座敷での宴会では台の上に乗った方が良いかもしれません。
しかし、このネタが分かる人もだんだん減ってくるんですよねぇ。やだやだ。

>懇親会～
ゲーム派のオフ会にサインしてたときみたいな気分になりました。賑やかというのはよいですな。

改めて感想を読み返すと、年取ったな―と思いますね(笑)
ライトニングトークぐらいなら、なんかやってみたいなと思いました。
もっとOutputしていかないといかんなー。