Sequel についてちょっと調べる

スレッドセーフ、コネクションプールが特徴ということ。でもActiveRecordでも実装済みらしい。

heroku に Redmine を設置するための参考リンク

ただ、レポジトリと連動させる方法が見つからなかったので、断念。。

毎日のご飯をちょっと美味しくする、たった1つの方法

この方法、はじめたのは大学生の頃なので、もう10年以上使っていることになります。

大学生時代から旅行が好きで、トルコ、中国、イタリア、ポルトガルなど、一人でいろいろな国に行っていました。

一人で外国に行くと、寺院や教会、昔の建物の観光はじっくり見てても、すっと終了するので、けっこう暇なことも多く、いつしか、旅行の楽しみは「現地で出会った人と話す、遊ぶ」ってことになってました。

そんなわけなので、ご飯を食べにいっても一人黙々と食べるより、店員さんと話しながら食べるのが楽しく。片言の英語やゼスチャーで店員さんと話します。


そんなとき、日本でご飯を食べていて、ふと、思いました。

「外国ではレストランでお金を払ったとき、『サンキュー』とか、『謝謝』とか言って帰るのに日本ではけっこう無言でお金払って帰っちゃうな。。」

それから、日本でもご飯を食べた後には店員さんに「ごちそうさま」と言うようにしました。

ごちそうさま、を言うと、店員さんがもう一回「ありがとうございました。」と言ってくれます。
ごちそうさま、を言うと、店員さんがにっこりしてくれます。
ごちそうさま、を言うと、いつもより、おいしい物を食べたような気になります。

うちで食べたときにも、「ごちそうさま、ふー、おいしかったー。」というと、ちょっと美味しくなります。
作ってくれた人もちょっとうれしくなります。

たまには、そんな話。

Amazon EC2 でDBサーバー立てたらInnoDBがなくなった話

Amazone EC2 でMySQLスレーブサーバー用のAMIイメージをつくろうと思っていたら、遭遇した問題。

最新のEBSスナップショットをからvolumeを作って、新しいインスタンスにattachして、インスタンスにログインして、MySQLを起動しました。

> SHOW SLAVE STATUS;

としてみると、Unknown table engine 'InnoDB' というエラーが。。。

> SHOW ENGINES;

おっしゃるとおり、InnoDB はリストされません。。
mysql のエラーログを確認すると、エラーがでてました。

110831 06:41:08 mysqld_safe Starting mysqld daemon with databases from /data/lib/mysql
110831 6:41:08 [Warning] '--default-character-set' is deprecated and will be removed in a future release. Please use '--character-set-server' instead.
110831 6:41:08 [Warning] '--log_slow_queries' is deprecated and will be removed in a future release. Please use ''--slow_query_log'/'--slow_query_log_file'' instead.
110831 6:41:08 InnoDB: Error: cannot allocate 5368725504 bytes of
InnoDB: memory with malloc! Total allocated memory
InnoDB: by InnoDB 111315808 bytes. Operating system errno: 12
InnoDB: Check if you should increase the swap file or
InnoDB: ulimits of your operating system.

本番サーバーはLargeインスタンスなんですが、テンプレート作成の一時インスタンスはケチって Microで立ち上げたところ、InnoDBに割り当てていたメモリサイズより小さかったみたいですね。。

それなら、mysqld が立ち上がらなくてもいいんじゃないかと思うんですが、InnoDBなテーブルを無視して、無理やり立ち上がるんですね。

COUNT(primary_key) と COUNT(*) のパフォーマンスの違い

自分の認識とまったく逆だった。。。

COUNT 関数を使ってMySQL のインデックスの基本を理解する

SELECT COUNT(id) FROM users WHERE avaiable = true;


みたいなのは逆にパフォーマンスを落とすということです。
勉強になります。

@ms76 さんからのご指摘により追記

innoDBの場合、逆にcount(primary_key)の方がパフォーマンスが悪いということ

successful と succeeding

AmazonでAuto Scaling を試していたら、 as-create-auto-scaling-group コマンドのヘルプでなんか似たような言葉が出てきた

--default-cooldown VALUE
Time (in seconds) between a successful scaling activity and succeeding scaling activity.

アルクで調べると、

  • successful
    • 〔結果が〕上出来な、上首尾の、成功した
  • succeeding
    • 続いて起こる

ということ。

成功したスケーリング動作のあと、それに続くスケーリング動作までの時間

という意味ですな。