CGSpace Notes

Documenting day-to-day work on the CGSpace repository.

January, 2023

2023-01-01

  • Apply some more ORCID identifiers to items on CGSpace using my 2022-09-22-add-orcids.csv file
    • I want to update all ORCID names and refresh them in the database
    • I see we have some new ones that aren’t in our list if I combine with this file:
$ cat dspace/config/controlled-vocabularies/cg-creator-identifier.xml | grep - oE '[A-Z0-9]{4}-[A-Z0-9]{4}-[A-Z0-9]{4}-[A-Z0-9]{4}' | sort -u | wc -l                         
1939
$ cat dspace/config/controlled-vocabularies/cg-creator-identifier.xml 2022-09-22-add-orcids.csv| grep -oE '[A-Z0-9]{4}-[A-Z0-9]{4}-[A-Z0-9]{4}-[A-Z0-9]{4}' | sort -u | wc -l
1973
  • I will extract and process them with my resolve-orcids.py script:
$ cat dspace/config/controlled-vocabularies/cg-creator-identifier.xml 2022-09-22-add-orcids.csv| grep -oE '[A-Z0-9]{4}-[A-Z0-9]{4}-[A-Z0-9]{4}-[A-Z0-9]{4}' | sort -u > /tmp/2023-01-01-orcids.txt
$ ./ilri/resolve-orcids.py -i /tmp/2023-01-01-orcids.txt -o /tmp/2023-01-01-orcids-names.txt -d
$ ./ilri/update-orcids.py -i /tmp/2023-01-01-orcids-names.txt -db dspace -u dspace -p 'fuuu' -m 247
  • Load on CGSpace is high around 9.x
    • I see there is a CIAT bot harvesting via the REST API with IP 45.5.186.2
    • Other than that I don’t see any particular system stats as alarming
    • There has been a marked increase in load in the last few weeks, perhaps due to Initiative activity…
    • Perhaps there are some stuck PostgreSQL locks from CLI tools?
$ psql -c 'SELECT * FROM pg_locks pl LEFT JOIN pg_stat_activity psa ON pl.pid = psa.pid;' | grep -o -E '(dspaceWeb|dspaceApi|dspaceCli)' | sort | uniq -c
     58 dspaceCli
     46 dspaceWeb
  • The current time on the server is 08:52 and I see the dspaceCli locks were started at 04:00 and 05:00… so I need to check which cron jobs those belong to as I think I noticed this last month too
    • I’m going to wait and see if they finish, but by tomorrow I will kill them

2023-01-02

  • The load on the server is now very low and there are no more locks from dspaceCli
    • So there was some long-running process that was running and had to finish!
    • That finally sheds some light on the “high load on Sunday” problem where I couldn’t find any other distinct pattern in the nginx or Tomcat requests

2023-01-03

  • The load from the server on Sundays, which I have noticed for a long time, seems to be coming from the DSpace checker cron job
    • This checks the checksums of all bitstreams to see if they match the ones in the database
  • I exported the entire CGSpace metadata to do country/region checks with csv-metadata-quality
    • I extracted only the items with countries, which was about 48,000, then split the file into parts of 10,000 items, but the upload found 2,000 changes in the first one and took several hours to complete…
  • IWMI sent me ORCID identifiers for new scientsts, bringing our total to 2,010

2023-01-04

  • I finally finished applying the region imports (in five batches of 10,000)
    • It was about 7,500 missing regions in total…
  • Now I will move on to doing the Initiative mappings
    • I modified my fix-initiative-mappings.py script to only write out the items that have updated mappings
    • This makes it way easier to apply fixes to the entire CGSpace because we don’t try to import 100,000 items with no changes in mappings
  • More dspaceCli locks from 04:00 this morning (current time on server is 07:33) and today is a Wednesday
    • The checker cron job runs on 0,3, which is Sunday and Wednesday, so this is from that…
    • Finally at 16:30 I decided to kill the PIDs associated with those locks…
    • I am going to disable that cron job for now and watch the server load for a few weeks
  • Start a harvest on AReS