监控器超时

　　CPU的情况将导致监控器超时。这在小规模系统中很少发生，但是在设计不良的较大型规模系统中会发生。

　　慢速的内存泄露变成快速泄露

　　较小规模系统中不大引人注意的一个内存泄露问题在较大规模的系统中变得影响重大。

　　原本未注意到的锁问题变得引人注目

　　应该在适当的地方使用锁。但是如果使用不当，该问题在较小规模的系统中也许会被人忽略。因为持有锁的线程会在另一段产生问题的指令运行前释放掉它长期占用的CPU使用权。但是在大规模系统中将会有更多的CPU抢占，这意味着将会有更多的机会看到不同线程对同一数据的并发访问。

　　死锁的机会变大

　　不同的调度模式将以不同的路径运行代码，所以遭遇死锁的机会也更大。举个例子，当CPU使用率很高时文件系统没有机会得到运行，而当以某种方式打破这一情形时，文件系统随即占用了的CPU使用权却再也没有运行。

　　时间同步变糟

　　时间同步任务的优先级并不高，所以当可用的CPU和网络资源变得更少时，不同节点的时钟将出现偏差。

　　日志数据丢失

　　由于日志队列容量过小从而无法应对增长的负载或是因为CPU太忙而没有时间片给予日志记录器分发日志数据，都将可能导致日志记录器开始丢失数据。根据队列的容量和类型不同，或将导致内存不足。

　　定时器没有在准确的时间触发

　　一个繁忙的系统无法在期望的时间触发定时器，这将导致系统的其余部分出现一连串的延迟。

　　ARP数据包丢失

　　在高负载的CPU或网络环境中，在主机间传送的ARP数据包可能会丢失。这是因为数据包被发送到了错误的网卡，一旦更新完路由表，将不会再发生这种情况。

　　文件描述符限制

　　在一个硬件上通常都会有一个固定的文件描述符数量上限。系统设计必须将所需的大文件描述符数量限制在该上限以内。如果取用的套接字描述符超过了文件描述符的可用池，那么涉及到大量连接(ftp，com，启动，客户端等等)的设计将会产生问题。规模化将可能造成描述符需求数量的峰值。当规模增长时，描述符泄露将会耗尽可用池。

　　套接字缓冲限制

　　系统都会为每个套接字分配一定量的缓冲空间，大量的套接字可能会减少系统整体的可用内存。随着规模增长，消息丢失也开始增长。这是因为接收消息的缓冲空间数量不足从而跟不上负载的压力。这同样也和优先级相关，因为一个任务没有足够的优先级从套接字中读取数据。较低优先级的任务可能会被发送者一方某个高优先级任务的消息所淹没。

　　启动镜像服务限制

　　一个节点的启动卡同一时间可服务的限制为X。FTP服务器基础设施必须限制启动卡服务的数量，否则将造成该节点发生CPU饥饿。

　　消息次序混乱

　　你的消息系统在高负载压力下传递消息的次数可能会发生混乱，这对非幂等的操作来说将产生问题。

　　协议的弱点

　　除非小心谨慎的创建应用层协议，否则规模的增长将带来大量的问题。

　　连接限制

　　一个某种类型的中央服务器在应付十个客户端的情况下也许绰绰有余。但是当有一千客户端的时候，它将无法满足到响应时间的需求。在这种情况下，平均响应时间将根据客户端数量成线性增长，我们称该复杂度为O(N)(“order N”)，但是若是其他更差的复杂度将会产生问题。举个例子，我们希望一个网络中的N个节点可以互相通信，我们可以让每个节点链接到一台中央交换服务器，这将需要O(N)条连接线。或者我们在每两个节点之间直接建立连接，这将需要O(N^2)条连接线(确切的数字或公式通常不重要，这只跟涉及到的N的高次有关)。

　　分层架构

　　这是一个很好的总结，所以我在此处引用了它：基于分层的架构从来不是用来构建低延迟，高吞吐量应用的。对于多层架构，究其本质是被创建用于解决昨天的历史问题的。从客户端-服务器时代过渡到互联网时代，它是可伸缩性方面完美的解决方案。

　　该问题域是关于如何扩展应用的规模以支持成百上千的用户。然而的我们都知道对于该问题的解决方案是n层架构。在可伸缩性的维度上我们选择了通过负载均衡的表现层，事实上这的确解决了问题。然而，当今时代，问题发生了演变。这些日子里，很多行业的问题已不再是仅仅关于提升用户体验了，数据量也成为了一个问题。

　　多处理器性能问题

　　当处理器被要求在大量无关工作间切换时，原本强大的硬件缓存加速常常会失效。