November, 2015
+ +2015-11-22
+ +-
+
- CGSpace went down +
- Looks like DSpace exhausted its PostgreSQL connection pool +
- Last week I had increased the limit from 30 to 60, which seemed to help, but now there are many more idle connections: +
$ psql -c 'SELECT * from pg_stat_activity;' | grep idle | grep -c cgspace
+78
+-
+
- For now I have increased the limit from 60 to 90, run updates, and rebooted the server +
2015-11-24
+ +-
+
- CGSpace went down again +
- Getting emails from uptimeRobot and uptimeButler that it’s down, and Google Webmaster Tools is sending emails that there is an increase in crawl errors +
- Looks like there are still a bunch of idle PostgreSQL connections: +
$ psql -c 'SELECT * from pg_stat_activity;' | grep idle | grep -c cgspace
+96
+-
+
- For some reason the number of idle connections is very high since we upgraded to DSpace 5 +
2015-11-25
+ +-
+
- Troubleshoot the DSpace 5 OAI breakage caused by nginx routing config +
- The OAI application requests stylesheets and javascript files with the path
/oai/static/css, which gets matched here:
+
# static assets we can load from the file system directly with nginx
+location ~ /(themes|static|aspects/ReportingSuite) {
+ try_files $uri @tomcat;
+...
+-
+
- The document root is relative to the xmlui app, so this gets a 404—I’m not sure why it doesn’t pass to
@tomcat
+ - Anyways, I can’t find any URIs with path
/static, and the more important point is to handle all the static theme assets, so we can just removestaticfrom the regex for now (who cares if we can’t use nginx to send Etags for OAI CSS!)
+ - Also, I noticed we aren’t setting CSP headers on the static assets, because in nginx headers are inherited in child blocks, but if you use
add_headerin a child block it doesn’t inherit the others
+ - We simply need to add
include extra-security.conf;to the above location block (but research and test first)
+ - We should add WOFF assets to the list of things to set expires for: +
location ~* \.(?:ico|css|js|gif|jpe?g|png|woff)$ {
+-
+
- We should also add
aspects/Statisticsto the location block for static assets (minusstaticfrom above):
+
location ~ /(themes|aspects/ReportingSuite|aspects/Statistics) {
+-
+
- Need to check
/abouton CGSpace, as it’s blank on my local test server and we might need to add something there
+ - CGSpace has been up and down all day due to PostgreSQL idle connections (current DSpace pool is 90): +
$ psql -c 'SELECT * from pg_stat_activity;' | grep idle | grep -c cgspace
+93
+-
+
- I looked closer at the idle connections and saw that many have been idle for hours (current time on server is
2015-11-25T20:20:42+0000):
+
$ psql -c 'SELECT * from pg_stat_activity;' | less -S
+datid | datname | pid | usesysid | usename | application_name | client_addr | client_hostname | client_port | backend_start | xact_start |
+-------+----------+-------+----------+----------+------------------+-------------+-----------------+-------------+-------------------------------+-------------------------------+---
+20951 | cgspace | 10966 | 18205 | cgspace | | 127.0.0.1 | | 37731 | 2015-11-25 13:13:02.837624+00 | | 20
+20951 | cgspace | 10967 | 18205 | cgspace | | 127.0.0.1 | | 37737 | 2015-11-25 13:13:03.069421+00 | | 20
+...
+-
+
- There is a relevant Jira issue about this: https://jira.duraspace.org/browse/DS-1458 +
- It seems there is some sense changing DSpace’s default
db.maxidlefrom unlimited (-1) to something like 8 (Tomcat default) or 10 (Confluence default)
+ - Change
db.maxidlefrom -1 to 10, reducedb.maxconnectionsfrom 90 to 50, and restart postgres and tomcat7
+ - Also redeploy DSpace Test with a clean sync of CGSpace and mirror these database settings there as well +
- Also deploy the nginx fixes for the
try_fileslocation block as well as the expires block
+
2015-11-26
+ +-
+
- CGSpace behaving much better since changing
db.maxidleyesterday, but still two up/down notices from monitoring this morning (better than 50!)
+ - CCAFS colleagues mentioned that the REST API is very slow, 24 seconds for one item +
- Not as bad for me, but still unsustainable if you have to get many: +
$ curl -o /dev/null -s -w %{time_total}\\n https://cgspace.cgiar.org/rest/handle/10568/32802?expand=all
+8.415
+-
+
- Monitoring e-mailed in the evening to say CGSpace was down +
- Idle connections in PostgreSQL again: +
$ psql -c 'SELECT * from pg_stat_activity;' | grep cgspace | grep -c idle
+66
+-
+
- At the time, the current DSpace pool size was 50… +
- I reduced the pool back to the default of 30, and reduced the
db.maxidlesettings from 10 to 8
+
2015-11-29
+ +-
+
- Still more alerts that CGSpace has been up and down all day +
- Current database settings for DSpace: +
db.maxconnections = 30
+db.maxwait = 5000
+db.maxidle = 8
+db.statementpool = true
+-
+
- And idle connections: +
$ psql -c 'SELECT * from pg_stat_activity;' | grep cgspace | grep -c idle
+49
+-
+
- Perhaps I need to start drastically increasing the connection limits—like to 300—to see if DSpace’s thirst can ever be quenched +
- On another note, SUNScholar’s notes suggest adjusting some other postgres variables: http://wiki.lib.sun.ac.za/index.php/SUNScholar/Optimisations/Database +
- This might help with REST API speed (which I mentioned above and still need to do real tests) +