On Thu 03-09-15 13:38:22, Carlos E. R. wrote:
On 03/09/2015 12:51, Michal Hocko wrote:
On Thu 03-09-15 12:07:03, Navin Parakkal wrote: [...]
The problem doesn't occur with Oracle systems because during backup they have ways to use direct I/O and many DBAs set that by default . ... When you are backing up TeraBytes of data ie full export and backup , i think it is better not to fill up the kernel caches that you are going to seldom use.
I am still not sure I understand what is _the problem_. Do you see any considerable stalls during backups caused by excessive slab usage? You have mentioned that you can see stalls during an artificial load earlier but nothing about a real world example.
As end user, I can suggest an scenario. I don't know if it relates to SLAB/SLUB, but I know that it is a real scenario similar to the one Navin describes.
On some systems, when writing the openSUSE DVD iso image to an USB stick, as the stick is slow writing, the kernel tries to cache as much as it can in memory, maybe the full 4 gigs. This, apparently, has the consequence of starving other processes of cache use and ram, on some machines, causing the entire machine to crawl and become unresponsive for minutes.
This doesn't seem to have anything to do with SL.B, though. It is more about amount of dirty pages which are allowed to be accumulated before writers get throttled (dirty_{backgroud_}ratio resp _bytes). And yes, we have seen these issues, especially with slow devices in the past a lot. The situation should be _somehow_ better these days but it is still recommended to use _bytes variants to throttle writers or start the writeback sooner. It would be, of course, much better if system could auto-tune but this is a hard problem which still waits for solving. -- Michal Hocko SUSE Labs -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org