An excellent write-up, thank you. In our case puppet-master is actually an LXC container instance. On reflection the values reported by top are meaningless, and I'm not convinced I know the solution for monitoring purposes. I might suggest however that part of application support now needs to include the question "is this a container instance" to help reduce time wasted by yourselves and others (this is not a criticism of you or your colleagues but an observation of an enhancement to be made across the industry in [potential] fault diagnosis).
I have removed the -Xmx192M from our start-up parameters, we'll see how things go for the time being. Thanks, James On 16 February 2015 at 13:04, Ken Barber <[email protected]> wrote: > > 16850 puppetdb 20 0 12.697g 418684 14848 S 0.9 0.4 4:32.74 java > > > > That's top now since it began running around 10.30 this morning (GMT). > 12G > > of ram? It's the only proc in the list having a 'g' against it. Seems > > excessive..? > > So, there is a difference in the columns here ... the column with the > 'g' is the 'virtual' usage, that means its the amount of RAM allocated > for potential usage. Its not using all of that memory right now, but > it can under large circumstances change to use that much. I'm not > quite sure why this is so high, you'd need to show a full output of > your settings, perhaps a ps auxwww | grep java will give us the > settings that have been passed and will enable me to understand why > its so high. Either way, it's usually been set to do that by > someone/something - by default our settings shouldn't enable Java to > consume 12 GB out of the box, so I can only presume the heap setting > was changed at some point. > > The column just after that is the RES column, indicating how much its > actually consuming now. This is usually the important one. I'm of > course trivialising the description of each column, but understand > virt versus res is important. There are lots of articles on the > internet about this subject that are definitely worth researching as a > sysadmin. > > Another thing, if that is truly that high, you might want to check > your dmesg output to make sure the process isn't getting caught by the > OOMkiller in Linux. I have no other information about your system then > what you've given me, so I can't make a judgement on whether 12 GB is > high or not for you. It does seem high, although I could understand > this increase in the setting if you were processing a lot of data. > > ken. > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-users/CAE4bNTmhJFvS-cUg3UoUxpyCoKV8YX7WKC1fq72XwHQ5yPtnUA%40mail.gmail.com > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAMH6%2Bax8KHKUZV%3Dy4E7AO3%2B0kdBFsN0RnZFXywORti8Lzy0R_w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
