我从事运营工作，因此是我们某些服务部署的主要决策者。我使用的分布式应用程序涉及多种类型的“服务”，其中一些服务比其他服务要求更高。我说“服务”是因为我不想造成混淆——这些是来自同一个 C++ 可执行文件的多个实例，只是使用不同的参数来告诉 exe 启动哪种服务类型。
传统上，我们过去部署服务的方式是一个1:1比率service-counts:cores——cores具体如下。不是hyper-threaded cores。
例子！
- 具有物理 CPU 的主机
4，每个 CPU 都有4内核。 - 在
/proc/cpuinfo这个主机中显示为具有32 processors--这不是我cores从这里开始说的意思。我说的是4cpus x 4cores == 16 cores总数。
我们的系统不是多线程的，因为服务同时在同一场景上并行工作。它是分布式的，但不是螺纹式。我们的服务不会跨线程彼此共享太多内存（我认为主要是数据库信息）。这可能是需要了解的重要信息。
我的问题是，考虑到我们的软件在技术上并不螺纹式因为它不会尝试利用线程计算（它主要是分散式处理负载），我是否应该关心service:core比率？我觉得这浪费了一堆可以被其他服务占用的未使用的周期。
例子！
- 主机16核，运行16个进程：
Load average: 2.94 2.96 3.01 - 服务负载约为
40%, 每个（此框中有 16 个相同类型的服务）
尽管平均负载相对较低，但我们仍然遵循1:1.我对内存总线争用的复杂性（即同一核心上的线程将争用访问同一内存总线）不太了解，但考虑到我们应该能够在该主机上托管更多进程Load average与16系统上的核心数量相差甚远。
问题！
service:core当提出一种主要忽略比率，而是主要关注服务负载和盒子负载作为 KPI 的新策略时，我应该考虑什么？对于此类应用程序，我是否应该考虑更详细的细节？
答案1
平均负载之外的其他因素包括内存使用、上下文切换以及磁盘或网络 I/O（或临时端口压力，取决于服务使用端口的无偿程度），尤其是当更多服务捆绑在单个主机上时。此外，当每日、每周或每月的 cron 作业启动时，100% 加载的系统可能会陷入灾难（有趣的事实：OOM 杀手通常会sshd在凌晨 04:00 由于 cron 每日任务而杀死 ），因此留下一些备用容量可能会很方便。
你们有什么类型的服务监控？如果您有服务的延迟和吞吐量指标，那么您可以测试不同的配置并将这些结果与当前的基准案例进行比较。 （如果情况变得更糟，那么你可以去找一下瓶颈在哪里......）
另外，如果单个系统上堆积了更多数据，那么与您当前的设置相比，如果该盒子着火，恢复情况有多糟糕？