[
https://issues.apache.org/jira/browse/OMID-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15408176#comment-15408176
]
Francisco Perez-Sorrosal edited comment on OMID-50 at 8/4/16 5:32 PM:
----------------------------------------------------------------------
Also I think that we should inject in the Processors the Wait strategy and make
the configuration of the different strategies happen in the DisruptorModule:
{code:title=PersistenceProcessorImpl.java|borderStyle=solid}
@Inject
PersistenceProcessorImpl(TSOServerConfig config,
@Named("PersistenceStrategy") WaitStrategy
strategy, // <-- Inject strategy here
CommitTable commitTable,
ObjectPool<Batch> batchPool,
Panicker panicker,
PersistenceProcessorHandler[] handlers,
MetricsRegistry metrics)
throws Exception {
...
//
------------------------------------------------------------------------------------------------------------
// Disruptor initialization
//
------------------------------------------------------------------------------------------------------------
....
this.disruptor = new Disruptor<>(EVENT_FACTORY, 1 << 20, disruptorExec
, SINGLE, strategy); // <-- Use injected strategy here
...
{code}
{code:title=DisruptorModule.java|borderStyle=solid}
public class DisruptorModule extends AbstractModule {
private final TSOServerConfig config;
public BatchPoolModule(TSOServerConfig config) {
this.config = config;
}
@Override
protected void configure() {
switch (config.getWaitStrategy()) {
case TSOServerConfig.WAIT_STRATEGY.HIGH_CPU:
bind(WaitStrategy.class).annotatedWith(Names.named("PersistenceStrategy")).to(BusySpinWaitStrategy.class);
bind(WaitStrategy.class).annotatedWith(Names.named("ReplyStrategy")).to(BusySpinWaitStrategy.class);
bind(WaitStrategy.class).annotatedWith(Names.named("RetryStrategy")).to(BusySpinWaitStrategy.class);
break;
case TSOServerConfig.WAIT_STRATEGY.LOW_CPU:
bind(WaitStrategy.class).annotatedWith(Names.named("PersistenceStrategy")).to(BlockingWaitStrategy.class);
bind(WaitStrategy.class).annotatedWith(Names.named("ReplyStrategy")).to(BlockingWaitStrategy.class);
bind(WaitStrategy.class).annotatedWith(Names.named("RetryStrategy")).to(BlockingWaitStrategy.class);
break;
...
}
bind(RequestProcessor.class).to(RequestProcessorImpl.class).in(Singleton.class);
bind(PersistenceProcessor.class).to(PersistenceProcessorImpl.class).in(Singleton.class);
bind(ReplyProcessor.class).to(ReplyProcessorImpl.class).in(Singleton.class);
bind(RetryProcessor.class).to(RetryProcessorImpl.class).in(Singleton.class);
}
}
{code}
was (Author: fperezsorrosal):
Also I think that we should inject in the Processors the Wait strategy and make
the configuration of the different strategies happen in the DisruptorModule:
@Inject
PersistenceProcessorImpl(TSOServerConfig config,
@Named("PersistenceStrategy") WaitStrategy
strategy, // <-- Inject strategy here
CommitTable commitTable,
ObjectPool<Batch> batchPool,
Panicker panicker,
PersistenceProcessorHandler[] handlers,
MetricsRegistry metrics)
throws Exception {
...
//
------------------------------------------------------------------------------------------------------------
// Disruptor initialization
//
------------------------------------------------------------------------------------------------------------
....
this.disruptor = new Disruptor<>(EVENT_FACTORY, 1 << 20, disruptorExec
, SINGLE, strategy); // <-- Use injected strategy here
...
public class DisruptorModule extends AbstractModule {
private final TSOServerConfig config;
public BatchPoolModule(TSOServerConfig config) {
this.config = config;
}
@Override
protected void configure() {
switch (config.getWaitStrategy()) {
case TSOServerConfig.WAIT_STRATEGY.HIGH_CPU:
bind(WaitStrategy.class).annotatedWith(Names.named("PersistenceStrategy")).to(BusySpinWaitStrategy.class);
bind(WaitStrategy.class).annotatedWith(Names.named("ReplyStrategy")).to(BusySpinWaitStrategy.class);
bind(WaitStrategy.class).annotatedWith(Names.named("RetryStrategy")).to(BusySpinWaitStrategy.class);
break;
case TSOServerConfig.WAIT_STRATEGY.LOW_CPU:
bind(WaitStrategy.class).annotatedWith(Names.named("PersistenceStrategy")).to(BlockingWaitStrategy.class);
bind(WaitStrategy.class).annotatedWith(Names.named("ReplyStrategy")).to(BlockingWaitStrategy.class);
bind(WaitStrategy.class).annotatedWith(Names.named("RetryStrategy")).to(BlockingWaitStrategy.class);
break;
...
}
bind(RequestProcessor.class).to(RequestProcessorImpl.class).in(Singleton.class);
bind(PersistenceProcessor.class).to(PersistenceProcessorImpl.class).in(Singleton.class);
bind(ReplyProcessor.class).to(ReplyProcessorImpl.class).in(Singleton.class);
bind(RetryProcessor.class).to(RetryProcessorImpl.class).in(Singleton.class);
}
}
> Provide an option to reduce tso-server CPU usage
> ------------------------------------------------
>
> Key: OMID-50
> URL: https://issues.apache.org/jira/browse/OMID-50
> Project: Apache Omid
> Issue Type: Improvement
> Reporter: Daniel Dai
> Assignee: Daniel Dai
> Fix For: 0.8.3.0
>
> Attachments: OMID-50-1.patch
>
>
> Currently tso-server use 300% cpu even at idle time. The reason for this 300%
> cpu usage is due to the BusyWaitStrategy used in disruptor. While this is
> good for throughput, it wastes resources in many use cases. In this ticket, I
> provide a config to use a different wait strategy and reduce the cpu usage
> with the option on.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
