Opsview Blog

Testing Opsview on a Sun Fire T2000

As Sun Microsystems partners we were given the opportunity to test drive one of the new CoolThreads servers. The Sun Fire T2000 we were delivered came with a six core UltraSPARC T1 processor, 2x 73GB SATA disks and 8GB memory. Next job - what to do with it...

We've deployed our Opsview monitoring software at a number of customers and have a good idea what level of hardware is required. Not suprisingly the main load is generated by the monitoring engine - Nagios 2. Generally we deploy on dual CPU (or dual core) servers running Linux or Solaris such as the Sun X2100.

We thought it would be interesting to test Opsview / Nagios 2 on the UltraSPARC T1, the results can be found in our White Paper.

GCC compiler optimisation

The GCC compiler offers a number of options that affect the speed and size of the resulting executable. This article shows how you can take advantage of these features.

Optimisation Flags

This sets which level of optimisation is performed on the executable

-O0 No optimisation is performed.

-O1 Performs most common forms of optimisations. The executable should be smaller and faster than with

-O2 Additional optimisation will be used. The executable should not be any larger than with -O1 however compilation will take longer and comsume more memory. This is the current default for GCC

-O3 Enables more expensive optimisations. These optimisations may increase the speed of the executable but will also increase its size. In certain circumstances these optimisations may actually make the executable slower. The only way to know for sure is to experiment!

-Os This enables optimisations that aim to reduce the size of the resulting executable. This is for systems with limited memory and diskspace. The because of size reduction the executable may run faster on these systems also.

-funroll-loops This option turns on loop-unrolling. This will make the executable larger and may increase its speed but this is far from guaranteed. Again, the only way to know is to experiment.

Changing these parameters will affect how the application compiles and may prevent successful compilation in some cases. If your application fails to compile try reducing the level of optimisation used.

System Architecture Flags

By using the -mcpu compiler flag it is possible to take advantage of processor specific optimisations. Examples include:

IA32
-mcpu=pentium4 For Intel Pentium 4 CPUs
-mcpu=athlon For AMD Athlon CPUs
-mcpu=c3 For VIA C3 used in many mini-itx systems

SPARC
-mcpu=supersparc Eg: Sun Sparcstation 20
-mcpu=ultrasparc Eg: Sun Ultra 1, 2, 5, etc

PowerPC
-mcpu=power Generic 32bit PowerPC CPU
-mcpu=power64 Generic 64bit PowerPC CPU
-mcpu=G5 Macintosh G5 system

As an alternative, the -march flag may be used to gain even greater levels of optimisation however it does not support compatibility with other CPUs in the same family so should be used with care.

A full list of supported CPU optimisations can be found in the GCC reference manual: http://gcc.gnu.org/onlinedocs/

Using these flags

To make use of the compilation flags listed above the environment variable CFLAGS should be set, eg:

$ export CFLAGS="-O3 -mcpu=pentium4 -funroll-loops"

If you want these changes to become permanent then add the above line to your ~/.bashrc file

Compliation Threads

The number of simultaneous compilation threads can be specified by the -j option, eg:

$ make -j 4 all

This reduces compile time on multi-processor systems as it can be set to make use of all available CPUs.

Reducing compile times with distcc

Found a great article at IBM DeveloperWorks about using distcc to dramically reduce C/C++ compilation times

http://www-106.ibm.com/developerworks/linux/library/l-distcc.html

We've been successfully using distcc to distribute compiles across three machines with an equivalent reduction in compilation time. Haven't managed to get distcc working across different hardware architectures yet (IA32 and UltraSPARC) but will post an update when we do.

The article is specific to Linux but the same principles will apply other Unix like operating systems.

OpenBSD Securelevels

Securelevels are kernel settings that prevent certain changes to a running OpenBSD system. They are designed to provide additional security and prevent common exploit methods such as manipulating kernel memory.

Securelevel -1
No additional security

Securelevel 0
Only used during when booting, functionally equivalent to Securelevel 1

Securelevel 1
This is the default.

- No user can write to /dev/mem and /dev/kmem.

- The raw devices of all mounted filesystems are read-only.

- The immutable (schg) and append-only (sappnd) file flags cannot be removed. Changes must be performed in single-user mode.

- Kernel modules cannot be loaded or unloaded (by default the kernel is monolithic so this is rarely an issue).

Securelevel 2

This offers the highest level of security. At this level there is a real tradeoff between extra security and system availability / flexibility.

- All raw-disk devices are read-only, not just those of currently mounted filesystems.

- The system clock cannot be set backwards or close to the overflow point.

- PF and NAT rules cannot be altered via pfctl.

- sysctl values cannot be changed.

In order to change PF, NAT and sysctl values must be performed in single user mode resulting in system downtime. This is fine for a stable firewall configuration (for example) but may not be acceptible in all circumstances.

Setting The Securelevel

To set the Securelevel edit /etc/rc.securelevel and set the parameter 'securelevel' to the required value, eg:

securelevel = 1

The Securelevel may also be raised while the system is running using the sysctl command:

$ sudo sysctl -w kern.securelevel=2

Encrypting OpenBSD virtual memory

Why would I want to encrypt my virtual memory?

OpenBSD is designed from the ground up as a secure Unix operating system and is often used for firewall and IDS deployments. Sensitive data including passwords can appear in memory as plaintext, this becomes a problem when memory is paged from RAM to the swap partition. In order to avoid sensitive data being stored in plaintext on the hard disk it is possible to encrypt the swap partition. This has a small performance impact so care should be taken on systems with limited RAM or high load averages.

How do I do it?

To enable VM encryption while the system is running, use the sysctl command:

$ sudo sysctl -w vm.swapencrypt.enable=1

To make the change permanent, edit the file /etc/sysctl.conf and set the following parameter:

vm.swapencrypt.enable = 1

This will take effect after the next system restart.