Chapter 4. Solutions and Sizing

This chapter proposes an help for sizing NetServers under Linux, depending on the different kind of use.

You have to consider that exercise as a bit perilous. Indeed, only the reality allows to test such previsions. Nevertheless, using the experience acquired by deploying solutions in the past, we can give some useful rules.

We may apply a certain number of rules valid for the sizing of classical Unix servers, considering that CISC systems (the majority in Linux environment) need 2.5 less times resources in memory than RISC systems, due to the fact that binaries used are smaller (Intel platforms are for the moment 32 bits architectures). This has also influences on disk and swap space.

It's obvious you have to consider, whatever the system, bottlenecks of the solution put in place, because they will determine the weakest link in the chain.

You have to look particularly at the following points :

• The number and the speed of disks (the I/O rate of 10.000 rpm disks may go up to 20 MB/s, and 25 for 15.000 rpm disks),

• The number and the speed of SCSI controlers (the I/O rate of Ultra2 LVD of the LC2000 - LH3/4/3000/6000 may go up to 80 MB/s, and latest B model up to 160 MB/s),

• The addition of a supplementary SCSI card supported, when adding slow peripherals (DAT, DLT, CD writer ...) in order to avoid that the controler slow down in compatible mode, and that I/O performances drop significantly.

You have also to be suspicious of the extensible functions of machines. Indeed, it's often better for a customer to add a new server, rather than to increase the capacities of the one in place. The first reason is a financial one, on one side, because the costs of add-ons on an already old system may be near those of a new system, whose prices are becoming cheaper and cheaper. And the same for maintenance. On the other hand, technically, it could be more interesting to benefit from the latest technologies to obtain a machine more equilibrate, powerful and to reuse the old one for secondary tasks (secondary DNS, ...) or to split processes from the other one. For example, when Ultra2 LVD was introduced, it was more interesting to buy a new server to benefit from the 80 MB/s SCSI bus speed, rather than to update a server which had 40 MB/s Ultra Wide SCSI. This implies that it's interesting to size correctly the server, from the begining, for the whole forseeable period of life of its use (typically 3 years nowadays).

In the same kind of ideas, you have to examine closely the choice between a bi-processors and two mono-processors machines. 2 different systems imply 2 disk controlers, 2 disks set, 2 separate RAM busses thus better performances, but more administration. On the other hand, a unique system renders it easier, allows for a quicker communication between processors, which could be necessary for certain applications, but makes the environment more fragile (more downtime in case of an hardware problem). In fact, there are more losses intrinsically on a multi-processor model, in communications at the system level. This question should mainly be considered for the addition of a processor (necesseraly obsolete) on a machine a posteriori, rather than to add a new server.

On memory aspects, Linux can manage today up to 64 GB in stable kernels. Linux takes the maximum from the memory you give to it, mainly by the constitution of a cache disk which improves greatly system performances. You may thus oversize the quantity of RAM installed, because it's preferable to a situation where the server would be forced to swap (which drop performances dramatically). The minimum RAM size provided on the NetServers (128 ou 256 MB) matches perfectly a normal use of a system, and doesn't need any particular addition. You have to take in account that there is no graphical environment used on production servers. Concerning the swap, under Linux, it comes in addition to the RAM to give the complete virtual memory available for the server. As a base rule, it's recommanded to give the same amount of swap space as the amount of RAM, to allow the system to put on disk nearly all the running processes in case of need. But the rule which exists for System V Unix (such as HP-UX) consisting of reserving twice the amount of RAM for swap isn't useful under Linux. You may note that Linux may swap certain inactive processes to free the maximum RAM possible. So having a system whose swap is partially used isn't necesseraly a proof of lack of memory, nor lack of performances.

You'll find below recommandations depending of the type of use made by the HP NetServer under Linux. It's possible to cumulate several functions on the same server. You'll take care to add at least in that case the resources needed to give the services.

Some generic rules have to be considered :

• We consider that the number of simultaneous users is the same as half the whole number of users on the server.

• The minimal RAM size needed for a usable Linux server is 32 MB, which is less than the minimum amount of RAM available on the NetServers (128 MB). In case you use X-Window with KDE or Gnome on this machine, you need to have 64 MB in supplement, thus 96 MB as a minimum.

• The minimal disk size needed for a usable Linux server is 2 GB, which is less than the minimum amount of disk available on the NetServers (9 GB).

• In case of use of Raid 1, you have to double the amount of disk space useful to obtain the disk space needed. In case of use of Raid 5, you need to add 1 disk to obtain the disk space needed (up to 8 disks).

• Except in particular cases (computing server), the amount of swap is the same as the amount of RAM.

• The minimal processor needed for a usable Linux server is a Pentium 133, which is less than the minimum processor available on the NetServers (Pentium III 933).

• Each X-Window user excuting a client on the server uses in average 2 MB.

• It may be useful to add network cards in this type of machine to smooth the traffic, depending on the number of clients. Using the bonding option provided by the Linux kernel may also be very useful.

You may also consult the linux performance tuning document provided by Adrian Likins