Joyentがまもなくサービスを終了するため、最近サーバーを切り替えました。ただし、リムホスティングのクエリはかなり長くかかるようです (2 ～ 6 回)。ただし、動作には大きな違いがあります。ほとんどのクエリは 0.02 秒以下で実行され、まったく同じクエリでも 0.5 秒以上かかる場合があります。両方のサーバーで mySQL と PHP が実行されていました (バージョンは同じですが、正確な数値は同じではありません)。
サーバーの負荷は、CPU の 20 ～ 40% のアイドル状態です。ほとんどのメモリが使用されていますが、それは正常であるとのことです。技術サポートは、スワッピングではないことを教えてくれました: 現在の様子は次のとおりです: (ただし、メモリ使用量は最終的には最大近くまで増加しますが、前回のように) 0k 使用、131064k フリー、981420k キャッシュ
SQL の最大接続数は 400 に設定されています。
では、なぜこれらの非常に遅いクエリを取得することがあるのでしょうか? .01 秒の場合もあれば、1 秒を超える場合もあるクエリの例を次に示しますtop。left、同盟としての guilds.name、rotate、what、player_data.first、player_data.last、ad AS gid、(aid=1892 AND aid>0) as am、フリート LIKE '%Turret%' AS turret、startLeft、startTop、endLeft , endTop, duration, startTime, movetype, moving,speed, defence, hp, lastAttack>1349740269 AS ra FROM Universe LEFT JOIN player_data ON Universe.uid=player_data.uid LEFT JOIN guilds ON aid=guilds.gid WHERE ( セクター='21_82 ' OR セクター='22_82' OR セクター='21_83' OR セクター='22_83' ) OR ( Universe.uid=1568425485 AND ( アップグレード=1 OR 建物=1 ))
はい、該当するすべての列にインデックスがあります。上記の 3 つのテーブルはすべて InnoDB テーブルです。つまり、テーブルはロックされておらず、行がロックされているだけです。
しかし、これは興味深いです: (新しいサーバー) Innodb_row_lock_time_avg 400 行ロックを取得する平均時間 (ミリ秒)。Innodb_row_lock_time_max 4,010 行ロックを取得する最大時間 (ミリ秒)。Innodb_row_lock_waits 31 行ロックを待機する必要があった回数。
行ロックを取得するのになぜそんなに時間がかかるのですか? 私の古いサーバーは行ロックをより速く取得できました: Innodb_row_lock_time_avg 26 行ロックを取得する平均時間 (ミリ秒)。
これが新しいサーバーです: Opened_tables 5,500 (わずか 2 時間で) 開かれたテーブルの数。開いているテーブルが大きい場合、テーブル キャッシュの値が小さすぎる可能性があります。テーブル キャッシュ 256 テーブル ロック待機 3,302 (わずか 2 時間)
これが古いサーバーです: Opened_tables 420
テーブルキャッシュ 64
それは理にかなっていますか？テーブルキャッシュを増やすと、状況が緩和されますか?
注: このサーバーには 1.5 GB あります
説明は次のとおりです。どこで使うか 1 SIMPLE player_data ref mainIndex mainIndex 8 jill_sp.universe.uid 1
1 SIMPLE ギルド eq_ref PRIMARY PRIMARY 8 jill_sp.player_data.aid 1