MiniM Knowledge Base | Jan 11, 2012
Hard Drive Configuration for MiniM
This article describes some tips for hard drive configuration for MiniM Database Server to improve overall server performance.
In most cases we are using only simplest hard drive configuration on the computer - single hard drive. But this is much slowest configuration of any possible.
Hard drive planning principles for heavy loaded server are based on the principles of file usage principles and are independent of the server type. First of all, administrator must determine what files are used by the server and file's usage modes.
If two files are located on the same hard drive, write or read operations with one file reposition hard drive head and this position is profitless for operations with second file. Using two (or more) this files on different hard drives allows I/O requests to be performed in parallel and each drives head is independent.
So, to improve performance of database system, we must use (ideally) one hard drive per each file, and split randomly used files per several hard drives. Of course, it is impossible and we must find compromise.
MiniM Database Server uses the following files:
If administrator is able to use several hard drives, he can place this files on different hard drives.
In depends of ability, I recommend place BIJ file on separate and fastest hard drive, but this drive may be with small volume.
Second, I recommend to find most widely used database and place data files on fast RAID array.
Third, I recommend to place journal directory on the separate hard drive.
Fourthly, I recommend locate executables and install MiniM instance on the system drive and all data files, BIJ and Journal locate on other hard drive.
Content of temporary database (TEMP) does not used after restart or hardware failure, so this data file may be located on RAM drive. If applications are heavy use this database, this option may improve performance without data lost. Note that RAM drive must be active before MiniM instance start.
And, last recommendation - check that application uses much more indices and randomly access real big globals, for example, application use many index structures. This type of access may cover all space in database much random. In this case I recommend (if it is able) plan to use database consisting of several extents and locate ones on different hard drives. This may significantly improve random access to database.Eugene Karataev