CentOS - Jun 2015 - Effectiveness of CentOS vm.swappiness

On Fri, Jun 05, 2015 at 09:33:11AM -0700, Gordon Messmer
wrote:
> On 06/05/2015 03:29 AM, Markus "Shorty" Uckelmann wrote:
> >some (probably unused) parts are swapped out. But, some of
> >those parts are the salt-minion, php-fpm or mysqld. All services which
> >are important for us and which suffer badly from being swapped out.
> 
> Those two things can't really both be true.  If the pages swapped
> out are unused, then the application won't suffer as a result.
No.

Let's say the application only uses the page once per hour. If there
is also I/O going on, then it's easy to see that the kernel could
decide to page the page out after 50 minutes, leaving the application
having to page it back in 10 minutes later.

-- greg

On 05.06.2015 19:47, Greg Lindahl wrote:
> On Fri, Jun 05, 2015 at 09:33:11AM -0700, Gordon Messmer wrote:
>> On 06/05/2015 03:29 AM, Markus "Shorty" Uckelmann wrote:
>>> some (probably unused) parts are swapped out. But, some of
>>> those parts are the salt-minion, php-fpm or mysqld. All services
which
>>> are important for us and which suffer badly from being swapped out.
>>
>> Those two things can't really both be true.  If the pages swapped
>> out are unused, then the application won't suffer as a result.
> 
> No.
> 
> Let's say the application only uses the page once per hour. If there
> is also I/O going on, then it's easy to see that the kernel could
> decide to page the page out after 50 minutes, leaving the application
> having to page it back in 10 minutes later.
That's true but it also means that if you lock that page so it cannot be
swapped out then this page is not available for the page cache so you
incur the i/o hit either way and it's probably going to be worse because
the system has no longer an option to optimize the memory management.
I wouldn't worry about it until there's actually permanent swap activity
going on and then you have to decide if you want to add more ram to the
system or maybe find a way to tell e.g. Bacula to use direct i/o and not
pollute the page cache.
For application that do not allow to specify this a wrapper could be
used such as this one:
http://arighi.blogspot.de/2007/04/how-to-bypass-buffer-cache-in-linux.html

Regards,
  Dennis

On 06.06.2015 04:48, Dennis Jacobfeuerborn wrote:
> On 05.06.2015 19:47, Greg Lindahl wrote:
>> On Fri, Jun 05, 2015 at 09:33:11AM -0700, Gordon Messmer wrote:
>>> On 06/05/2015 03:29 AM, Markus "Shorty" Uckelmann wrote:
>>>> some (probably unused) parts are swapped out. But, some of
>>>> those parts are the salt-minion, php-fpm or mysqld. All
services which
>>>> are important for us and which suffer badly from being swapped
out.
>>>
>>> Those two things can't really both be true.  If the pages
swapped
>>> out are unused, then the application won't suffer as a result.
>>
>> No.
>>
>> Let's say the application only uses the page once per hour. If
there
>> is also I/O going on, then it's easy to see that the kernel could
>> decide to page the page out after 50 minutes, leaving the application
>> having to page it back in 10 minutes later.
> 
> That's true but it also means that if you lock that page so it cannot
be
> swapped out then this page is not available for the page cache so you
> incur the i/o hit either way and it's probably going to be worse
because
> the system has no longer an option to optimize the memory management.
> I wouldn't worry about it until there's actually permanent swap
activity
> going on and then you have to decide if you want to add more ram to the
> system or maybe find a way to tell e.g. Bacula to use direct i/o and not
> pollute the page cache.
> For application that do not allow to specify this a wrapper could be
> used such as this one:
> http://arighi.blogspot.de/2007/04/how-to-bypass-buffer-cache-in-linux.html
Actually I found better links:
https://code.google.com/p/pagecache-mangagement/
http://lwn.net/Articles/224653/

"It is to address the "waah, backups fill my memory with
pagecache" and
the "waah, updatedb swapped everything out" and the "waah,
copying a DVD
gobbled all my memory" problems."

Regards,
  Dennis