December, 2015

Wed, 02 Dec 2015 13:18:00 +0300

2015-12-02

Replace lzop with xz in log compression cron jobs on DSpace Test—it uses less space:

# cd /home/dspacetest.cgiar.org/log
# ls -lh dspace.log.2015-11-18*
-rw-rw-r-- 1 tomcat7 tomcat7 2.0M Nov 18 23:59 dspace.log.2015-11-18
-rw-rw-r-- 1 tomcat7 tomcat7 387K Nov 18 23:59 dspace.log.2015-11-18.lzo
-rw-rw-r-- 1 tomcat7 tomcat7 169K Nov 18 23:59 dspace.log.2015-11-18.xz

I had used lrzip once, but it needs more memory and is harder to use as it requires the lrztar wrapper
Need to remember to go check if everything is ok in a few days and then change CGSpace
CGSpace went down again (due to PostgreSQL idle connections of course)
Current database settings for DSpace are db.maxconnections = 30 and db.maxidle = 8, yet idle connections are exceeding this:

$ psql -c 'SELECT * from pg_stat_activity;' | grep cgspace | grep -c idle
39

I restarted PostgreSQL and Tomcat and it’s back
On a related note of why CGSpace is so slow, I decided to finally try the pgtune script to tune the postgres settings:

# apt-get install pgtune
# pgtune -i /etc/postgresql/9.3/main/postgresql.conf -o postgresql.conf-pgtune
# mv /etc/postgresql/9.3/main/postgresql.conf /etc/postgresql/9.3/main/postgresql.conf.orig 
# mv postgresql.conf-pgtune /etc/postgresql/9.3/main/postgresql.conf

It introduced the following new settings:

default_statistics_target = 50
maintenance_work_mem = 480MB
constraint_exclusion = on
checkpoint_completion_target = 0.9
effective_cache_size = 5632MB
work_mem = 48MB
wal_buffers = 8MB
checkpoint_segments = 16
shared_buffers = 1920MB
max_connections = 80

Now I need to go read PostgreSQL docs about these options, and watch memory settings in munin etc
For what it’s worth, now the REST API should be faster (because of these PostgreSQL tweaks):

$ curl -o /dev/null -s -w %{time_total}\\n https://cgspace.cgiar.org/rest/handle/10568/32802?expand=all
1.474
$ curl -o /dev/null -s -w %{time_total}\\n https://cgspace.cgiar.org/rest/handle/10568/32802?expand=all
2.141
$ curl -o /dev/null -s -w %{time_total}\\n https://cgspace.cgiar.org/rest/handle/10568/32802?expand=all
1.685
$ curl -o /dev/null -s -w %{time_total}\\n https://cgspace.cgiar.org/rest/handle/10568/32802?expand=all
1.995
$ curl -o /dev/null -s -w %{time_total}\\n https://cgspace.cgiar.org/rest/handle/10568/32802?expand=all
1.786

Last week it was an average of 8 seconds… now this is ¹⁄₄ of that
CCAFS noticed that one of their items displays only the Atmire statlets: https://cgspace.cgiar.org/handle/10568/42445

The authorizations for the item are all public READ, and I don’t see any errors in dspace.log when browsing that item
I filed a ticket on Atmire’s issue tracker
I also filed a ticket on Atmire’s issue tracker for the PostgreSQL stuff

2015-12-03

CGSpace very slow, and monitoring emailing me to say its down, even though I can load the page (very slowly)
Idle postgres connections look like this (with no change in DSpace db settings lately):

$ psql -c 'SELECT * from pg_stat_activity;' | grep cgspace | grep -c idle
29

I restarted Tomcat and postgres…

November, 2015

Mon, 23 Nov 2015 17:00:57 +0300

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 remove static from 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_header in 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/Statistics to the location block for static assets (minus static from above):

location ~ /(themes|aspects/ReportingSuite|aspects/Statistics) {

Need to check /about on 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.maxidle from unlimited (-1) to something like 8 (Tomcat default) or 10 (Confluence default)
Change db.maxidle from -1 to 10, reduce db.maxconnections from 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_files location block as well as the expires block

2015-11-26

CGSpace behaving much better since changing db.maxidle yesterday, 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.maxidle settings 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)

CGSpace Notes

December, 2015

2015-12-02

2015-12-03

November, 2015

2015-11-22

2015-11-24

2015-11-25

2015-11-26

2015-11-29