>> What Thomas is looking to define is a setup where an RAM would be the first >> device for the temp results (to enable much faster processing -- RAM disk >> has 100x IO of even an SSD!!), with any excess falling to an SSD or HDD. >> The approach/setup is perfectly reasonable -- it tries to place temp data on >> devices which will provide the greatest benefit. > > This is exactly what TempCacheLimit is about. Temp results are initially > stored in the server memory and then (after overflowing TempCacheLimit) > are swapped to disk (temp files).
The problem with TempCacheLimit in CS and SC is that it is per connection and thus IMHO: a) RAM usage is hard to predict as the number of connections is in the game, and b) each connection might have different RAM / temp cache usage requirements. A dedicated temp file storage faster than a regular hard disk, being it a RAM disk or SDD, with a fall-back to a regular disk in case the first and faster storage is exhausted, is more controllable from a maximum sizing planning POV, IMHO. As long as the TempCacheLimit used RAM isn't more efficiently used/accessed than storing temp data on a RAM disk, I would argue that usage of a RAM disk is the preferred way, because it easier to handle, especially with CS and SC. Just a thought. Regards, Thomas ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
