Memory cache Ubuntu 9.10 server x86 doesn't work as expected

Question

We're using an Ubuntu 9.10 server to transfer Ghost-image files. We configured it only with Samba. And the DOS-clients connect to Samba. The latest updates are installed and so far the servers is running fine.

When we image 10 pc's with the same image of 2 files of 2GB there's no disk activity. Everything is loaded in the RAM. There's 4GB in the server.

But when we use 2 pc's with 2 different image files of 500 MB (8x) files then there's a lot of continuous disk activity. The speed is lower.

So it seems that Ubuntu doesn't cache more then one big file. Are there settings to change this behaviour?

Answer 1

2x 8x 500Mb is more than your 4Gb machine is ever going to hold in cache, so it is unlikely that either of the two PC is getting much from cache (i.e. all the file reading is resulting in disk access).

Reading two files concurrently is going to be slower than reading one as the disks heads will need to flip from file to file - the effect this has on observed performance can be quite considerable unless you have solid-state drives where the effect is minimised due to the near-zero (relative to spinning disk based drives) random access latency.

2x 2Gb is still going to be more than your machine can hold in cache at any given time so is also not going to be fully cached. But a large chunk of it can be, so if machine 2 starts reading soon after machine 1 it will blocks cached during machine 1's read operations. With 100Mbit networking machine 2 is likely to be the same distance behind machine 1 in each file during the whole operation. With 1Gbit networking the drives may be the bottleneck in which case machine 2 will soon catch up and the two will alternate between which causes a physical read and which gets the cached copy of the blocks instead.

I suspect therefore that you are seeing disk activity in the first case (4Gb worth of reads) but there will be little by way of head movements so you will not actually hear the activity (if you are listening for the clicking of the drives to gage this) nor will the few head movements be enough to make you noticed a speed difference. By the time the first machine gets to the end of the transfer the start of the files will have been pushed out of the cache, but the second and subsequent machines either haven't started yet or have read beyond that point already anyway.

To speed this process up I suggest that you compress the image files (drive images tend to compress well unless the drives are encrypted, especially if you zero the free space before taking the image). It will make taking new images take longer but save you time in the restore process as it will make better use of the server's cache, will result in less disk activity even if nothing useful is in cache, and will reduce network load too (if you decompress on the client side).

Answer 2

I think the slow down your seeing is mostly due to the networking layer. Ghost uses multicast so imaging 10 computers with 1 image is the same as imaging 1 computer. But if you're broadcasting 2 images at once then both broadcasts are competing for network bandwidth.

That's not to say that disk activity has nothing to do with any performance you're seeing. I'm just offering another perspective.

Answer 3

David wrote:

2x 8x 500Mb is more than your 4Gb machine

In our test with a HP7700 and a HP7800 we have 2 images that are divided in (about 8) segments. Per image only one segment of 500 MB needs to be loaded in cache simultaneaously.

So 2x 500 is 1 GB. When a certain segment is completely loaded to the client, the next segment of 500 MB needs to be loaded. But we had much disk-activity. (With 1 big segment of 2 GB and only loading to HP7800's the server's disks are doing nothing...)

3dinfluence: we don't use multicast, each client loads directly from the server.