I have some development zLinux guests with 25 JVM's.  Most of these aren't used 
on a typical day and can idle along with a 200MB heap.  But if a development 
team is doing load testing, then the heap and memory footprint for a JVM can 
grow to 1.5GB+.  If 2-3 teams are doing testing, my Linux memory utilization on 
that guest just grow by 4-6 GB.  I cannot "right size" some of these guests 
without fixed heaps which seems wasteful, and relying on multiple 500MB VDISK 
linux swaps for Linux can have downsides.  I've had guest VDISKS paged out by 
VM with terrible performance penalties.  I'd hypothesize VDISK can be far more 
likely to get paged out than memory by the file cache!    Swappiness=0 doesn't 
prevent the cache from being populated.  If it's populated, VM still might not 
see that memory as LRU.   Unless I can help out the hypervisor by preventing 
some memory from being used, then it limits our ability to overcommit memory on 
VM.

So a month ago I asked the list about cpuplugd, CMM, & CMMA.  Everyone said to 
stay away from these.  But this is exactly the problem I was trying to solve, 
and why I went with the drop caches approach.    I don't need "always on" help, 
just the ability to suppress the linux file cache.  Drop caches seems to help.  
On a guest described like above, I'm going into the day with a 1.5GB cache 
(still too big), but 3.5GB of free memory that is a candidate for LRU.  That 
seems to work for me.

Rob - For your example script to work, does CMM need to be fully configured?

And with "fairness in opinions" in mind, how would you recommend I approach my 
situation Mauro?

Jon


-----Original Message-----
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Rob van 
der Heij
Sent: Friday, August 16, 2013 5:22 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: linux cache

The thing that happened to your servers is that drop_caches frees up page
frames in Linux that have not been referenced for a long time. Linux starts
to use them for something else, and requires z/VM to page it in. To make
room for that, VM will page out other parts of the guests.

You're still missing the point. We don't drop the caches because Linux
needs memory but because we want to determine what memory to give back to
VM. Yes, you also lose the good things from cache, but that's a trade-off
to make with performance instrumentation. As I started my first response in
this thread, if you don't plan to give the pages back with CMM or CMMA, it
is not a good idea to use drop_caches and swappiness might be a better way
to help workloads that get in trouble.

Rob


On 15 August 2013 19:16, Mauro Souza <thoriu...@gmail.com> wrote:

> I have read it now. And as I think there's no CMM involved, I still
> disagree.
> I said I would never ever drop caches because I saw it almost killing a
> LPAR. I had a customer that put drop_caches on crontab, and at that time
> *every* guest started dropping caches and zVM was crazy doing a lot of
> page-ins and page-outs. Nobody understood why the system was unresponsible.
> I think is less costly to zVM to handle dozens of page-ins and outs for a
> Linux needing 10MB of memory here and there, than to drop 2GB of caches at
> the same time. If you drop all the cache at the same time, Linux will have
> to make an I/O  operation for every file it will read, and zVM will have to
> read a lot of data from PAGE that will be just ignored.
> No matter if you drop all the cache at the same time, or drop a page when
> you need it, zVM will have to bring it back. Dropping all caches is like
> paying a $100k loan in one time, instead of splitting it in 1000 times of
> $100.
>
>
> Mauro
> http://mauro.limeiratem.com - registered Linux User: 294521
> Scripture is both history, and a love letter from God.
>
>
> 2013/8/15 Rob van der Heij <rvdh...@gmail.com>
>
> > On 15 August 2013 17:34, Mauro Souza <thoriu...@gmail.com> wrote:
> >
> >
> > > You can safely ignore the cache usage on Linux, zVM will realise the
> page
> > > was not in use and drop it itself. When Linux needs memory, it will
> > reclaim
> > > cache pages automatically.
> > >
> > > So we disagree. Maybe we wouldn't if you had read the page that I
> linked
> > to.
> >
> > The point that you miss is when Linux needs memory and reclaims a page
> > frame from page cache, z/VM will first bring back the old contents that
> > Linux did not care about anymore. This is where getting a free page will
> > slow you down. Especially since the LRU patterns interfere. The idea is
> > that you want to drop the backing page from z/VM either before it is
> paged
> > out or before z/VM will page it back in. If you have CMMA enabled, then
> > having Linux free the page (by drop_caches) will prevent z/VM from paging
> > it out.
> >
> > Rob
> >
> > ----------------------------------------------------------------------
> > For LINUX-390 subscribe / signoff / archive access instructions,
> > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
> > visit
> > http://www.marist.edu/htbin/wlvindex?LINUX-390
> > ----------------------------------------------------------------------
> > For more information on Linux on System z, visit
> > http://wiki.linuxvm.org/
> >
>
> ----------------------------------------------------------------------
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
> visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390
> ----------------------------------------------------------------------
> For more information on Linux on System z, visit
> http://wiki.linuxvm.org/
>

----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

________________________________

The information contained in this e-mail message is intended only for the 
personal and confidential use of the designated recipient(s) named above. This 
message may be an attorney-client or work product communication which is 
privileged and confidential. It may also contain protected health information 
that is protected by federal law. If you have received this communication in 
error, please notify us immediately by telephone and destroy (shred) the 
original message and all attachments. Any review, dissemination, distribution 
or copying of this message by any person other than the intended recipient(s) 
or their authorized agents is strictly prohibited. Thank you.

----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Reply via email to