Very odd memory behavior. Is this normal?

[Shaun Thomas]

Devs,

Ever since we moved from 2.6.* to 3.*, I've noticed some very odd MM behavior I'd like to run past you. It's pretty difficult to replicate, but I've figured out a fairly straightforward method. But first, the issue:

Our systems with 72GB of RAM on a 3.2 kernel eventually converge on this, from /proc/meminfo:

Active(file):   29059980 kB
Inactive(file): 29069296 kB

Basically some kind of even split across Inactive and Active, suggesting a hard IO loop that's purging as fast as it can promote. It's pretty easy to cause, too. If you have PostgreSQL handy, any DB that just barely fits in memory should be sufficient.

createdb pgbench
pgbench -i -s 4000 pgbench
pgbench -T 1800 -c 24 -S pgbench

I let that run for a while to cache everything, until read IO slows down to a trickle according to iostat. Memory at that point looks like this:

Active(file):   61056316 kB
Inactive(file):   249968 kB

And free -m looks like this:

             total       used       free     shared    buffers     cached
Mem:         72485      66963       5521          0          2      64183
-/+ buffers/cache:       2776      69708
Swap:         2047          0       2047

So I have 5GB available, 64GB cached... looks pretty normal. I leave the pgbench running, then in another terminal, I waste more memory than I have free:

python - <<EOF
foo = bytearray(8 * 1024 * 1024 * 1024)
from time import sleep
sleep(1000)
EOF

After a minute or two, Active and Inactive are even again, and IO to the underlying device is extremely high. In our case, that's 350MB/s in random reads. Every kernel I've tested does this. 3.2, 3.5, 3.8. I haven't been able to go higher than that, but the behavior seems pretty consistent. This is with zone_reclaim_mode disabled, and numactl --interleave=all doesn't change anything.

I get that it needs to balance memory, but this seems excessive somehow. I'm probably missing something, though. Any insight would be helpful, and I can try to provide anything else you need if this is a legitimate complaint.

Thanks!

--
Shaun Thomas
OptionsHouse | 141 W. Jackson Blvd | Suite 500 | Chicago IL, 60604
312-676-8870
sthomas@xxxxxxxxxxxxxxxx



______________________________________________

See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/