-   Linux - Kernel (
-   -   Extremely sluggish system with newest kernels under high memory load (

Einars 03-09-2012 07:06 PM

Extremely sluggish system with newest kernels under high memory load
When using newest kernels (starting with 3.0 till 3.2), system becomes unresponsive when some application fills up all (or almost all) physical memory. One way to reproduce - importing some complicated multipage pdf document in Gimp. When ram usage hits about ~900mb (1G ram total), computer basically locks up - takes more than 10 seconds to respond to single keypress. Also high HDD activity is observed. Of course it's logical - I guess kernel tries to move something to swap partition. The thing is, even after longer waiting, HDD trashing is still going on and swap usage almost hasn't changed. When using kernel 2.6.39, system gets somewhat sluggish in this scenario, but at least completely managable, and I can see swap usage climbing. I have tried to fiddle with some virtual memory parameters (like swappiness), but nothing helped. This problem was even worse in 3.0 kernels - I got some serious sound stuttering during even relatively light I/O - like launching video player. All tested kernels are self-compiled. Any clues are more than welcome, since this bug (or "feature") is very annoying (especially when this happens during some network gaming session).

syg00 03-09-2012 07:37 PM

Seeing a few like this recently. I'd be guessing transparent huge pages.
Try this - "echo madvise > /sys/kernel/mm/transparent_hugepage/defrag"

Do some testing, and if no change try never instead of madvise. If that doesn't help, try turning THP off altogether.
echo never > /sys/kernel/mm/transparent_hugepage/enabled

Let us know how it goes.

Einars 03-09-2012 08:05 PM

Unfortunately I havent even compiled hugepage support into kernel, so that shouldn't be the cause(don't have anything in /sys/kernel/mm dir) :( Just tested again and same strange situation - some high I/O happening (like 10-30 Mb/s), but swap usage changes very little (40 Mb out of 1,5 Gb)

Einars 03-10-2012 09:55 AM

Don't know if this can be called 'solved' but I compiled kernel with cgroups support and together with little daemon called ulatencyd situation seems to have gotten a bit better. Needs some more testing.

H_TeXMeX_H 03-10-2012 12:58 PM

I've had the opposite experience, i.e. recent 3.2.x kernels have solved these types of problems for me.

Here's what I have enabled:

Also, I have disabled swap completely, I have zcache enabled instead. I use the deadline I/O scheduler, if you use CFQ make sure to have CONFIG_BLK_CGROUP enabled as well as CONFIG_CFQ_GROUP_IOSCHED. I've found deadline to be better for me.

Einars 03-11-2012 04:36 AM

Thanks for suggestion. Unfortunately, that didnt helped much, although those features (cleancache, zcache) seems interesting and worth some testing. I guess I don't pay enough attention to all those new kernel features :) I little clarification those newer kernel generally perform fine exept case I mentioned situation when close to running out of physical RAM. Of course, this isn't noticeable on newer computers with several gigs of RAM.

All times are GMT -5. The time now is 05:32 AM.