Thanks for the reply, Tomasz.
We have now done some more performance tests working with pure C/C++
code, and the results we are finding seem to indicate that the disk
thrashing has to do with the OS disk cache, and not as a result of the
lo_open call. Notably, we have been unable to recreate the problems we
found with the size of the shared buffers affecting performance, which
confirms Tom's conclusions.
We still have a performance issue, but the latest round of tests
indicate a number of places we should try to tweak.
Thanks for your patience, Tom.
Regards,
Michael Akinde
Database Architect, met.no
Tomasz Ostrowski wrote:
On Tue, 22 Jan 2008, Michael Akinde wrote:
What I *do* see is that the process size as reported by "top"
quickly jumps to 900MB plus and then sits there. This is not a
memory leak though, it is just a side effect of the way "top"
reports usage of shared memory.
Also, since the blob is opened and closed, why does the process allocate
new memory to open a new blob, rather than reuse existing memory?
I think a process does not allocate new memory, it just uses his
shared buffer. The OS does not give physical memory for a process
immediately when it is allocated for example by malloc, it gives it
in chunks - only when it is first read or written to.
Regards
Tometzky
begin:vcard
fn:Michael Akinde
n:Akinde;Michael
org:Meteorologisk Institutt, Norge;IT
adr;quoted-printable:;;Gaustadall=C3=A9en 30D;Oslo;;0313;Norge
email;internet:[EMAIL PROTECTED]
tel;work:22963379
tel;cell:45885379
x-mozilla-html:FALSE
url:http://www.met.no
version:2.1
end:vcard
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
