Linuxdoc Linux Questions
Click here to ask our community of linux experts!
Custom Search

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 :

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 :

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

4.1. Linux as file and print server

4.1.1. Linux as file server

The sharing service uses 2 MB of RAM, and 2 more MB per share. In case of a unique share (users space for example), it leads to a 2 MB consumption per user. In the proposed case, we estimate that each user has 100 MB of disk space on the server, with an evolution to 200 MB 3 years later. Processor resources used are relativeley small, an entry level model will be sufficient from that point of view. We will priviledge the I/O speed with Ultra 3 LVD SCSI at 160 MB/s, if the budget allows it, and 15.000 RPM disks.

Table 4-1. Sizing of a file server

Simultaneous users RAM size Disk size Machine example
1 - 100 312 MB 27 GB E800
100 - 500 1 GB 117 GB LC2000
500 - 1000 2 GB 216 GB LH3000

4.1.2. Linux as print server

The sharing service uses 2 MB of RAM, and 2 more MB per printer shared. In case of a unique share (One printer per user typically), it leads to a 2 MB consumption per user. In the proposed case, we estimate that each user prints simultaneously files of 5 MB in average, thus we need to have that space available on the server. Processor resources used are relativeley small, an entry level model will be sufficient from that point of view.

Table 4-2. Sizing of a print server

Simultaneous users RAM size Disk size Machine example
1 - 100 312 MB 9 GB E800
100 - 500 1 GB 9 GB E800
500 - 1000 2 GB 9 GB LC2000