Thanks, Kai, for you great comments.
Ron Smith
[EMAIL PROTECTED]
"Having an email problem is painful, but character-building."
On Jul 26, 2008, at 8:31 AM, Kai Schaetzl wrote:
Finally: figures :-)
These figures do not indicate any problems. That "inactive memory"
is -
according to the explanation link you gave - what we call "buffers" in
Linux. However, it's not the same "buffers" that free shows. Growing
buffers tells there is enough RAM available to let it grow. There's no
indication that there is a memory problem.
That's been my perception when I look at the figures, though the
actual performance hits during peak mail throughput had given me pause.
Few "free memory" doesn't mean anything on Unix-like systems. That's
what
they are programmed to do, keep as much as possible in the buffers.
Only
when your used swap (VM) increases to more than 10% of the available
swap
there *might* be a problem. Please run "free" (I hope that is
available on
Mac, too), that will give much better figures about RAM usage than
top.
The figures from Activity Viewer you quoted are *very* suspicious, I
wouldn't trust them at all. It's interesting that they all fluctuate
around 600 MB. Very suspicious.
Hmmm. That's interesting and notable. I must bear that in mind as we
continue to test. However that is a common number to see among all the
Mac servers that I run.
As Joanne already pointed out that mdworker process takes a lot of
memory.
That was probably the reason why you had to up the RAM in this
machine.
According to the given links it's a realtime content indexer. Hell!
That
means it indexes every mail and every file that gets created/changed
on
your machine! The more mail you get the more mdworker will do! If we
are
not very mistaken *that* is the source of your problem. What's
relevant
for your problem is not the memory, it's the load! I expect that
load to
grow heavily when you get mail because mdworker grabs a good portion
of
your cpu indexing it.
Spotlight (mdworker) doesn't index any of the incoming mail because it
is located in the /var/CommuniGate/ directory. When I view it in real
time, it fluctuates very minimally and rarely can I recall ever seeing
it above 0.3% CPU time. Usually it is 0. The indexing is done
primarily on home directories and since this is a server, nothing is
added to my directory save any rare file that I put there that
pertains to the server software itself.
You can see the load in top in the first few lines. There are two main
figures. % idle shows how much your system is idle, if it decreases
your
CPU is getting used. If it stays constantly low that means that your
CPU
is in heavy usage. Look at it while the system has problems! The load
average shows how much the system "has to work". It's calculated
from I
don't know what. It's a relative figure and needs interpretation.
Usually,
if it goes over 2 that means that the system is loaded, but still
working
at a reasonable level. Normally, it shouldn't stay at this level for
hours, though, and it should not go much higher, unless for short
peaks.
You can "calibrate" these figures by yourself by looking at the load
at
various times and correlating that to the current tasks and how the
machine behaves. F.i. if you tar cz a 1GB directory the load will go
up
very soon, maybe to 2, 3, 4, 5 and other task may becomne a bit
sluggish,
depending on your horse power.
Yes, yes. That's what I've been doing and why its so confusing. The
CPU usage does not rise under load. The cgserver process percentage
remains steady! That's been so confusing because the Queue files
continue to increase, but mail is not being delivered... unless I
stopped the spamd process.
The first figure is the current load, the other two are 5 and 15 (or
ten?)
minutes ago. The figures from this "light" system load are already too
high for my taste, I suspect that this "base load" comes from the fact
that this machine is not only a server but also runs GUI (X) and is
used
as workstation, too, at least temporarily (?).
No, it is not a workstation. I run no other GUI apps on it. Most of my
work is done with terminal, except to remote in to view the activity
monitor itself. The Activity Monitor has no effect on system
performance, CPU times or anything else that I have ever seen in all
the years I've run my small server herd.
If you want to run this system as a server you have to shut down as
much
stuff as you can that is irrelevant for that. And the no. 1
candidate is
that mdworker process.
I have that process set not to run on the next reboot, should the
current changes in the DNS of the machines network settings and the
changes in the spamd call prove not to resolve this issue. I would be
so glad NOT to find that that this is a memory leak issue. If this is
something so simple and stupid as me miss-setting the DNS server
preferences, then I deserve a swift kick!
I think if you want to use a Mac as a server you hit the limit where
it
suffices to use and know all the nice click-a-dee-click stuff that
Mac and
Windows have in common. You need to read up on the BSD-ish nature of
Mac
OS and how it works under the hood and how to use the unixish tools it
offers.
I don't think the issue is that the Mac as a platform. This same
server performed under a DDoS load just about a month ago that lasted
a week and a half and was STILL getting mail delivered. It handled
1000 smtp channels and only began to falter at 2000 to 2500. That's
another story to tell if you need help fighting DDoS off.
No as a server, I've always been VERY pleased over the years with the
performance and as I said this issue is very recent.
Thanks again so much for your kind comments, Kai.
Kai
