What is Statseeker
	Screenshots
	Hardware Requirements
	Statseeker's Approach
	An Analyst's View
	Software License
	Request a Free Trial

Unsupported Hardware/Configurations:

• VMware
• SAN (Storage Area Networks)

Server hardware requirements depend entirely on the size of the network being monitored and the type and volume of data being collected, stored and processed. Monitoring a small number of SNMP objects (e.g. a 10,000 interface network) and a couple of low volume NetFlow collectors will only require a current model commodity PC.

For best performance we recommend the following:

Up to 20,000 network interfaces and minimal NetFlow collection requirements:

• 64 bit Dual Core CPU, with 2MB of L2 cache for each core
• 2GB RAM
• 500GB Hard Drive
• Gigabit capable NIC

Up to 50,000 network interfaces and average NetFlow collection requirements:

• 64 bit Quad Core CPU, with 2MB of L2 cache for each core
• 8GB RAM
• 1TB Hard Drive
• Gigabit capable NIC

For more than 50,000 network interfaces or large NetFlow deployments, please contact Statseeker Technical Support for assistance.

For a detailed list of supported chipsets go to: FreeBSD Supported Hardware.

Statseeker does NOT recommend RAID 5 or 6 due to their relatively slow access speeds.

Statseeker RECOMMENDS the use of a single large disk or disks configured as RAID 0 or RAID 1.

Click here for more examples of Hardware Configurations.

A detailed discussion on hardware requirements follows:

1. CPU Type
   1. Number of CPU cores

      There are many different CPU types, clock speeds and cache configurations available today. Statseeker's pollers, packet capture and analysis modules, NetFlow collectors and databases use concurrent real time processing which can make use of multi core CPUs.

      Multiple CPU cores allow user initiated reports to be generated without effecting the real time data collection and processing.

      Virtual CPUs were available in many older Intel CPUs via the hyperthreading feature. Hyperthreading is not a real CPU core and provides no benefit to Statseeker. Make sure hyperthreading is turned OFF in the BIOS. Note: Your BIOS may use the term "Logical Processor" when refering to hyperthreading.

   2. 64bit vs 32bit

      Statseeker is designed, coded, profiled and tested on 64bit architecture. We do release a 32bit version but place a heavier focus on our 64bit stream.

      One of the major problems with the 32bit architecture is that it has a maximum physical memory addressable limit of 4GB. In practice, a 32bit PC is limited to 2 to 3GB of addressable RAM because peripheral devices such as video cards and disk controllers use chunks of the address space below 4GB and the RAM is remapped by the BIOS to above 4GB, which is out of the reach of a 32bit operating system. 64bit architectures do not have this severe limitation.

      Note: Many of the internal data types and structures in Statseeker are 64bit, and therefore the software will run faster when loaded on a 64bit operating system.

   3. CPU speed, cache size and memory speed

      The fastest CPU is not necessarily the highest clocked chip, but more a combination of CPU clock, cache size and main memory speed. L1 cache is small, but a lot faster than L2 cache, which in turn is a lot faster than accessing main memory. Code written to run mostly in L1/L2 cache can be orders of magnitude faster than code accessing main memory. Much of Statseeker's code is tuned to utilize CPU cache efficiently.

2. Memory Size

   Statseeker requires an ample amount of free memory to operate efficiently. Many of the modules allocate large amounts of memory.

   For example:

   • database processes map large files directly into active memory
   • the ping/SNMP pollers allocate ICMP/UDP socket buffers so bursts of incoming responses are not dropped
   • the pollers build all requests once at start up and leave them in memory
   • SNMP processes load the entire set of compiled MIBs into memory
   • processes which communicate via pipes allocate large read/write buffers
   • user requests load all the necessary data into memory before producing the relevant reports/graphs
   • the timeseries database performs its own background preemptive file read-aheads, which fill inactive memory with useful content before it is needed
   • netflow collectors allocate large UDP socket buffers so bursts of incoming packets are not dropped
   • each LAN Analyzer allocates large kernel and user process buffers

   If Statseeker runs short of free memory it will swap memory contents out to disk which will have a drastic effect on performance.

