Remove threadcount
Reported by Deleted User | October 13th, 2010 @ 05:35 PM
From a high level, the decision to use a certain number of threads is probably not easily determine by a user of rundeck. In my experience, every 100 threads requires 1GB of memory. Since an end user isn't going to be aware of what the -mx startup record is, nor do I think they should be bothered with it, the threadcount option should be removed.
Instead, the default configuration is to run as fast as possible. Underneath the scenes, we may be calculating the ratio based on how rundeck is launched, etc, but that's hidden from the user.
On the flip side, I think there should be a throttle command. This means that someone can say limit the number of dispatch commands to some value. I.e. only dispatch to 30 per second or 30 per minute so they can control how quickly the change occurs.
Perhaps a helpful metric to collect at the end of the run is what the concurrency per second actually is. This can help forecast how fast a change can be rolled out.
Comments and changes to this ticket
-
Greg Schueler October 14th, 2010 @ 08:43 AM
it seems like manual specification of the threadcount should still be allowed, with perhaps another option for "Optimized" threadcount, which could automatically set the threadcount to some value based on number of target nodes and system tuning.
options could be "Optimized threadcount", "Single thread" and "Other: __"
-
Deleted User October 14th, 2010 @ 09:53 AM
I think it should be only throttled. More options are going to lead to confusion.
-
Alex-SF November 2nd, 2010 @ 03:27 PM
- Milestone changed from “Rundeck 1.0” to “Rundeck 1.1”
- Milestone order changed from “11” to “0”
-
Alex-SF December 29th, 2010 @ 05:49 PM
- Milestone changed from “Rundeck 1.1” to “Rundeck 1.2”
- Milestone order changed from “7” to “0”
-
Alex-SF February 1st, 2011 @ 11:47 AM
- Milestone cleared.
- Milestone order changed from “1” to “0”
-
jhmartin June 23rd, 2011 @ 08:55 AM
I have to say more options leads to more flexibility; sensible defaults should make it unnecessary for 'joe user' to update this value.
-
Deleted User June 23rd, 2011 @ 09:02 AM
The original idea for this request is that setting this value too high will cause RunDeck to stop working due to lack of memory. The option should be run serially or run as bloody parallel as possible where bloody parallel is some max based on internal constant either set in configuration or calculated internally.
Please Sign in or create a free account to add a new ticket.
With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.
Create new ticket
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป
(DEPRECATED) Please use github issues for issue tracking at http://github.com/dtolabs/rundeck/issues
Alex-SF
Greg Schueler