Physical and Logical IO's

[Stojcevski Dejan]

Hi to all,
I have EVA3000 storage attached to rp4440 / 4GB RAM/ 2 x CPU 800 MHz.
On the LUN's comming from the EVA I have an Informix database.
All the logical volumes are evenly stripped between all the LUN's from the EVA.
My problem is that I see bigger number of physical IO's from the EVA than Logical IO's.
How is this possible? What should I monitor on OS level? Any parameters which are related with the issue?
Thanks.

[Pete Randall]

Logical IOs are buffered into memory - therefor you get multiple actual records with one logical read. The physical IOs are unbuffered and therefor there are more of them.


Pete

[Stojcevski Dejan]

From 4 systems I have with similar configuration (storage attached to the server) this is the only one with this behaviour. In every other system I have more Logical IO's than Physical ones.
And I have forgotten to tell you: logical volumes created on the LUN's - informix engine is using them as raw devices - no filesystem at all on them.

[Jan van den Ende]

Pete,

is that correct?

My understanding has always been, that a Logical IO is when the program does an IO (which usually IS to/from a buffer), while Physical IO is the actual data transfer between memory and storage (usually issued, completely transparant to the user or his program, by the OS storage subsystem).

Now, ONE read from a contigous storage can bring in enough data to satisfy several small program READs from the buffer, ( and something similar but more complex for WRITEs) so here, fewer physical READs occur than logical ones.
OTOH, some programs, notably db cachers, or backup solutions, issue physical IO (read or write) requests for VERY big chuncks of data.
Bigger than the max size of storage transfer.
Or, like in this case, a chunk (to be) stored over several stripe sectors.
Then, of necessity, the one logical IO is broken up (again, fully transparantly) into several (and that can be many) physical IOs.
Apparently, the latter scenario is seen here.

hth

Proost.

Have one on me.

jpe

[Stojcevski Dejan]

I agree with the last post.
In my case we are using raw (character) devices rather than filesystems. Having said that I suppose IO's will not go trough the filesystem buffers but truoght informix buffers directly to the storage. (correct?). Then what can be done in such a situation? All tricks on db side are already done. Somethisn on the OS level?

[Pete Randall]

On rethinking my answer, I believe I managed to get it backwards - sorry for confusing the issue!


Pete

[James R. Ferguson]

Hi:

"Physical" I/O is an actual fetch of data from a storage device such as a disk.

"Logical" I/O is a programmatic request for data satisfied by a memory (block, buffer) access.

A logical I/O may cause a physical I/O in the first place, or a logical I/O may retrieve a part of a block (buffer) of data from memory.

SAN devices (particularly) and the Unix buffer cache greatly reduce physical I/O.

One of the easist ways to monitor the ratios of physical and logical I/O is to use 'glance'.

Regards!

...JRF...

[Stojcevski Dejan]

Still the question stands: why there are more physucal than logical IO's?Not enough memory?

[Hein van den Heuvel]

>> All the logical volumes are evenly stripped between all the LUN's from the EVA.


What is the stripe size?

If a logical IO does not entirely fit in stripe then it will be split over multiple physical IOs each to their corresponding luns.

The multiplier I expect for logical to physical is:
Average IO size divided by chunk size (for the large IOs) PLUS average IO size divided by chunk size for the small IOs which happen to cross a chunk boundary.
I just made up that formula.
It is not accurate and should probably take an 8KB or DB page size into account.

Hope this helps,

Hein van den Heuvel
HvdH Performance Consulting.

[A. Clay Stephenson]

This is not all that an uncommon occurence --- especially on servers running databases with raw i/o. If doing buffered i/o, every logical i/o eventually becomes at least one physical i/o --- and ideally many logical i/o's result in few physical i/o's. This is referred to as "cooked" i/o. Every UNIX box will have some cooked i/o to handle routine OS tasks and loading of the application programs. Now consider the case of your database running raw i/o. There is still some routine non-database activity occurring and those are your logicals i/o but you have far more raw i/o in an active database and those are not logical i/o's.

[Jan van den Ende · Accepted solution]

Dejan,

>>>
Then what can be done in such a situation? All tricks on db side are already done. Somethisn on the OS level?
<<<

Maybe you should look at it from an entirely different angle.
What you are seeing looks GOOD to me!!
This is the reason striping was invented.

. You issue an IO request for "much" data.
Now, the disk drives are only as fast as they are. Compared to electronics, VVEERRYY SSLLOOWWWWW.
So, the trick is, to use some extra electonics to make the "logical" request for one big chunck into several (as many as you have stripe members) requests, each for the part of the data on every drive. Now, each drive operates at drive speed IN PARALLEL, so the various pieces of your data have a total aggregate arrival speed. All that remains is for the electronics to assemble it nicely back.

The only way to get rid of the relative many physical IOs is by getting rid of the stripe set. The price will be very reduced data throughput.
But will you want that??

Na zdrowie. (please correct into the right Macedonian spelling!)

Have one on me.

jpe

[A. Clay Stephenson]

Actually, striping should have nothing to do with the ratio of logical to physical i/o's under raw i/o simply because EVERY i/o is a physical i/o in that case. You really have little to "fix" here because it is expected behavior when a database uses raw i/o. You should actually still be buffering the i/o but the buffering takes place in the databases's shared memory areas rather than in the UNIX buffer cache.

Now something that you could try is converting your database files to use fully cooked files so that you buffer in both the databases's cache and the UNIX buffer cache but in most cases, well written SQL will do better by increasing the database cache and using raw i/o but in the cases where you have little control over the SQL, I have definitely seen times where cooked i/o plus large database cache performed better.

[Hein van den Heuvel]

Clay,

The original note states:

>> All the logical volumes are evenly stripped between all the LUN's from the EVA.

I read that as LVM based striping.
Say the chunk size is 64k.
Now ask for a single logical 128k raw IO.
Surely that will have to become two 64 K physical IOs in the best case when the IO starts at a chunk boundary.
If that IO woudl start after reading 8K already, then it would become 3 IOs : 48K from first chunk to first lun, 64K from second lun, final 8 K from 3rd lun (or back to first, with just 2 members). Because those physical IOs can be issues simultaneously this can be faster then 1 larger IO, if the data is from controller cache and with fast connection, or it could be slower is it causes multipl physical disk seeks.

Hein.

[Yogeeraj_1]

hi,

Can you please post some comparative numbers?

if the difference is not too large, this can be simply ignored.

kind regards
yogeeraj

[Bill Hassell]

As mentioned, raw I/O bypasses the buffer cache (and Informix typically uses raw devices for data). You will always see a *lot* of physical I/O's with Informix. But for a clearer picture of raw versus filesystem activity, get a copy of Glance and use it to look at your data rates.

Although you can do a bit of volume management by changing to striped volumes, the largest improvement will occur with database adjustments. For instance, the Informix defaults out of the box do not take advantage of large amounts of memory. The most important performance improvement is to increase Informix BUFFERS. Your Informix DBAs should also look at enabling async I/O, aka KAIO and be sure to adjust the kernel parameter shmmax as required. And of course, take a look at the slowest Informix SQL tasks to see if there are missing indexes, etc. Here are some other ideas:

http://www.managementsoftware.hp.com/products/spi/spi_informix/ds/spi_informix_ds.pdf
http://groups.google.com/group/comp.databases.informix/browse_thread/thread/430fd1e014caa581/cf3741adc00ef8f3%23cf3741adc00ef8f3

You may find that 4Gb is just not enough to realize the full performance of your rp4440 and EVA disks.