Hi all, We've run into similar issues in the past. This only applies to linux, but the biggest help has been to increase the ulimit for open files and processes per user. The defaults for these are not high enough for a Dspace production server (although it might be fine if your running a clustered, load-balanced instance). Ours are set to 16384 open files and 62754 user processes, and that seems to have eliminated the problem.
It's also important to make sure your jvm is tuned so that the -Xmx parameter (maximum allowed memory usage) is high enough. Thanks, Seth Robbins On Wed, Oct 31, 2018 at 11:28 AM Tim Donohue <[email protected]> wrote: > Hi Manuela, > > Have you checked for any errors in your DSpace logs from over the > weekend? It's possible that the thumbnail generation process could be > running out of memory (or similar) and causing general instability issues. > So, it'd be worth looking at the logs during the time of the thumbnail > generation process to see if it's hitting major errors. (As a sidenote, > generating 20,000 thumbnails at once is a *very large number* of > thumbnails. So, it does make me wonder if the memory settings on your > server are properly optimized.) > > I'd also recommend considering upgrading to DSpace 5.10 (latest 5.x > version), as in 5.9 we upgraded the PostgreSQL JDBC database driver. > DSpace 5.8 uses a very old version of the PostgreSQL database driver, and > it's possible you are hitting a problem/bug in how that driver is > communicating with your PostgreSQL database. Here's more information on > that JDBC driver update: https://jira.duraspace.org/browse/DS-3854 > > Please respond on this list with any extra information you may find. > > - Tim > > > On Wed, Oct 31, 2018 at 1:53 AM Manuela Ferreira <[email protected]> > wrote: > >> Hello! >> >> Since this Monday, our repository, that uses DSpace 5.8, has been very >> unstable. Suddenly it stops to respond http requests, freezes the dspace >> and coccon log, and accumulate about 250 "idle in transaction" on >> postgresql. The most of this "idle in transaction" are like this (see >> printscreen attached): >> SELECT * FROM MetadataValue WHERE resource_id= $1 and resource_type_id = >> $2 ORDER BY metadata_field_id, place >> >> In dspace.cfg our db configuration are: >> # Maximum number of DB connections in pool >> # we have tried 250, but it is still unstable >> db.maxconnections = 150 >> >> # Maximum time to wait before giving up if all connections in pool are >> busy (milliseconds) >> db.maxwait = 10000 >> >> # Maximum number of idle connections in pool (-1 = unlimited) >> #we tried 30, but it is still unstable >> db.maxidle = 50 >> >> # Determine if prepared statement should be cached. (default is true) >> db.statementpool = true >> >> # Specify a name for the connection pool (useful if you have multiple >> applications sharing Tomcat's dbcp) >> # If not specified, defaults to 'dspacepool' >> db.poolname = dspacepool >> >> >> In postgresql.conf, for Postgresql 9.5 >> max_connections = 1000 >> >> >> Since Monday, we restart Tomcat, the situation normalize for 10 minutes >> in average, and then, the problem returns. During the night, probably due >> to small number of http requests, the repository remains stable for more >> time. >> >> The only thing that we have doing in the last week is generate about of >> 20.000 pdf.jpg every morning, until get all 190.000 pdf.jpg generated. >> Before that, we generate only jpg.jpg thumbnails. This Monday morning we >> almost finish to generate all the pdf.jpg, but at afternoon the DSpace had >> been unstable. Can the pdf.jpg generated in last days be the cause of >> instability? How can I delete this pdf.jpg? >> >> We increase the level of dspace and postgresql log, attached. >> >> Please, help. Our repository was almost offline since Monday and we can't >> find why. >> >> Manuela Klanovicz Ferreira >> dspace_log_aux.txt >> <https://drive.google.com/file/d/1JREWDTcI1VnK9M5A2weifqFoCXP4mphT/view?usp=drive_web> >> postgresql_log_aux.txt >> <https://drive.google.com/file/d/13CVjMUw8o3S57m7NxH146CEQSr54sLAa/view?usp=drive_web> >> >> >> >> -- >> 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 [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at https://groups.google.com/group/dspace-tech. >> For more options, visit https://groups.google.com/d/optout. >> > -- > Tim Donohue > Technical Lead for DSpace & DSpaceDirect > DuraSpace.org | DSpace.org | DSpaceDirect.org > > -- > 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 [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/dspace-tech. > For more options, visit https://groups.google.com/d/optout. > -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/dspace-tech. For more options, visit https://groups.google.com/d/optout.
