LogLevelディレクティブ：エラーログに記録されるレベルApache ではエラーが発生したときにログを記録しますが、重大なエラーが発生した時だけを記録するのか、それとも警告のようなものまでログとして記録するのかなどエラーを記録するレベルを設定することができます。ここでは LogLevel ディレクティブ を使って Apache のエラーログに記録されるレベルを設定する方法について解説します。レベルは emerg から debug まで全部で 8 のレベルがあります。
大きめのテーブルにカラムやインデックスを追加する際の注意 - LukeSilvia’s diary
先日大きめ(といっても500万行くらい)のテーブルにインデックス付きのカラムを追加しようとして痛い目にあったので調査。 大きめのテーブルにカラムやインデックスを追加するとどうなるか 今回は単純に、「ALTER TABLE 〜 」で追加しようとしました。追加するカラムは3つで、 varchar(255) インデックスなし varchar(255) ↓のdate 型カラムとマルチカラムインデックスの形式のユニークインデックスあり date インデックスあり SQL を実行し、状況を「SHOW PROCESSLIST」で監視していたら、1つ目のカラム追加で次のような状態に… 最初にState が「copy to tmp table」状態になり、次の状態に遷移するまで1時間かかる 次にState が「Repair with keycache」状態になり、完了までに1時間かかる 次のカラム追加に対す
copy to tmp table - @kyanny's blog
たかだか700万行、 mysqldump して 150MB 弱のデータ量しかないテーブルに一つユニークインデックスを貼るだけで7時間半かかってまだ終わらないってどういうことよ。この大きさになるともう ALTER TABLE では無理だってことか・・・。夜中に ALTER TABLE し始めたときと、ついさっきとで、 show full processlist の結果は悲しくも変わらず copy to tmp table のまま。何個かインデックス貼るうちの最初の一個でこれじゃあ。ほっといても永遠に終わらなそうだ。 RENAME TABLE したあと元の名前でインデックスありのテーブルを作り直し、 INSERT INTO new_table SELECT * FROM old_table するのと、 mysqldump して CREATE TABLE にインデックスたして全部ロードしなおすの
【翻訳】なぜ Bundler 1.1 は速くなるのか
Pat Shaughnessyさんの "Why Bundler 1.1 will be much faster" を翻訳しました。 元記事はこちら： http://patshaughnessy.net/2011/10/14/why-bundler-1-1-will-be-much-faster （翻訳の公開と画像の使用は本人より許諾済みです） 翻訳の間違い等があればブログコメントやTwitter(@oshow)などで遠慮無くご指摘ください。 2011年12月発売の WEB+DB PRESS Vol.66 には Bundler の解説記事が載っているそうです。 「Bundler1.1 ではなく Bundler 自体を知りたい」という人は、そちらを手にとってみてはいかがでしょうか。 なぜ Bundler 1.1 は速くなるのか 2011年10月15日 by Pat Shaughnessy ここ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
