Add notes for 2017-11-24

content/post/2017-11.md

@@ -830,3 +830,24 @@ $ grep 70.32.83.92 dspace.log.2017-11-23 | grep -o -E 'session_id=[A-Z0-9]{32}'
 - I came across some interesting PostgreSQL tuning advice for SSDs: https://amplitude.engineering/how-a-single-postgresql-config-change-improved-slow-query-performance-by-50x-85593b8991b0
 - Apparently setting `random_page_cost` to 1 is "common" advice for systems running PostgreSQL on SSD (the default is 4)
 - So I deployed this on DSpace Test and will check the Munin PostgreSQL graphs in a few days to see if anything changes
+
+## 2017-11-24
+
+- It's too early to tell for sure, but after I made the `random_page_cost` change on DSpace Test's PostgreSQL yesterday the number of connections dropped drastically:
+
+![PostgreSQL connections after tweak (week)](/cgspace-notes/2017/11/postgres-connections-week.png)
+
+- There have been other temporary drops before, but if I look at the past month and actually the whole year, the trend is that connections are four or five times higher on average:
+
+![PostgreSQL connections after tweak (month)](/cgspace-notes/2017/11/postgres-connections-month.png)
+
+- I just realized that we're not logging access requests to other vhosts on CGSpace, so it's possible I have no idea that we're getting slammed at 4AM on another domain that we're just silently redirecting to cgspace.cgiar.org
+- I've enabled logging on the CGIAR Library on CGSpace so I can check to see if there are many requests there
+- In just a few seconds I already see a dozen requests from Googlebot (of course they get HTTP 301 redirects to cgspace.cgiar.org)
+- I also noticed that CGNET appears to be monitoring the old domain every few minutes:
+
+```
+192.156.137.184 - - [24/Nov/2017:20:33:58 +0000] "HEAD / HTTP/1.1" 301 0 "-" "curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.27.1 zlib/1.2.3 libidn/1.18 libssh2/1.4.2"
+```
+
+- I should probably tell CGIAR people to have CGNET stop that