[GE users] mysql path + arco issues
alena.plestilova at sun.com
Tue Feb 17 12:35:42 GMT 2009
> On Fri, Feb 13, 2009 at 08:53:29AM +0100, aja wrote:
>> http://gridengine.sunsource.net/howto/arco/arco_mysql.txt ?
>> You can find useful information there.
>> Especially, do not forget to configure MySQL server to use InnoDB as the
>> default storage engine!
> A question and an issue for the Arco gurus...
> 1. Back when we installed Arco, the install guide made little distinction
> on the engine used for MySQL. From Aja's comments above, it appears that
> this is a big deal. What features/engine characteristics is Arco
> using where InnoDB matters over the default (MyISAM)?
> (My current cluster/Arco uses MyISAM and I want to understand if
> it's worth it to convert the tables to InnoDB...)
The storage engine should support transactions, MyISAM does not support
> 2. If dbwriter dies (for whatever reason), we've seen that the cleanup process
> never catches up. In poking around, we see (for example):
> SELECT hv_id FROM sge_host_values WHERE hv_time_end < '2008-02-16 14:00:00' limit 500
> as a sub-select of a DELETE. Why is the SQL code structured this way?
> On a small-medium cluster (100 nodes/400 CPUs) the sub-select can take
> several minutes to run (our sge_host_values table is 110M rows).
> Why limit each sub-select to 500? When we get into this state, the
> cleanup never catches up and thrashes the DB. I go in by hand and
> run the delete with a WHERE clause (no sub-select, no limit).
> -- Cris
The limit was added due to the issue
I don't have much experience with Mysql database so I will appreciate
yours, do you think it won't cause any problem when the limit is removed
from delete statement for Mysql?
If you have problems with deleting data I can recommend to disable
deletion rules and delete them manually or write a script which would do it.
aja & sun
e-mail: aja at sun.com
To unsubscribe from this discussion, e-mail: [users-unsubscribe at gridengine.sunsource.net].
More information about the gridengine-users