topic Re: Syslog Performance under hpvm guest in Operating System - HP-UX

Syslog Performance under hpvm guest

sumdomo — Wed, 05 Jan 2011 21:48:30 GMT

Hi all,
We have a strange question regarding the syslog() call.
I am testing the performance of hpvm 4.2 running in HP BL860C box
Host is running HPUX 11.31 vse and guest is running HPUX 11.31
I have the following code to test the performance:

#include
#include
#include

int main (void)
{
int iteration =0;
time_T startTime=0;
openlog("ptest",LOG_PID,LOG_USER);
cout<<"\nNumber of Iteration: ";
cin >> iteration;

startTime = time(0);
for(int i=0; i {
syslog(LOG_DEGUG,"Test Message");
}

cout << "\nIteration Count="< cout << ",Time Elapsed ="<}

complied it under the guest and ran it.
The result was very different between the HPVM guest and host and standalone(without hpvm).

For instance, if I take the Iterations as 1000 times.

HPVM guest was 27.2 seconds compared with 3.4 seconds in HPVM host.

Does anyone experience this?

thanks.

Re: Syslog Performance under hpvm guest

Anonymous — Thu, 06 Jan 2011 12:03:10 GMT

Interesting.

This is not really HPVM performance problem. It's more related to whether syslogd which drains /dev/log pipe manages to run in parallel with your logging code or if they share the same cpu. If they share the same cpu, the pipe consumes only 8k and since syslog(3c) writes in 2k chunks, for 1000 iterations you get 250 times EAGAIN from the write() call. Since we go to sleep for .1 sec to let the pipe drain after EAGAIN, that becomes some 25 seconds of additional sleep time.

Make sure you are comparing apples and apples. HPVM guest has typically less cpus than the host and thus on host the chance of syslogd getting scheduler right after it's woken up after the first write to pipe is higher.

Also any throttling in HPVM CPU entitlements (maximum entitlement set to <100%) or some other load running on the guest could lead to the same.

Re: Syslog Performance under hpvm guest

Eric SAUBIGNAC — Thu, 06 Jan 2011 15:47:26 GMT

Bonjour,

I wonder: instead of reporting elapsed time, that depends on many factors, may be you could try to report CPU time used [ man 3c clock ]. Not sure, but I think it could be a more accurate value to analyse.

HTH

Eric

Re: Syslog Performance under hpvm guest

sumdomo — Thu, 06 Jan 2011 20:34:21 GMT

Hi All,

Thanks for your reply.
I would consider more like it is HPVM performance problem cause the same code running under Host is fast or reasonable time.

thanks.

Re: Syslog Performance under hpvm guest

Anonymous — Thu, 06 Jan 2011 20:43:27 GMT

I've tried to explain the reasons why it's not. So how many cpus host and guest have?

Re: Syslog Performance under hpvm guest

sumdomo — Thu, 06 Jan 2011 21:19:36 GMT

Oh, sorry

It has 1 cpu on host and only one guest with 1vcpu

Re: Syslog Performance under hpvm guest

Anonymous — Thu, 06 Jan 2011 21:32:00 GMT

I believe bl860c uses dual core processors, so you have 2 cores (which is what I meant by using word cpu), right? See for example top(1m) output and count the CPU lines.
On guest with single vcpu your code which writes to /dev/log and syslogd which drains it have to serialize and the delays I've mentioned are inevitable. The same would happen on standalone (non virtual) system with single CPU core.
The runtime in seconds you'll see will always be > (number_of_iterations/40).

Re: Syslog Performance under hpvm guest

sumdomo — Sat, 08 Jan 2011 06:12:24 GMT

Stan,

What if I assign 2 vcpus on the guest?
What if I add one more physical CPU to the blade to make it 4 cores and assigned 4 vcpus to the guest?
Can you guide me how the host calculation is 3.4 secs?

Thanks in advance for your time

Re: Syslog Performance under hpvm guest

Anonymous — Mon, 10 Jan 2011 08:21:56 GMT

Adding CPUs (and vCPUs) does increase chance of the 2 processes running in parallel. The more cpus the better. Note that it's not 100% predicable as there could be other processes willing to run. There is no obvious calculation behind the 3.4 seconds, most likely you've hit the .1 sec wait a few times because of some other processes fighting
syslog for CPU.