If you have Oracle Database deployed on Linux and have not yet settled upon collectl as your primary tool for system-level performance data collection, well, we need to have a long talk!
DISCLAIMER
I work for Amazon Web Services. The opinions I share in this blog are my own. I'm *not* communicating as a spokesperson for Amazon.
In other words, I work at Amazon, but this is my own opinion.
Pages
- About
- Index of Posts
- Misc
- Papers, Webcasts, etc
- SLOB Resources
- Little Things Doth Crabby Make
Blogroll
- AWS Database Blog
- Bart Sjerps
- Beat Ramseier
- Bertrand Drouvot's blog
- Daniel Westermann
- flashdba
- Franck Pachot
- Frits Hoogland
- Gokhan Atil
- James Morle
- Jan Karremans Blog (Johnnyq72)
- Jason Arneil
- Jonathan Lewis
- Luca Canali's Blog
- Mahmoud Hatem Blog
- Mark Smith
- Martin Bach
- Mauro Pagano
- Nikolay Savvinov
- Noons
- Pardy DBA
- Real World Technologies
- StorageIOblog (Greg Shulz)
- THE ORACLE ALCHEMIST
- The SQL Herald
- Tim Hall
Join 744 other subscribers
Recent Posts
- VMware Are Serious About Oracle Database Performance Characterization
- Little Things Doth Crabby Make – Part XXIII. IEC 60027 Still Makes Me Crabby!
- Microsoft Shares Oracle Database Direct NFS Capabilities with SLOB Testing Results
- Announcing SLOB 2.5.4
- Announcing SLOB 2.5.3
- (no title)
- Following Various Legal Action Regarding “Oracle Cloud Revenue”
- Announcing SLOB 2.5.2.4
- Announcing SLOB 2.5.2.3
- Announcing SLOB 2.5.2.2
Recent Comments
11.2.0.4
Automatic Workload Repository
AWR
columnar database
column projection
DBaaS
Exadata
Exadata benchmarks
Exadata ERP
Exadata OLTP
Exadata Storage Grid
Exadata Xeon 5600 Datawarehousing
HP Oracle Database Machine
Netezza
Netezza Oracle
NUMA
numactl
OOW12
OpenWorld
OpenWorld 2011
Oracle
Oracle Database performance XtremIO flash
Oracle Exadata Storage Server
Oracle Exadata Storage Server Software
Oracle I/O Performance
Oracle Performance
Oracle Programmable Storage Server
predicate offload processing
Random I/O
Sandy Bridge
SLOB
SLOB Testing
SUMA
Teradata
whitepaper
X2-2 vs X2-8
Xeon E5
Xeon E5-2600
Xeon E7 Performance
XtremIO
Copyright
All content is Β© Kevin Closson and "Kevin Closson's Blog: Platforms, Databases, and Storage", 2006-2015. Unauthorized use and/or duplication of this material without express and written permission from this blogβs author and/or owner is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to Kevin Closson and Kevin Closson's Blog: Platforms, Databases, and Storage with appropriate and specific direction to the original content.
Thanks for the tip. Any comments about why it is better then, for example, using NMON ?
Forget it π
As said, thanks for the tip and forget the stupid question about nmon.
π
Kevin, do you have any clue/idea how to monitor on Linux
1) read(2)/write(2) avg syscall time per running process (I/O completition, or lets better say to VM – yup, without O_DIRECT)
2) how to measure seqential vs random ratio for process/disk ?
3) VM ratio hit?
E.g. i could use something similliar to “strace -r -s 0 -e read,write -p ” for point 1 but would like it to being less intrusive.
For second, is there is any other option on Linux that writing dedicated ptrace(2)-based utility tracing lseek(2),read(2),write(2) ??
3) Any idea??????
Jakub,
Perhaps you might investigate OProfile? Strace single-steps processes so it is worthless in this regard.
Jakub – This probably isn’t exactly what you’re looking for, but a feature of collectl that I don’t think has gotten a lot of use its ability to show I/O by process, assuming of course you have a kernel > 2.6.22 that was also built with process accounting enabled. See http://collectl.sourceforge.net/Process.html for more details.
The reason I bring it up is you’ll at least be able to see a processes I/O rates as well as the number of I/O systems calls its doing if you select the I/O summary format.
And of course you can see it at the individual thread level as well if you so choose by including –procopts t.
-mark
Kevin,
Regarding single-stepping, isn’t the strace system call tracing done via trapping the syscall entry and return only and not via single-stepping the whole execution path?
Tanel.
…I’m talking about ptrace() PTRACE_SYSCALL option here…
Tanel, I think you are right. I wonder if my wires were crossed between it and truss (or if even truss does that)…hmmm…I’ll have to investigate and clarify. I’ve got single-stepping in my mind somehow…need to figure out why π
You’ve been debugging too much lately? π
I think truss doesn’t do single-stepping either, at least in Solaris, as it uses /proc/pid/ctl interface which supports setting breakpoint traps at specific system calls (there are ctl flags PCSENTRY and PCSEXIT).
Nevertheless, stracing / trussing critical (background) processes in production should require careful thought first as you can cause trouble to traced process (missed signals, failed IOs) as I’ve once evidenced here: http://blog.tanelpoder.com/2008/06/14/debugger-dangers/
Jakub, in addition to OProfile, if you’re on recent Linux (RHEL 5+ equivalent) then you can look into SystemTap. It is getting mature enough now for professional (non-hacker) use – on my CentOS 5.2 install it’s kernel and userland parts are preinstalled so I didn’t need to start patching and recompiling kernel (for which I just don’t have the time and will).
I’ve just been doing too much. Period.
Why don’t use SAR that is standard in all unices and well know to all system admins ?
mdx4 – I guess you still don’t get it and maybe won’t until you try collectl out and see for yourself. Can sar produce data in a format you can easily plot? Can sar collect data on infiniband? slabs? and other ‘less common but still critical’ types of data? can sar run at sub-second monitoring levels? can sar provide much of its output on a single line for easy reading? can you easily feed sar data to other programs over a socket in real-time? far too many other things to list. I think sar is fine at what it does, but there is so much more it doesn’t do and that’s why I wrote collectl.
-mark
Ok, thanks for valuable hints. I think that SystemTap is the long time solution, but I wanted to look at old systems too. It even seems that Oracle wrote some part of public SystemTap scripts π
I’ve started developing ptrace(2) (lseek/read/write, pwrite is currently missing) based fileops aggregation utility to trace I/O characteristic on fds , when I’ve hit strange issues in production (as Tanel mentioned) for Java apps, one even DoSed my whole system. Maybe sometime I’ll have time to finish & release it.
However I still get no idea how to calculate VM ratio hit over time…
I recently discovered /proc/buddyinfo, which shows how memory is fragmented, thought it useful and added it to collectly so now you can literally see in real-time how many fragments of what sizes are available. However I don’t have a real good feel for how much extra overhead is being generated by having too many small fragments and not enough larger one. Could it make a bigger difference for heavy data movers like oracle? Is this new look at memory fragmentation of use to anyone?
-mark
I wasn’t sure where to post this to I thought I’d tack it onto the end of this string.
I just released a new version of collectl that might even get Kevin’s attention because it now has a data collectl API. This means if there are any readily available Oracle specific stats, it shouldn’t be too tough (if you’re a perl programmer) to add them into collectl.
Why would you want to do this? That’s easy – imagine looking at some oracle data and cpu/disk/interrupt/ctx/etc data ALL at the same time either on your terminal or maybe even in a plot – yes, this mechanism allows your custom data to be recorded in plot format too.
You’re seeing Oracle I/O rates drop? Now you can watch linux stats and see if any resources are starved and causing your problems. Of course you could still do that without this feature but just think how much harder it would be.
-mark
Hi Mark,
Well, you know I’m a huge fan…didn’t know if you were aware of this or not, but collectl made the grade for inclusion into Exadata packaging. You really produced a winner with collectl!
Time for another update – a couple of weeks ago I open-sourced a set of utilities I had written awhile back for collectl, called collectl-utils. There’s a pretty good writeup at http://collectl-utils.sourceforge.net/ so I won’t repeat myself with what’s already stated there, other than to say there’s a very cool [my opinion] web-based plotting utility and another that makes it real easy to watch multiple systems at once. I even have a picture of watching the cpu load on 192 systems once a second, all displayed on a single very wide line (takes 3 monitors)!
This could also morph into a related discussion on visualization of data and monitoring intervals. I’m alway amazed how many people run sar at the default monitoring interval of 10 minutes and think they’re ‘protected’ because in the event of a failure they’ll know what went wrong. Even ganglia users tend to use coarser intervals of a minute or more and may not even realize they’re not seeing ‘the whole truth’ about what their systems are doing.
I’m a fan of 1-10 second intervals because they give you a ton of data and but you almost always have to plot it unless you know an exact time period to drill into. That’s why I made generating output as plottable data a key feature of collectl and also why I wrote colplot. Having tried a number of plotting tools I continue to be impressed with what a great job gnuplot does in terms of speed and detail. It’s plots may not be as ‘pretty’ as excel or ganglia but I think accuracy trumps pretty, which is something not all plotting packages can claim.
-mark
Hi Mark,
Love the kit! Updates always welcome here!
Hey Kevin – it’s been awhile but the wait has been worth it!
I’ve just rewritten my colmux tool, part of collectl-utils and if you haven’t tried it before I promise that with this rewrite you’ll never put it down. It’s always been able to monitor clusters of nodes by multiplexing collectl output from multiple systems into a single display, but I’ve now added the ability to sort on any column and present the data in a top-like manner.
The results are stunning! You can now look at virtually anything collectl can report across your entire cluster! Want to find a slow disk out of thousands? Piece of cake. Looking for memory leaks – just sort the process output by memory. How about an oracle process run amok – I haven’t tried that but I’m sure you will. π
If you want to see what I posted about it on sourceforge you can either look it up there or just click on this – http://collectl-utils.sourceforge.net/colmux.html
enjoy…
-mark
Hi Mark,
Great news. Thanks for the update and, of course, for the great work on collectl.