What would be interesting here is the paging statistics during your test
case.
What does "vmstat 1", and "vmstat -p 1" look like while your generating
this behavior?
Is it really case the reading/writing from swap is slow, or simply that
the system
on the whole is slow because it's dealing with a sustained memory deficit?
Also, I'd like to understand better what you're looking to optimize for.
In general, "tuning" for swap is a pointless exercise (and it's not my
contention
that that is what you're looking to do - I'm not actually sure), because the
IO performance of the swap device is really a second order effect of
having a memory working set size larger than physical RAM, which means
the kernel spends a lot of time doing memory management things.
The poor behavior of swap may really be a just a symptom of other activities
related to memory management.
What kind of machine is this, and what does CPU utilization look like
when you're inducing this behavior?
Thanks,
/jim
Peter C. Norton wrote:
> We use solaris 10 at my company, but I noticed this behavior is the
> same/worse on sxde, and I wanted to know if someone could test this on
> a recent nevada build.
>
> The problem:
>
> We have long used tmpfs for /tmp on systems where we want to provide
> our uses with a scratch space for them to put small files. This does
> get abused occasionally, but for that use it has been fine.
>
> The other day, we saw some puzzling behavior. Specifically, when a
> system with a lot of memory (16gb) had a 10gb file in /tmp, and a few
> large processes running (say 2 gb in 2 processes for the sake of
> argument) reading that file from /tmp became unbearably slow.
>
> While investigating this, we came up with a test scenario that
> consistantly reproduced this behavior. The behavior is that if you
> have a system with 4gb of memory, and create a 1gb file in /tmp, and a
> 1gb file in /var/tmp, and then you start 2 processes each with an rss
> of about 1gb, your reads from /tmp get very... very..... slow. The
> file in /tmp was maxing out at about 6mb/sec read, with a typical read
> speed of about 2.5mb/sec as measured by iostat. The file from /var/tmp
> reads about 50mb/sec.
>
> All the large processes do is keep scanning their active memory in
> this loop:
> for(;;) {
> for (int i=0; i < nints; i++) {
> buf[i]++;
> }
> }
>
> We've found that using a similar scenario with 3 of these processes,
> one will swap out, an when killing the most active one, the swap in
> happens again at aound 2.5mb/sec.
>
> This makes /tmp pretty bad in most scenarios, but what's stunning is
> how swap behaves so slowly when paging a program back in.
>
> Does anyone know what is going on here, does this happen in nevada,
> and what we can do about this? We are persuing this with sun support
> but I thought this was a topic of broader interest.
>
> Thanks,
>
> -Peter
>
>
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
