[chef] Re: Re: Re: Re: [ANN] jvmargs, a sanity checker for JVM options

[Bryan Berry < >]

well I can definitely be horribly mistaken on the matching Xmx and Xms
:) , and am willing to change the  code

iirc I read the matching Xmx and Xms in the "Java Performance" book
but I could be mistaken

On Thu, Mar 21, 2013 at 2:44 PM, Jesse Campbell 
<
 >
 wrote:
> I've read plenty that suggests that depending on the situation, having
> different Xms and Xmx values can be beneficial.
>
> i've seen things like this:
> http://java-monitor.com/forum/showthread.php?t=427
> which suggest that setting them the same has no particularly beneficial
> effect.
>
> and I've seen things like this:
> http://weblogs.java.net/blog/kcpeppe/archive/2011/12/19/setting-xmx-xms-still-considered-harmful
> which suggest that the ideal settings are for xms to be your 99% case, and
> xmx allow for some wiggle room
>
> in fact, i haven't seen any really good recent analyses that support setting
> them the same, just lots of rhetoric
>
> -jesse
>
>
> On Thu, Mar 21, 2013 at 9:31 AM, Bryan Berry 
> <
 >
>  wrote:
>>
>> min and max should be the same because there is no benefit to having a
>> lower min according to everything I have read. It can slow down your
>> application startup however.
>>
>> it will not support parsing a space delimited string, only the options
>> specifically for the JVM, for example
>>
>> "java  -Djava.io.tmpdir=/tmp/foo -server -Xmx256m -Xint
>> -XX:MaxPermSize=512M -classpath /tmp/foo.jar:/tmp/baz.jar
>> org.apache.catalina.Bootstrap start "
>>
>> jvmargs doesn't add the java binary to the beginning nor the
>> "org.apache.catalina.Bootstrap start"
>>
>> I do want to handle the classpath but i have not figured out a clean
>> way to handle that yet :(
>>
>> i would very much appreciate feedback and testing. this afternoon i
>> hope to add support for arbitrary rules like the following
>>
>> "if Max heap is greater than available RAM, raise an error"
>> "if Max heap is changed, also set Min heap to same value"
>>
>> On Thu, Mar 21, 2013 at 2:18 PM, Jesse Campbell 
>> <
 >
>>  wrote:
>> > hey, been looking for something like this to come along, looks like a
>> > very
>> > clean, sane way to handle it :D
>> >
>> > in your todo you have ensure min and max heap should be the same. why is
>> > this?
>> >
>> > i didn't dig to far into the code, but will it support parsing a space
>> > delimited string, as the current tomcat and tomcat6 cookbooks expect, or
>> > will the cookbook be expected to handle that?
>> >
>> > thanks!
>> >
>> >
>> > On Thu, Mar 21, 2013 at 4:53 AM, Bryan Berry 
>> > <
 >
>> > wrote:
>> >>
>> >> hey folks,
>> >>
>> >> i have written a little gem to parse JVM options and would love some
>> >> feedback on it. Managing JVM options in a cookbooks is a total PITA
>> >> and I hope this makes it easier. This is less than alpha quality, i am
>> >> posting it here to get some feedback, not to notify others of a
>> >> production-ready tool. I foresee it being used in Java-related
>> >> cookbooks to provide a set of application-specific defaults and then
>> >> make it easy to override or add to them in recipe code.
>> >>
>> >> https://github.com/bryanwb/jvmargs
>> >>
>> >> This library parses JVM options so that any given option is only
>> >> stored once. It does this by breaking each option into one of the
>> >> three option categories:
>> >>
>> >> 1. standard, ex: -server, -enablesystemassertions
>> >> 2. nonstandard, ex: -Xmx128M, -Xint
>> >> 3. unstable, ex: -XX:-DisableExplicitGC, -XX:AltStack=128M
>> >> 4. directive, ex: -Dcom.sun.management.jmxremote
>> >>
>> >> JVMArgs will ensure that only one value is stored for any given
>> >> option. Here is a quick example
>> >>
>> >> args = JVMArgs::Args.new("-XX:-DisableExplicitGC", "-Xmx256M")
>> >> # "-XX:-DisableExplicitGC" is now stored in args
>> >> args.add("-XX:+DisableExplicitGC")
>> >> args.add("-Xmx2G")
>> >> # the settings are now "-XX:+DisableExplicitGC" and "-Xmx2G"
>> >
>> >
>
>