Memcached扩展策略

目前,我正在运行一个具有4个专用memcached服务器的生产环境,每个服务器都有48Gb的RAM(专用于memcache的42个)。 目前他们做得很好,但是stream量和内容都在增长,明年也一定会增长。

你对进一步扩展memcached的策略有什么想法? 你到现在为止做了什么:

你是否增加更多的内存,直到他们的全部容量 – 有效地加倍相同数量的盒子上的caching池? 或者是通过添加更多的相同的盒子和相同数量的RAM来水平缩放

目前的机器肯定可以处理更多的内存,因为它们的CPU负载很低,唯一的瓶颈就是内存,但是我想知道分配caching不是一个更好的策略吗,使事情变得更加冗余,并且尽量减less对caching的影响丢失一个盒子(丢失48Gb的caching而不是96Gb)。 你将如何处理这个决定?

我很想知道你正在移动的是什么,消耗超过100 GB的内存,而不是最大化你的网卡。

Memcache在机器之间进行相当线性的扩展,所以你必须要问的问题是:

  • 我的系统总线目前是否饱和?
    • 这可能与CPU使用率无关 – DMA传输不会以这种方式显示
  • 高密度内存与增加内存容量的新盒子相比有多昂贵?
    • 机架空间的全部成本,功耗等
  • 您是否发现1%的时间内有25%的caching和2%的时间有12.5%的caching有根本的区别? (随机select的失败率)。

缩放是10%直觉,70%衡量和适应,20%回头尝试别的东西。

加载他们,直到他们最大限度的出最薄弱的环节或停止成本效益。 他们可能已经或可能不在那里。

当我这样做的时候,通常在点盒子尺寸(机架空间成本),高密度芯片的费用和故障情况处理之间是平衡的。 这几乎总是以低于最大内存密度(以及通常不是最快的芯片)的configuration结束,正如你所提到的,这改善了节点故障的影响,并且通常使它们更具成本效益。 进行此select时需要考虑的一些成本/事项:

  • 节点成本(CPU / MEM /等)
  • 机架空间成本
  • pipe理费用/成本
  • 失败的场景(你想要做N + 1吗?)

我也做了升级到最大出箱,因为你也是在增长集群(通常是很小的时候),因为当你扩大规模给你更多的时间来做更大的build筑时,在短期内购买更多的内存可能会更便宜决定。