nilog: Tokyo Cabinet (2009-06-25)

← 前の日	2009-06-25	次の日 →
← 一年前		一年後 →

Twitter (2009-06-25)
Tokyo Cabinet http://tokyocabinet.sourceforge.net/ [t] 2009-06-25 13:01:16

関連するかも情報
pixiv「ただいまメンテナンス中です。」の画像 http://gyazo.com/e3f2625281b33cdb0a0b50f5fc68f658.png [t] 2009-06-25 12:54:13
Tokyo Cabinet http://tokyocabinet.sourceforge.net/ [t] 2009-06-25 13:01:16
Tokyo Tyrant http://tokyocabinet.sourceforge.net/tyrantdoc/ [t] 2009-06-25 13:01:20
HDDにやさしい運用を考えるならそろそろメモリキャッシュな key value ストアを考えなきゃいけない、と。あ、blackhole ストレージじゃなくて [t] 2009-06-25 13:04:19
MySQLにはオンメモリストレージがあったはず。 [t] 2009-06-25 13:04:47
「BLACKHOLE ストレージエンジンはデータを受け入れますがそれを格納せずに捨ててしまう「black hole」として機能します」 http://bit.ly/AdKgG [t] 2009-06-25 13:05:41
「MEMORY ストレージエンジンはメモリ上に情報を格納するテーブルを作成します」「サーバが再起動したときにはデータは全て失われています」 http://bit.ly/HKtVr [t] 2009-06-25 13:06:54
@yuka_ ただいま～ (とボットに返事してみる) [t] 2009-06-25 13:14:58
実験環境: MySQLのクエリー量を見るとselectが全体の60%, deleteが25%, insertが15%ぐらい。MySQL内でのキャッシュヒット率が10%に満たない。 [t] 2009-06-25 13:24:21
MySQLのテーブルがクラッシュしますた。ERROR 145 (HY000): Table './xxxxxxxx/hogehoge' is marked as crashed and should be repaired [t] 2009-06-25 13:25:21
repair table するとよくクラッシュするんだよね [t] 2009-06-25 13:26:35
「Try fixing it by using the --safe-recover (-o), the --force (-f) option or by not using the --quick (-q) flag」ということで safe recover なう。 [t] 2009-06-25 13:30:59
それにしても repair table に (2 hours 12 min 21.67 sec) もかかったのになんたること。 [t] 2009-06-25 13:31:58
@twk キャッシュヒット率が低いのはたぶんレコードの数が多すぎるんでしょうねー [t] 2009-06-25 14:19:35
「mysql> delete from url_cache where cachedtime < 20090601;」「Query OK, 638038 rows affected (27 min 57.64 sec)」残りは33万件。 [t] 2009-06-25 15:08:12
@twk ひんじゃくなサーバなのでキビしいんですよねー・・・ってパラメータよく見たらもうちょっと増やせそうな予感ｗ [t] 2009-06-25 15:10:19
@ikakiuchi Englishman in New York をアコギでカバーしているんですね。なんだかお洒落系サウンドな感じ。 http://bit.ly/b0tSQ [t] 2009-06-25 15:14:28

2009年06年25日のnilogをすべて表示する