您在针对 Amazon Redshift 运行 SQL 查询时是否遇到过连接问题？您是否使用一种较新的可用 EC2 实例类型（C3、R3 等）？那么这篇文章也许能帮到你！ 我们最近发现从 EC2-Classic 实例到 EC2-VPC 中的 Redshift 集群运行查询时出现问题。我们执行了许多故障排除步骤，包括： 测试不同的 PSQL 客户端版本 在进程上运行 strace 尝试简单且常见的查询 经过上述步骤后，我们发现： 测试不同的 PSQL 客户端版本 => 没有区别 当在进程上运行strace时=>输入查询后，它陷入了WAIT状态 尝试更简单的查询 => 非常简单的查询，返回较少数量的行，即。SELECT count(*) from tablename，没有显示任何问题。 

那么原因可能是什么？从我们的推论中，我们意识到它必须进一步进入堆栈，并且在应用程序端没有任何内容。然后我们遇到了一个关于 ServerFault 的问题该问题似乎是我们遇到的同样的问题！ 答案讨 沙特阿拉伯电报号码数据 论了最大传输单元 (MTU)，并且讨论了根据您使用的环境和/或实例配置不同 MTU 设置的实例。 什么是 MTU？MTU 代表最大传输单元。它是以字节为单位测量的数据单元的最大大小。通常，在处理 MTU 时，以太网的默认设置为 1500。您可以通过运行以下命令来检查它（即使用设备 eth0 的 Linux 服务器示例）较新的 EC2 实例（c3、m3 等）配置了归类为“巨型帧”的 MTU 设置。

什么是巨型帧？“巨型帧”本质上是设置为大于 1500 的 MTU。根据您的应用程序/堆栈，它可以非常有用，可以提高数据传输效率。对于每一帧，它将发送更大的数据负载。这对于大文件传输之类的事情非常有用，因为每个帧都会占用 CPU 时间。如果您可以在相同（或更少）数量的帧中发送更大的数据集，这将显着提高两个设备之间的传输速率。 那么，如果我的 c3.large 实例设置为 MTU 9001，那就太好了，对吧？不幸的是，情况并非总是如此。原因是两个端点应以相同的速率进行通信，在本例中是 EC2 实例和 Redshift 集群。