This isn't directly related to development but more part of Mifos installation/administration/configuration.
While working on issue 2098, I've been using a box with the following specs as a dedicated MySQL database server: * CPU: Intel Core 2 Duo (dual-proc), 2.2Ghz * RAM: 4GB * O/S: Windows something or other (probably XP?) * MySQL version 5.0.51b community edition * Lots of disk space, but not sure how fast the disks are Issue 2098 deals with a crashing and particularly slow batch job. During the batch job, MySQL was only using 50MB of RAM and 0% CPU, while the Mifos application was using as much CPU as possible. The Windows Task Manager reported total I/O read bytes by the MySQL instance on testblue since it started as 1.14 TB. Since I'm assuming there isn't much number crunching going on in Mifos, and given the information at http://dev.mysql.com/doc/refman/5.0/en/innodb-tuning.html , I'm guessing there are two major performance problems: 1. Mifos is generating lots of unnecessary database traffic during normal operation 2. MySQL is disk bound We are always working to improve the first item, but the second one should hopefully be more of a "quick fix". I've never done MySQL performance tuning, but after searching the Web a bit it seemed apparent that increasing innodb_buffer_pool_size, innodb_log_buffer_size, and innodb_log_file_size should give us a good start towards leveraging RAM to reduce server disk I/O. Even if this doesn't speed up Mifos, it should help performance in any case where MySQL is the bottleneck. Note that in every case I /have/ monitored performance, the Mifos application appears to be the bottleneck. At any rate, it is important to mention that when modifying innodb_log_file_size, you must cleanly shutdown MySQL and delete the existing InnoDB log file. The process is outlined in detail here: http://dev.mysql.com/doc/refman/5.0/en/adding-and-removing.html The names of the logfiles on my system were ib_logfile0 and ib_logfile1. I just moved them to the recycle bin in case something went wrong and I had to revert back to the previous InnoDB log file size in the config file. While MySQL was stopped, I adjusted the settings. When it restarted, it automatically rebuilt the InnoDB log files. Here are the only settings I added that differ from the default my.ini shipped with this version of MySQL: innodb_buffer_pool_size = 1200M innodb_log_buffer_size = 8M innodb_log_file_size = 256M More resources that may be helpful in performance tuning MySQL: http://dev.mysql.com/doc/refman/5.0/en/innodb-parameters.html http://dev.mysql.com/doc/refman/5.0/en/innodb-tuning.html There are of course many more ways to tune the MySQL database, but unless it is clear that MySQL is the bottleneck, it doesn't make sense. Another interesting bit of information is that, in Mifos v1.1, no less than 88 (eighty eight) queries were performed to render a client detail page. The Mifos/MySQL conversation to render that page comprised 246,576 bytes of network traffic. Subsequent requests for the same client detail page yielded similar results. I'm sure Cheetah will have more intuitive caching and more efficient database traffic. -- Adam Monsen ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Mifos-functional mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mifos-functional
