Mapserver on Linux vs Windows

[Bill Binko]

Just a few thoughts...

Ed McNierney wrote:
> If all your data are coming from external SDE sources, outside of your
> control, then don't worry about those.  Pay attention to the
> configuration of your MapServer systems.
>
>   
Also, you'll need to be very careful about your network setup: even 
simple things like DNS resolution can kill you in this type of system.
> In your scenario, your MapServer systems will all be acting as OGC
> clients and servers.  In those scenarios, those machines will be doing a
> lot of disk I/O, writing data retrieved from the SDE boxes and then
> reading that data to build and serve output data.  As a result, you will
> have a lot of simultaneous reading and writing going on.  Each system
> will have a very busy disk subsystem.
>
> You will want a disk subsystem that has very low random seek times
> (since you'll be jumping around among multiple requests all the time),
> and can handle lots of simultaneous I/O requests.  Conversely, all your
> MapServer data is transient data used only to serve the current request,
> so you don't need to worry about redundancy or disk failure on your data
> disks.
>
> That sounds like a recipe for (a) a RAID 0 (striped) array of disks, (b)
> SCSI drives, and (c) high-RPM disks.  The RAID 0 array will give you
> excellent read and write performance.  It will give you no data
> redundancy, but you don't care about that.  You should opt for a large
> number of smaller disks rather than a small number of larger disks, as
> this will improve your performance.  SCSI drives will handle multiple
> I/O requests better than IDE drives.  And high-RPM drives (15K RPM) will
> reduce your seek times (and are another reason to use SCSI, as SCSI
> drives are generally available at higher RPMs).
>
>   
I'd actually consider moving off of magnetic disk entirely for this 
application.  Today, you can get common off the shelf server 
motherboards that will hold up to 64GB of RAM, and in the project size 
you're considering, you have even more options.

On a linux system, you can use ramfs very simply:

mount -t ramfs none /var/gis/tmp -o maxsize=2000000 

(2000000 = ~2Gb in bytes, you might try additional options like noatime, 
noexec, nodev, nosuid)

And use that as your IMAGE_PATH parameter.  (I believe all of the OGC 
client interfaces use the IMAGE_PATH space for temporary files, but you 
might want to check that)

If you have static data (such as base maps, or "common" shapefiles) that 
you use locally, you can always copy them (read-only) into a second 
ramdisk at bootup (with similar options).

With DDR2 4G memory sticks going for < $400, this may be a far less 
expensive option than the SCSI RAID path.

It's actually interesting to consider the fact that this could be a 
solid state device :-)   That would _seriously_ increase your uptime and 
reduce your maintenance costs including backup, recovery, etc. Just DHCP 
boot it from an existing server and store syslog output on a remote 
host.  However, that's going a bit afield, and may cause headaches in 
your IS department.

Just my $.02.

Bill