PEAK XOOPS - MySQLの保守 
XOOPS
XOOPS : MySQLの保守
ふと思い立って、 /var/log/mysql_slow_queries をチェックしたら、
DELETE FROM xp_session WHERE sess_updated < 1151347298;
この手のクエリがずらっと並んでいました。
確かにXOOPSにおいて、sessionテーブルはゲストアクセスでも常に書き換えられているのですから、テーブルデータとしてのフラグメンテーション（セクタ/クラスタのフラグメンテーションではない）も相当なはずです。
というわけで、mysqlcheck -o --all-databases をかけてみたらビックリ。
Optimizeをかける前は、628932byteだったMYDファイルが174648byteまで減りました。
当然中身は同じデータなわけで、いかにスカスカで、アクセスしづらい状況だったか、ということです。
ついでに、インデックス情報の更新 mysqlcheck -a --all-databases もやってみたら、XOOPSのsessionテーブルはどれも"already up to date"ではありませんでした。
どういう理由で、sessionテーブルのindex情報が最新状態でなくなっているのかは判りませんが、session処理がXOOPSにとって重い処理であることは間違いないので、このあたりを改善できれば速度向上に役立つ気がします。
とりあえず、サーバ管理者権限をお持ちなら、cronに、index情報の更新と、テーブルオプティマイズを仕掛けるべきでしょう。（自分への戒めも含め）
30 6 * * * /usr/bin/mysqlcheck -a --all-databases > /dev/null 2>&1
45 6 * * 0 /usr/bin/mysqlcheck -o --all-databases > /dev/null 2>&1
Comments list
gusagi
Posted on 2006/8/22 0:05
Quote:こちらこそ、書き方がまずかったですね＾＾；
通常のサイトであれば、Optimizeで問題ないと思います。
ただ、アクセスが集中している状態（メルマガを発行しているサイトで、メルマガ発行直後とか）でOptimizeをかける場合だけリスクがあるので、cronの設定時間に気をつける必要がある、と書けば良かったですね。
（そもそも、cron自体、深夜とかに設定する人が多いか
）
逆に、Optimizeをかけないでパフォーマンスが劣化してく方が普通にありうるので、定期的にOptimizeをかけることは全面的に賛成です。
ちょっと誤解を招く書き方ですみません。
実際にそういう現象があるのであれば、DBの混雑具合によらず、Optimizeをしない、というのが一番ですね、という意味です。
だって、MYDが壊れるのはさすがにシャレになりません。
通常のサイトであれば、Optimizeで問題ないと思います。
ただ、アクセスが集中している状態（メルマガを発行しているサイトで、メルマガ発行直後とか）でOptimizeをかける場合だけリスクがあるので、cronの設定時間に気をつける必要がある、と書けば良かったですね。
（そもそも、cron自体、深夜とかに設定する人が多いか
）逆に、Optimizeをかけないでパフォーマンスが劣化してく方が普通にありうるので、定期的にOptimizeをかけることは全面的に賛成です。
GIJOE
Posted on 2006/8/21 4:12
Quote:ちょっと誤解を招く書き方ですみません。
実際にそういう現象があるのであれば、DBの混雑具合によらず、Optimizeをしない、というのが一番ですね、という意味です。
だって、MYDが壊れるのはさすがにシャレになりません。
だから、cronでは、インデックスチェックだけをやりましょう。
Optimizeについてはとりあえずやめましょう、というスタンスで
「テーブルロックしてるはずなのに、Optimize直後からデータが壊れていた」＆「Optimizeは稀にデータを壊す、という情報を聞きかじっていた」ので、Optimizeを悪者にしていました
実際にそういう現象があるのであれば、DBの混雑具合によらず、Optimizeをしない、というのが一番ですね、という意味です。
だって、MYDが壊れるのはさすがにシャレになりません。
だから、cronでは、インデックスチェックだけをやりましょう。
Optimizeについてはとりあえずやめましょう、というスタンスで
gusagi
Posted on 2006/8/20 20:59
Quote:やっぱりそうですかね＾＾；
「テーブルロックしてるはずなのに、Optimize直後からデータが壊れていた」＆「Optimizeは稀にデータを壊す、という情報を聞きかじっていた」ので、Optimizeを悪者にしていました
う〜ん。
いくらなんでもそれは、MySQLかファイルシステムに問題があるのでは？
「テーブルロックしてるはずなのに、Optimize直後からデータが壊れていた」＆「Optimizeは稀にデータを壊す、という情報を聞きかじっていた」ので、Optimizeを悪者にしていました
GIJOE
Posted on 2006/8/20 13:05
Quote:う〜ん。
いくらなんでもそれは、MySQLかファイルシステムに問題があるのでは？
MySQLは3.23でも、テーブル単位のロックは持っているので、Optimize(ロック)中にINSERT/UPDATE/DELETEが来ても処理しないでしょう。
それはともかく、今回のsessionテーブルで一番の問題は、OptimizeよりもIndex破損の方ですね。MYIファイルの方なら、最悪、完全に壊れても復旧可能なので、-a の方を高い頻度で行うべきか？
書き込み（Insert / Update / Delete）が頻繁に行われているテーブルにOptimizeをかけると、稀にですがテーブル内の情報がおかしくなる場合があった気がするので。
いくらなんでもそれは、MySQLかファイルシステムに問題があるのでは？
MySQLは3.23でも、テーブル単位のロックは持っているので、Optimize(ロック)中にINSERT/UPDATE/DELETEが来ても処理しないでしょう。
それはともかく、今回のsessionテーブルで一番の問題は、OptimizeよりもIndex破損の方ですね。MYIファイルの方なら、最悪、完全に壊れても復旧可能なので、-a の方を高い頻度で行うべきか？
gusagi
Posted on 2006/8/18 20:30
アクセスの少ない時間の方が良いですよね（’’）
書き込み（Insert / Update / Delete）が頻繁に行われているテーブルにOptimizeをかけると、稀にですがテーブル内の情報がおかしくなる場合があった気がするので。（仕事で、そんな現象が。。。）
書き込み（Insert / Update / Delete）が頻繁に行われているテーブルにOptimizeをかけると、稀にですがテーブル内の情報がおかしくなる場合があった気がするので。（仕事で、そんな現象が。。。）
Login