3. Disk Space

   Statseeker requires an ample amount of free disk space to operate efficiently. The various databases are made up of extremely large files and it is important that these files are written to the file system in a sequential order. When these files become fragmented, disk seek times will and database performance both drop off dramatically.

   It is important to note that the Statseeker time series database will utilize three times its maximum daily disk allocation size as part of its daily validate, compact, and backup processes.

   It is also important to note that the main consumer of disk space is NetFlow. Monitoring NetFlow on a busy core router that has many unique IP conversations/protocol combinations can consume an enormous amount of disk space quickly. Be sure to have a large amount of free disk space if you wish to deploy NetFlow.

4. Disk Speed

   For optimum performance, Statseeker prefers a disk with fast seek speed and a large on disk cache (16-32MB) to assist with large sequential reads and writes. The raw sequential read/write speed is determined by how fast the disk spins and the bit density on the platters. A larger disk (ie higher bit density) can read/write more data per revolution than a smaller disk (which needs to spin a lot faster to make up for the performance loss). There may be no performance improvement by selecting a smaller, often more expensive disk with faster transfer speeds.

   The two modern interface types are SATA (serial ATA) and SAS (serial SCSI). Statseeker runs and performs extremely well on a SATA disk so there is no need to buy expensive SAS disks.

   Note: A SAS controller is backwards compatible with SATA, so you should be able to plug a SATA II disk into a SAS controller without a problem. Vendors rarely mention this as they prefer to sell you the more expensive SAS disks.

   In practice, a SATA disk is as reliable as a SAS disk. Refer to the following Google disk reliability study: http://storagemojo.com/2007/02/19/googles-disk-failure-experience/

5. RAID

   Statseeker has done extensive research into various file system and RAID configuration combinations to determine optimum performance criteria and therefore recommend the following:

   1. Do NOT use any of the parity RAID configurations (such as RAID 5 or 6) as their performance can be ten to fifteen times slower. Statseeker will not operate correctly while a RAID 5/6 system is rebuilding itself due to its dismal disk performance.
   2. For pure performance, a striped (RAID 0) configuration with a 128KB stripe size will give a fairly optimal performance. Note: Many controllers appear to default to a 64KB stripe size.
   3. For redundancy, a mirrored (RAID 1) configuration will perform well. Depending on the controller, read performance will be better than a single disk as the controller can read different parts of a file from each disk.
   4. For both performance and redundancy, a striped/mirrored combination (RAID 1+0 or 0+1) with a 128K stripe size is best.

   Statseeker developers have performed a great deal of RAID testing using a single core 500Mhz LSI MegaRAID controller (Dell Perc 6 equivalent) and a dual core 1.2GHZ Adaptec controller, with batteries installed and write caching enabled. Both controllers performed well, but the cheaper LSI controller was a performance bottle neck in large six disk RAID configurations. All testing was performed using commodity 7200RPM 500GB SATA II disks.

6. Ethernet Controllers

   Use a Gigabit capable NIC. Do NOT use a 10/100Mb NIC. Our testing has shown that the performance of the pollers deteriorates when running on 10/100Mb NICs. The ping pollers maximum rate is reduced from more than 60,000 per second to 3,000 per second, a 20 times drop in performance.

7. Hardware Configuration Examples

   (Large Networks)

   This specification should scale to 50,000 interfaces and a moderate amount of NetFlow collection.

   • Motherboard
     • Intel DQ35JO Desktop motherboard with onboard Intel Gigabit NIC
   • CPU
     • Intel Core2 Quad Processor Q6600 with 2MB L2 cache per core
   • RAM
     • 8GB
     • 4 * 2GB 667Mhz DDR2 modules
     • Installed in pairs for 1066Mhz memory bandwidth
   • Disk
     • 750GB Seagate 7200RPM SATA II
     • 32MB on disk cache
     • raw sequential read performance of ~105MB per sec