hamada
bungu****@leo*****
2005年 10月 27日 (木) 11:06:00 JST
こんにちわ。 On Wed, 26 Oct 2005 13:17:30 -0700 NOBI <nobi2****@nobi*****> wrote: > す。何故1度目がFAILするのかは原因不明ですが・・。 先にも書いてますが、たぶん/etc/rc.d/init.d/mysqldの記述に問題が有るんだ と思います。内容は既述につき、繰り返しませんが。 あくまでも想像ですが、RHELとFedoraLegacyは同じようにメンテナンスしてて、 同じような問題を抱えてるんじゃないでしょか？ > set-variable = key_buffer=256M > set-variable = sort_buffer=1M 当方なら両方とも倍にします。メモリが1GB載ってるなら。 http://allabout.co.jp/career/database/closeup/CU20040722A/ ↑主要パラメータについての説明。 > Uptime: 823 Threads: 13 Questions: 2242 Slow queries: 8 Opens: 47 > Flush tables: 1 Open tables: 41 Queries per second avg: 2.724 long_query_time=10でコレですか？(^_^;) これは本格的に対策が要りそうな。 $ mysqladmin extended-status でのKey_readsとKey_read_requestsから、インデックスのキャッシュヒット率を 計算してみてください。 100 - ((Key_reads / Key_read_requests) * 100) 「Key読込リクエスト」に対する「実際に読み込まれたKey」の比が実読み込み比 率ですから、これを100%から引いたものが「“非”実読み込み比」＝「キャッシュ から読んだKey比率」ということになります。 当方のトコでは上記キャッシュヒット率が99.9%とかなんすが、たぶんNOBIさん の環境では、ヒット率がより低いのではないかと。 > 後の結果です。キャッシュ生成が終わった後に再度全ての商品ページを開いても > Slow queriesは０でした。 ↑これがちょっと意味解りません。スロークエリ数は積算値だと思ってるんで、 「キャッシュ生成後にスロークエリが０になった」ってのは謎。 とりあえず、my.cnfの[mysqld]下に set-variable = long_query_time=5 set-variable = log-slow-queries=slow.log とか追記しスロークエリのログとって、スローな（＝重い）クエリが何故スロー になるのかを調べてくことになると思います。 基本的にEXPLAINでの行数調べになると思いますが、重い時に $ mysqladmin processlist とかやって、Timeの値が妙に大きかったり、Stateに妙な表示が出てないか等を 確認することも必要でしょう。 processlistを継続的に監視するにはmytopが便利です。 http://jeremy.zawodny.com/mysql/mytop/ > のデータベースを使ったアプリケーションは通常通り問題なく動いているのでや > はりデータの検索に時間がかかっている、といったところみたいです。 今回のボトルネックがディスクなのかCPUなのか、こちらからではよく解んない んですよね。個人的には「ディスクくさい」という印象なんですが、CPU100%と いうお話しもありましたし…。 場合によっては「MySQLを4.0化する」も視野に入ってくると思います。特にコス トの高い“重い”SQLの繰り返しにクエリキャッシュは劇的に効きますんで、入 れ替える手間に見合ったリターンが得られるかもしれず。 # なんだか既に“チューニングの泥沼”に踏み込みかけ…(^^;; はまだ＠バックアップを忘れずに ------------------------------ MLログ検索 http://www.bitscope.co.jp/search/tep.html osC-FAQ http://oscommerce.jouhou.tv/wiki/index.php?FAQ
