The first thing I would do is to upgrade the Kernel, as per you r mail u said u were running 2.4.20-8, get the latest one for RH9 that is 2.4.20-31.9 SMP, and you might see a huge difference, if it doesn't work, then make sure you have properly indexed the colums, mytop is a great tool for diagnosis, also see the slow query log, play around with top and other OS tools, this should work if not switch to INNODB
Kishore Jalleda On 8/11/05, Aaron <[EMAIL PROTECTED]> wrote: > Hi all , > > I have been experiencing intermittent locking issues with MYSQL. It > appears that sometimes a query will lock reliease its lock, and is > causing other queries to wait and wait until the connection limit is > reached and i am locked out of the database. Has anyone ever had > anything like this happen? > > The setup: > Redhat 9.0 , Kernel 2,4,20-8smp > mysql-standard-4.1.7-pc-linux-i686-icc-glibc23 > MyISAM Tables (And unless InnoDB can support fulltext or some other > equivalent , migrating isnt an option at present) > ext2fs > > Our Datbase Activity: > We have a somewhat active website. > Things run fairly smoothly for the most part , although we do have some > slow queries from time to time. > We have far more selects than updates , but updates are still reasonably > active. > Frequently , an update will get locked while a slower query is running. > Sometimes we can experience a large backup waiting for a slow query , > but typically everything sorts out once the slow query finishes. > Rarely , however , a query will be in a "locked" state and will not let > go of its lock. Subsequent updates lock , and subsequent selects lock. > Eventually , if the above has happened , the connection table will fill up. > > We dont have any scripts that explicitly LOCK TABLES , aside from our > backup script which uses mysqlhotcopy. > Is it possible that the mysqlhotcopy LOCK TABLES could interfere with > the locking from the website activity? > > I apologise for the vagueness of this request , I really dont know what > direction would be best to further diagnose this. > If you have any advice , it would be greatly appreciated. > > thanks for your time! > Aaron > > > -- > MySQL General Mailing List > For list archives: http://lists.mysql.com/mysql > To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED] > > -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
