Izu, Masahiro
izum****@campu*****
2003年 1月 11日 (土) 04:42:25 JST
伊豆です。 早々のReplyありがとうございます。 TAMURA Toshihiko wrote: > ●MySQLのチューニング > MySQLのパラメータの設定でも、かなり改善できるかもしれません。 > アプリケーションやサーバのメモリ量などによって設定は異なりますが、 > 以下のような情報を参考にして、 > mysqladmin status の "Slow queries:" や "Queries per second avg:"で > パフォーマンスを監視することができます。 > > 5.5.2 サーバーパラメーターのチューニング > http://www.mysql.gr.jp/jpdoc/4.0/manual.ja_MySQL_Optimization.html > MySQLサーバーのチューニング > http://www.mysql.jp/mysql/TIPS/tune.html > MySQLの高度な管理とチューニングテクニック > http://www.atmarkit.co.jp/flinux/rensai/mysql11/mysql11a.html > Web+DB PRESS Vol.4 "特集２ DBパフォーマンスチューニング" ありがとうございます。参考にさせて頂きます。 > それから、よく言われるのは、max_connections の値がネックになることが > あるということですね。 これは、 max_connectionsをもっと取った方がいいということでしょうか？ どうも挙動を監視していると、同時接続数が多すぎてうまく処理できていない リクエストが多く見られるような気がするのですが。 > ●ハードウェア > ハードウェアの性能に頼るのは手っ取り早いのは確かですよね。 > メモリ量を増やせれば効果は大きいと思いますし、 > MySQLのデータを格納するディスクを分けるのも効果があります。 そうですね。DiskIOが足を引っ張っているかもしれません。 ただ、CPU使用率は下がらないかも。 > > ・MySQLの使用メモリを512MB程に設定 > これは、効果がありましたか？ 最初、何も手を打たないと同時接続数30ぐらいでCPU100%になっていましたが 対策を全部行ったあとは70接続ぐらい捌けるようになりました。 どの手がどのくらい効いたかはよく分かりませんでした。 > > ・DBMSの分離 > > これはかなり効くような気がする。ただ、この対策だけで200人ぐらいのお客様を > > さばけるかどうか？ > 最終的にはこれが必要なんでしょうが、これはこれで大変ですからね。 topでの表示を見る限り、Mysqldでの負荷が非常に高くなっていました。 処理性能的には別筐体に移すのはマイナスですが、CPUから見ると 効果はあると思っています。 逆にCPUを増設できるマシンならそれも効果的かと。 （カーネルを変更する必要はありますが） > > 以下のサーバスペックでこの程度の処理能力というのは妥当なものなのでしょうか？ > もし情報を持っている方がいれば、私も教えてもらいたいです。 何か指標があればいいんですけどね。 それからまた質問になってしまうのですけれども Tepの最新版では、トランザクションを使用していますでしょうか？ 先の投稿でもちょっと書いたのですけれど、 注文確定の段階で カートからordersへのデータ移項時の途中終了が非常に多いようです。 ここは、複数レコードが作成される場所ですので、トランザクションで まとめてやらないとまずいと思うのですが。 （Mysqlでうまく処理できるのかどうかは分かりません） また、在庫の引き落としも、同時アクセスは考慮されていないようです。 だいぶ実在庫とのずれが出ています。 ここらは割と一般的なことだと思うのですが、どうでしょうか。 > 成果があがったら、また教えてください。 > 大規模なショップを、是非成功させてください。 ありがとうございます。 また進展があったら投稿します。 引き続きの情報をお待ちしています。よろしくお願いします。 -- 伊豆雅宏 (Izu, Masahiro Mailto:izum****@campu*****)
