Nuxeo Drive / PostGresql satured

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Pierre_Jenicot1

Hi,

Currently, we use the Nuxeo Drive client in my company (about 140 users) For performance reasons, we separated the different flows between Nuxeo DM and Nuxeo Drive (see diagram)

We have a problem of connections in our database PostgreSQL. Our instances are heavily loaded because of flooding by the Nuxeo Drive client (refresh every 3 seconds).

Have you an idea of ??the settings I can change to avoid this saturation?

Thank you in advance

Example of our configuration (nuxeo-prod3) :

# Database configuration  
nuxeo.db.min-pool-size = 5 
nuxeo.db.max-pool-size = 60 
nuxeo.db.validationQuery = SELECT 1 
nuxeo.vcs.min-pool-size = 0 
nuxeo.vcs.max-pool-size = 58 
nuxeo.vcs.blocking-timeout-millis = 100  
nuxeo.vcs.idle-timeout-minutes = 10

I based this documentation here: http://doc.nuxeo.com/display/public/ADMINDOC/JDBC+Datasource+Configuration

ataillefer_

Hi,

This is interesting but I wonder why exactly you have a separate instance for the requests coming from Nuxeo Drive, instead of load balancing all the request to the 3 nodes? Have you made some tests / benches encouraging this configuration?

Maybe it is useful to dedicate an instance to the load generated by Nuxeo Drive for the upstream synchronization (content modified locally that needs to be updated server side), though for the polling part (getting changes from the server to send the change summary to the client) it is mainly a query to the audit log table that is involved, so as there is only one database in your configuration, no matter if onr Nuxeo instance takes care of Nuxeo Drive, it will all end up in this database, which indeed is probably the bottleneck.

The request for changes (thus the query to the audit log) is done every 5 seconds by default by each client. You can change this parameter client side, by launching the ndrive program with the delay parameter, for instance setting it to 60 seconds:

ndrivew.exe --delay 60

For the database configuration, you can also check the Configuring PostgreSQL page which is dedicated to PostgreSQL configuration and tuning for production. The "Reporting problems" section is interesting as it allows you to make a finer analysis of the problem: tables with a lot of entries, slow queries, memory usage, ...

Hope this helps.