Poor FreeBSD Performance under cacti/snmp usage when using remote shell

hi folks,

I am observing that for a machine with the following specs:-

Copyright (c) 1992-2005 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 6.0-STABLE #3: Thu Jan 26 20:38:29 SGT 2006
root@xxxxxxxxxxxxxxxxxxxx:/usr/obj/usr/src/sys/IX-NW
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2791.01-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0xf29 Stepping = 9

Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
Features2=0x4400<CNTX-ID,<b14>>
Hyperthreading: 2 logical CPUs
real memory = 4160552960 (3967 MB)
avail memory = 4074123264 (3885 MB)
-- snip --
amr0: <LSILogic MegaRAID 1.51> mem 0xfebf0000-0xfebfffff irq 72 at device
8.0 on pci8
amr0: <LSILogic PERC 4/Di> Firmware 2.37, BIOS 1.05, 128MB RAM
-- snip --
amrd0: <LSILogic MegaRAID logical drive> on amr0
amrd0: 104034MB (213061632 sectors) RAID 5 (optimal)
ses0 at amr0 bus 0 target 6 lun 0
ses0: <PE/PV 1x6 SCSI BP 1.1> Fixed Processor SCSI-2 device
ses0: SAF-TE Compliant Device

configured with:-

em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=b<RXCSUM,TXCSUM,VLAN_MTU>
-- snip --
ether 00:0b:db:94:f8:65
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active

and running cacti/snmp applications (to poll 83 network devices/1831
interfaces in less then 9secs for every 300sec) is hitting these kind of
gstats

dT: 0.501 flag_I 500000us sizeof 240 i -1
L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps
ms/d %busy Name
46 315 0 0 0.0 315 5491 138.3 0 0 0.0
99.9| amrd0
46 315 0 0 0.0 315 5491 139.8 0 0 0.0
99.9| amrd0s1
46 315 0 0 0.0 315 5491 139.9 0 0 0.0
99.9| amrd0s1f

for consistently few minutes... while the memory condition is reported to
be:-

Active: 288006144 Bytes
Inactive: 3293306880 Bytes
Wired: 218345472 Bytes
Reserved: 5644288 Bytes
Cache: 192761856 Bytes
Kernel: 139264 Bytes
Interrupt: 8192 Bytes
Buffer: 117211136 Bytes

Total: 4078235648 Bytes
Free: 85340160 Bytes

my question would be is that an acceptible behaviour? i.e. should i look for
upgrade or is there a tuning which can still make something out of it?
because when i access this m/c for usual tasks of editing files and copy
stuff it sometimes hangs for few minutes..

it is a source compiled box with the following make.conf

--- make.conf ---
# apache
WITH_APACHE_PERF_TUNING=yes
WITH_THREADS_MODULES=yes
# libiconv
WITHOUT_EXTRA_ENCODINGS=yes
# php
WITH_GD=yes
# gd
WITH_XPM=yes
WITH_LZW=yes

# mysql
WITH_CHARSET=latin1
WITH_XCHARSET=latin1
WITH_PROC_SCOPE_PTH=yes
BUILD_OPTIMIZED=yes
BUILD_STATIC=yes

#mtr
WITHOUT_X11=yes
# snmp

NET_SNMP_SYS_CONTACT="shanali@xxxxxxxxxxx"
NET_SNMP_SYS_LOCATION="Telepark"
DEFAULT_SNMP_VERSION=3
NET_SNMP_MIB_MODULES="host smux ucd-snmp/diskio"
NET_SNMP_LOGFILE=/var/log/snmpd.log
NET_SNMP_PERSISTENTDIR=/var/net-snmp

#make
MAKEOPTS=-j4

#noprofile
NO_PROFILE= true
# added by use.perl 2006-01-26 21:28:26
PERL_VER=5.8.7
PERL_VERSION=5.8.7
--- make.conf ---

while cacti is doing pretty fine...

06/22/2006 06:10:09 PM - SYSTEM STATS: Time:7.9338 Method:cactid Processes:1
Threads:30 Hosts:83 HostsPerProcess:83 DataSources:3218 RRDsProcessed:1831
06/22/2006 06:15:12 PM - SYSTEM STATS: Time:9.7663 Method:cactid Processes:1
Threads:30 Hosts:83 HostsPerProcess:83 DataSources:3218 RRDsProcessed:1819
06/22/2006 06:20:09 PM - SYSTEM STATS: Time:7.6809 Method:cactid Processes:1
Threads:30 Hosts:83 HostsPerProcess:83 DataSources:3218 RRDsProcessed:1831
06/22/2006 06:25:10 PM - SYSTEM STATS: Time:8.2421 Method:cactid Processes:1
Threads:30 Hosts:83 HostsPerProcess:83 DataSources:3218 RRDsProcessed:1831
06/22/2006 06:30:10 PM - SYSTEM STATS: Time:8.6010 Method:cactid Processes:1
Threads:30 Hosts:83 HostsPerProcess:83 DataSources:3218 RRDsProcessed:1831

Any assistance on where to look for an appropriate tuning would be much
appreciated.

--
Best Regards.
_______________________________________________
freebsd-performance@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "freebsd-performance-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • [PATCH] Document Linuxs memory barriers [try #3]
    ... The attached patch documents the Linux kernel's memory barriers. ... I've tried to get rid of the concept of memory accesses appearing on the bus; ... barring implicit enforcement by the CPU. ...
    (Linux-Kernel)
  • Re: read vs. mmap (or io vs. page faults)
    ... not fit in main memory, and there are overheads related to the heuristics ... But because the CPU is underutilized, ... reasonably sized user buffer). ... You have to measure the actual overhead to see what the actual cost is. ...
    (freebsd-questions)
  • Re: Cost of calling a standard library function
    ... It accesses/reads memory using esi 4 ... > safly move it within the cache, without having to go via ebx. ... try it the same thing on a different earlier CPU, ... should check it out...for "tight inner loop" stuff, ...
    (alt.lang.asm)
  • Re: Uses for memory barriers
    ... of memory ordering are not all that helpful in explaining memory ordering ... Formal verification of a particular -implementation- is another story, ... My "seen" approach would work for all CPU architectures ... mutual-exclusion algorithms (with memory barriers added) would be examples. ...
    (Linux-Kernel)
  • Re: High memory
    ... memory and then copy it up above 1MB...but if you want to put ... outside the CPU, memory is seen in a completely different light...this ... 1MB with "real mode memory" labelled on it or anything...the actual memory ... the system bus to actual hardware devices...hence, ...
    (alt.lang.asm)