At 07:22 PM 11/15/2010, John wrote:
> I have a hard time believing that writing tiny files affects 'performance'
Under the scenario I described, it occurs. Physical media can only
handle a certain number of IOPs, and with heavy disk access forcing
the write cache to fill and the OS to suspend further writes, every
transaction has to wait extra time. If you're curious to know more,
check out the documentation on vm.dirty_ratio for Linux (though I
mostly see this happen on Windows servers).
You're also missing the design limitations of the actual drives.
Assuming IDE/SATA, the disks do not support disconnected writes,
which is a significant performance bottleneck when you are writing to
the disk; only disconnected reads are supported. So that means
anything you write to cache you take a performance hit (and possibly
latency, as you only get 1 outstanding write for each drive, on a
RAID array, you get multiple writes (1 per disk))
SAS/SCSI drives have 128 concurrent writes (tagged command queue depth).
> I have no idea what baseline performance is in the context of a
game server.
The baseline performance in that case would be no background disk access.
mlock()? Memory backed filesystem that doesn't cause faults?
different drives? sockets? null?
> Writing anything to disk from cache takes a hit anyways, ie: TLB
hits/misses, etc.
I'm not talking about nanosecond-level differences when I talk about
delays from disk writes, as TLB hits/misses would cause. I'm talking
about multiple-millisecond delays. The typical SATA drive has on the
order of a ~10ms latency, and having to wait on a log write causes
noticeable "spikes"/delays.
See above.
> Do you know where the 'FPS' gets it's number from?
This was previously discussed.
gettimeofday(tv1)
usleep(1000);
gettimeofday(tv2)
(tv2 - tv1 * 10e5) / %1000 (IIRC, it's been a long time)
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlds_linux
