2011-08-18 9 views
6

私は非常に高いCPUスパイクをmysqldプロセスで処理しています(100%を上回り、ある時点で300%を見たこともあります)。私の負荷平均は約0.25、.34、.28です。MySQL高いCPU使用率と永続的なリンク

私はこの問題については、この偉大な記事を読む:行うには、メインのもののMySQL high CPU usage

一つは、持続的な接続を無効にしています。だから私はphp.iniとmysql.allow_persistent = onmysql.max_persistent = -1をチェックした。これは無制限を意味する。

これは念のために何かを変更する前に、私のためにいくつかの質問を提起:

  1. 私のmysqldプロセスが100%を超えるスパイクされている場合はすべてのカップル秒が私の負荷平均は彼らが、その後大きくすべきではありませんか?
  2. 永続リンクを無効にすると、スクリプトはそのまま機能し続けますか?
  3. これをオフにしてphpをリロードすれば、現在のユーザーには何を意味するのですか?多くのアクティブユーザーが存在するためです。

EDIT:

CPU情報:Core2Quadのq9400 2.6 GHzの

答えて

8

永続的な接続では、CPUを単独で使用することはありません。何も接続を使用していない場合、アイドル状態になり、わずかのメモリしか消費しません。

平均負荷は平均値です。 0%から100%の間で1秒に10回交替するプロセスがある場合、平均負荷は0.5になります。彼らは長期的な永続的な高CPUを把握するのに適しているが、その性質上、スパイクの兆候を隠す/消滅させる。

通常、mysqlと永続的に接続する必要はありません。 MySQLには比較的高速の接続プロトコルがあり、永続的な接続を使用することで時間を節約することは、ごくわずかです。欠点は、接続が永続的になると、一貫性のない状態になる可能性があることです。例えば接続を使用しているアプリケーションが突然停止した場合、MySQLはそれを認識せず、クリーンアップを開始します。つまり、アプリケーションによって作成されたサーバーサイド変数、ロック、トランザクションなどは、アプリケーションがクラッシュしたときの状態になります。

接続が別のアプリで再利用されると、シンクの洗面所や汚れていないトイレに汚れた食べ物が含まれています。それはトランザクション/ロックが絡んでいるためにデッドロックを引き起こす可能性が非常に高い - 新しいアプリはそれらについて知りませんし、古いアプリはもはやそれらを放棄することはもうありません。

+0

トイレの類推のためにありがとう:)私のPHPの永続的なリンクオプション。iniは問題ありませんが、mysql_pconnectを使用しないでください。 – bMon

+0

負荷平均の心配はどこから始めるべきですか? 1.0以上、5.0以上、20.0? – bMon

+2

永続的な接続で何も間違っていることはありません。あなたのスクリプトのいずれかが正しく処理されていれば、私のパンツをロードしたことになります。もしスクリプトが死んでしまった場合は、mysqlがクリーンアップできるように接続をクローズしてください。 –

0

スパイクが細かいです。これはMySQLの仕事です。あなたの負荷平均が適切と思われます。

永続リンクを無効にするということは、単にスクリプトがデータベースへの既存の接続を使用できないことを意味します。私はこれを無効にすることをお勧めしません。最低でも、それらを無効にしたい場合は、MySQLではなくアプリケーションで行います。これにより、状況によっては負荷がわずかに増加することさえあります。

最後に、DBの永続性は、サイトのユーザー(一般的にはユーザー)とは関係ありません。ユーザーはリクエストを行い、一度すべてのページ・リソースがロードされると、それは次のリクエストまでロードされます。 (いくつかの特定のケースを除いて)いずれにしても、リクエストが発生している間も、スクリプトは引き続きDBに接続されます。