Hi Stephen,
"Stephen C. Tweedie" wrote:
> Hi,
>
> On Fri, 28 Jan 2000 13:00:22 +0100, Serge Robyns
> <serge.robyns@advalvas.be> said:
>
> > Is any of the active workers on the ll_rw_blk code thinking of
> > implementing per proces io metrics for block devices?
>
> What sort of metrics had you in mind? In general it's pretty hard to
> account IO to specific processes. Write is hardest: filesystem write IO
> is usually triggered by the background flush services in the VM, not by
> the processes writing to the files in the first place. Even for reads,
> if several processes try to read the same data at the same time, the
> kernel will bring it into cache only once: who do you account the IO
> against?
I basically accounted physical reads/writes against the pid currently running.
As you mentioned, writing to disk is mostly done by the background flusher.
But the read IO is accounted against the one doing the (first) request for
that part of data.
The idea is to have an idea who's doing what on the IO level. This allows to
do some capacity planning
on the global level without to have to dig into details of each application.
In case of an oracle db, for example it would be nice to see for example that
the io is done by
oracle shadow procs and the DBwiter for example instead of any other proces.
Also when running multiple database instances, it would enable us to see
(quickly) which ones
are generating the most IO. This is just an example.
The idea actually is to provide tools like BMC Best/1 or other perf. tools
more data to do some
performance reporting/modelling than it is actually posible.
On other unices thoose metrics are available, with the restrictions mentioned
by you.
Win2000 will have this also (this was one of the drawbacks of NT for doing
performance modelling,
and the only option left is to divide all the io over all the proceses, which
is far from correct).
>
>
> Buffer/page cache metrics would be easier to track than actual IO: the
> number of buffers dirtied and the cache hit/miss rates would all be
> fairly easy to track.
Those are the one I've in my mind. I did only the track of the reads & writes
done by ll_rw_blk and
updated the current running proc's data. That data was than also made
available to the proces
accounting functions.
The only real problem I'm facing, is that I had to extend the procfs proces
data (/proc/<pid>/stat) with two
addtional entries. And this could break some code, who using it, althoug by
appending them it seems
that top was still functioning!
If we could also add request counts (or cache hits) it would be really nice.
>
>
> --Stephen
Serge
-- _______________ / \ | Serge Robyns \_______________________________ | \ | RC&S (Robyns Consulting & Services) \ | 139, avenue De Fre | | 1180 Uccle - Belgium | | HR Brussels: 638.234 - VAT: BE 457.552.265 | | \|/ | | phone: +32(477)29.66.97 -O- fax: +1(801)469-9358 | | /|\ | | | | \|/ mailto:serge.robyns@advalvas.be \|/ | \___/o\____ http://web.wanadoo.be/rc.s/ ____/o\____/- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Feb 07 2000 - 21:00:14 EST