Hi,
Having problems with the OpenXPKI which runs on heavily loaded computer:
Hangs of the openxpki server during start or run.
"top" reports that when it happens
"perl" occupies 99% of processor time.
My system is FreeBSD-6 @ dual core Pentium-4 with 1.5 GB memory.
The most reproducible hang is a run of
the update_svn_and_test.pl script with DEBUG="1" setting.
The last message which I can see in the logs is
"Starting OpenXPKI..." during test
t/60_workflow/15_csr_and_certificate_issuance.
Looks that this test fails due to non correct
termination of test t/60_workflow/10_certificate_signing_request.t
(see attached log with line "Starting OpenXPKI..."
here related to test 10_certificate_signing_request).
If I put DEBUG="0", then everything runs ok.
BTW, nobody here succeeded to terminate the
update_svn_and_test.pl script with DEBUG="1".
Alex, how much memory do you have in your testing host?
I can imagine two reasons of these hangs.
Reason A. In the openxpki code there are multiple cases when
(1) values which are returned back
are not checked for type and consistency.
E.g. in the same test 10_certificate_signing_request:
'ERROR' => 'Can\'t call method "fetch_workflow"
on an undefined value at
/home/svysh/prefix/lib/perl5/site_perl/5.8.8/mach//OpenXPKI/Server/API/Workflow.pm
line 257.
This is due to the code:
my $factory = __get_workflow_factory({
WORKFLOW_ID => $wf_id,
});
my $workflow = $factory->fetch_workflow(
$wf_title,
$wf_id
);
When I say DEBUG="1", then __get_workflow_factory returns
"undef", which propagates further unchecked.
(2) request for external agent (e.g. database) sometime does not
check for timeout, nor for communication error report.
Looks like we adopt a hypothesis that once established connection
to the database (usually this is checked during initialization),
lasts forever and we do not need to check if it works in real time?
(3) I failed to understand if openxpki is ready for the
situation when (e.g.) database
server stays in the swap for considerable time due to external reason.
What happens if several unserved requests go into
the same socket, while openxpki thinks that they are meant for
the different databases sleeping in the swap? Who will serve what
after awakening? Maybe we should take care ourselves
and build a special queue for requests going to the socket?
Reason B. A single idle PostgreSQL server easily eats 15 MB of memory.
When talked by the openxpki server it forks and eats up to 100 MB.
Do we agree, that if we want to serve 10 users simultaneously,
we need to have 1 GB of memory for databases only, not counting
other important servers?
Say direct observation via "top" shows that openxpki server
eats up to 100 MB of memory per logged in user.
Maybe somebody knows a more economical
and clever way how to deal with a database, which serves multiple
simultaneous user requests?
All the best, Sergei
======================================================
Attached is the log mentioned above:
Starting OpenXPKI...
ok - PID file exists
ok - Socketfile exists
ok - Logged in successfully
ok - Successfully complains about missing field
ok - Correct error message
ok - Successfully created CSR workflow instance
ok - Approve activity exists
ok - Workflow ID exists
ok - WF is in state PENDING
ok - Correct cert subject
not ok - Successfully changed subject
# Failed test 'Successfully changed subject'
# at t/60_workflow/10_certificate_signing_request.t line 147.
not ok - Changed subject in context
# Failed test 'Changed subject in context'
# at t/60_workflow/10_certificate_signing_request.t line 148.
# got: undef
# expected: 'CN=fully.qualified.example.com,DC=Test,DC=OpenXPKI,DC=org'
# $VAR1 = {
# 'LIST' => [
# {
# 'LABEL' =>
'I18N_OPENXPKI_SERVICE_DEFAULT_COMMAND_EXECUTION_ERROR',
# 'PARAMS' => {
# 'ERROR' => 'Can\'t call method
"fetch_workflow" on an undefined value at
/home/svysh/prefix/lib/perl5/site_perl/5.8.8/mach//OpenXPKI/Server/API/Workflow.pm
line 257.
# '
# }
# }
# ],
# 'SERVICE_MSG' => 'ERROR',
# 'PARAMS' => {
# 'WORKFLOW' => {
# 'CONTEXT' => {}
# }
# }
# };
not ok - get_workflow_info()
# Failed test 'get_workflow_info()'
# at t/60_workflow/10_certificate_signing_request.t line 160.
======================================================
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
OpenXPKI-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openxpki-devel
