标签: throughput

我最近了解了在开始提供实际请求之前需要预热应用程序(具有高吞吐量要求)的方案.这背后的逻辑是允许JIT发挥其性能魔力!

这是Java应用程序的标准还是通常用于内存繁重(占用空间)的应用程序？

TL; DR:我有可能反应堆吞吐量有限吗？我怎么说？io_service的实现是多么昂贵和可扩展(跨线程)？

我有一个远程大规模并行应用程序,运行在超线程双四核Xeon机器上,具有大量RAM和快速SSD RAID.这是使用boost :: asio开发的.

此应用程序接受来自大约1,000台其他计算机的连接,读取数据,解码简单协议,并将数据混洗到使用mmap()映射的文件中.该应用程序还使用madvise(WILLNEED)预取"未来"mmap页面,因此它不太可能阻止页面错误,但只是为了确定,我已经尝试产生多达300个线程.

这是在Linux内核2.6.32-27-generic(Ubuntu Server x64 LTS 10.04)上运行的.Gcc版本是4.4.3,boost :: asio版本是1.40(都是Ubuntu LTS的股票).

运行vmstat,iostat和top,我看到磁盘吞吐量(在TPS和数据卷中)都是%的单个数字.同样,磁盘队列长度总是比线程数小很多,所以我不认为我是I/O绑定的.此外,RSS攀升,但然后稳定在几个演出(如预期)和vmstat显示没有分页,所以我想我不是内存限制.CPU恒定为0-1%用户,6-7%系统,其余为空闲.线索!一个完整的"核心"(记住超线程)是CPU的6.25%.

我知道系统落后了,因为当超过64kB未完成时,客户端机器阻止TCP发送,并报告事实; 他们都在报告这一事实,并且系统的吞吐量远远低于预期,预期和理论上的可能性.

我的猜测是我在争夺某种锁定.我使用应用程序级锁来保护可能会发生变异的查找表,因此我将其分为256个顶级锁/表来打破这种依赖.但是,这似乎没有任何帮助.

所有线程都通过一个全局io_service实例.在应用程序上运行strace表明它花费大部分时间来处理futex调用,我想这与io_service reactor的基于事件的实现有关.

我可能反应堆吞吐量有限吗？我怎么说？io_service的实现是多么昂贵和可扩展(跨线程)？

编辑:我最初没有找到这个其他线程,因为它使用了一组不与我重叠的标签: - /很可能我的问题是在执行boost :: asio reactor时使用的过度锁定.请参阅C++套接字服务器 - 无法使CPU饱和 然而,问题仍然存在:我如何证明这一点？我该如何解决？

你能否解释如何解释偏差与吞吐量？1000 ++偏差结果是否意味着测试中的Web性能不佳？你怎么能说被测网络表现良好？它是基于.吞吐量结果？怎么样？

什么监听器最适合跟踪一千个用户的负载/性能

最后,可以在测试时检查服务器的cpu/ram使用情况

我正在尝试将DynamoDB表备份到S3.由于某些原因,通过AWS控制台上的导出来执行此操作不起作用,而且由于表格不是那么大,我尝试使用基于boto的脚本来执行此操作.这是我脚本的主要部分:

import boto.dynamodb2
from boto.dynamodb2.table import Table
c_ddb2 = boto.dynamodb2.connect_to_region(...)
table  = Table("myTable",connection=c_ddb2)
# also connect to S3 
scanres = table.scan()
for item in scanres:
    # process and store next item

我收到以下异常:

