-
Notifications
You must be signed in to change notification settings - Fork 313
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
Race hangs while starting with many indices #320
Comments
I created the following track to reproduce the issue:
It creates 800 indices (which takes a while) but I managed to make it work on Mac OS X 10.11.6 (El Capitan). Initially I tried to run it with 1000 indices but Elasticsearch ran out of file descriptors:
(this one is on 5.6.0 but I also tried (and succeeded) on 2.3.3). So I wonder whether you're running out of file descriptors and that's why it hangs? Can you please check the output of |
I never ran into the file descriptor issue you described, I don't think rally ever started creating indices in ES. My ulimit is set to 7168. I was able to track this down a bit more, though. I think the problem is actually related to my mapping files. Each of my indices has a different mapping file and many of them are fairly large (megabytes). Changing all of my indices to use the same small mapping file allowed me to run the race. |
with
for every index that is created. As you have huge mapping files we should probably define an upper limit for the log output in this case.
That should be sufficient for creating a few hundred indices (I managed to create more than 800 with 10240).
Ok. For my reproduction I just reused the mapping file for the I think this could be caused by several issues:
Can you please tell me the size of your largest mapping file and also whether Rally has actually logged something like the log statement that I've shown above? Then I'll continue to reproduce. However, setting up that many indices (with large mappings) will always be slow. Maybe we can apply some smarts and show a progress indication in case you are creating more indices than some threshold. |
I've created #321 to avoid logging multi-megabyte mappings. |
My largest mapping is 5MB. I don't ever see the |
I'm gonna have a look what's going on (or rather not going on ;)). |
I could reproduce it and I know what's going on: Rally loads the mapping file when loading the track. This happens (always) on the coordinator and the intention is that the track should be self-contained so it is easier to send it between Rally nodes (e.g. when you distribute the load driver). The problem is that Rally serializes the whole track internally to send it to the load driver and this happens even when you are on a local machine because the load driver is a separate (sub)process. I think we can revert to lazy-loading for the mapping file because it should be sufficient to do all the index setup on the coordinating node. As this also requires changes to the node placement of specific actors this is a bit more effort than just moving the code to read the mapping file. Anyway, I attempt to tackle it but it will probably take a bit of time to be ready. |
I wanted to keep this ticket open to think whether we can make this lazy-loading work. While we could implement it, it would prevent or complicate other use-cases, like the definition of tracks in simple files (as opposed to a fully-fledged track repository). I'd really like to make both cases work but for now we need to decide whether we want to go either into one or the other direction. Therefore, I am closing this ticket without adding lazy-loading for now. However, should the internal infrastructure change, we can revisit and maybe add this later. |
Rally version (get with
esrally --version
):esrally 0.7.1
Invoked command:
esrally race --track=small-indices --distribution-version=2.3.3
Configuration file (located in
~/.rally/rally.ini
)):JVM version:
OS version:
macOS Sierra 10.12.5
Description of the problem including expected versus actual behavior:
Attempting to start a race on a track with hundreds of indices never starts. If I reduce the number of indices, the race runs as expected. In the hanging case, the
Driver
never seems to receive theStartBenchmark
message.Steps to reproduce:
Provide logs (if relevant):
The text was updated successfully, but these errors were encountered: