I have used SAR -b to get some Unix cache / buffer metrics and the results are confusing me a bit.
The pread/s & pwrit/s are showing 0. However the lread/s and lwrit/s are showing figures. I note also that the bread/s and bwrit/s are showing figures. I believe that pread/s and pwrit/s is not used in SAR but rather bread/s and bwrit/s are used instead - is this correct ?
What is the difference between logical read/writes and physical read/writes to the Unix cache / buffer ? I though a logical read / write was to the buffer but a physical one was to the disk itself ?
Also why is bread/s & bwrit/s considerably less that lread/s and lwrit/s ? Does the bread and bwrit figures indicate the nos of unix blocks and hence encapsulate a number of the logical reads & writes reported by the lread and lwrite figures ?
pread & pwrite are for raw I/O to character devices.
lread & lwrit are I/O to the buffer, not disk
logical read/write means that the I/O was done to a buffer, ie., memory.
Physical I/O is to a device - tty, disk, tape.
The more use the system gets from buffers, the more efficient overall I/O throughput becomes.
thanks for the reply.
Do you know know how the unix buffer / cache is set ? ( I presume it is a kernel based setting )
I notice from SAR -d that my read cache is consistently at 100% but my write cache frequently falls below 65%. What does this mean. Should I be tuning the write cache and if so, how ?
Is there a single buffer / cache or separate ones for read & write ?
Actually - what are you doing?
Unless you really have I/O problems - or disk thrashing - or some clearly defined problem, like every process is totally I/O bound, you should probably leave things alone.
It appears to me like you do not know what you are looking at, so your changing things could lead to big trouble.
Process space can also have file caches or buffers. Applications control caching (buffering) and that's where control of buffers usually should start, not at the kernel level. Look for applications that have called setvbuf() to turn off buffering, for example.
In general, disks have pretty big on-board caches, so you don't have to worry too much about the kernel cache if things are working reasonably well.
The write thing is the number of cache hits/misses - misses caused by writing new data to files; hits are a write updating an existing record in the cache, like a row in a database table.
Generally, the best thing to do is called load-leveling - placing really active directories on physically separate disks. This mostly applies to writes, but if there are lots of reports running you may also have a problem with reads bombing one disk, so move directories around in that case as well. The I/O request queue indicates the magnitude of this problem.