> We have a database was very slow suddenly, when I used truss and I find the > pread syscall from oracle > was slow (130+ ms). But the iostat and vxstat(we used veritas QIO) show > nothing abnormal. From vmstat we could see the sys cpu is very high.
There is a known issue with Oracle's ASM layer that can give this sort of behaviour. If this is the problem I think it is you need to speak with Oracle Support and get a patch/update from them. It would help if you could describe your infrastructure: Q: What OS do you have (uname -a) Q: What systems are you using? Q: What version of Oracle do you have? Q: Do you use Oracle ASM? Q: Do you see high service times in the Oracle AWR reports but not at the physical level (iostat,vxstat, or at the storage)? Q: Do you see the problem when large numbers of users connect within a small time period? Hint: Write some D to look at what happens once pread() is called and time each subsequent function. Use the 'flowindent' argument to DTrace to make things easier to see. Refine your D to look at the functions which are taking a long time (similar time to pread). Quantized graphs are particularly useful for the second itteration to show the distribution (in time) for each function of interest. If you are using ASM specifically look at the ksfdread(), ksfdshare(), & skgfqio() functions within the ASM Layer using the PID provider. Note you'll need Solaris 10 update 4 or higher for the PID provider. You'll also want to look at and time the open() system call using the SYSCALL provider. If you find open() is the thing taking the time then it's the Oracle issue I'm thinking of. You should really open a support call with Sun & Oracle for this to get some dedicated resource. -- This message posted from opensolaris.org _______________________________________________ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
