高性能开发答案

【问题标题】：High Performance Development高性能开发
【发布时间】：2012-11-02 16:55:43
【问题描述】：

背景

我们一直在努力尝试为“高性能”应用程序提供解决方案。该应用程序基本上是一个高吞吐量的内存管理器，可以同步回磁盘。 “读取”和“写入”非常高，每秒大约 3000 个事务。我们尝试在内存中做尽可能多的事情，但最终数据会变得陈旧，需要刷新到磁盘，这就是一个巨大的“瓶颈”接踵而至的地方。该应用程序是多线程的，大约有 50 个线程。没有IPC（进程间通信）

尝试

我们最初是用 Java 编写的，它工作得很好，直到达到一定的负载，遇到瓶颈并且无法跟上。然后我们在 C# 中进行了尝试，也遇到了同样的瓶颈。我们使用非托管代码 (C#) 进行了尝试，虽然在初始测试中使用 MMF（内存映射文件）非常快，但在生产中，读取速度很慢（使用视图）。我们确实尝试了 CouchBase，但我们偶然发现了围绕高网络利用率的问题。这对我们来说可能是糟糕的配置！

额外信息：在我们的 Java 尝试（非 MMF）中，我们的线程与需要刷新到磁盘的信息队列构建到无法跟上“写入”的程度到磁盘。在我们的 C# 内存映射文件方法中，问题是 READS 非常慢，而 WRITES 工作完美。由于某种原因，视图很慢！

问题

所以问题是，您打算传输大量数据的情况；有人可以提供一种可能的方法或架构设计来提供帮助吗？我知道这似乎有点宽泛，但我认为高性能、高吞吐量的具体性质应该缩小答案范围。

谁能保证在这样的级别上使用 Couchbase、MongoDB 或 Cassandra？其他想法或解决方案将不胜感激。

【问题讨论】：

我不确定，但我认为当达到某个限制（但不是很大的数字，例如你现在使用的四分之一）时将其他线程中的数据写入磁盘，同时继续读取数据可以帮助。然后你可以释放这个内存并开始写其他的。我真的不知道答案我只是认为它可以提供帮助
不确定它是否适合您的数据传输问题，但加利福尼亚大学的一篇论文中显示了一种软件设计。 “SEDA：条件良好、可扩展的互联网服务架构”。 ACM ISBN 1-58113-389-8-1/01/10。它讨论了如何在多线程/分阶段系统中获得高吞吐量。
阿迪尔，谢谢我们正在这样做。 Coding.mof 将查看该论文，非常感谢。
如何在磁盘之间分片数据？此外，我个人不能保证 Mongo 在如此高的负载下的性能如何，但它们似乎非常重视速度，并提供了很多设施来尝试在多个服务器/磁盘之间分配读/写负载。跨度>
你说你已经尝试过 Java/C#/Unmanaged C# 并且一切都很慢。听起来架构和开发环境不是这里的问题，而是您只是试图在当前硬件上做太多事情。你需要一些强大的力量，我建议你在一些重要的硬件上花一些钱。

标签： c# performance design-patterns

【解决方案1】：

首先，我想明确一点，我几乎没有（如果有的话）构建高性能、可扩展的应用程序的经验。

Martin Fowler 对 LMAX 架构进行了描述，该架构允许应用程序在单个线程上每秒处理大约 600 万个订单。我不确定它是否可以帮助您（因为您似乎需要移动大量数据），但也许您可以从中获得一些想法：http://martinfowler.com/articles/lmax.html

该架构基于Event Sourcing，通常用于提供（相对）简单的可扩展性。

【讨论】：

这看起来很有希望，但需要一些时间才能获得“概念”。但是会看看我们是否可以从 Disruptor 模式中得到一些东西。
是的，这并不能真正解决我们的问题。破坏者模式更关注何时有大量工作（工作步骤）要完成，以及工作之间的争用（例如，在队列中发现的争用）。我们的问题出在一个独立的队列中，无法有效地写入磁盘，而队列没有达到无法管理的大小。

【解决方案2】：

大量数据和磁盘访问。我们在谈论什么样的磁盘？如果您处理多个文件，HDD 往往会花费大量时间来移动磁头。（不过，如果您使用 SSD，这应该不是问题。）此外，您应该利用内存映射文件以页面大小的块进行管理的事实。如果可能，数据结构应与页面边界对齐。

但无论如何，您必须确保您知道什么瓶颈是什么。例如，如果您实际上由于线程同步而浪费时间，那么优化数据结构就没有多大帮助。而且，如果您使用的是 HDD，页面对齐可能不如将所有内容以某种方式填充到单个文件中那样有帮助。因此，请使用适当的工具来确定哪些刹车仍在阻碍您。

使用通用数据库实现可能不会像您希望的那样帮助您。毕竟，它们是通用的。如果性能确实是个大问题，考虑到您的要求的特殊实现可能会胜过这些更通用的实现。

【讨论】：

这样的分析工具，例如对于 Java 是 JProfiler
你好沃姆博，谢谢。好的提示；我之前研究过SSD路线，但不幸的是，尽管硬件制造商更新了算法以防止这种情况发生，但仍然存在限制读写的“单元”问题；我们的处理速度会在短时间内杀死磁盘。您能否详细说明“与页面边界对齐的数据结构”？为什么会有好处？
coding.mof，yip 使用 IBM 产品和 Microsoft 完成了分析工作。谢谢
@DaneBalia：您可能想分享您在分析中发现的内容。
Wormbo 在说“确保你知道瓶颈是什么”时一针见血。根据我们的分析，瓶颈首先揭示了“jvm 不释放内存”的问题。经过进一步的预期，我们注意到队列没有释放对象，这直接指向磁盘无法跟上 (I/O)。

【解决方案3】：

如果您想快速避免持久性和写入队列，并在读取时使用内存疮/缓存。

语言与此无关。\

【讨论】：

不确定是否投反对票 .. 语言通常相差 10-30% 左右（有些相差 50%）。但是到磁盘的 IO 比内存慢 10K。看看 Lmax 最小化 IO 并在单台机器上执行 6M 事务/秒。使用持久队列的常见用法也是如此，我保证您的吞吐量将减少至少 10 倍。而且您对死信队列进行了可怕的手动维护。现在看看语言数据与持久性成本的比较。这并不意味着你没有持久性，但将其最小化会有所帮助..