You are correct, this was a new build, with a later version of SA and migrated Bayes files.  It could very well be the case that Berkeley DB needs to be patched, or the data converted in some fashion.

I will say that in a VM environment, we tried to build gcc, and it took MUCH longer than on a physical box with the same processors.  VMware analyzed our data, and they determined that we should disable NPTL and use LinuxThreads instead (kb 1470).  This did help substantially, and though slower than the physical machine, it was acceptable.

I have tried this for SA, and it does seem to cut down the CPU required, so there is some hope.

Theo Van Dinter <[EMAIL PROTECTED]> wrote:
On Fri, Oct 27, 2006 at 09:10:28PM +0000, Mark wrote:
> > I run my SMTP server entirely in a VMware VM, and have *never* seen a
> > high CPU usage on that particular machine. I run Postfix, Amavis-new
> > 2.4.3, SA 3.1.7 and quite some plug-ins.
>
> I would run any of the "db_dump" or db_upgrade" utils for BerkeleyDB; or
> reinstall DB_File (and make darn sure it's compiled against the correct
> BerkeleyDB libs). At any rate, I myself would probably be more inclined to
> look into a BerkeleyDB issue than a Vmware one.

Yeah, I doubt there's an issue with VMware specifically (ESX++). My guess is
that if you're seeing different behavior between a physical host and virtual
host, there's something different in the virtual host -- different OS, libs,
perl modules, etc.

Obviously that won't be the case if you virtualized a physical machine, but I
seem to recall from the start of the thread that you migrated the data but not
the OS.

--
Randomly Selected Tagline:
My wife and I were happy for years. Then we met.


All-new Yahoo! Mail - Fire up a more powerful email and get things done faster.

Reply via email to