延迟增加 你遇到的延迟可能完全不同于规模的增长。CPU 资源不足是主要原因。 任务优先级被证明是错误的 可正常工作在轻负载情况下的任务优先级计划在重负载时会产生问题。尤其是，当有一个不好的流程控制机制时，高优先级的任务工作，低优先级的任务引起丢失和内存使用失效，因为低优先级的任务会获得比较少的执行机会。 队列的尺寸不够足够大 很多对象暗示更多并发操作将被产生，这意味着队列的大小需要增加。 启动时间更长 对象越多，需要越多的实践从磁盘加载到应用程序。 同步时间更长 对象越多，需要越长实践来同步各个对象之间的数据。 有不一样的测试在大配置中 因为搭建测试时间如此之多，所以实际测试搭时间少了。你不能在开发阶段访问一个大的系统，所以很可能你的设计将比一开始大。 操作需要更长时间如果某个操作被应用到每个对象，那么随着更多对象的增加，将会需要比以前更长的时间。表会更大，所以可能对一个数据量的数据很快的查询现在需要长得多的时间。 更多随机的失效在普通的操作中你可能看不到某种特定的失效。在规模增大以后响应将下降，ARP请求将下降，文件系统将显现出特定的错误，消息可能丢失，回复可能丢失，等等。 更大的窗口导致失败上规模意味着更有可能会失败，因为一切都需要更长的时间。对很小的数据集，某种交换数据的协议可能进行得飞快，这意味着它少有机会看到重启或超时，但对于更大规模，时间窗口增长意味着新的问题可能会第一次出现。 超时不具有伸缩性在数据集变大时，很少数据集时的超时将不会发出请求。再加上CPU匮乏的问题，你的代码可能甚至没有机会运行，超时进一步的失效了。 重试不具有伸缩性 在失败被声明前，应用没有办法选择重试的数量，因为它们没有支持做出决策的足够的信息。一秒钟4次重试好不好？为什么不20次呢？ 优先级继承大范围内的锁会存留更长时间，这给看到优先级继承问题创造了更好的机会。 消费模式的打破在一个规模你能从生产者获得所有的数据。但在另一个规模你用完了队列的空间/内存。一个这样的例子就是某种轮询器，它被用来从远程的队列轮询所有的数据 源，接下去再继续下一个队列。当队列上只有少量的项目时，这工作的很好。但可能某个属性变化会致使远程队列上的项目数量膨胀，轮询器会使某个节点耗尽内 存。 看门狗超时100% CPU负荷的情形会导致看门狗（监视器）的超时。在较小规模的系统中，这鲜有发生，但是对较大规模的不良设计可能会使之发生。 缓慢的内存泄漏成为快速泄漏在较小规模内存泄漏不会被人注意，但在较大规模它可能会变得非常显著。 失效的锁变得引人注目一个应该在适当位置的锁但未在，在较小规模系统可能不引人注意，因为线程可能永远也不会恰好在能引起问题的指令前放弃处理器。在较大规模的系统中，将有更多的抢占，这意味着会有更多的机会看到不同的线程同时访问数据。 死锁增加的可能性不同的调度模式使代码沿不同的路径运行，因此会有更大的遇到死锁的可能性。例如，当文件系统由于高CPU使用率而不能获得运行的机会，有时不知何故它会占用100%CPU而且不会再次运行。 时间同步的损失时间同步不具有一个非常高的优先级，因此随着CPU和网络资源变得稀缺，不同节点的时钟将会漂移。 记录器丢弃数据记录器会丢弃数据，是因为它的队列太小了，不能应对增长的负载，或者CPU太忙了，不能给记录器时间去分派日志数据。根据队列的大小和类型，这可能会引起OOM(内存不足Out Of Memory)。 定时器没有在正确的时间触发 一个繁忙的系统将无法在期望的时间触发定时器，这会在系统的其它部分级联的引起一个时间延迟。 ARP丢弃在CPU高负荷或者网络高负载期间，机器之间的ARP会丢弃。这意味着包会被发送到错误的条目，直到表格被更新，也有可能永远也不会更新。 |
