vmstat -s

[Ingo Duschl]

hello we got a K260 3 CPU with 3.2GB RAM and three Jamaica boxes with at least 20 Harddisk.
if i do vmstat -s igot a lot of
"total address trans. faults taken" and a lot of "device interrupts" a few 1000 in a few seconds after vmstat -z. can anyone help where to begin to search or ist this kind of normal.

[Mark Grant]

I think this is supposed to be like that. device interupts are just the way devices work.

I am guessing that total address translation faults taken is also OK. It probably means something like an "address translation" was attempted from cache or some place in memory and it wasn't there and had to be got from somewhere else instead.

Anyway, looking at the system I happen to be on at the moment, we have similar figrues to you.

[Nicolas Dumeige]

What are you looking for exactly ?

I mean, you've posted this thread on the database section, if you're using Oracle for instance, you can look at the V$_SESSION_WAIT to check an I/O bottleneck or use STATPACK...

Therefore my question, why are you monitoring interputs ?

[Bill Hassell · Accepted solution]

A typically busy database server can service hundreds to thousands of interrupts per second. If the number were lowered, the system would run very slowly. An interrupt can be anything from the internal time tick (which is used to check context switching between programs) to programs requesting services such as memory or I/O, to interupts from devices such as LAN or disk. Address Translation Faults are not bad things, they are the number of times that the CPU ran out of register space to map memory for a process. These registers are incredibly fast (they run much faster than regular memory) to provide page addresses for data. If a process is extremely large dozens to hundreds of megs, then the registers must be reloaded with different pointers quite often in order for a process to reach all areas of the requested memory. Each translation fault requires some time to load (many nanoseconds) and this delays RAM from getting the address setup. If these faults occur at thousands of times per c\second, the overall processing speed (CPU only) will slow down for that process.

The workaround for this is to change the executable to use large pages with the chatr command. NOTE: this applies only to processor chips that support large (changeable) page sizes (PA-8000 or later, or any processor that is 64-bit capable). To see the details: http://docs.hp.com/cgi-bin/fsearch/framedisplay?top=/hpux/onlinedocs/B2355-90655/B2355-90655_top.html&con=/hpux/onlinedocs/B2355-90655/00/00/65-con.html&toc=/hpux/onlinedocs/B2355-90655/00/00/65-toc.html&searchterms=tlb%7chit%7crates%7cimprove&queryid=20040319-063859

[Mark Grant]

Wow Bill, thanks for the interesting information. I'd like to offer you the ten points but it's not my thread.

Regards





P.S. No points for me on this one please.