Skip to content

improve lua intepreter thread locality #5872

@romange

Description

@romange

(Enhancement, not sure what's the impact of it, but I suspect it is significant for use-cases with single shard lua invocations)

Currently, an interpreter is acquired on the coordinator thread see ServerState::BorrowInterpreter()

But for single shard lua transactions we could actually use the interpreter running on the destination shard.
see Service::EvalInternal and if (CanRunSingleShardMulti(sid, *params, *tx)) { check.

We can not not do it now because of several reasons:

  1. the tx fiber should not block on anything as it will immediately create huge latency for all the operations scheduled on it.
  2. racing with other coordinator threads could lead to deadlocks where the tx A with lower id was blocked on the transaction B with higher id that acquired the interpreter but could not run because it waits for A to finish.

I believe the problem is that semaphore functionality of limiting number of interpreters is coupled with actually getting the interpreter. If we separate this and keep the limits at the coordinator level, we could get interpreters at shard level if needed

Idea: separate interpreter acquisition from the semaphore limits and use:
global vector<atomic_int> used_interpreter_count(pool->size())

  1. semaphores will still be enforced at the coordinator level.
  2. Coordinator will proceed only if used_interpreter_count is less than a limit.
  3. Once it proceeds it can acquire unconditionally an interpreter object in the thread it runs. So in case of CanRunSingleShardMulti, it will take it from the shard thread.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions