Transactional governor limits and managed packages

Question

My company is looking to install a very large managed package into our org, which has a significant amount of custom apex as well as several other large managed packages. As we test the package in production, we are running into governor limit issues. Specifically, when closing an opportunity, we are hitting the Apex CPU time limit. I'm looking to debug this, and I have a few questions.

First, I'm pretty sure the answer is yes, but do managed packages contribute to your total CPU time limits? And if so, to which other limits does managed package code contribute to? I can't seem to find any clear documentation of this.

Second, is there any way to track CPU time used by a specific package? This is what I see in my debug logs - this is the writeup of the limits usage of one of the packages:

I get SOQL and DML limits, but CPU time remains at zero. I can log my own CPU time usage using the Limits.getCpuTime() command, which can help me figure out how much CPU time our internal processes are using, but I would like to identify how much time each individual managed package is responsible for using. This way we can work with the vendors of the biggest culprit(s) to hopefully resolve the issue.

Answer 1

For certified managed packages, each namespace gets its own set of limits. Excepted from this separation, however, is CPU Time. Packages which are not certified share all per-transaction governors with the local namespace.

From Execution Governors and Limits:

Per-Transaction Certified Managed Package Limits

Certified managed packages—managed packages that have passed the security review for AppExchange—get their own set of limits for most per-transaction limits. Certified managed packages are developed by Salesforce ISV Partners, are installed in your org from Salesforce AppExchange, and have unique namespaces.

Here is an example that illustrates the separate certified managed package limits for DML statements. If you install a certified managed package, all the Apex code in that package gets its own 150 DML statements. These DML statements are in addition to the 150 DML statements your org’s native code can execute. This limit increase means more than 150 DML statements can execute during a single transaction if code from the managed package and your native org both execute. Similarly, the certified managed package gets its own 100-SOQL-query limit for synchronous Apex, in addition to the org’s native code limit of 100 SOQL queries.

There’s no limit on the number of certified namespaces that can be invoked in a single transaction. However, the number of operations that can be performed in each namespace must not exceed the per-transaction limits. There’s also a limit on the cumulative number of operations that can be made across namespaces in a transaction. This cumulative limit is 11 times the per-namespace limit. For example, if the per-namespace limit for SOQL queries is 100, a single transaction can perform up to 1,100 SOQL queries. In this case, the cumulative limit is 11 times the per-namespace limit of 100. These queries can be performed across an unlimited number of namespaces, as long as any one namespace doesn't have more than 100 queries. The cumulative limit doesn’t affect limits that are shared across all namespaces, such as the limit on maximum CPU time.

Note
These cross-namespace limits apply only to namespaces in certified managed packages. Namespaces in packages that are not certified don’t have their own separate governor limits. The resources they use continue to count against the same governor limits used by your org's custom code.