Understanding Your Usage
As software development becomes more central and mission-critical to business operations, it’s important to ensure that your Sonatype Nexus Repository is deployed appropriately for your scale.
Our in-product usage metrics and alerts help administrators know when it’s time to review their current deployment model. See our usage metrics help documentation to learn where to find that information and how those numbers are calculated.
Using Nexus Repository OSS and Seeing Usage Alerts?
If you are seeing usage alerts in your Sonatype Nexus Repository OSS deployment, this means your scale is exceeding what is appropriate for an OSS deployment on OrientDB.
Contact our sales team to discuss upgrading to a Sonatype Nexus Repository Pro deployment using a PostgreSQL database.
Already Using Pro, but Still Seeing Usage Alerts?
Sonatype Nexus Repository Pro deployments using an embedded database will also see usage alerts should scale exceed what is appropriate for your embedded database.
If you are a Pro customer seeing usage alerts, you should migrate to a PostgreSQL database as soon as possible.
Each of the Nexus Repository reference architectures also provides additional suggestions for implementing options such as high availability or resiliency.
What Triggers In-Product Usage Level Warnings?
For deployments of Nexus Repository OSS or Pro that use an embedded database (OrientDB or H2), in-product warnings will appear when usage levels approach or exceed one of the following thresholds:
20,000 requests per day
100,000 components
Why Did Sonatype Add Usage Warnings for Embedded Databases?
While embedded databases are appropriate for disposable edge caches, test deployments, and low-concurrency team usage, an external PostgreSQL is recommended for more demanding use. This is particularly true for higher-concurrency use, or in any situation where Nexus Repository is the system of record for the components that it stores.
Embedded databases require the system to enter read-only mode to get a consistent backup. Because of this, many deployments are not properly backed up, leading to extremely long recovery times in the case of an outage that requires restoring data.
Concurrent loads can lead to data integrity problems in OrientDB, which can make some or all components unavailable to users.
In addition, there are other benefits of Pro such as high availability, single sign-on, and world class support.
Tip
To help you determine a deployment model that is appropriate for your needs, we’ve created a series of reference architectures for Nexus Repository. Each architecture provides system requirements and deployment strategies to handle specific ranges of anticipated total load. We also provide sizing instructions so that you can appropriately evaluate your total projected load.
What Can I Do if Migrating to Pro or PostgreSQL is Not Possible?
If you are not able to change your deployment model in the near term, we recommend that you evaluate ways to reduce usage in order to ensure your deployment is stable.
Reducing build frequency or developer load on Nexus Repository can reduce concurrency of request rates.
Nexus Repository’s cleanup policies can also help reduce a high component count by eliminating components you no longer need to store. Check out our cleanup policy documentation for details on this powerful feature.