EPrints Technical Mailing List Archive
See the EPrints wiki for instructions on how to join this mailing list and related information.
Message: #05873
< Previous (by date) | Next (by date) > | < Previous (in thread) | Next (in thread) > | Messages - Most Recent First | Threads - Most Recent First
Re: [EP-tech] Too many connections
- To: "eprints-tech@ecs.soton.ac.uk" <eprints-tech@ecs.soton.ac.uk>
- Subject: Re: [EP-tech] Too many connections
- From: Jonathan Green <Jonathan.Green@nottingham.ac.uk>
- Date: Tue, 16 Aug 2016 09:08:24 +0000
Likewise thanks John that was really interesting about what can cause a backlog. Certainly a bit of knowledge worth keeping in mind. Also >2500 authors! And there was me thinking one of ours with >240 was a
lot! Cheers Jonathan From: eprints-tech-bounces@ecs.soton.ac.uk [mailto:eprints-tech-bounces@ecs.soton.ac.uk]
On Behalf Of George Macgregor Hi John and Jonathan – Thanks to you both for the detailed replies. John: You’ve definitely given me something to investigate here as I think we are on MyISAM - thanks. Time to perform some checks!
J Cheers
From:
eprints-tech-bounces@ecs.soton.ac.uk [mailto:eprints-tech-bounces@ecs.soton.ac.uk]
On Behalf Of John Salter Hi George, My understanding is that the database max_connections is something that should be tuned in relation to your Apache config (and both should be tuned to the server resources available). Recently we had been suffering with some performance issues. We were hitting our Apache MaxClients – but the root cause seems to have been the database: We were using MyISAM tables (the MySQL default when we implemented EPrints). The following sequence of events caused us problems: 1.
Slow SELECT query (possibly from generate_views, but there were a few other possibilities – a paper with >2,500 authors…) 2.
Update on table included in above SELECT (whilst it was still running) 3.
SELECT on above table MyISAM can handle parallel SELECT queries on the tables without any problem *until* you throw an UPDATE into the equation. MyISAM uses table-level locking, and the UPDATE will wait for the slow SELECT
to complete, and the other SELECTs get queued behind the UPDATE. If you have a MySQL session open when you hit a max_connections issue, do a: mysql>SHOW PROCESSLIST\G You might see a query in the ‘sending’ state (that’s been running for a while) and a lot of ‘waiting for table lock’ entries. If you do, you may well be seeing the same issue we had. We have altered our database tables to use InnoDB (which is the default MySQL engine since 5.5.5), but you’ll need to understand what you’re doing when updating it if you go down this route… I posted recently on this list about a [dataset]__index tables missing a primary key – I discovered this as part of the planning to move to InnoDB. Cheers, John From:
eprints-tech-bounces@ecs.soton.ac.uk [mailto:eprints-tech-bounces@ecs.soton.ac.uk]
On Behalf Of George Macgregor Hello colleagues. Occasionally our EPrints suffers the “too many connections” MySQL connection error. In the past when EPrints has suffered this error my assumption has been that there is a query hanging which then has a knock on effect on other queries
as they can’t write to a table. We currently have max_connections set to 300 (which seems like a lot) but I can observe from previous chatter on the list that some go up to 1000. I was therefore wondering what the community considered to be an appropriate
connection limit? Given all the traffic I can observe it is conceivable – however unlikely - that 300 is insufficient. Have others observed something similar?
Thanks in advance!
-- George Macgregor Information Services Directorate | University of Strathclyde Curran Building | 101 St James Road Glasgow G4 ONS Tel: 0141 548 3496 Email:
george.macgregor@strath.ac.uk Web:
http://personal.strath.ac.uk/george.macgregor/ Twitter:
@g3om4c orcid.org/0000-0002-8482-3973 Ensure that your research outputs are eligible for submission in the next REF.
Authors' accepted manuscripts of journal articles and conference proceedings accepted after 01 April 2016 must be deposited in PURE as soon as possible after acceptance for publication – email
openaccess@strath.ac.uk for further information or visit
http://www.strath.ac.uk/openaccess. -- The University of Strathclyde is a charitable body, registered in Scotland, with registration number SC015263 This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. |
- References:
- [EP-tech] Too many connections
- From: George Macgregor <george.macgregor@strath.ac.uk>
- Re: [EP-tech] Too many connections
- From: John Salter <J.Salter@leeds.ac.uk>
- Re: [EP-tech] Too many connections
- From: George Macgregor <george.macgregor@strath.ac.uk>
- [EP-tech] Too many connections
- Prev by Date: [EP-tech] MySQL 'row size too large'
- Next by Date: [EP-tech] REFCC plugin functionality question
- Previous by thread: Re: [EP-tech] Too many connections
- Next by thread: [EP-tech] Simple Searches and send_alerts
- Index(es):