Open Stack

During the time when we wrote that, we were discussing the various
use-cases that we usually see in our clouds. The use-cases ranged anywhere
from cpu-heavy batch processing, scientific modeling, or basic web hosting.

I believe, but I could be wrong as that discussion was 10 months ago (!),
that it was more efficient to turn off hyper-threading for batch-heavy or
modeling use-cases.

I personally have hyper-threading turned on for all processors that support
it. This is because I see a wide variety of use-cases for the clouds that I
maintain -- not just one, let alone one that would benefit from having it
disabled.

The last statement about performance testing is indeed vague. For examples
on how to test performance, you could:

* Do something simple like set up a few instances and see how they perform
under normal load, then disable hyper-threading and see if there's a
difference.
* Use something more comprehensive like the Phoronix Test Suite. (note: I
don't have any experience with that suite, it's just the first that comes
to mind)

Joe


On Tue, Dec 24, 2013 at 6:00 PM, Dnsbed Ops <ops at dnsbed.com> wrote:

> On 2013-12-24 16:21, sylecn wrote:
>
>> I'd like to hear some real world experience on this topic. Do you enable
>> hyper-threading in your openstack cluster? Does it matter at all for
>> your use case?
>>
>> My current use case is java based web app and node.js based web app.
>> Both facing internet users with potentially high concurrency. The cpu on
>> nova-compute node is E5-2620x2, 24 cores with HT on.
>>
>
> I have also the same question on the hyper-threading item.
> Do you anybody have the experience on it?
>
> Thanks.
>
> _______________________________________________
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20131224/a95875e9/attachment.html>