# io/socket/sql/client\$1connection
<a name="ams-waits.client-connection"></a>

`io/socket/sql/client_connection` イベントは、スレッドが新しい接続を処理している最中に発生します。

**Topics**
+ [サポート対象エンジンバージョン](#ams-waits.client-connection.context.supported)
+ [Context](#ams-waits.client-connection.context)
+ [待ち時間増加の考えられる原因](#ams-waits.client-connection.causes)
+ [アクション](#ams-waits.client-connection.actions)

## サポート対象エンジンバージョン
<a name="ams-waits.client-connection.context.supported"></a>

この待機イベント情報は、以下のエンジンバージョンでサポートされています。
+ Aurora MySQL バージョン 2 および 3

## Context
<a name="ams-waits.client-connection.context"></a>

イベント`io/socket/sql/client_connection` は、受信する新規クライアント接続を処理するためのスレッド作成で mysqld がビジー状態であることを示します。このシナリオでは、スレッドが割り当てられるのを接続が待っている間、新しいクライアント接続リクエストの対応処理が遅くなります。詳細については、「[MySQLサーバー (mysqld)](AuroraMySQL.Managing.Tuning.concepts.md#AuroraMySQL.Managing.Tuning.concepts.processes.mysqld)」を参照してください。

## 待ち時間増加の考えられる原因
<a name="ams-waits.client-connection.causes"></a>

この イベントが通常よりも多く表示され、パフォーマンスの問題を示している可能性がある場合、典型的な原因は次のとおりです。
+ アプリケーションから Amazon RDS インスタンスへの新しいユーザー接続が突然増加しています。
+ ネットワーク、CPU、またはメモリがスロットリングされているため、DB インスタンスは新しい接続を処理できません。

## アクション
<a name="ams-waits.client-connection.actions"></a>

`io/socket/sql/client_connection` がデータベースアクティビティを占領している場合でも、必ずしもパフォーマンスの問題を示すわけではありません。アイドル状態でないデータベースでは、待機イベントは常に最上位にあります。パフォーマンスが低下したときにのみ動作してください。待機イベントの原因に応じて、異なるアクションをお勧めします。

**Topics**
+ [問題のあるセッションとクエリを特定する](#ams-waits.client-connection.actions.identify-queries)
+ [接続管理のベストプラクティス](#ams-waits.client-connection.actions.manage-connections)
+ [リソースがスロットリングされている場合にインスタンスをスケールアップする](#ams-waits.client-connection.upgrade)
+ [上位ホストと上位ユーザーを確認する](#ams-waits.client-connection.top-hosts)
+ [performance\$1schema テーブルのクエリを実行する](#ams-waits.client-connection.perf-schema)
+ [クエリのスレッド状態を確認する](#ams-waits.client-connection.thread-states)
+ [リクエストとクエリを監査する](#ams-waits.client-connection.auditing)
+ [データベース接続をプールする](#ams-waits.client-connection.pooling)

### 問題のあるセッションとクエリを特定する
<a name="ams-waits.client-connection.actions.identify-queries"></a>

DB インスタンスにボトルネックが発生している場合、ユーザーの初期のタスクは、その原因となるセッションとクエリを見つけることになります。便利なデータベースブログ記事は、[Performance Insights を使用した Amazon Aurora MySQL ワークロードの分析](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/)を参照してください。

**ボトルネックの原因となっているセッションとクエリを特定するには**

1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。

1. ナビゲーションペインで、[**Performance Insights**] を選択します。

1. DB インスタンスを選択します。

1. **データベース負荷**で、**待機でスライス**を選択します。

1. ページの下部で **トップ SQL** を選択します。

   リストの上部にあるクエリは、データベースで最大のロードを引き起こしています。

### 接続管理のベストプラクティス
<a name="ams-waits.client-connection.actions.manage-connections"></a>

接続を管理するには、次の戦略を検討してください。
+ 接続プーリングの使用

  必要に応じて、接続数を徐々に増やすことができます。詳細については、ホワイトペーパーの [Amazon Aurora MySQL データベース管理者ハンドブック](https://d1.awsstatic.com/whitepapers/RDS/amazon-aurora-mysql-database-administrator-handbook.pdf)を参照してください。
+ リーダーノードを使用して、読み取り専用トラフィックを再配布します。

  詳細については、「[Aurora レプリカ](Aurora.Replication.md#Aurora.Replication.Replicas)」および「[Amazon Aurora エンドポイント接続](Aurora.Overview.Endpoints.md)」を参照してください。

### リソースがスロットリングされている場合にインスタンスをスケールアップする
<a name="ams-waits.client-connection.upgrade"></a>

次のリソースでスロットリングの例を探してください。
+ CPU

  Amazon CloudWatch メトリクスで CPU 使用率が高くなるかどうかを確認してください。
+ Network

  CloudWatch メトリクス `network receive throughput` および `network transmit throughput` の値の増加を確認します。インスタンスがインスタンスクラスのネットワーク帯域幅制限に達した場合は、RDS インスタンスをより高いインスタンスクラスタイプにスケールアップすることを検討してください。詳細については、「[Amazon Aurora DB インスタンスクラス](Concepts.DBInstanceClass.md)」を参照してください。
+ 解放可能なメモリ 

  CloudWatch メトリクス `FreeableMemory` のドロップをチェックします。また、拡張モニタリングをオンにすることを検討してください。詳細については、「[拡張モニタリングを使用した OS メトリクスのモニタリング](USER_Monitoring.OS.md)」を参照してください。

### 上位ホストと上位ユーザーを確認する
<a name="ams-waits.client-connection.top-hosts"></a>

Performance Insights を使用して、上位ホストと上位ユーザーを確認します。詳細については、「[Performance Insights ダッシュボードを使用してメトリクスを分析する](USER_PerfInsights.UsingDashboard.md)」を参照してください。

### performance\$1schema テーブルのクエリを実行する
<a name="ams-waits.client-connection.perf-schema"></a>

現在の接続数と合計接続数の正確な数を取得するには、`performance_schema` テーブルをクエリします。この手法では、多数の接続の作成を担当する出典ユーザーまたはホストを特定します。例えば、次の通り `performance_schema` テーブルをクエリします。

```
SELECT * FROM performance_schema.accounts;
SELECT * FROM performance_schema.users;
SELECT * FROM performance_schema.hosts;
```

### クエリのスレッド状態を確認する
<a name="ams-waits.client-connection.thread-states"></a>

パフォーマンスの問題が継続する場合は、クエリのスレッド状態を確認してください。`mysql` クライアントで、次のコマンドを実行します。

```
show processlist;
```

### リクエストとクエリを監査する
<a name="ams-waits.client-connection.auditing"></a>

ユーザーアカウントからのリクエストとクエリの性質を確認するには、AuroraAurora MySQL アドバンスト監査を使用します。監査を有効にする方法については、[Amazon Aurora MySQL DB クラスターでのアドバンストな監査の使用](AuroraMySQL.Auditing.md) を参照してください。

### データベース接続をプールする
<a name="ams-waits.client-connection.pooling"></a>

接続管理に Amazon RDS プロキシを使用することを検討してください。RDS プロキシーを使用すると、アプリケーションでデータベース接続をプールおよび共有して、アプリケーションのスケール能力を向上させることができます。RDS Proxy は、アプリケーション接続を維持しながらスタンバイ DB インスタンスに自動的に接続することで、データベースの障害に対するアプリケーションの耐障害性を高めます。詳細については、「[Amazon RDS Proxy for Aurora](rds-proxy.md)」を参照してください。