【问题标题】:Java Multi-Threading Performance ImprovementJava 多线程性能改进
【发布时间】:2014-03-22 13:33:54
【问题描述】:

我的应用程序使用单线程完成一项任务大约需要 200 毫秒。我们在 MQ 上附加了侦听器,它将拾取消息并进行处理。

当我将 MDB 线程数增加到 5 时,处理队列中的 5 条消息所需的处理时间应该在 200 毫秒左右,但大约需要 600 毫秒。可能是什么问题或任何改进建议它。

我们有文件 I/O ,数据库插入更新操作在进程之间参与。

【问题讨论】:

  • 代码在哪里?您正在使用什么处理器(nof cores)?如果没有这些信息,我们将无法为您提供帮助。
  • 如果您的建议属实,您可以简单地创建 1000 个线程并在 200 毫秒内处理 1000 条消息。情况并非如此,因为您没有 1000 个内核允许并行执行所有线程,并且因为所有任务都访问其他共享资源:内存、磁盘、另一个同步对象等。让我们将磁盘作为一个例子:它不能同时在 5 个不同的位置写入。所以每个线程都必须等待磁盘可用。
  • 它是一个 8 核处理器。
  • 视情况而定。是否正在执行磁盘/内存 I/O?网络通讯?排队和出队消息、产生线程和协调线程池的开销?在代码中的任何一点同步?是否使用了不一定同时服务 5 个请求的共享资源?
  • @saurabhgoyal 不,每个线程都会获得一些时间来访问磁盘,这也会增加总时间(因为线程之间的切换也需要一些时间)。但归根结底,它归结为物理定律:如果您写入磁盘的单个盘片,则使用单个写入头,它一次只能写入一个位置,并且每次位置都必须移动变化。用于将信息传输到磁盘的总线带宽也受到限制。

标签: java multithreading file mq


【解决方案1】:

如果您的任务仅受 CPU 限制,则它可能会接近线性扩展至系统中的 CPU(内核)数量。但是,正如您所说,您正在使用共享资源,这可能是您的问题的原因。尝试分析您的应用程序,看看那里实际发生了什么。

【讨论】:

  • 这不是真的。只有当且仅当应用程序易于并行化时,您才能接近线性缩放,但情况并非总是如此。
  • 我的陈述中有什么不实之处?
  • 不受 CPU 限制并不意味着自动线性缩放。比赛条件、同步等怎么样。
  • 在应用程序中使用共享内存时确实如此。当您使用消息传递(如提问者提到的)时,您不必为此烦恼。
【解决方案2】:

您是与队列管理器共享 MQ 连接,还是每个线程都有自己与队列管理器的连接?

【讨论】:

    猜你喜欢
    • 2011-12-15
    • 2012-08-14
    • 1970-01-01
    • 2014-05-25
    • 1970-01-01
    • 1970-01-01
    • 2021-09-08
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多