> This strikes me as odd, seeing as databases usually want all > the layers > below them to get out of the way as much as possible; they perform all > the caching they need themselves.
Except in the case of really large databases where the 31-bit ceiling is significant, or when the system is running in a virtual environment that does not expose all it's capabilities to the database engine. With 64-bit clean code, this may be different, but I haven't gotten to beat on the 64-bit Oracle for Z code yet. The database level caching approach quickly runs into the process size/disk buffer utilization problems that grow the virtual machine WSS (even with raw I/O, you've just traded the system queuing the buffers for the application queuing the buffers), and tends to generate the problem of getting stuck in the bottom of E3 with nowhere to go; symptom: database goes non-responsive. This approach keeps the Linux image smaller, and makes the resource starvation problem less common. It also allows 31-bit guests to take some advantage of large physical storage sizes indirectly (remember, 31-bit systems are limited to 2G storage). > In fact, Oracle was one of the folks who lobbied the most for getting > 'raw' (uncached by the Linux kernel) device access, and this did in > fact turn out to improve Oracle performance (on Linux/Intel). I would expect it to do so on Intel where there's no effective system level disk cache. Since MDC allows Linux I/O to effectively return asynchronously (even without async io in the linux driver and is active even during the Linux raw disk io) you win some nice gains, esp if the disk controllers also have the NVRAM DASDFW turned on. > Do you have performance data comparing the scenarios? Since it involves specific customers, we'll discuss that privately off-list, but yes, at least in 1 case so far. -- db
