Phil Leinhauser wrote:
> Eric Shubert wrote:
>> MagicWISP Sales wrote:
>>> I just wanted to thank everybody for their help. I had a qtp toaster
>>> running on VMWare on a Quad Pentium 2 machine – let me tell you that
>>> will not work. It was an experiment that got pressed into service as
>>> an emergency. Scan times after killing blacklists and ClamAV on
>>> emails of 222k were at 300 seconds, wow. It caused duplicate emails
>>> and all kinds of craziness, even after adding Spamdyke. I used one of
>>> Jakes tips on his video page and cut the scan time down to an average
>>> of 110 on the same email. Quite an improvement but still too high to
>>> be usable. I moved the VM to a temp machine this week, an old
>>> E-Machines computer of all things with an AMD Athlon XP 2000 processor
>>> with a whole 1G of memory, and scan times on the same message fell to
>>> 17 seconds. Again – still too high, but at least the duplicate emails
>>> stopped. I just used another tweak from Jakes video site and the scan
>>> time fell to 9 seconds, with the blacklists and ClamAV scans going
>>> again. That will work until the replacement server gets here next
>>> week. If you are using VMWare, you really need a higher end machine,
>>> I think that could be the moral of this story. The first server that
>>> was in use, had a sister sitting right next to it that ran the QTP,
>>> plus webhost, plus a radius server, and never ever broke a sweat.
>>> VMWare is a hog to say the least. Jake’s video subscription may be
>>> the best thing I have found for some quick instruction on usage of
>>> real world tweaks. Jake and Eric are always willing to help, and have
>>> great experiences to provide. Also a shout out to Brent for fixing
>>> the Spamdyke script – it works. Now if I can figure out how to make
>>> the smtp log change at midnight instead of whenever it wants, I will
>>> be happy. Great job all of you guys – you really are lifesavers!!!
>>>
>>
>> Thanks for sharing.
>>
>> Before I comment on this, I want to check the facts. This was a Quad
>> P-II, and not a Quad P-4, right? Just checking. Not that it would make
>> all that much difference. I'll have some comments to make regarding your
>> experience with VM guests soon.
>>
>> FWIW, I just migrated a QMT from one VM guest to another, on the same
>> host. The former ran nicely (and still does on another host). The new
>> QMT VM is a pig. I'm not sure what the problem is yet. Top takes 10% of
>> the cpu on the pig host, while on another guest w/ same kernel, top runs
>> less than 1%. So somewhere I'm seeing a ~10x performance difference
>> between 2 guests on the same host. It'll be interesting (to say the
>> least) to find the reason why. There are some differences between the 3
>> guests, but not too many. I hope to nail it soon.
>>
>
> I've determined that as long as the ram on the guest is less than 656M,
> the guest runs speedily. If it's over that, then performance degrades by
> a factor of 10. This threshold is not hard and fixed, as on another host
> the limit appeared to be 680M.
I'm afraid to ask how you came to that strange number...
Binary sort - splitting the difference between 2 values (768 and 640
initially) and testing each one. It's real easy to see when there's a
problem. 'top' takes 30-40% of cpu initially, then settles in at ~10%.
When top takes that much cpu, you know you have a problem. ;)
I did see you
mention that before somewhere but it was related to running on 32 bit.
Yeah, I made a note on the wiki about a 896M ceiling above which there
was a slight performance hit. I'm not sure which page I saw that on, but
it's probably somewhere in the reference links. What I was seeing was
not at all slight!
I'm running x64 host and guest and haven't seen anything like that. In
fact my QMT guest was running on 4G for a while and after watching it, I
saw it never really used more than a couple hundred meg. The rest went
to cache. I just knocked it back to 1G a couple weeks ago and it seems
to be just as happy and perky.
Yeah, QMT doesn't need all that much ram to run efficiently. I'm not
sure what a good number is yet. It'll no doubt depend on how many
messages need to be processed at once.
Are you running VMware Tools? I've narrowed the problem down to the
guest memory management module that's part of Tools. I installed it to
get the vmxnet device which is supposed to perform better, and the guest
memory manager was included. I'd like to use the e1000 virtual network
device, as that's supposed to perform best and doesn't require tools. I
haven't managed to get it to work yet though.
I'll also be looking further at open-vm-tools. They have the open source
components (which is most of) vmware-tools, and I think they're a little
more up to date. If I can get what I need from there, that'll be the
route I take.
>
> This appears to be an issue with memory management (duh). This VM guest
> has vmware-tools installed, which does have a guest memory management
> component. Could be a bug in that code. I'll be doing more testing to
> try identify the culprit, and post findings on the wiki.
>
I think that's a note worthy of the wiki. Most people don't understand
that the tools do more than video drivers. I'll add that...
Thanks.
> The difference in performance is rather astounding, and counter
> intuitive in that *less* ram runs faster. I'm sure there's a logical
> explanation, but I don't yet know what it is.
Haven't seen it in x64.
Good to know.
Phil
>
> --
> -Eric 'shubes'
--
-Eric 'shubes'
---------------------------------------------------------------------------------
Qmailtoaster is sponsored by Vickers Consulting Group
(www.vickersconsulting.com)
Vickers Consulting Group offers Qmailtoaster support and installations.
If you need professional help with your setup, contact them today!
---------------------------------------------------------------------------------
Please visit qmailtoaster.com for the latest news, updates, and packages.
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
