return to OCLUG Web Site
A Django site.
December 19, 2007

Pythian
pythian
» Pythian Goodies: The Answer to Free Memory, Swap, Oracle, and Everything

I gave this talk at the UKOUG, and I have received a few requests to post the slides online. Instead of just posting the PowerPoint I took some time to give the presentation again (internally here at Pythian) and this time we recorded the session and we’re posting it here in a variety of formats. This is a bit of a departure from the typical Pythian Goodies, in that it is scripted, and there is a lot of content here in the whitepaper, but there hasn’t been a Goodie in a while so why not!

I’d love to hear from you, so please feel free to ask any follow-up questions to this post in the comments.

Abstract

Do I have enough memory? Why is my free memory so low? Am I swapping to disk? Can I increase my SGA (db cache) size? Can I add another instance to this server? Are my system resources used optimally? These are all questions that often haunt DBAs. This presentation is The Answer. It covers in detail the different types of memory, how to monitor memory, and how to optimally use it with Oracle. Multiple examples in the presentation demonstrate how certain actions on the database side cause different memory areas to be allocated and used on the OS side. Key underlying differences in operating systems approaches to managing memory will be highlighted, with special attention given to Linux, Solaris, and Windows. Using Linux as an example throughout, this presentation explains how to effectively use tools such as “top”, “vmstat” and “/proc/meminfo” to look into into a system’s allocation and use of memory.

Below you should see a flash video with me giving the session.

Download this presentation!
Powerpoint
IPod video (right-click and Save As . . .)
MP3 audio only

And below you will find the complete contents of the whitepaper. This is intended to be a good overall reference resource for how memory works in Oracle, using Linux as an example.

(more…)

These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Slashdot
  • Google
  • del.icio.us
  • Facebook
  • bodytext
  • Technorati
  • TwitThis
  • Reddit
  • Spurl
  • De.lirio.us
  • Furl
  • blogmarks
  • Ma.gnolia
  • E-mail this story to a friend!

November 29, 2006

Dave O'Neill
dmo
blog
» MIME::Parser memory usage

rjbs has been trying to improve Email::Simple's memory consumption, so I figured I'd give his test a try on MIME::Parser, just for the heck of it.

It's not a very good test for MIME::Parser, because Email::Simple doesn't itself do most of the stuff MIME::Parser does, but it's something.

Given the numbers he posted, for Email::Simple, I expected MIME::Parser to be much worse, but instead, for an 8MB message with 50 headers I get:

$ perl ./readmail-mimetools big.msg 
just started                : 1556  3384
after require File::Slurp   : 2564  4180
after slurping              : 18204 19812
after require MIME::Parser  : 21928 23460
after construction          : 37684 39236
So... the code over head for MIME::Parser is about 3.7MB, and we take just under 2x the message size for internal representation.

Trying again, with MIME::Parser's tmp_to_core and output_to_core turned off (this makes it litter your filesystem with temp files named "msg-22195-1.txt" for each MIME body) it's a bit better:

$ perl ./readmail-mimetools-noncore big.msg 
just started                : 1560  3384
after require File::Slurp   : 2564  4180
after slurping              : 18204 19812
after require MIME::Parser  : 21928 23460
after construction          : 29832 31412
So, what does this prove? Well, MIME-tools doesn't suck as bad as I thought. That's about it.