Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Concurrency optimization for native graph loading #2345

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

Gankris96
Copy link

@Gankris96 Gankris96 commented Dec 19, 2024

Description

Fixes #2265

Refactors the graph load into a 2 step approach detailed here - #2265 (comment)

This will help to move out the opening of indexInput file outside of the synchronized block so that the graphfile can be downloaded in parallel even if the graph load and createIndexAllocation are inside synchronized block.

Related Issues

Resolves #2265

Check List

  • New functionality includes testing.
  • New functionality has been documented.
  • API changes companion pull request created.
  • Commits are signed per the DCO using --signoff.
  • Public documentation issue/PR created.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Signed-off-by: Ganesh Ramadurai <[email protected]>

minor updates
@Gankris96 Gankris96 force-pushed the concurrent-graph-load branch from 7cb8710 to 8e90b88 Compare December 19, 2024 01:30
@Gankris96 Gankris96 changed the title Concurrency optimization for graph native loading Concurrency optimization for native graph loading Dec 19, 2024
@navneet1v
Copy link
Collaborator

Please add an entry in the changelog.

// close the indexInput
@Override
public void close() {
if (readStream != null) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you set preload=false in here?

try {
indexSizeKb = Math.toIntExact(directory.fileLength(vectorFileName) / 1024);
readStream = directory.openInput(vectorFileName, IOContext.READONCE);
readStream.seek(0);
Copy link
Contributor

@0ctopus13prime 0ctopus13prime Dec 20, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Curious, why we need this? Is this for those IndexInput subclasses having a lazy loading kind of stuffs?

* Preloads the entry by opening the indexInput
*/

public abstract void preload();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. Can we give a meaningful name? What it does is actually doing a preparation before 'loading' bytes into memory. e.g. opening a stream

  2. Can we make it have an empty body?
    Then let those subclasses need this to add their implementation.

void preload() {
}

@@ -328,6 +328,8 @@ public NativeMemoryAllocation get(NativeMemoryEntryContext<?> nativeMemoryEntryC

// Cache Miss
// Evict before put
// preload the graph file before proceeding to load the graph into memory
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not preloading the graph file, isn't it? 🤔
Opening a stream != loading the graph file, I believe

@@ -75,6 +91,18 @@ public static class IndexEntryContext extends NativeMemoryEntryContext<NativeMem
@Getter
private final String modelId;

@Setter
@Getter
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you remove @Setter here?
This variable should be modified from outside other than testing.
Instead of having a public scope getter, please find another way to change it in testings.

@0ctopus13prime
Copy link
Contributor

HI @Gankris96, thank you for the PR.
I see this clearly will bring benefit for the cases where multiple threads are competing each other.
But just curious, after this fix, how much performance gain do you see?

@Gankris96
Copy link
Author

Gankris96 commented Dec 20, 2024

HI @Gankris96, thank you for the PR. I see this clearly will bring benefit for the cases where multiple threads are competing each other. But just curious, after this fix, how much performance gain do you see?

Hi @0ctopus13prime - yes i am working on getting the benchmarking numbers. Primarily trying to test it on remote store backed index to see the performance gains.

Will update with Benchmarking numbers soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[FEATURE] Concurrency optimizations with native memory graph loading and force eviction
3 participants