He did not mention what model 520 he had, but unless he has the highest
end (P20) model with BOTH cores activated, he only has a single socket and
a single core, so what are the other LPARs supposed to use if the Domino
LPAR has 100%? And, they might not even have a full power CPU. They still
used the total CPU governor on the first gen 520's, which, like the
Interactive governor, kick in and use up CPU to prevent you from getting
all the power in the physical package.
They could check if the LPARs are "uncapped", meaning the Domino LPAR can
borrow CPU from the other LPAR, when it is not in use. If this is the
case, they would see up to 125% processor utilization on the WRKACTJOB
We had a database that was taking a long time on the first open, as it was
rebuilding views automatically. We put in a program document to update
them in the morning and afternoon, so they would be built before the first
user hit them. This database is only updated a couple of times a day
though, so it might not help if you are updating it continuously.
We put multiple UPDALL program docs in to run a few minutes apart, once
around 7 am and again around noon.
xxx_PRD\Accounting\CreditCollect.nsf -T OpenInvoices
xxx_PRD\Accounting\CreditCollect.nsf -T OpenInvoiceByCusNo
xxx_PRD\Accounting\CreditCollect.nsf -T OpenInvoicesAging
xxx_PRD\Accounting\CreditCollect.nsf -T OpenInvoicesByPO
Timothy, I agree with Walter's reply back on the list. I doubt the
RAM is the issue on this one - unless the 4GB isn't just allocated to
Domino. With you only having 3/4 of a processor, I would start here to
improve the issue. I would suggest pulling another 1/4 processor from the
other LPAR(s) on the system (assuming they're not all too heavily
You should be able to get the admin to bump this up on the fly. Hopefully
the admin will at least let you get some more cpu at least temporarily.
Let us know....
On Mon, May 5, 2008 at 6:24 PM, Timothy Briley <tlbriley@xxxxxxxxxxxxxx>
I sent the PMR to Walter, who was kind enough to respond, but you ask
good questions as well.
"Are the performance problems a direct result of the growth of the
DB? When the DB was initially rolled out was the performance acceptable ?"
Yes to both, which is frustrating because at the time of rollout this
brand new server was meant to last us 5 years as configured.
"Have you(or the DB developers) looked into how the view indexes are
being refreshed ?"
They are set to refresh automatically. If there's a better way, I'm open
"As far as the length of time to open the main document, what is
happening when the doc opens? Does it retrieve data from other documents?"
When the main doc opens, ODBC is used in the QueryOpen event to find
a record in an AS/400 flat file and compare the data to a single
field in the main document. If they differ, the main doc is updated
with the new data, but that is only the case about 10% of the time.
No other look-ups to docs are performed.
So given that performance went south with a 33% increase in the
number of documents, I'd really like to know where to spend my money
hardware-wise to get performance back where it was.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2021 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.