River
  1. River
  2. RIVER-171

Should use one sync to commit multiple pending Outrigger log records to disk

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: jtsk_1.1
    • Fix Version/s: None
    • Component/s: com_sun_jini_outrigger
    • Labels:
      None
    • Bugtraq ID:
      5026860

      Description

      Bugtraq ID 5026860

      All operations on Outrigger's log file are serlialized by a single
      lock. Currently each durable operation on a persistent Outrigger will
      result in two syncs (we could this down to one, see RIVER-128), this means that
      outrigger's overall througput is limited by the cost of these syncs
      (e.g. if the two syncs cost 25ms we can only get 40 ops / s).

      If we queued up disk ops, and then used a single queue thread to
      commit them to disk (while the queuing thread waited on completion of
      the commit to disk) when the queue had multiple pending operations we
      could write them all out under one set of syncs. This would not
      improve the best case latency for durable operations, but should allow
      for higher throuput when running multi-threaded work loads.

        Issue Links

          Activity

          Phil Steitz created issue -
          Phil Steitz made changes -
          Field Original Value New Value
          Description Bugtraq ID [5026860http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5026860]

          All operations on Outrigger's log file are serlialized by a single
          lock. Currently each durable operation on a persistent Outrigger will
          result in two syncs (we could this down to one, see 5026757), this means that
          outrigger's overall througput is limited by the cost of these syncs
          (e.g. if the two syncs cost 25ms we can only get 40 ops / s).

          If we queued up disk ops, and then used a single queue thread to
          commit them to disk (while the queuing thread waited on completion of
          the commit to disk) when the queue had multiple pending operations we
          could write them all out under one set of syncs. This would not
          improve the best case latency for durable operations, but should allow
          for higher throuput when running multi-threaded work loads.
          Bugtraq ID [5026860|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5026860]

          All operations on Outrigger's log file are serlialized by a single
          lock. Currently each durable operation on a persistent Outrigger will
          result in two syncs (we could this down to one, see 5026757), this means that
          outrigger's overall througput is limited by the cost of these syncs
          (e.g. if the two syncs cost 25ms we can only get 40 ops / s).

          If we queued up disk ops, and then used a single queue thread to
          commit them to disk (while the queuing thread waited on completion of
          the commit to disk) when the queue had multiple pending operations we
          could write them all out under one set of syncs. This would not
          improve the best case latency for durable operations, but should allow
          for higher throuput when running multi-threaded work loads.
          Phil Steitz made changes -
          Description Bugtraq ID [5026860|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5026860]

          All operations on Outrigger's log file are serlialized by a single
          lock. Currently each durable operation on a persistent Outrigger will
          result in two syncs (we could this down to one, see 5026757), this means that
          outrigger's overall througput is limited by the cost of these syncs
          (e.g. if the two syncs cost 25ms we can only get 40 ops / s).

          If we queued up disk ops, and then used a single queue thread to
          commit them to disk (while the queuing thread waited on completion of
          the commit to disk) when the queue had multiple pending operations we
          could write them all out under one set of syncs. This would not
          improve the best case latency for durable operations, but should allow
          for higher throuput when running multi-threaded work loads.
          Bugtraq ID [5026860|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5026860]

          All operations on Outrigger's log file are serlialized by a single
          lock. Currently each durable operation on a persistent Outrigger will
          result in two syncs (we could this down to one, see RIVER-128), this means that
          outrigger's overall througput is limited by the cost of these syncs
          (e.g. if the two syncs cost 25ms we can only get 40 ops / s).

          If we queued up disk ops, and then used a single queue thread to
          commit them to disk (while the queuing thread waited on completion of
          the commit to disk) when the queue had multiple pending operations we
          could write them all out under one set of syncs. This would not
          improve the best case latency for durable operations, but should allow
          for higher throuput when running multi-threaded work loads.
          John McClain made changes -
          Link This issue is related to RIVER-128 [ RIVER-128 ]

            People

            • Assignee:
              Unassigned
              Reporter:
              Phil Steitz
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:

                Development