strace is the system call tracer for Linux. It currently uses the arcane ptrace() (process trace) debugging interface, which operates in a violent manner: pausing the target process for each syscall so that the debugger can read state. And doing this twice: when the syscall begins, and when it ends.
This means strace pauses your application twice for each syscall, and context-switches each time between the application and strace. It’s like putting traffic metering lights on your application
I was spending time on graphing the Apache Server status values in graphite ( Cpu load and busy worker etc ) .
While doing all this performance testing I was curious to know about the CPU usage,
So how does the status is saying 2.51% of CPU usage.
<dt>Current Time: Wednesday, 12-Aug-2015 06:32:02 PDT</dt>
<dt>Restart Time: Wednesday, 05-Aug-2015 11:48:40 PDT</dt>
<dt>Parent Server Generation: 0</dt>
<dt>Server uptime: 6 days 18 hours 43 minutes 22 seconds</dt>
<dt>Total accesses: 15410608 – Total Traffic: 104.8 GB</dt>
<dt>CPU Usage: u14425.6 s284.27 cu0 cs0 – 2.51% CPU load</dt>
<dt>26.3 requests/sec – 187.5 kB/second – 7.1 kB/request</dt>
<dt>8 requests currently being processed, 4 idle workers</dt>
So basically the numbers in CPU usage (system and user ) indicate the total cpu time, in seconds, that httpd has been using.
And percentage value is the amount of CPU time used over the existence of the process.
e.g. with above data :
The server is up from 6 days 18 hours 43 minutes 22 seconds i.e. (6*24)*3600+18*3600+43*60+22=585802 seconds
and it has used 14709.87 seconds ( System+user second’s ) out of 629002 i.e. 14709.87/585802=0.0251 i.e. 2.51%.
On the similar lines the server-status calculates the requests/second.
e.g. with above sample values,
requests_per_second = Total accesses / uptime in seconds
= 15410608/585802 = 26.3
Voila, that’s how the values are calculated.
So if your server’s uptime is quite high you will always be getting the cpu usage and throughput averaged out.
And if you are relying too much on CPU Load from server status you will loose the momentarily load spikes ( so keep watching top too 🙂
Got a wonderful article by Grig about HAProxy and Apache tuning.
For performance reasons HAProxy doesn’t log directly to files. So we need to handle that with syslog server.
But Haproxy also requires a syslog to listen on UDP port ( which in default syslog/rsyslog installation is not enabled )
So here is how you can enable the Haproxy logging in Centos
[root@instance-00000042 haproxy]# cat /etc/rsyslog.d/haproxy.conf
# Enable UDP port 514 to listen to incoming log messages from haproxy
# don’t log anywhere else
[root@instance-00000042 haproxy]# head /home/prod/lb/conf/GGVA/haproxy/junedtest.1.cfg
log 127.0.0.1 local0
log 127.0.0.1 local1 notice
#log loghost local0 info
Restart the rsyslog and you will have your log’s ( Make sure to enable the log roation )
[root@instance-00000042 rsyslog.d]# cd /var/log/haproxy/
[root@instance-00000042 haproxy]# ls -l
-rw——- 1 root root 0 Aug 5 04:00 admin.log
-rw——- 1 root root 0 Aug 5 04:00 haproxy.log