代码之家  ›  专栏  ›  技术社区  ›  gregmac

在处理阻塞进程时管理线程和内存使用情况

  •  3
  • gregmac  · 技术社区  · 14 年前

    有一个API负责最后的数据库部分,它为单个设备获取多个条目(在后台,这也会进行一些查找以在数据库中查找ID,因此一次为单个设备处理多个条目意味着只进行一次查找,而不是每个条目一次)。

    为此,我有一个包含几个部分的程序:

    • 解析文件,将数据提取到一组公共数据对象中。
      • 这是一个线程化进程,每个文件有一个线程,将数据添加到线程安全的集合中
      • 在加载每个文件时,其DB条目被标记为“进行中”
    • 将对象保存到数据库
      • 另一个线程进程,它提取给定设备的所有对象,然后告诉数据API保存它们。
      • 一旦单个文件中所有设备的保存成功(或者如果有失败),原始文件的DB条目将被标记为success/failed

    我的问题是:管理何时解析文件、使用多少线程、有多少RAM等的最佳方法是什么?

    • 通过对每个设备进行更多的数据分组,系统的整体效率得到了提高

    那么,我如何知道何时解析文件以确保它能以最快的速度运行,而不会因为使用太多的RAM而影响性能呢?

    2 回复  |  直到 12 年前
        1
  •  1
  •   Henk Holterman    14 年前

    似乎您有一个非常受I/O限制的系统(输入端的文件和输出端的DB)。我没有看到CPU密集型部件。

    显而易见的优化已经存在:将大量传入的文件打包,并将每个设备的数据分组。成本是内存消耗和数据库更新的延迟。你需要参数。

    作为第一个想法,我会把它设置在3个由有界队列连接的街区。这些队列将让任何“不堪重负”的组件限制其供应商。

    块2:1个线程来组织和分组数据。决定设备数据何时应进入数据库

    块3:1+线程将数据推送到数据库。

    这些块给了这个系统一些灵活性。有限的队列允许您控制资源消耗。请注意,应该参数化块2以调整块大小。

        2
  •  0
  •   Mikael Svenson    14 年前

    dispatcher可以不断监视可用的系统内存和cpu使用情况(例如使用性能计数器api)。

    只要有足够的空闲内存或足够低的cpu负载,就启动一个新线程。您必须进行一些测试,以找到应用程序的最佳阈值。

    另外,如果您是在32位上运行,那么一个进程只能使用大约800mb的ram,然后才会出现内存不足异常,因此您可能也需要考虑到这一点。

    程序流程如下:

    1. 当达到内存限制(和/或cpu限制)时,将它们批处理到dbapi
    2. 当您批处理到dbapi时,内存被释放,新文件可以被处理-转到1