EPrints Technical Mailing List Archive

See the EPrints wiki for instructions on how to join this mailing list and related information.

Message: #07697

< Previous (by date) | Next (by date) > | < Previous (in thread) | Next (in thread) > | Messages - Most Recent First | Threads - Most Recent First

Re: [EP-tech] New system, crashing periodically b/c MySQL Locking

This should do it:

 

SELECT

  TABLE_NAME,

  ENGINE

FROM

  information_schema.TABLES

WHERE

  TABLE_SCHEMA = 'doras';

 

If you've migrated EPrints config, or migrated databases, there might be some old-format tables hanging around.

 

Cheers,

John

 

From: eprints-tech-bounces@ecs.soton.ac.uk [mailto:eprints-tech-bounces@ecs.soton.ac.uk] On Behalf Of Fran Callaghan via Eprints-tech
Sent: 14 February 2019 15:38
To: eprints-tech@ecs.soton.ac.uk
Subject: Re: [EP-tech] New system, crashing periodically b/c MySQL Locking

 

Hi John,

 

Thanks for the very prompt feedback. I don't have a line in mysql.pm so I'll try setting that (to 3 or 4 as suggested). Interestingly the ideal solution is to "produce better SQL" but isn't it only eprints producing the SQL?

 

As for MyISAM I thought it was deprecated (or at least supplanted by InnoDB) the system was only built 6 months ago. Can anybody tell me how I can determine if it's using MyISAM?

 

Thanks again,

Fran

 

 

On Thu, 14 Feb 2019 at 15:28, John Salter <J.Salter@leeds.ac.uk> wrote:

Hi Fran,

A couple of things to look at:

In ~/perl_lib/EPrints/Database/mysql.pm, do you have a line that references 'optimizer_search_depth'?

If not, this might be useful: https://github.com/eprints/eprints/issues/120

 

 

If you already have that, what about the storage engines the tables are using?

MyISAM uses table-level locking, but InnoDB use row-level locking.

I did some investigations a while ago, and found that some queries that looked like they shouldn't lock a table were doing so for some reason (I cannot recall the exact details - but I don't think it's an 'eprints' thing - I could recreate the scenario in the DB directly).

 

Any of that help?

Cheers,

John

 

 

From: eprints-tech-bounces@ecs.soton.ac.uk [mailto:eprints-tech-bounces@ecs.soton.ac.uk] On Behalf Of Fran Callaghan via Eprints-tech
Sent: 14 February 2019 14:50
To: eprints-tech@ecs.soton.ac.uk
Subject: [EP-tech] New system, crashing periodically b/c MySQL Locking

 

Hi Everybody,

 

We have a (reasonably) new install that has been grinding to a halt every week or two. When I look at 'top' on the command line (Red Hat) mysqld is hogging 100% CPU. When I use mysqladmin processlist I can see a number of sessions queuing behind this...

 

| 104558 | doras | localhost | doras | Query   | 1587 | statistics                   | INSERT INTO `cache17312`(`pos`, `eprintid`) SELECT @i:=@i+1, `eprintid` FROM (SELECT `eprint`.`eprin | 0.000    |

The other processes (queued) are all waiting for table level lock and look like this...

 

| 105134 | doras | localhost | doras | Query   | 487  | Waiting for table level lock | UPDATE `eprint` SET `edit_lock_user`='1037', `edit_lock_since`='1550139932', `edit_lock_until`='1550 | 0.000    |

| 105135 | doras | localhost | doras | Query   | 486  | Waiting for table level lock | SELECT `eprintid`,`rev_number`,`eprint_status`,`userid`,`importid`,`source`,`dir`,`datestamp_year`,` | 0.000  

 

Eventually the max http processes is reached and the system crashes. The only remedy is to restart httpd and mariadb.

 

Any ideas what this insert into cache is and why it's locking the the system?

Thanks for any guidance

Fran Callaghan

Dublin City University

 

Séanadh Ríomhphoist/Email Disclaimer

Tá an ríomhphost seo agus aon chomhad a sheoltar leis faoi rún agus is lena úsáid ag an seolaí agus sin amháin é. Is féidir tuilleadh a léamh anseo. 

This e-mail and any files transmitted with it are confidential and are intended solely for use by the addressee. Read more here.

 
 


Image removed by sender.

Image removed by sender.Image removed by sender.Image removed by sender.Image removed by sender.Image removed by sender.

 

Séanadh Ríomhphoist/Email Disclaimer

Tá an ríomhphost seo agus aon chomhad a sheoltar leis faoi rún agus is lena úsáid ag an seolaí agus sin amháin é. Is féidir tuilleadh a léamh anseo. 

This e-mail and any files transmitted with it are confidential and are intended solely for use by the addressee. Read more here.

 
 


Image removed by sender.

Image removed by sender.Image removed by sender.Image removed by sender.Image removed by sender.Image removed by sender.