AWS Athenaの同時実行制限：送信されたクエリの数と実行中のクエリの数
AWS Athenaの制限 によると、一度に同じタイプのクエリを20個まで送信できますが、これは弱い制限であり、要求に応じて増やすことができます。私が使う boto3 Athenaと対話するために、私のスクリプトは16のCTASクエリを送信します。各クエリは完了するまで約2分かかります。 AWSアカウントでは、Athenaサービスを使用しているのは私だけです。ただし、コンソールを使用してクエリの状態を見ると、すべての状態がRunningであるにもかかわらず、実際に実行されているクエリは数個（平均5個）しかないことがわかります。これは通常、Athenaの履歴タブに表示されるものです。
Athenaにクエリを送信した後、サービス全体の負荷と受信リクエストの量に基づいてリソースを割り当て、クエリを処理することを理解しています。しかし、私はそれらを異なる曜日と時間に実行しようとしましたが、それでも約5つのクエリが同時に実行されることになります。
だから私の質問はこれがどうあるべきかということですか？もしそうなら、およそ15のクエリがアイドリングし、利用可能なスロットを待機している場合に、最大20のクエリを送信できるという点は何ですか。
アップデート2019-09-26
セクション AWS Glueカタログ構成プロパティ のあるプレストドキュメントのHive CONNECTORを偶然見つけました。見えます
Hive.metastore.glue.max-connections：Glueへの同時接続の最大数（デフォルトは5）。
これは私の問題と何か関係があるのかと思いました。私が理解しているように、AthenaはAWS Glueデータカタログをメタストアとして使用するように構成されたEMRクラスターで実行される単なるPrestoです。
したがって、AthenaのEMRクラスターがGlueへの同時接続にデフォルト値を使用するという事実から問題が発生した場合はどうなりますか？これは5であり、私の場合、実際に実行されている同時クエリの数（正確には）の正確な数です。
アップデート2019-11-27
Athenaチームは最近、Athenaに多数の新機能を導入しました。 QUEUEDはしばらくの間enum状態になっていますが、現在まで使用されていません。そのため、履歴タブでクエリの状態に関する正しい情報を取得しましたが、他のすべては同じままです。
また、同様の問題がある another post が公開されました。
Athenaサービスに対するアカウントの制限はSLAではなく、クエリスケジューラの優先事項です。
使用可能な容量によっては、他のクエリを実行していない場合でも、クエリがキューに入れられることがあります。高い同時実行制限の意味するところは内部的なものであり、変更される可能性がありますが、私の経験では、クエリスケジューラがクエリを処理する際の優先順位と考えるのが最善です。すべてのアカウントのクエリは同じサーバープールで実行され、全員がクエリを実行している場合、容量は残りません。
同じクエリを何度も実行して、時間の経過とともにクエリ実行メトリックをプロットすることで、実際の動作を確認できます。これらのメトリックが大きく変化し、クエリがキューの一番上にキューイングされる時間にスパイクがあることに気づくでしょう。 1時間ごと–他の全員がスケジュールされたクエリを実行しているとき。