Question Client I/O metrics

[ron]

OE 10.2 on RH Linux

I have used VSTs to get a variety of database disk I/O statistics - but how about client I/O (ie, temp files). Is there a way to get this information too?

 

[Rob Fitzpatrick]

VSTs are relational views on database shared memory, so if it isn't in shared memory it isn't in the VSTs. The DB doesn't have info on what's happening with client temp files.

That begins to change in OE 11, as it has temp-table VSTs, but still no tables to tell you about temp files.

You can use the -y and -yx parameters to give you some info about temp file interaction, like the size of some client-side caches, number of times programs are swapped out, etc.

You can use -T to change where temp files are written and use -t to make them visible. With -t though, you will have to clean up the files yourself if your client crashes.

Without -t, you can use lsof -p <client PID> to see the file handles for the client process, and see the file sizes. You can't otherwise see them in a directory listing as Progress creates them as unlinked files.

If you want to optimize temp file I/O you could point -T to a tmpfs file system, so the I/O you do is in memory instead of on disk. You could also point other frequently-accessed client files there like protermap and convmap.cp, using Progress environment variables.

 

[TheMadDBA]

Turn on -t for sure. Easiest way to tell.

I am not a fan of memory file systems myself. Some are flaky and it isn't always easy to get that memory back for maintenance events.

But there are parameters to help skip most of the temp file io. And code fixes for a lot of other issues.

Once you find out which types of files are active there will be different solutions. Or maybe you will be pleasantly surprised that there isn't excessive io b

 

[ron]

Thank you very much for the replies; you have confirmed what I thought was the case.

I will probably make the temp files visible with -t. But unless I put them in their own file system I can't get I/O statistics. And iostat doesn't normally show i/o for tmpfs. But if I run iostat -p ALL 3 3 I get details against "ram0", etc - but what do all the "ram?" devices actually mean?

 

[TheMadDBA]

Honestly sizes greater than the defaults will give you most of the info you need. When you get a listing we can help you out from there. Most likely you will see DBI* files which means adjustments to -Bt and -tmpbsize are in order.

Ram0,ram1,etc are ram disks. By default they are created but not necessarily configured. You can check to see if any filesystems are mounted on /dev/ramX.

 

[ron]

I'm not keen to change anything just yet - because I want to be able to quantify any effect of what any change might cause.

I can move the client tmp files into tmpfs (being the only "available" file system I have) - but I'd still like to see what the I/O metrics are. Iostat shows me details for the hard disks - but not (by default) for tmpfs. If I specify iostat -p ALL I get "ram" items - but I can't find information to tell me what it means.

 

[TomBascom]

A lot depends on your OS and the available tools. About the only good thing about HPUX is "glance". It has a nice capability to show IO ops (both physical and logical) by filesystem. It's also pretty easy to see what is going on on a per process basis.

I have not found anything as good on other platforms and these days HPUX is almost irrelevant.

Turn on -t. See what grows. If there is enough activity to be concerning figure out why that temp file is growing and then increase the appropriate client side buffer or fix the corresponding code.

(Use "lsof" and/or "fuser" to figure out which temp files belong to whom. Use kill -USR1 <pid> to get a 4gl stack trace and find out what is going on in the code.)

 

[TheMadDBA]

Note that signal that Tom suggested will just generate the stack but not actually kill the process.

If you are just getting started with tuning the temp io is probably way down the to do list. But turning on -t and posting some findings would go a long way to knowing for sure.