<div dir="ltr"><div><div>Hi,<br><br></div>I was going to suggest htop. That would tell you which one is taking so much CPU. Also, can you post the result of 'uptime'? <br><br>--<br></div>Y<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 4 April 2015 at 00:17, Shrinand Javadekar <span dir="ltr"><<a href="mailto:shrinand@maginatics.com" target="_blank">shrinand@maginatics.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks Clay.<br>
<span class=""><br>
On Fri, Apr 3, 2015 at 3:03 AM, Clay Gerrard <<a href="mailto:clay.gerrard@gmail.com">clay.gerrard@gmail.com</a>> wrote:<br>
> On a single node where network transfers are cheaper, and a small object<br>
> size request rate oriented workload - a good load generator should be able<br>
> to reach cpu limits with enough concurrency.  If you're targeting a disk<br>
> saturating throughput oriented workload - larger objects sizes (1-10MB) is<br>
> the way to go.<br>
<br>
</span>Yes, I am aware of this. But the object sizes may not be in my<br>
control. Therefore, I will have to stick to 256K objects.<br>
<span class=""><br>
><br>
> Is the load generator also running on the same box?  You should try to<br>
> validate your observations with a well know swift benchmarking tool like<br>
> ssbench.  What's your total requests per second?<br>
<br>
</span>Nope, the load generator is running on a separate machine connected to<br>
the Swift instance by a 1G link.<br>
<br>
I want to get as much throughput from Swift as possible. During these<br>
experiments, I have 256 PUTs happening in parallel and a total of<br>
102400 PUTs. I have seen ~300 Obj/s. But, I'm getting this at the cost<br>
of 100% CPU utilization.<br>
<br>
I am reasonably confident that the benchmarking tool is not at fault<br>
here. We have tested several different object stores with the same<br>
tool and the results there have been consistent with the expectations.<br>
<span class=""><br>
><br>
> My profiling in the past has revealed that the md5 checksumming in the<br>
> object server(s) is the largest (but by far not the only) consumer of cpu -<br>
> all of the other things you mentioned take cpu cycles - tanstaafl.  On a<br>
> single node the problem is exasperated per replica - what's your goals?<br>
<br>
</span>I see. I'm using 2 replicas; they're being written to two different disks.<br>
<span class=""><br>
><br>
> Are you sure you're saturating all the cores evenly - what's it look like<br>
> with like `htop` - have you tried tuning your worker counts or any other<br>
> other config settings?<br>
<br>
</span>I have set workers to auto. Reducing the workers, esp. the proxy<br>
server worker has resulted in lower throughput. Also, I have set<br>
threads-per-disk in the object server to 4. I experimented with 8, but<br>
didn't see too much difference. Analysis done using sysdig suggests<br>
that CPU is the bottleneck; not disk.<br>
<br>
I'll take a deeper look at this with htop and see what's happening.<br>
<br>
-Shri<br>
<br>
P.S. "tanstaafl": Knew the phrase; but learnt the acronym just now...<br>
Learn something new everyday!! :-).<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> -Clay<br>
><br>
> On Thu, Apr 2, 2015 at 10:12 PM, Shrinand Javadekar<br>
> <<a href="mailto:shrinand@maginatics.com">shrinand@maginatics.com</a>> wrote:<br>
>><br>
>> Top shows the CPUs pegged at ~100%. Writes are done by a tool built<br>
>> in-house which is similar in functionality to other object store<br>
>> benchmarking tools. As I mentioned, there are 256 parallel object<br>
>> writes (PUTS), each of 256K bytes.<br>
>><br>
>> On Thu, Apr 2, 2015 at 9:21 PM, Yogesh Girikumar <<a href="mailto:yogeshg1987@gmail.com">yogeshg1987@gmail.com</a>><br>
>> wrote:<br>
>> > Also how are you doing the object writes to benchmark it? Are you using<br>
>> > dd?<br>
>> ><br>
>> > On 3 April 2015 at 09:50, Yogesh Girikumar <<a href="mailto:yogeshg1987@gmail.com">yogeshg1987@gmail.com</a>><br>
>> > wrote:<br>
>> >><br>
>> >> What does top say?<br>
>> >><br>
>> >> On 3 April 2015 at 02:34, Shrinand Javadekar <<a href="mailto:shrinand@maginatics.com">shrinand@maginatics.com</a>><br>
>> >> wrote:<br>
>> >>><br>
>> >>> Hi,<br>
>> >>><br>
>> >>> I have a single node Swift instance. It has 16 cpus, 8 disks and 64GB<br>
>> >>> memory. As part of testing, I am doing 256 object writes in parallel<br>
>> >>> for ~10 mins. Each object is also 256K bytes in size.<br>
>> >>><br>
>> >>> While my experiment is running, I see that the CPU utilization of the<br>
>> >>> box is always ~100%. I am trying to understand what is causing this<br>
>> >>> high CPU utilization. Some of this could be attributed to:<br>
>> >>><br>
>> >>> 1. MD5 checksum calculation done to verify every PUT.<br>
>> >>> 2. MD5 checksum calculation by the auditor (if it runs during this<br>
>> >>> interval).<br>
>> >>> 3. Hash calculation of the path to decide which partition the object<br>
>> >>> goes<br>
>> >>> to.<br>
>> >>><br>
>> >>> Are there any other CPU intensive operations happening on the system<br>
>> >>> that I should be aware of?<br>
>> >>><br>
>> >>> I see that the proxy-server has a "PUT" queue. Is there some<br>
>> >>> processing of the data in this queue? Would simply putting data in and<br>
>> >>> out of the queue, streaming the data between the proxy and object<br>
>> >>> server use considerable CPU?<br>
>> >>><br>
>> >>> Thanks in advance.<br>
>> >>> -Shri<br>
>> >>><br>
>> >>> _______________________________________________<br>
>> >>> Mailing list:<br>
>> >>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
>> >>> Post to     : <a href="mailto:openstack@lists.openstack.org">openstack@lists.openstack.org</a><br>
>> >>> Unsubscribe :<br>
>> >>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
>> >><br>
>> >><br>
>> ><br>
>><br>
>> _______________________________________________<br>
>> Mailing list:<br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
>> Post to     : <a href="mailto:openstack@lists.openstack.org">openstack@lists.openstack.org</a><br>
>> Unsubscribe :<br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
><br>
><br>
<br>
_______________________________________________<br>
Mailing list: <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
Post to     : <a href="mailto:openstack@lists.openstack.org">openstack@lists.openstack.org</a><br>
Unsubscribe : <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
</div></div></blockquote></div><br></div>