Item Submission Upload step taking longer time to respond

[ayukap...@gmail.com]

Our item submission has been working fine until just a few days when the upload step would take up to a minute or more to load.

It seems I cant figure out where the problem is as the server resources are still very adequate and all other steps are working ok.

File upload also takes way longer than normal to load.

Has anyone encountered this problem before?

[ayukap...@gmail.com]

A quick update on this matter.  I have noticed that we are having more than 100 table locks just for one submission (no other user using the system). And this slows down the transition from the access step to the upload step by up to a minute or two.

Is this how it should work ? Any help with this is highly appreciated.

[ayukap...@gmail.com]

Hi everyone,

This problem of a very slow upload step is very collection specific. The collection has ~150 items in the workflow and ~4000 archived items.

I would appreciate any help.

This specific query to update/select metadata value is very slow both in PostgreSQL 12 and PostgreSQL 9.6 -  DSpace 6.3 tomcat 8

 select metadata0_.dspace_object_id as dspace_o7_12_3_, metadata0_.metadata_value_id as metadata1_27_3_, metadata0_.metadata_value_id as metadata1_27_2_, metadata0_.authority as authorit2_27_2_, metadata0_.confidence as confiden3_27_2_, metadata0_.dspace_object_id as dspace_o7_27_2_, metadata0_.text_lang as text_lan4_27_2_, metadata0_.metadata_field_id as metadata8_27_2_, metadata0_.place as place5_27_2_, metadata0_.text_value as text_val6_27_2_, metadatafi1_.metadata_field_id as metadata1_25_0_, metadatafi1_.element as element2_25_0_, metadatafi1_.metadata_schema_id as metadata5_25_0_, metadatafi1_.qualifier as qualifie3_25_0_, metadatafi1_.scope_note as scope_no4_25_0_, metadatasc2_.metadata_schema_id as metadata1_26_1_, metadatasc2_.short_id as short_id2_26_1_, metadatasc2_.namespace as namespac3_26_1_ from public.metadatavalue metadata0_ left outer join public.metadatafieldregistry metadatafi1_ on metadata0_.metadata_field_id=metadatafi1_.metadata_field_id left outer join public.metadataschemaregistry met  

[Alan Orth]

Dear list,

We upgraded from DSpace 5.8 to 6.3 yesterday and now our PostgreSQL connections and locks have skyrocketed. I have a bunch of editors emailing me that they can't edit or approve items in their workflows. Attaching Munin usage graphs for PostgreSQL where you can obviously see the issue beginning after the upgrade yesterday.

I have 1,344 locks currently, and the number keeps going up...

$ psql -c 'SELECT * FROM pg_locks pl LEFT JOIN pg_stat_activity psa ON pl.pid = psa.pid;' | wc -l
1344

What are people doing about this? Are there any commits we can cherry-pick from the upcoming DSpace 6.4? Should I file an issue? We are using PostgreSQL 10.15. Any help or comments appreciated.

Thanks again,

--
All messages to this mailing list should adhere to the DuraSpace Code of Conduct: https://duraspace.org/about/policies/code-of-conduct/
---
You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-tech/e989a70e-a2e9-43b5-bfca-b48b2c85fb49n%40googlegroups.com.

--

Alan Orth
alan...@gmail.com
https://picturingjordan.com
https://englishbulgaria.net
https://mjanja.ch