[MUD-Dev] Re: processors

Petri Virkkula pvirkkul at iki.fi
Mon Feb 1 09:35:52 New Zealand Daylight Time 1999


>>>>> "Diablo" ==   <diablo at best.com> writes:

Diablo> It's definitely not disk access. We barely access the disk at
Diablo> all. Nearly everything is held in memory. 

	Even if it looks so I think it would be wise to check your
	disk access patterns. An operating system can easily achieve
	100% read cache hit rate (provided that there are enough
	memory in the machine) but write cache rates are usually very
	much lower. And surely you are writing atleast something to
	your disks?

	JC Lawrence gave us a good example, but here is another:
	BatMUD used to run on a machine that has 200MHz UltraSPARC
	CPU. All CPU power was used by the mud, but that could be
	handle by limit number of simultanous players.

	While the mud is not writing big quantities of data into a
	disk, it does very regurarily write something, for example
	logs are written, players are saving their character and so
	on. That did not cause much of problem, UNTIL another process
	accessed the same physical disk. For example a simple a grep,
	find etc. caused the mud to slow down noticeably, even lagging
	badly.

	What I gathered from statistics was that the mud and the grep
	or find were competing to get their turn to access the same
	physical disk. Not only that, the physical disk was
	read to/written from very different places, thus after every
	read/write disk head had to be moved to a correct place. And
	because disks have generally bad seek times, both processes
	(the mud and a grep for example) were waiting for completion of
	seek and read/write done by the other process.

	To solve the base problem (lack of CPU power) we decided to
	buy a new machine. But we  also thought about the above I/O
	problem. One solution might have been to rewrite our game
	driver to use threads. That would have taken too much time, so
	we had to do something else.

	The solution to the I/O problem was to buy lots of memory, AND
	to buy four physical disks and to use disk mirroring. I am not
	sure how well that works, but atleast we thought that disk
	mirroring would make it possible for multiple processes to
	access a partition simultanously.


	Petri





More information about the MUD-Dev mailing list