阿里云ECS
云服务器ECS（Elastic Compute Service）是阿里云提供的性能卓越、稳定可靠、弹性扩展的IaaS（Infrastructure as a Service）级别云计算服务。云服务器ECS免去了您采购IT硬件的前期准备，让您像使用水、电、天然气等公共资源一样便捷、高效地使用服务器，实现计算资源的即开即用和弹性伸缩。阿里云ECS持续提供创新型服务器，解决多种业务需求。
云服务器选择
云服务器又叫云计算服务器或云主机。云服务器使用了云计算技术，云服务器整合了数据中心三大核心要素：计算、网络与存储。云服务器基于集群服务器技术，虚拟出多个类似独立服务器的部分，云服务器具有很高的安全稳定性。云服务器是新时代产物，大多数中小企业对云服务器了解并不深刻，在选择云服务器过程中存在很多问题，可能会导致自己的业务在运行过程中出现故障。云服务器更具有安全性。因为云服务器具有防ARP攻击和MAC欺骗功能，云服务器可进行快照备份，云服务器保证数据永久不丢失。而且云服务器比传统的物理服务器更加可靠，因为云服务器是基于服务器集群的，因此云服务器具有较高的硬件冗余，云服务器能大大降低故障发生率。云服务器还具有故障自动迁移功能，如果一台云服务器出现故障，云服务器上面的应用会自动迁移到其他云服务器上面，云服务器从而保证业务能够正常运行。云服务器能实现快照备份，当主机出现故障时，云服务器能够一键恢复故障前的所有数据。
使用中的问题
使用过程中也遇到了好多的问题，也进行记录和整理，和大家一起分享。
问题一：Linux实例NAT哈希表满导致ECS实例丢包
注意：此处涉及的内核参数如下。
net.netfilter.nf_conntrack_buckets
net.netfilter.nf_conntrack_max
问题现象
Linux实例出现间歇性丢包，无法连接实例。请参见ping 丢包或不通时链路测试说明，通过tracert、mtr等工具排查，外部网络未见异常。同时，在系统日志中重复出现大量类似以下错误信息。
Feb 6 16:05:07 i-*** kernel: nf_conntrack: table full, dropping packet.
Feb 6 16:05:07 i-*** kernel: nf_conntrack: table full, dropping packet.
Feb 6 16:05:07 i-*** kernel: nf_conntrack: table full, dropping packet.
Feb 6 16:05:07 i-*** kernel: nf_conntrack: table full, dropping packet.
原因分析
ip_conntrack是Linux系统内NAT的一个跟踪连接条目的模块。ip_conntrack模块会使用一个哈希表记录TCP协议“established connection”记录，当这个哈希表满之后，便会导致“nf_conntrack: table full, dropping packet”错误。Linux系统会开辟一个空间，用于维护每一个TCP链接，这个空间的大小与nf_conntrack_buckets、nf_conntrack_max参数相关，后者的默认值是前者的4倍，所以一般建议调大nf_conntrack_max参数值。
说明：系统维护连接比较消耗内存，请在系统空闲和内存充足的情况下调大nf_conntrack_max参数，且根据系统的情况而定。
解决方法
登录Linux实例，如何登录Linux实例请参见使用管理终端连接Linux实例。
执行以下命令，编辑系统内核配置。
vi /etc/sysctl.conf
修改哈希表项最大值参数net.netfilter.nf_conntrack_max为655350。
修改超时参数net.netfilter.nf_conntrack_tcp_timeout_established为1200，默认情况下超时时间是432000秒。
执行sysctl -p命令，使配置生效。
问题二：报“Time wait bucket table overflow”错误
注意：此处涉及的内核参数为net.ipv4.tcp_max_tw_buckets。
问题现象
Linux实例的/var/log/messages日志信息全是类似“kernel: TCP: time wait bucket table overflow”的报错信息，提示“time wait bucket table”溢出，系统显示类似如下。
Feb 18 12:28:38 i-*** kernel: TCP: time wait bucket table overflow
Feb 18 12:28:44 i-*** kernel: printk: 227 messages suppressed.
Feb 18 12:28:44 i-*** kernel: TCP: time wait bucket table overflow
Feb 18 12:28:52 i-*** kernel: printk: 121 messages suppressed.
Feb 18 12:28:52 i-*** kernel: TCP: time wait bucket table overflow
Feb 18 12:28:53 i-*** kernel: printk: 351 messages suppressed.
Feb 18 12:28:53 i-*** kernel: TCP: time wait bucket table overflow
Feb 18 12:28:59 i-*** kernel: printk: 319 messages suppressed.
执行以下命令，统计处于TIME_WAIT状态的TCP连接数，发现处于TIME_WAIT状态的TCP连接非常多。
netstat -ant|grep TIME_WAIT|wc -l
原因分析
参数net.ipv4.tcp_max_tw_buckets可以调整内核中管理TIME_WAIT状态的数量。当实例中处于TIME_WAIT状态，及需要转换为TIME_WAIT状态的连接数之和超过net.ipv4.tcp_max_tw_buckets参数值时，messages日志中将报“time wait bucket table” 错误，同时内核关闭超出参数值的部分TCP连接。您需要根据实际情况适当调高net.ipv4.tcp_max_tw_buckets参数，同时从业务层面去改进TCP连接。
解决方法
执行以下命令，统计TCP连接数。
netstat -anp |grep tcp |wc -l
执行以下命令，查询net.ipv4.tcp_max_tw_buckets参数。如果确认连接使用很高，则容易超出限制。
vi /etc/sysctl.conf
根据现场情况，增加net.ipv4.tcp_max_tw_buckets参数值的大小。
执行sysctl -p命令，使配置生效。
