On Thu, 16 Jun 2011 08:34:34 -0400 Julien Vehent <[email protected]> wrote:
[...] > > It's better now, it seems. It's been running for a few days without > devouring memory: > > $ ps -ylC dspam > S UID PID PPID C PRI NI RSS SZ WCHAN TTY TIME CMD > S 999 18378 1 0 80 0 17264 45464 ? ? 00:02:56 > dspam > > I did not change anything in dspam configuration, but I did tweak > postgres a bit, essentialy adapting the shared_buffer. I don't know how > that could have an influence on Dspam, or maybe it's just not related at > all. > It is! How high was your shared_buffer? You know that by default PostgreSQL is using (I think) 64 shared buffers each having 8Kb. Some operations lock the shared buffer and some don't. I guess that the maintenance task of DSPAM is heavy using the shared buffer and this results in such a high memory usage on your part. Remember that 'ps' is not always capable in detecting processes using shared memory and counts the shared memory as used memory. > I'm still curious about that valgrind command though, just in case it > happens again. > Just running the DSPAM server with valgrind would result in a insane amount of log data. Are you really willing do run it with valgrind? > > Thanks, > Julien > -- Kind Regards from Switzerland, Stevan Bajić ------------------------------------------------------------------------------ EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ Dspam-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspam-user
