精华内容
下载资源
问答
  • 问题一最近发现kibana的日志传的很慢,常常查不到日志,由于所有的日志收集都只传输到了一个logstash进行收集和过滤,于是怀疑是否是由于logstash的吞吐量存在瓶颈。一看,还真是到了瓶颈。优化过程经过查询logstash...

    问题一

    最近发现kibana的日志传的很慢,常常查不到日志,由于所有的日志收集都只传输到了一个logstash进行收集和过滤,于是怀疑是否是由于logstash的吞吐量存在瓶颈。一看,还真是到了瓶颈。

    优化过程

    经过查询logstash完整配置文件,有几个参数需要调整

    1

    2

    3

    4

    5

    6

    7

    8# pipeline线程数,官方建议是等于CPU内核数

    pipeline.workers: 24

    # 实际output时的线程数

    pipeline.output.workers: 24

    # 每次发送的事件数

    pipeline.batch.size: 3000

    # 发送延时

    pipeline.batch.delay: 5

    PS:由于我们的ES集群数据量较大(>28T),所以具体配置数值视自身生产环境

    优化结果

    ES的吞吐由每秒9817/s提升到41183/s,具体可以通过x-pack的monitor查看。

    问题二

    在查看logstash日志过程中,我们看到了大量的以下报错

    1

    2[2017-03-18T09:46:21,043][INFO][logstash.outputs.elasticsearch] retrying failed action with response code: 429 ({"type"=>"es_rejected_execution_exception", "reason"=>"rejected execution of org.elasticsearch.transport.TransportService$6@6918cf2e on EsThreadPoolExecutor[bulk, queue capacity = 50, org.elasticsearch.common.util.concurrent.EsThreadPoolExecutor@55337655[Running, pool size = 24, active threads = 24, queued tasks = 50, completed tasks = 1767887463]]"})

    [2017-03-18T09:46:21,043][ERROR][logstash.outputs.elasticsearch] Retrying individual actions

    查询官网,确认为时ES的写入遇到了瓶颈

    1Make sure to watch for TOO_MANY_REQUESTS (429) response codes (EsRejectedExecutionException with the Java client), which is the way that Elasticsearch tells you that it cannot keep up with the current indexing rate. When it happens, you should pause indexing a bit before trying again, ideally with randomized exponential backoff.

    我们首先想到的是来调整ES的线程数,但是官网写到”Don’t Touch There Settings!”, 那怎么办?于是乎官方建议我们修改logstash的参数pipeline.batch.size

    在ES5.0以后,es将bulk、flush、get、index、search等线程池完全分离,自身的写入不会影响其他功能的性能。

    来查询一下ES当前的线程情况:

    1

    2

    3

    4

    5

    6

    7

    8

    9

    10

    11

    12

    13

    14

    15

    16

    17

    18

    19

    20

    21

    22

    23

    24

    25

    26

    27

    28

    29

    30

    31

    32

    33

    34

    35

    36

    37

    38

    39

    40

    41

    42

    43

    44

    45

    46

    47GET _nodes/stats/thread_pool?pretty

    {

    "_nodes": {

    "total": 6,

    "successful": 6,

    "failed": 0

    },

    "cluster_name": "dev-elasticstack5.0",

    "nodes": {

    "nnfCv8FrSh-p223gsbJVMA": {

    "timestamp": 1489804973926,

    "name": "node-3",

    "transport_address": "192.168.3.***:9301",

    "host": "192.168.3.***",

    "ip": "192.168.3.***:9301",

    "roles": [

    "master",

    "data",

    "ingest"

    ],

    "attributes": {

    "rack": "r1"

    },

    "thread_pool": {

    "bulk": {

    "threads": 24,

    "queue": 214,

    "active": 24,

    "rejected": 30804543,

    "largest": 24,

    "completed": 1047606679

    },

    ......

    "watcher": {

    "threads": 0,

    "queue": 0,

    "active": 0,

    "rejected": 0,

    "largest": 0,

    "completed": 0

    }

    }

    }

    }

    }

    其中:”bulk”模板的线程数24,当前活跃的线程数24,证明所有的线程是busy的状态,queue队列214,rejected为30804543。那么问题就找到了,所有的线程都在忙,队列堵满后再有进程写入就会被拒绝,而当前拒绝数为30804543。

    优化方案

    问题找到了,如何优化呢。官方的建议是提高每次批处理的数量,调节传输间歇时间。当batch.size增大,es处理的事件数就会变少,写入也就越快了。

    1

    2

    3

    4

    5

    6vim /etc/logstash/logstash.yml

    #

    pipeline.workers: 24

    pipeline.output.workers: 24

    pipeline.batch.size: 10000

    pipeline.batch.delay: 10

    具体的worker/output.workers数量建议等于CPU数,batch.size/batch.delay根据实际的数据量逐渐增大来测试最优值。

    展开全文
  • TD-LTE上行吞吐率优化指导书 拟制: 广西LTE专项项目组 日期: 更新: 日期: 审核: 日期: 批准: 日期: 华为技术有限公司 版权所有 侵权必究 目录 1 指标定义和调度原理 2 1.1 指标定义 2 1.2 上行调度...

    产品名称 密级
    LTE 内部公开
    产品版本 共12页

    TD-LTE上行吞吐率优化指导书

    拟制: 广西LTE专项项目组 日期:
    更新: 日期:
    审核: 日期:
    批准: 日期:

    华为技术有限公司
    版权所有 侵权必究

    目录
    1 指标定义和调度原理 2
    1.1 指标定义 2
    1.2 上行调度基本过程 3
    2 影响上行吞吐率的基本因素 3
    2.1 系统带宽 3
    2.2 数据信道可用带宽 3
    2.3 UE能力限制 4
    2.4 上行单用户RB数分配限制 4
    2.5 信道条件 4
    问题的定位思路 5
    2.6 上行吞吐率根因分析全貌 5
    2.7 问题定位流程详述 6
    2.7.1 分配RB数少/UL Grant不足定位方法 6
    2.7.2 低阶MCS定位方法 7
    2.7.3 IBLER高问题定位方法 7
    2.7.4 覆盖问题定位方法 8
    3 典型案例 8
    3.1 上行达不到峰值 8
    3.1.1 问题描述 8
    3.1.2 问题分析 8
    3.1.3 解决措施 8

    1指标定义和调度原理
    1.1指标定义
    吞吐率定义:单位时间内下载或者上传的数据量。
    吞吐率公式:吞吐率=∑下载上传数据量/统计时长。
    上行吞吐率主要通过如下指标衡量,不同指标的观测方法一致,测试场景选择和限制条件有所不同:
    (1)上行单用户峰值吞吐率:上行单用户峰值吞吐率以近点静止测试,进行UDP/TCP灌包,使用RLC层平均吞吐率进行评价。需要记录下行RSRP、上行SINR、上行RLCThr、IBLER等信息。
    (2)上行单用户平均吞吐率:上行单用户平均吞吐率以移动测试时,进行UDP/TCP灌包,使用RLC层平均吞吐率曲线(吞吐率-PL曲线)进行评价。移动区域包含近点、中点、远点区域,移动速度最好30km/h以内。需要记录下行RSRP、上行SINR、上行RLCThr、IBLER等信息;RLC层平均吞吐率使用各点吞吐率地理平均结果。为便于问题定位,单用户平均吞吐率测试时,需要同时记录probe信息,以便从地理分布上找出异常点进行问题定位。
    (3)上行单用户边缘吞吐率:上行单用户边缘吞吐率是指移动测试,进行UDP/TCP灌包,对RLC吞吐率进行地理平均,以两种定义分别记录边缘吞吐率。
    定义1)以CDF曲线5%的点为边缘吞吐率;
    定义2)以PL为120定义为小区边缘,此时的吞吐率为边缘吞吐率;此处只定义RSRP边缘覆盖的场景,假定此时的干扰接近白噪声,此种场景类似于单小区测试。对于多个小区共同覆盖的干扰高风险边缘区域的定义,已经有运营商提出,在以后的文档版本更新完善。
    (4)上行小区峰值吞吐率:上行小区峰值吞吐率测试时,用户均在近点,采用UDP/TCP灌包,信道质量足以达到最高阶MCS,IBLER为0;通过小区级RLC平均吞吐率观测。测试步骤如下:
    a、用户近点接入,同时开始上行灌包。
    b、记录数据,包括每UE上行SINR、IBLER、Thr和Probe信息,以及上行小区吞吐率和RB利用率。
    (5)上行小区平均吞吐率:上行小区平均吞吐率测试时,用户分布一般类似1:2:1分布,即近点1UE、中点2UE、远点1UE,其中近点/中点/远点定义为RSRP-85dbm/-95dbm/-105dbm。采用UDP/TCP灌包。通过小区级RLC平均吞吐率观测;记录包括每UE上行SINR、IBLER、Thr和Probe信息,以及上行小区吞吐率和RB利用率。
    1.2上行调度基本过程

    在初始接入时,UE在PUCCH发送SR(调度请求),用来请求少量数据的上行资源调度。eNB侧根据实际资源情况和调度算法,给UE分配相应的上行资源,在PDCCH上下发ULGrant通知UE;在已有上行资源的情况下,UE在PUSCH发送BSR(缓冲区状态报告)进行上行资源调度请求;eNB侧在PDCCH上下发ULGrant通知UE。
    2影响上行吞吐率的基本因素
    2.1系统带宽
    系统的不同带宽决定了系统的总RB数

    2.2数据信道可用带宽
    公共信道的开销进一步决定了用户可以实际使用的资源,其中下行主要包括PDCCH和系统消息,上行主要包括PUCCH、SRS、PRACH.
    2.3UE能力限制
    在计算单用户峰值时,在考虑用户可用带宽时,还需要考虑UE能力的限制,不同类型UE具备不同的上下行峰值速率,且只有Cat5终端才支持上行64QAM;

    2.4上行单用户RB数分配限制
    在计算单用户的上行吞吐率时,还要考虑单用户分配的RB个数需满足一定条件。
    2.5信道条件
    信道条件主要包含RSRP,AVGSINR,信道相关性等参数,这些都会对实际的信号解调性能造成影响。如果RSRP过低,则可使用的有用信号的越低;如果AVGSINR过低,则干扰信号强度较有用信号越大;而信道相关性会对RANK值计算造成影响:一般MIMO模式要求信道相关性低,而BF模式则要求信道相关性高,这些都将对解调性能造成较大影响。
    3问题的定位思路
    3.1上行吞吐率根因分析全貌

    4.1-1 上行吞吐率低问题分析定位思路
    一般而言,吞吐率由频谱效率、频带宽度、频带占用机会、误码率综合决定。在LTE系统中,频谱效率由MCS决定,MCS由SINR和IBLER决定;频带宽度由分配的RB数决定;频带占用机会由UL grant决定;误码率主要考虑IBLER,HARQ重传以后,残留BLER通常较低,但由于重传会影响传输的效率,进而影响RLC层吞吐率,因此只考虑初次传输的BLER,也即IBLER。
    3.2问题定位流程详述
    3.2.1分配RB数少/UL Grant不足定位方法
    当发现RB数较少/UL grant低时,需要进行以下的判断动作:
    首先检查是否为DSP能力限制;通过IFTS跟踪观察上行DSP能力限制的RB数。
    观察核心网指配的QoS速率,如果偏低,则检查核心网开户信息是否异常;
    从L1 TTI跟踪中统计观察是否存在大量DTX情况,判断方法:观察上行DMRS RSRP,如果发现RSRP值在调度的TTI处于底噪(-120dbm)附近,或者与前后的RSRP值相差较大,则认为是上行PUSCH的DTX。对比eNB侧DCI0次数,如果相差较大,则认为存在大量的DTX,需要判断PDCCH质量问题,是否是下行PDCCH IBLER较高,导致UL Grant解错。说明:PDCCH允许一定的误检率,允许1%以内;而且上行HARQ时,调度器不需要下发ULGrant。
    观察是否数据源不足(上报BSR 对应的值),如果数据源不足,需要排查是否上层数据源异常,可能包括如下原因:(1)如果是UDP业务,检查上行灌包(出口速率)是否超过峰值速率。(2)如果是TCP单线程业务,尝试多个线程,如果吞吐量可以提升到峰值速率,则可以认定是PC机的TCP窗口没有符合要求。说明:如果ULGrant个数偏小,一般是由于上述两个原因导致。
    在性能检测中观察在线用户数,看是否存在多用户并行业务(2个以上)的情况,如果存在多用户,则主要观察RB利用率是否达到了100%,公平性是否得到满足。如果RB利用率低,则需要判断ICIC和频选是否开关打开,是否存在问题;如果公平性得不到满足,则可能为功控和ICIC的问题。这里的公平性指RB数公平,与算法的目标一致。
    检查PRACH的资源配置。上行预留PRACH的时候,会对上行分配RB产生影响,对上行峰值速率产生影响,10M系统更明显。可以将PRACH设置到PUSCH最低端,且将PRACH默认周期从5ms扩大为20ms。
    检查PUCCH配置,当前默认配置占用8RB,在单用户峰值测试时,可以手动改为2个RB,提高上行峰值吞吐率,再测极限峰值。
    3.2.2低阶MCS定位方法
    MCS由几方面决定:干扰、IBLER、UE CAT能力、是否扩展CP、下行PDCCH质量:
    在较高的上行SINR时,如果下行PDCCH质量太差,导致UL grant丢失,会导致IBLER较高;SINR调整算法模块,依据IBLER历史信息,对SINR测量值进行调整,输入到MCS选择模块,确保IBLER收敛于目标值。也就是说在PDCCH较差的情况下,可能存在上行SINR较好而MCS较低的情况。这种情况下通过查看上行测量SINR、SINR调整量、IBLER可以进行判断。如果某一段时间测量SINR比较高,而SINR调整量为负的较大值,而IBLER也超过门限值,则可能属于这种情况,需要进行PDCCH质量的问题进行分析。
    空载时(UE没有入网),打开LMT上小区性能检测中的干扰检测项,查看全带宽上RSSI(第101列)是否超过正常范围。以下为空载下,RSSI取值(底噪为-120dBm左右,全带宽为RSSI显示中第101列)
    BW RSSI
    20MHz -101dBm
    10MHz -104dbm
    5MHz -107dBm
    如果空载下,总RSSI明显大于上述值,需要确认是否存在干扰。可以查看不同RB上干扰状况(一般为-120波动)。特别注意观察中间频段RB上的RSSI是否比其他RB上高较多(RRU或者其他设备的直流干扰会抬升RSSI)。出现这种现象时请检查组网和UE RRU,通过扫频确定是否有窄带干扰,或者是UE设备异常。(说明:所谓中间频段是只RB序号在中间的RB,如20M带宽时,49和50RB;10M带宽时24和25RB。)
    判断是否由于终端能力限制,具体现象是MCS阶数最大只能达到24阶,这时进一步查看终端能力即可判断。
    是否扩展CP在算法中对应了不同的MCS选择表格,映射得到的MCS有区别,在非超远覆盖场景下,需保证设置为normal CP。
    3.2.3IBLER高问题定位方法
    查看空载RSSI是否有干扰(3.2.2所述),排除干扰问题;同时观察UE发射功率是否为最大,如果未达到最大,则可能为UE问题。
    在统计IBLER时,如果发生PDCCH质量差导致UL grant丢失,UE不发数据的情况,eNB会将该TTI作为CRC校验错处理,统计为误块,导致IBLER升高。
    当发现IBLER不收敛时,如果非MCS0,则需要判断SINR调整算法开关SW_SINR_ADJUST是否关闭,该开关关闭以后,导致MCS选择前的SINR调整量不能依据IBLER情况及时调整,MCS无法降低导致IBLER无法收敛;如果该开关打开,则检查调整量是否已经达到下限不能再下降从而导致MCS无法降低同时IBLER升高。
    3.2.4覆盖问题定位方法
    存在上行RSRP信号较弱导致上行吞吐率低情况,可查看UE发射功率是否达到最大,如果未达到最大,则可能为UE问题。如果UE发射功率已达到最大,可从链路损耗、覆盖范围、是否存在阻挡物或弱覆盖区域等原因进行处理。
    切换异常,一般指切换到不合理小区、切换不及时、切换频繁导致上行吞吐率低,需结合无线环境、配置参数进行处理。
    4典型案例
    4.1上行达不到峰值
    【问题描述】:小区近点上行吞吐率无法达到峰值。
    【问题分析】:上行单用户吞吐率达到峰值必须具备以下三个条件:
    MCS选择到最高28阶,BLER为0;这就要求SINR要高于20dB。
    UE分配到最多RBNum;
    数据源充足,ULGrant个数等于每s上行的子帧个数。
    因此,这个问题的定位需要从RBNum、MCS/SINR和ULGrant数目三个方面进行。
    确保MCS选择到最高阶。
    通过Probe查看上行MCS。Probe中的UL MCS显示栏中务必只显示MCS 28和MCS27,其中MCS28和MCS27的调度次数相加等于上行子帧个数表示调度数据充足,100个27阶是因为发送SRS时SRS子帧码率会增加,需要强制降阶(TDD在用户数较少的情况下,SRS在特殊子帧发数,就不会有降阶的问题)。如果ULGrant个数低于上行子帧个数,请检查数据源是否充足或者BSR上报周期是否合理(修改为5ms)。
    说明:MCS由两方面决定:SINR值和IBLER。P0决定了到达ENB的期望功率谱密度,直接影响SINR,进而影响MCS。如果上行SINR波动较大,导致有时BLER较高,SINR调整功能为保证IBLER收敛会降低MCS。
    查看SINR。从MCS定标测试结果看,48RB下,MCS28阶需要SINR在20dB以上。SINR低于20dB从以下几个方面定位:
    在Probe上查看UE发射功率是否达到最大23dBm。开环时,需确认P0是否配置合理值(基线偏=-67dBm,α=0.7)。如果发射功率没有达到最大,需要通过抬升P0抬升UE发射功率。
    如果上行SINR波动较大,查看是否是TA不准导致;是否是不断变化的干扰导致。可以将UE退网,观察RSSI。
    确保干扰 IOT在正常范围内。
    空载时(UE没有入网),打开LMT上小区性能检测中的干扰检测项,查看全带宽上RSSI(第101列)是否超过正常范围。以下为空载下,RSSI取值(底噪为-121dBm,全带宽为RSSI显示中第101列)
    BW RSSI
    20MHz -101dBm
    10MHz -104dbm
    5MHz -107dBm
    如果空载下,总RSSI明显大于上述值,需要确认是否存在干扰。可以查看不同RB上干扰状况(一般为-121波动)。特别注意观察中间频段RB上的RSSI是否比其他RB上高较多(RRU或者其他设备的直流干扰会抬升RSSI)。出现这种现象时请检查组网和UE RRU,或者联系RTT和中射频兄弟定位。(说明:所谓中间频段是只RB序号在中间的RB,如20M带宽时,49和50RB;10M带宽时24和25RB。)
    确保RB数目达到最大。
    查看UE分配RB数目有两种途径:UE侧Probe查看和eNB侧LMT跟踪
    通过Probe中Bandwith项监控查看:

    其中,左边一列表示RB数目,右边一列表示RB起始位置。如上图
    一是LMT中RB利用率监控项,单用户最大90RB,加上PUCCH 8个RB,应该显示98RB;
    如果RB数目不足,可能由以下几个原因:
    数据源不足。
    P0设置不合理。
    PRACH占用资源。
    确保ULGrant充足。
    可以通过查看Probe上的ULGrant个数确定。

    如果ULGrant小于上行子帧总数,则说明数据量不足或者PDCCH解错。可能由以下原因引起:
    (1)如果是UDP业务,检查上行灌包(出口速率)是否超过峰值速率。
    (2)如果是TCP单线程业务,尝试多个线程,如果吞吐量可以提升到峰值速率,则可以认定是业务电脑的TCP窗口没有符合要求,需要按照本文前述方法修改TCP默认发送窗口太小。
    说明:如果ULGrant个数不足,一般是由于上述两个原因导致。
    (3)是否是下行PDCCH BLER较高,导致UL Grant解错。需要修改PDCCH的CCE聚合级别。
    说明:PDCCH允许一定的误码率,默认是1%;而且上行HARQ时,调度器不需要下发ULGrant,所以在计算ULGrant个数时需要用上行子帧总数*0.9。
    (4)BSR上报问题。需要将BSR周期从32ms修改为5ms。
    4 通过修改PRACH位置和周期提高峰值速率。
    上行预留PRACH的时候,会对上行分配RB产生影响,对上行峰值速率产生影响,10M系统更明显。可以将PRACH设置到PUSCH最低端,且将PRACH默认周期从5ms扩大为20ms。
    5 通过修改PUCCH占用RB数目提高峰值速率。

    展开全文
  • 我以为这个方案吞吐率会很高,但实际运行时,在最后时刻经常出现这种情况: 如图,梯子1,2,3明明都是空的,但后上梯子的猴子还是只选择梯子0.实际观察会发现,在等待梯子1上所有猴子过河的过程中,吞吐率会有比较...

    为猴子选择梯子时,其中的一个策略是选择距离起点最近的猴子速度最大的梯子。我以为这个方案吞吐率会很高,但实际运行时,在最后时刻经常出现这种情况:
    在这里插入图片描述
    如图,梯子1,2,3明明都是空的,但后上梯子的猴子还是只选择梯子0.实际观察会发现,在等待梯子1上所有猴子过河的过程中,吞吐率会有比较大的下降。(gui上显式的是实时吞吐率)
    思考之后我发现,可能是因为这些猴子在生成后,立刻进行选择梯子的操作,当时梯子0的指标比较优越,就导致这一批猴子全部选中了梯子0.而由于猴子生成和过河之间隔了较长的一段时间,导致等到这批猴子过河的时候全部集中选择梯子0.
    很明显,这不是我们想要的结果。为了提高吞吐率,我们希望猴子尽可能均匀地分布在所有梯子上。由此,我在上述方案的基础上进行了改进。在每个猴子选中一个梯子后,将其添加到该梯子的等待列表上,在其在梯子上前进一次之后,将其从梯子的等待列表移除。而在选择梯子时,若要选中一个梯子,需要满足一下三个条件:

    • 梯子方向与该猴子方向相同
    • 该梯子距离起点最近的猴子速度最大
    • 该梯子等待列表中的猴子个数不超过k(自己设定)
      如果没有满足条件的梯子,则该猴子在岸上等待,1s后重新进行一次选择。

    改进的方案能够比改进前的方案取得更高的吞吐率
    在这里插入图片描述

    展开全文
  • 最近我做了一些以太网吞吐量和丢包方面的优化工作,有一些心得和大家分享一下。 一、测试模型 二、影响吞吐量和丢包的因素 1. 网卡DMA缓冲区大小 这个缓冲区决定tx ring buffer和rx ring buffer的大小...

    现在有很多硬件平台理论上支持千兆以太网接口,但实际传输速率远远低于千兆,并且丢包率很高。最近我做了一些以太网吞吐量和丢包率方面的优化工作,有一些心得和大家分享一下。

    一、测试模型

     

    二、影响吞吐量和丢包率的因素

    1. 网卡DMA缓冲区大小

        这个缓冲区决定tx ring buffer和rx ring buffer的大小,如果ring buffer太小,那么网卡缓存数据包的能力有限,当接收数据能力超过cpu处理能力时就会产生丢包现象。ring buffer越大,吞吐能力就越强,丢包的概率就越小。

     

    2. CPU处理能力

        CPU处理速度越快,网卡接收到的数据包在网卡DMA缓冲区中的存留时间就越短,因此就可以腾出更多的空间来暂存新接收到的数据包。因此,CPU的处理能力直接决定了系统的吞吐量,运算速度越快,吞吐量越高。

     

    3. 内存总容量

        当网卡DMA缓冲区太小时,ring buffer不够用,会造成网络数据丢包。此时,需要将数据包及时从ring buffer里面取出来,暂存到接收队列里面(发送数据时同理)。然后在合适的时机再把数据包上传给协议栈。这种处理方式会瞬时大量消耗系统内存,当吞吐量很大时,会引起内存剩余容量抖动,甚至导致内存不足的异常出现。

     

    三、调试注意事项

    1. 当前ring buffer是否设置为网卡最大ring buffer;

    2. 高负载时注意CPU占用率,重点关注软中断和网络数据包处理线程的占用率总和;

    3. 关注low memory剩余容量,长时间测试时,剩余容量是否有下降趋势;

    4. 长时间测试后,查看log,系统是否有出现异常报警;

     

    四、推荐优化方法

    1. 提高CPU处理能力,例如提升CPU频率或者运行模式;

    2. 提高内存总容量,增加系统内存或者更换更大的内存;

    3. 优化软中断收发包的处理方法,将软中断处理数据包的过程分为两步处理。例如把收包放到软中断里面处理,把数据包上报协议栈放到内核线程处理,类似于上半部和下半部。这样做可以减少中断屏蔽时间,尽可能多的接收外部数据到网卡缓冲区,从而增加吞吐量。同时,用内核线程去上报数据包到协议栈可以避免丢包。

     

    上面介绍了千兆网卡提升吞吐量和减小丢包率的方法,我实际测试有很大的改善,分享出来供大家参考。

    当然,实际优化过程中可能会遇到更种问题,本文仅仅提供优化思路。

     

     

     

     

     

    展开全文
  • 但是存在预测结果不准确的情况,影响整个网络的吞吐率。在基于遗传算法优化的神经网络预测模型基础上,提出了SU进行协作的频谱预测方法,提高了SU预测空闲信道的准确率。讨论了协作频谱预测条件下,在通信强度、协作...
  • 我们知道,CPI的倒数,又叫做IPC(Instruction Per Clock),也就是一个时钟周期里面能够执行的指令数,代表了CPU的吞吐率。那么,这个指标,放在我们前面几节反复优化流水线架构的CPU里,能达...
  • 了解GC的CPU和内存开销 并发GC通常会增加CPU的使用。...对于低吞吐量的非计算密集型应用,GC的高CPU使用可能不需要担心。 图2 ParNew/CMS和G1的CPU使用百分数%:相对来说CPU使用变化明显的节点使...
  • 当然了,对于服务器的提速方案也要根据具体情况而言,比如对于香港服务器,我们应该采用充分提高服务器带宽利用来达到相应的提速要求,对于一些容易抽风的地区,我们也可以采用此方案。我们今天主要利用锐速...
  • 指令系统计算机的基本概念指令系列机AmdahlAmdahlAmdahl定律CPU性能公式系统结构的评价标准等效指令速度指令系统主流指令系统指令系统的设计与优化指令组成指令系统的优化指令字格式的优化缩短地址码地址码优化指令...
  • 降低 GC 频率在分代 GC 算法中,降低 GC 频率可以通过:(1) 降低对象分配(新生代)/晋升(老年代);(2) 增加各代空间的大小,(3)增加Old GC触发阈值但是空间并不是越大越好,相反,过大的空间可能会导致GC的停顿时间...
  • 性能优化有两大指标:延时与吞吐。linux优化思维导图:平均负载[root@node200 ~]# uptime 20:45:44 up 11:24, 2 users, load average: 0.00, 0.01, 0.05 当前时间 启动运行时长 当前正在登陆的用户 1、5、15分钟...
  • MySQL优化方法主机操作系统数据库应用MySQL优化理论吞吐率(Throughput) VS 延时(Latency)吞吐率: 我们一般使用单位时间内服务器处理的请求数来描述其并发处理能力。称之为吞吐率(Throughput),单位是 “req/s”。 ...
  • 性能优化概述

    千次阅读 2017-09-04 10:53:10
    如何做性能优化 确定优化目标 定位性能瓶颈 制定优化方法 测试优化效果 ...性能优化目标是什么 ...吞吐量,越大越好 ...同样的资源下(前提),吞吐量越高越好,响应时间越低越好。...通过对资源使用
  • 研究了信息与能量同传中继信道传输速率的优化与实现。系统模型为三节点两跳中继模型,中继...仿真证明,两跳不等时长的安排可以获得更高的吞吐量,而采用Raptor码可实现对信道容量的充分利用和信息高效而可靠的传输。
  • LNMP优化

    2019-09-26 17:33:51
    LNMP优化 LNMP优化从系统安全,系统资源占用率,及web服务并发负载这三个方面体现,并 且主要体现在web服务并发负载这...容量,提高硬盘吞吐率等。 本文谈的Linux优化加固是在不提升硬件配置的情况下,通过优化...
  • MySQL优化方法的关键是? MySQL参数优化,innodb_buffer_pool_size/innodb_flush_log_at_trx_commit/sync_binlog...吞吐率:一般使用单位时间内服务器处理的请求数来描述其并发处理能力,称之为吞吐率(Throughput...
  • lnmp mysql 优化_LNMP优化

    2021-01-27 06:39:33
    1:首先进行linux优化加固Linux优化加固最好的办法就是提升硬件配置,比如提高CPU运算能力,增大内存容量,提高硬盘吞吐率等。本文谈的Linux优化加固是在不提升硬件配置的情况下,通过优化内核配置,从而提高linux...
  • MySQL优化方法论

    2019-01-09 11:22:00
    MySQL优化理论 吞吐率(Throughput) VS 延时(Latency) 吞吐率: 我们一般使用单位时间内服务器处理的请求数来描述其并发处理能力。 称之为吞吐率(Throughput),单位是 “req/s”。 吞吐率特指Web服务器单位时间...
  • Hbase性能优化

    2018-07-18 21:25:26
    一、性能优化 1.1性能优化的目标 (1)读VS写 ...(3)参考值——每个RegionServer吞吐率>20MB/s 读吞吐率>3000ops/s,写吞吐率>10000ops/s (4)尽量在Hbase表结构设...
  • 性能优化

    2020-11-19 09:17:46
    性能指标:吞吐率、响应时间、QPS/IOPS、TP99、资源使用率是我们经常关注的指标。 时间度量:从cpu cycle到网络IO,自上到下,时间量级越大。 监控、分析、优化,三部曲,以终为始,循环往复。 ...
  • 在如今互联网时代,数据的实时搜索性,针对生产环境几百万 QPS/S,只有在了解 ElasticSearch 高阶原理后,才能更有效的进行优化,提升索引以及读写并发性,通过压测快速定位问题并找到解决方案,本场 Chat 您将学...
  • CUDA优化总结

    千次阅读 2016-12-16 17:55:30
    优化内存使用方法来获得最大的内存吞吐优化指令使用方式来获得最大的指令吞吐量 具体再可以从以下几个方面入手:CUDA配置优化:指的是在CUDA核函数执行之前,其参数的设置,根据显卡的参数,结合核函数的特点,...
  • 这些场景的特性是,会在短时间内产生大量的数据需要消化并写入数据库,需要数据库能够提供高并发、高吞吐率的写入性能,需要满足每秒上万行甚至上百万行的写入吞吐率。针对这些场景,我们在存储层做了很多的优化(本...
  • 为了评估这种有效的TCP吞吐量表达式,将两个跨层优化问题作为应用示例进行了阐述,以分别最大化传输层的有效吞吐量和能源利用。 仿真结果表明,我们对传输机会的分析是准确的,所推导的有效TCP吞吐量表达比现有的...
  • Cao的JEP草案旨在在禁用并发优化时提高G1垃圾收集器的吞吐量,并减少总体CPU使用。 他之所以想这样做,是因为G1垃圾收集器的写后障碍目前比并行和并发标记清除等传统垃圾收集器要复杂。 原因是G1支持并发优化,这...
  • jvm优化

    千次阅读 2016-05-10 14:55:03
    一、初始状态,吞吐量为8.7/s 二、参考java程序性能优化。重新设置堆大小和永久区大小、禁用显示GC、去掉类校验、使用并行回收收集器代替串行收集器、使用CMS回收器、设置较大的survivior区,...吞吐率提高到9.4/s
  • 针对采用复合域方法来实现字节替换吞吐率小的问题,本文利用先计算的方法进行了5级轮内流水线设计,去除关键路径上的一些计算来降低关键路径延迟提高吞吐率。在FPGA器件Virtex-6 XC6VLX240T上,通过Xilinx ISE 14.7...
  • 优化的目的 我们线上hbase集群使用了group分组功能,但没有针对不同业务分组的特点做特殊优化,hbase服务能力没有彻底激发出来。...从而提高吞吐能力,进而减少机器,提升资源利用的能力,节约成本。 要...
  • 在此基础上,提出了调节误包率、优化业务吞吐率,并通过加权以满足业务不同吞吐率和延迟要求的优化算法,优化综合了物理层、MAC层、链路层和业务要求的影响.为验证算法的正确性,进行了仿真分析.结果表明,在给定的参数下...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 652
精华内容 260
关键字:

吞吐率优化