Traceback (most recent call last):
  File "/home/.../ddb2s3.py", line 155, in <module>
    main()
  File "/home/.../ddb2s3.py", line 124, in main
    for it in scanres:
  File "/usr/local/lib/python2.7/dist-packages/boto/dynamodb2/results.py", line 62, in next
    self.fetch_more()
  File "/usr/local/lib/python2.7/dist-packages/boto/dynamodb2/results.py", line 144, in fetch_more
    results = self.the_callable(*args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/boto/dynamodb2/table.py", line 1213, in _scan
    **kwargs …

背景:

我正在开发一个与数据库相关的程序,我需要按顺序将脏元数据从内存刷新到磁盘./ dev/sda1是volumn格式,因此将逐块访问/ dev/sda1上的数据,如果按顺序访问,则块在物理上相邻.我使用直接I/O,因此I/O将绕过文件系统的缓存机制并直接访问磁盘上的块.

问题:

在打开/ dev/sda1之后,我将读取一个块,更新块并将块重新写回/ dev/sda1开头的相同偏移量.

代码如下 -

//block_size = 256KB
int file = open("/dev/sda1", O_RDWR|O_LARGEFILE|O_DIRECT);
for(int i=0; i<N; i++) {
    pread(file, buffer, block_size, i*block_size);
    // Update the buffer
    pwrite(file, buffer, block_size, i*block_size);
}

我发现如果我不做pwrite,读取吞吐量是125 MB/s.

如果我执行pwrite,读取吞吐量将为21 MB/s,写入吞吐量为169 MB/s.

如果我在pwrite之后pread,写吞吐量是115 MB/s,读吞吐量是208 MB/s.

我也试过read()/ write()和aio_read()/ aio_write(),但问题仍然存在.我不知道为什么在读取文件的相同位置后写入会使读取吞吐量如此之低.

如果一次访问更多的块,就像这样

pread(file, buffer, num_blocks * block_size, i*block_size);

问题会缓解,请参阅图表.

我正在使用mongodb的上限集合+ tailable游标作为pubsub引擎,使用pymongo.(这种方法在这里描述).我的环境包括几个主题,几个发布者和几十个订阅者.

这很有效,除了每隔一段时间我遇到插入操作,这需要花费很长时间才能完成.

我的理解是mongodb可以支持> 10K docs/sec的插入,这就是为什么我很惊讶单个插入操作可能需要85ms.(我在生产环境中也观察过几次> 1秒,但无法使用此SSCCE重现它).

为了将延迟降至最低,日记功能被禁用,并且我使用最低写入问题,这有助于,但没有解决问题.

是什么导致这种情况,我该如何解决？

这是一个SSCCE.我并行运行以下脚本两次:

import time, pymongo, pandas as pd
DBNAME = 'test5'
COLLNAME = 'abc'
mongo = pymongo.MongoClient()
#mongo[DBNAME].drop_collection(COLLNAME)
if DBNAME not in mongo.database_names():
    coll = mongo[DBNAME].create_collection(COLLNAME,
                                    capped = True, size = 50 * 1024 * 1024, max = 1024 * 1024,
                                    fsync = False,  # no delays please (FYI, journaling is disabled)
                                    #autoIndexId = False,
                                    )

tarr = []
for _ in range(1000):
    msg …

我们正在尝试使用HornetQ存储和转发机制......但是使用核心网桥将消息从一个独立的HornetQ实例转发到另一个实例非常慢.我们无法将吞吐率提高到每秒200条以上.

令人惊讶的事实是,如果我们直接在目的地HornetQ实例指向同一客户端(即向转发HornetQ实例发布消息),我们开始观察每秒超过1000条消息的吞吐率(此客户端是基于JMS的).这基本上意味着在Forwarding HornetQ实例和Destination HornetQ实例之间配置的核心桥是有问题的.

以下是在Forwarding HornetQ上配置核心桥的相关章节:

<connectors>
            <connector name="netty-bridge">
                 <factory-class>org.hornetq.core.remoting.impl.netty.NettyConnectorFactory</factory-class>
                 <param key="host" value="destination.xxx.com"/>
                 <param key="port" value="5445"/>
                 <param key="batch-delay" value="50"/>
                 <param key="tcp-send-buffer-size" value="1048576"/>
                 <param key="tcp-receive-buffer-size" value="1048576"/>
                 <param key="use-nio" value="true"/>
           </connector>
</connectors>
<address-settings>
      <address-setting match="jms.queue.Record">
                <dead-letter-address>jms.queue.RecordDLQ</dead-letter-address>
                <max-size-bytes>262144000</max-size-bytes>
                <page-size-bytes>10485760</page-size-bytes>
                <address-full-policy>PAGE</address-full-policy>
        </address-setting>
</address-settings>
<queues>
         <queue name="jms.queue.Record">
                  <address>jms.queue.Record</address>
         </queue>
</queues>
<bridges>
        <bridge name="core-bridge">
                <queue-name>jms.queue.Record</queue-name>
                <forwarding-address>jms.queue.Record</forwarding-address>
                <retry-interval>1000</retry-interval>
                <retry-interval-multiplier>1.0</retry-interval-multiplier>
                <reconnect-attempts>-1</reconnect-attempts>
                <confirmation-window-size>10485760</confirmation-window-size>
                <static-connectors>
                        <connector-ref>netty-bridge</connector-ref>
                </static-connectors>
        </bridge>
</bridges>

以下是在Destination HornetQ上配置核心桥的相关章节:

<acceptors>
      <acceptor name="netty">
        <factory-class>org.hornetq.core.remoting.impl.netty.NettyAcceptorFactory</factory-class>
         <param key="host"  value="${hornetq.remoting.netty.host:192.168.2.xxx}"/>
         <param key="port"  value="${hornetq.remoting.netty.port:xxxx}"/>
         <param key="tcp-send-buffer-size"  value="1048576"/>
         <param key="tcp-receive-buffer-size"  value="1048576"/>
         <param key="use-nio"  value="true"/> …

我有一组 25,000 多个 url 需要抓取。我一直看到在大约 22,000 个网址后，抓取速度急剧下降。

看看这些日志行以获得一些观点：

2016-04-18 00:14:06 [scrapy] INFO: Crawled 0 pages (at 0 pages/min), scraped 0 items (at 0 items/min)
2016-04-18 00:15:06 [scrapy] INFO: Crawled 5324 pages (at 5324 pages/min), scraped 0 items (at 0 items/min)
2016-04-18 00:16:06 [scrapy] INFO: Crawled 9475 pages (at 4151 pages/min), scraped 0 items (at 0 items/min)
2016-04-18 00:17:06 [scrapy] INFO: Crawled 14416 pages (at 4941 pages/min), scraped 0 items (at 0 items/min)
2016-04-18 00:18:07 [scrapy] INFO: Crawled 20575 pages (at …

我有一个使用 DynamoDB 的应用程序，我注意到他们刚刚实现了很棒的自动缩放。我喜欢这个概念，我的应用程序的时机非常完美。但是，我仍然遇到一些问题，我想知道我是否无法调整设置以将其删除。

我的应用程序的使用量明显激增，因此我认为这是一个理想的使用方法，但是在启用自动缩放后，我仍然会遇到一些限制。这是我过去 12 小时的阅读图表：

正如您所看到的，当它达到峰值时，使用率设置得很低，所以它会限制一两分钟，直到更新开始，然后才能工作。我想这没关系，而且比不缩放要好，但我希望它根本不节流......

有什么方法可以告诉 DynamoDB 永远不要节流，除非它超过 100（或 200 或我设置的任何上限）？只是如果它出现激增将吞吐量提高 15 分钟或其他什么直到激增结束？

我有一个用例，我们没有得到太多在单个请求中存在要更新的条目列表的情况，并且大多数情况下，只有一个条目被请求更新。但将来，这种情况可能会增长，因此我正在考虑使用 BatchPutItem 而不是 PutItem。

• 当请求中只有一个项目需要更新时，使用 BatchPutItem 是否有任何缺点？
• 我认为消耗的 RCU 是相同的，但是是否有任何其他差异，或者当请求中只有一个条目时，BatchPutItem 的行为与 PutItem 相同？