System Cpu Between 50-70% and need to find out why
Paul
bsdlist at cogeco.ca
Tue Apr 24 01:04:24 UTC 2007
> > options QUOTA
>
>This is going to make filesystem operations very slow. It is fixed in
>7.0 and might be backported at some point. kib@ may be able to
>provide a patch again 6.x that you could test.
>
>Kris
Dear Gentlemen,
I appreciate your suggestions today. Unfortunately I had to dump the
6.2 and scale back to the 4.12 for now and possibly for good as I
could not find a solution.
Just for point of reference here is a snapshot of the 4.12 box (see
below). Notice the 98% idle. This is what I experienced in the old
box. Most of the time it was idle in a range of 20-70% during busy
times and 70-90% idle during non busy times. On the new box it was
hardly ever idle. I still am not sure what was wrong but we had a
difficult time simulating this as it was quite well tested.
Today, when all I had was qpopper actively running on the new 6.2
"super" machine it was choking on the system being 50-70% used. The
only reason I point this out is to comment and be complete on this
thread on the belief that I would expect 100% usage on the new
freebsd 6.2 amd64 with the double dual core xeon processors
(technically 2* the cpus) and 4* the ram. This is in no way a
complaint on the suggestions that were given.
I have a hunch it was an issue with the speed it was able to write to
the disk as qpopper moves the mail files from the /usr partition to
the /var partition during transfer. This works just fine on the old
machine but it was not working fine on the new machine. I am still
unclear as to why this was not visible in the drive statistics (which
seemed normal) and was visible in the CPU usage. Everything on the
new 6.2 server seemed to take a lot more cpu percentages as a matter
of visual inspection for the same versions of the 32bit i386
programs. In the old freebsd 4.12 server rarely would a process
take >20% cpu. On the new 6.2 I commonly saw 20-50% for simple
qpopper processes.
I am going to try and reproduce the errors in a non-live environment
to see if there is a fix for these problems. For people looking to
roll out a 6.2 stable system on the Intel S5000PAL dual core Intel
platform using SATA II on the amd64 branch be forewarned it may not
be simple given my experience. Before the areca card arc-1130d, I
tried an Intel raid card SRCS16 which in my opinion on Freebsd gave
poor performance on disk transfers during tests for Raid 5. The areca
card on the benchmarks and install seemed to be quite superior for
every test. I even had a 1gig chip installed in the raid card to take
advantage of the extra ram for caching.
I made an effort on this system to get everything up-to-date for all
firmware and to the best of my ability configured "right" over the
last 3 months. It is unfortunate that it seems to be a shadow in
comparison of the old slower 4.12 box. Clearly I must have had something wrong.
If anyone has some tips on how to try and reproduce the errors I
would greatly appreciate it.
Regards and in appreciation for your efforts and suggestions thus far,
Paul
last pid: 40347; load
averages: 0.44, 0.66, 0.59
up 0+05:30:50 20:37:27
127 processes: 2 running, 125 sleeping
CPU states: 0.0% user, 0.0% nice, 0.9% system, 0.4% interrupt, 98.7% idle
Mem: 1355M Active, 1937M Inact, 191M Wired, 180M Cache, 199M Buf, 235M Free
Swap: 400M Total, 400M Free
PID USERNAME PRI NICE SIZE RES
STATE C TIME WCPU CPU COMMAND
40276 spamfilter 2 0 144M 143M sbwait 0 0:02 2.64% 1.95% perl
39569 vscan 2 0 51940K 45896K accept 0 0:03 1.42% 1.42% perl5.8
1095 nobody 18 0 52340K 39128K lockf 0 0:21 0.98% 0.98% httpd
39643 vscan 2 0 50864K 44920K select 0 0:02 0.63% 0.63% perl5.8
19715 root 2 0 47852K 43548K select 0 1:19 0.59% 0.59% perl
39880 vscan 2 0 53516K 47412K accept 0 0:03 0.54% 0.54% perl5.8
39977 vscan 2 0 53600K 47512K accept 0 0:02 0.54% 0.54% perl5.8
489 root 2 0 14248K 12892K
poll 0 28:52 0.39% 0.39% bbackup
40097 user1 2 0 2704K 2268K sbwait 0 0:01 0.05% 0.05% qpopper
More information about the freebsd-smp
mailing list