[Bug 1211110] Re: network manager openvpn dns push data not updating resolv.conf

2014-06-26 Thread Gabriel Nell
Would love to see this feature to make a very popular VPN client work
seamlessly with Ubuntu. I'm on 14.04 and trying to figure out a work-
around for this (probably will disable resolvconf).

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to openvpn in Ubuntu.
https://bugs.launchpad.net/bugs/120

Title:
  network manager openvpn dns push data not updating resolv.conf

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/120/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 568823] Re: Improved Java Memory/Performance Defaults

2010-04-26 Thread Gabriel Nell
An additional possibility is to specify the JVM using the -server
flag. Although Java also will auto-set this based on the machine
class, currently it will only choose the server JVM one machines with
2GB+ of RAM and 2 cores. Interestingly, the 32bit instances offered by
EC2 (a popular choice for hosting web frontends) have 1.7GB of RAM,
which would cause the client VM to be auto-selected.

http://java.sun.com/docs/hotspot/HotSpotFAQ.html#compiler_types
http://java.sun.com/j2se/1.5.0/docs/guide/vm/server-class.html

-- 
Improved Java Memory/Performance Defaults
https://bugs.launchpad.net/bugs/568823
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to tomcat6 in ubuntu.

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 568823] [NEW] Improved Java Memory/Performance Defaults

2010-04-23 Thread Gabriel Nell
Public bug reported:

Binary package hint: tomcat6

Forking an issue from #541520

The current default of a 128MB heap does not make sense. This was chosen
when Java 1.4 had a default maximum heap size of 64MB. In Java 1.5 and
later, the JVM will automatically size the heap based on available
memory. So the current default setting actually unnecessarily sets a
limit on the memory available to tomcat, when not setting anything at
all would actually allow the modern JVMs to do a better job.

References:
http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html#par_gc.ergonomics.default_size
http://java.sun.com/javase/6/docs/technotes/guides/vm/gc-ergonomics.html
http://java.sun.com/docs/hotspot/gc5.0/ergo5.html

***
initial heap size:
Larger of 1/64th of the machine's physical memory on the machine or some 
reasonable minimum. Before J2SE 5.0, the default initial heap size was a 
reasonable minimum, which varies by platform. You can override this default 
using the -Xms command-line option.

maximum heap size:
Smaller of 1/4th of the physical memory or 1GB. Before J2SE 5.0, the default 
maximum heap size was 64MB. You can override this default using the -Xmx 
command-line option.
***

** Affects: tomcat6 (Ubuntu)
 Importance: Undecided
 Status: New

-- 
Improved Java Memory/Performance Defaults
https://bugs.launchpad.net/bugs/568823
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to tomcat6 in ubuntu.

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 568823] Re: Improved Java Memory/Performance Defaults

2010-04-23 Thread Gabriel Nell
Attaching proposed patch.

** Patch added: tomcat6.mem.diff
   http://launchpadlibrarian.net/45066613/tomcat6.mem.diff

-- 
Improved Java Memory/Performance Defaults
https://bugs.launchpad.net/bugs/568823
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to tomcat6 in ubuntu.

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 541520] Re: Using incorrect JVM Garbage Collector

2010-04-23 Thread Gabriel Nell
Done (#568823). As I say I'm still not convinced about the CMS collector
as a default, but I'll follow up later if I become more passionate about
it. :)

-- 
Using incorrect JVM Garbage Collector
https://bugs.launchpad.net/bugs/541520
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to tomcat6 in ubuntu.

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 541520] Re: Using incorrect JVM Garbage Collector

2010-04-21 Thread Gabriel Nell
The point that we know something the JVM can't know, eg, that this JVM
is running a web server, is fair. I'm still not convinced that
specifying the CMS collector is the right application of this knowledge,
and I'm new to Ubuntu (from a contributor standpoint, anyway) so I don't
know what the project goals are for the default configuration. But for
now let me move down what I hope is a fruitful path. It sounds like (and
please correct me if I'm wrong) we want to choose settings that:

1) at a minimum, work (eg, after running apt-get, tomcat actually boots up 
and serves requests)
2) has reasonable defaults to suit the sort of hardware we expect people to run 
web servers on

Currently our defaults are:

-Xmx128M -XX:+UseConcMarkSweepGC

Which satisfies #1, but I still think is not great for #2. Maybe as you
alluded we'd do better by not specifying the maximum heap size? The
rationale was that 64MB is not usually enough, and that made sense under
JDK1.4, when this was the default heap size. However it looks like in
1.5 and later, the heap selection was changed to be based on the amount
of available RAM

***
initial heap size:
Larger of 1/64th of the machine's physical memory on the machine or some 
reasonable minimum. Before J2SE 5.0, the default initial heap size was a 
reasonable minimum, which varies by platform. You can override this default 
using the -Xms command-line option.

maximum heap size:
Smaller of 1/4th of the physical memory or 1GB. Before J2SE 5.0, the default 
maximum heap size was 64MB. You can override this default using the -Xmx 
command-line option.
***

So if we don't give any heap parameters to the JVM:

- The heap will be at least 128MB (satisfy goal #1) on any machine with 512MB 
or more of RAM
- The JVM is free to choose a heap much larger than 128MB, based on the 
available memory (satisfy goal #2)

For this reason I'd suggest we remove the -Xmx128M portion from the
command line.

References:
http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html#par_gc.ergonomics.default_size
http://java.sun.com/javase/6/docs/technotes/guides/vm/gc-ergonomics.html
http://java.sun.com/docs/hotspot/gc5.0/ergo5.html

-- 
Using incorrect JVM Garbage Collector
https://bugs.launchpad.net/bugs/541520
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to tomcat6 in ubuntu.

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 541520] Re: Using incorrect JVM Garbage Collector

2010-04-20 Thread Gabriel Nell
Folks -- sorry for chiming in here after the train has apparently left
the station :)

I've been working on optimizing my Tomcat configuration for the past
couple days, and this optimization has mostly centered around the
garbage collector. I'm concerned that specifying the CMS collector is
classic premature optimization. If I absorbed this change, my
application performance would have gotten suddenly worse. But let's not
talk about my specific case.

To excerpt from the same whitepaper referenced above (section 6, first
paragraph):

Thus, the initial recommendation for selecting and configuring a
garbage collector is to do nothing! That is, do not specify usage of a
particular garbage collector, etc. Let the system make automatic choices
based on the platform and operating system on which your application is
running.

As this implies, the Hotspot JVM will actually select a collector for
you based on the system resources. Further, Sun's GC tuning document
found at

http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html#available_collectors.selecting

Advises that heap size should actually be the first knob you adjust
before switching collectors.

I'm all for choosing smart defaults. But I think in this case the advice
from the guys who make Java is pretty clear. Let the JVM decide, and if
it's not good enough, only then optimize for the metrics you care about,
and do not begin by choosing a specific collector.

-- 
Using incorrect JVM Garbage Collector
https://bugs.launchpad.net/bugs/541520
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to tomcat6 in ubuntu.

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs