写点什么

Intel PAUSE 指令变化影响到 MySQL 的性能,该如何解决?

  • 2020-04-23
  • 本文字数:11215 字

    阅读完需:约 37 分钟

Intel PAUSE指令变化影响到MySQL的性能,该如何解决?

1. 背景

在 2017 年,Intel 发布了新一代的服务器平台 Purley,并将 Intel Xeon Scalable Processor(至强可扩展处理器)重新划分为:Platinum(铂金)、Gold(金)、Silver(银)、Broze(铜)等四个等级。产品定位和框架也变得更加清晰。


因美团线上海量数据交易和存储等后端服务依赖大量高性能服务器的支撑。随着线上部分 Grantly 平台 E 系列服务器生命周期的临近,以及产品本身的发展和迭代。2019 年开始,RDS(关系型数据库服务)后端存储(MySQL)开始大量上线 Purley 平台的 Skylake CPU 服务器,其中包含 Silver 4110 等。


Silver 4110 相比上一代 E5-2620 V4,支持更高的内存频率、更多的内存通道、更大的 L2 Cache、更快的总线传输速率等。Intel 官方数据显示 Silver 4110 的性能比上一代 E5-2620 V4 提升了 10%。


然而,随着线上 Skylake 服务器数量的增加,以及越来越多的业务接入。美团 MySQL DBA 团队发现部分 MySQL 实例性能与预期并不相符,有时甚至出现较大程度的下降。经过持续的性能问题分析,我们定位到 Skylake 服务器存在性能瓶颈:


  • CPU 负载相对较高。

  • TPS 等吞吐量下降。


接下来,我们将从 Intel CPU、ut_delay 函数、PAUSE 指令三方面入手,进行剖析定位,并探索相关优化方案。

2. 性能问题分析

2.1 Grantly 与 Purley CPU 性能差异

首先,基于上述两代平台的 CPU(Grantly 和 Purley),通过基准测试,横向对比在不同 OS 下的性能表现。


通过基准测试数据,总结如下:


  1. 在 oltp_write_only(只写)的场景下 Purley 4110 的性能下降较为明显。

  2. 同为 Purley 4110,CentOS 7 比 CentOS 6 oltp_write_only(只写)性能有提升。


我们通过二维折线图,来展示性能之间的差异:



在上图中,同为 Purley 4110,CentOS 7 比 CentOS 6 性能有提升。具体提升原因,因不涉及本文重点内容,所以不在这里详细展开了。


New MCS-based Locking Mechanism

Red Hat Enterprise Linux 7.1 introduces a new locking mechanism, MCS locks. This new locking mechanism significantly reduces spinlock overhead in large systems, which makes spinlocks generally more efficient in Red Hat Enterprise Linux 7.1.


红帽官网 Release Notes 显示,从内核 3.10.0-229 开始,引入了新的加锁机制,MCS 锁。可以降低 spinlock 的开销,从而更高效地运行。普通 spinlock 在多 CPU Core 下,同时只能有一个 CPU 获取变量,并自旋,而缓存一致性协议为了保证数据的正确,会对所有 CPU Cache Line 状态、数据,同步、失效等操作,导致性能下降。而 MSC 锁实现每个 CPU 都有自己的“spinlock”本地变量,只在本地自旋。避免 Cache Line 同步等,从而提升了相关性能。不过,社区对于 spinlock 的优化争议还是比较大的,后续又有大牛基于 MSC 实现了 qspinlock,并在 4.x 的版本上 patch 了。具体实现可以参看:MCS locks and qspinlocks


在大致了解 CentOS 7 性能的迭代后,接下来我们深入分析一下 Skylake CPU 4110 导致性能下降的缘由。

3. CPU 性能跟踪

3.1 定位热点函数

具体定位 4110 性能瓶颈,分如下几步:


  1. 首先,通过 perf top 来跟踪一下 Linux CPU 性能开销。

  2. 然后,通过 perf record 记录函数 CPU 周期的消耗占比。

  3. 最后,通过火焰图来验证定位热点函数。



可以看到,其中占 CPU 消耗占比较大为:ut_delay 函数。


我们继续深挖一下函数链调用关系:


# Children      Self  Command  Shared Object        Symbol                                                                                                                                                                            # ........  ........  .......  ...................  ..................................................................................................................................................................................#    93.54%     0.00%  mysqld   libpthread-2.17.so   [.] start_thread            |            ---start_thread               |                         |--77.07%--pfs_spawn_thread               |          |                         |           --77.05%--handle_connection               |                     |                         |                      --76.97%--do_command               |                                |                         |                                |--74.30%--dispatch_command               |                                |          |                         |                                |          |--71.16%--mysqld_stmt_execute               |                                |          |          |                         |                                |          |           --70.74%--Prepared_statement::execute_loop               |                                |          |                     |                         |                                |          |                     |--69.53%--Prepared_statement::execute               |                                |          |                     |          |                         |                                |          |                     |          |--67.90%--mysql_execute_command               |                                |          |                     |          |          |                         |                                |          |                     |          |          |--23.43%--trans_commit_stmt               |                                |          |                     |          |          |          |                         |                                |          |                     |          |          |           --23.30%--ha_commit_trans               |                                |          |                     |          |          |                     |                         |                                |          |                     |          |          |                     |--18.86%--MYSQL_BIN_LOG::commit               |                                |          |                     |          |          |                     |          |                         |                                |          |                     |          |          |                     |           --18.18%--MYSQL_BIN_LOG::ordered_commit               |                                |          |                     |          |          |                     |                     |                         |                                |          |                     |          |          |                     |                     |--8.02%--MYSQL_BIN_LOG::change_stage               |                                |          |                     |          |          |                     |                     |          |                         |                                |          |                     |          |          |                     |                     |          |--2.35%--__lll_unlock_wake               |                                |          |                     |          |          |                     |                     |          |          |                         |                                |          |                     |          |          |                     |                     |          |           --2.24%--system_call_fastpath               |                                |          |                     |          |          |                     |                     |          |                     |                         |                                |          |                     |          |          |                     |                     |          |                      --2.24%--sys_futex               |                                |          |                     |          |          |                     |                     |          |                                |                         |                                |          |                     |          |          |                     |                     |          |                                 --2.23%--do_futex               |                                |          |                     |          |          |                     |                     |          |                                           |                         |                                |          |                     |          |          |                     |                     |          |                                            --2.14%--futex_wake               |                                |          |                     |          |          |                     |                     |          |                                                      |                         |                                |          |                     |          |          |                     |                     |          |                                                       --1.38%--wake_up_q               |                                |          |                     |          |          |                     |                     |          |                                                                 |                         |                                |          |                     |          |          |                     |                     |          |                                                                  --1.33%--try_to_wake_up               ...
复制代码


将上述调用通过火焰图进行直观展示:



现在基本可以确定,所有的函数调用,最后大部分的消耗都在 ut_delay 上。

3.2 ut_delay 和 PAUSE 之间的关联与性能影响

3.2.1 MySQL ut_delay 实现

接下来,我们继续看一下 MySQL 源码中 ut_delay 函数的功能:


/*************************************************************//**Runs an idle loop on CPU. The argument gives the desired delayin microseconds on 100 MHz Pentium + Visual C++.@return dummy value */ulintut_delay(/*=====*/  ulint delay)  /*!< in: delay in microseconds on 100 MHz Pentium */{  ulint i, j;
UT_LOW_PRIORITY_CPU();
j = 0;
for (i = 0; i < delay * 50; i++) { j += i; UT_RELAX_CPU(); }
UT_RESUME_PRIORITY_CPU();
return(j);}...
# define UT_RELAX_CPU() asm ("pause" )# define UT_RELAX_CPU() __asm__ __volatile__ ("pause")
复制代码


可以了解到,MySQL 自旋会调用 PAUSE 指令,从而提升 spin-wait loop 的性能。

3.2.2 PAUSE 指令周期的演变

我们可以看下 Intel 官网,也描述了在新平台架构 PAUSE 的改动:


Pause Latency in Skylake MicroarchitectureThe PAUSE instruction is typically used with software threads executing on two logical processors located in the same processor core, waiting for a lock to be released. Such short wait loops tend to last between tens and a few hundreds of cycles, so performance-wise it is better to wait while occupying the CPU than yielding to the OS. When the wait loop is expected to last for thousands of cycles or more, it is preferable to yield to the operating system by calling an OS synchronization API function, such as WaitForSingleObject on Windows* OS or futex on Linux.

The latency of the PAUSE instruction in prior generation microarchitectures is about 10 cycles, whereas in Skylake microarchitecture it has been extended to as many as 140 cycles.

The increased latency (allowing more effective utilization of competitively-shared microarchitectural resources to the logical processor ready to make forward progress) has a small positive performance impact of 1-2% on highly threaded applications. It is expected to have negligible impact on less threaded applications if forward progress is not blocked executing a fixed number of looped PAUSE instructions. There’s also a small power benefit in 2-core and 4-core systems.

As the PAUSE latency has been increased significantly, workloads that are sensitive to PAUSE latency will suffer some performance loss.


  • 上一代架构中(Grantly 平台 E 系列)PAUSE 的周期时长为 10 cycles,新一代的 Skylake 架构中则为 140 cycles。

  • 如果程序中使用固定次数的 PAUSE 循环来实现一段时间的延迟,以此阻塞程序执行,可能引发非预期的延迟。

  • 由于 PAUSE 周期增加,对于 PAUSE 敏感的应用会有一定的性能损失。


衡量程序执行性能的简化公式


ExecutionTime(T)=InstructionCount∗TimePerCycle∗CPI


即:程序执行时间 = 程序总指令数 x 每 CPU 时钟周期时间 x 每指令执行所需平均时钟周期数。


MySQL 内部自旋,就是通过固定次数的 PAUSE 循环实现。可知,PAUSE 指令周期的增加,那么执行自旋的时间也会增加,即程序执行的时间也会相对增加,对系统整体的吞吐量就会有影响。


显然,Intel 文档已说明不同平台、不同架构 CPU PAUSE 定义的周期是不一样的。


下面,我们通过一个测试用例来大致验证、对比一下新老架构 CPU 执行 PAUSE 的 cycles:


#include <stdio.h>#define TIMES 5
static inline unsigned long long rdtsc(void){ unsigned long low, high; asm volatile("rdtsc" : "=a" (low), "=d" (high) ); return ((low) | (high) << 32);}
void pause_test(){ int i = 0; for (i = 0; i < TIMES; i++) { asm( "pause\n"\ "pause\n"\ "pause\n"\ "pause\n"\ "pause\n"\ "pause\n"\ "pause\n"\ "pause\n"\ "pause\n"\ "pause\n"\ "pause\n"\ "pause\n"\ "pause\n"\ "pause\n"\ "pause\n"\ "pause\n"\ "pause\n"\ "pause\n"\ "pause\n"\ "pause\n" :: :); }}
unsigned long pause_cycle(){ unsigned long start, finish, elapsed; start = rdtsc(); pause_test(); finish = rdtsc(); elapsed = finish - start; printf("Pause的cycles约为:%ld\n", elapsed / 100); return 0;}
int main(){ pause_cycle(); return 0;}
复制代码


其运行结果统计如下:



  • 4110 和 5118 PAUSE 周期较大,均为 100 多,它们属于 Purley 第一代架构:Skylake。

  • 4210 和 5218 PAUSE 相比前一代有提升,是因为它们同属 Purley 第二代架构:Cascadelake,该代 CPU PAUSE 指令有优化。

3.2.3 Intel 提升 PAUSE 猜想

Intel 提高 PAUSE 指令周期的原因,推测可能是减少自旋锁冲突的概率,以及降低功耗;但反而导致 PAUSE 执行时间变长,降低了整体的吞吐量。


The increased latency (allowing more effective utilization of competitively-shared microarchitectural resources to the logical processor read to make forward progress) has a small positive performance impact of 1-2% on highly threaded applications. It is expected to have negligible impact on less threaded applications if forward progress is not blocked executing a fixed number of looped PAUSE instructions.

3.3 PAUSE 导致写瓶颈分析

接下来,我们深入分析一下 PAUSE 指令导致 MySQL 写瓶颈的原因。


首先,通过 MySQL 内部统计信息,查看一下 InnoDB 信号量监控数据:


SEMAPHORES----------OS WAIT ARRAY INFO: reservation count 153720--Thread 139868617205504 has waited at row0row.cc line 1075 for 0.00 seconds the semaphore:X-lock on RW-latch at 0x7f4298084250 created in file buf0buf.cc line 1425a writer (thread id 139869284108032) has reserved it in mode  SXnumber of readers 0, waiters flag 1, lock_word: 10000000Last time read locked in file not yet reserved line 0Last time write locked in file /mnt/workspace/percona-server-5.7-redhat-binary-rocks-new/label_exp/min-centos-7-x64/test/rpmbuild/BUILD/percona-server-5.7.26-29/percona-server-5.7.26-29/storage/innobase/buf/buf0flu.cc line 1216OS WAIT ARRAY INFO: signal count 441329RW-shared spins 0, rounds 1498677, OS waits 111991RW-excl spins 0, rounds 717200, OS waits 9012RW-sx spins 47596, rounds 366136, OS waits 4100Spin rounds per wait: 1498677.00 RW-shared, 717200.00 RW-excl, 7.69 RW-sx
复制代码


可见写操作并阻塞在:storage/innobase/buf/buf0flu.cc 第 1216 行调用上。


跟踪一下发生等待的源码:buf0flu.cc line 1216:


    if (flush_type == BUF_FLUSH_LIST        && is_uncompressed        && !rw_lock_sx_lock_nowait(rw_lock, BUF_IO_WRITE)) {    // 加锁前,判断锁冲突
if (!fsp_is_system_temporary(bpage->id.space())) { /* avoiding deadlock possibility involves doublewrite buffer, should flush it, because it might hold the another block->lock. */ buf_dblwr_flush_buffered_writes( buf_parallel_dblwr_partition(bpage, flush_type)); } else { buf_dblwr_sync_datafiles(); } rw_lock_sx_lock_gen(rw_lock, BUF_IO_WRITE); // 加sx锁 }... #define rw_lock_sx_lock_nowait(M, P) \ rw_lock_sx_lock_low((M), (P), __FILE__, __LINE__)...
rw_lock_sx_lock_func( // 加sx锁函数 /*=================*/ rw_lock_t* lock, /*!< in: pointer to rw-lock */ ulint pass, /*!< in: pass value; != 0, if the lock will be passed to another thread to unlock */ const char* file_name,/*!< in: file name where lock requested */ ulint line) /*!< in: line where requested */
{ ulint i = 0; sync_array_t* sync_arr; ulint spin_count = 0; uint64_t count_os_wait = 0; ulint spin_wait_count = 0;
ut_ad(rw_lock_validate(lock)); ut_ad(!rw_lock_own(lock, RW_LOCK_S));
lock_loop:
if (rw_lock_sx_lock_low(lock, pass, file_name, line)) {
if (count_os_wait > 0) { lock->count_os_wait += static_cast<uint32_t>(count_os_wait); rw_lock_stats.rw_sx_os_wait_count.add(count_os_wait); }
rw_lock_stats.rw_sx_spin_round_count.add(spin_count); rw_lock_stats.rw_sx_spin_wait_count.add(spin_wait_count);
/* Locking succeeded */ return;
} else {
++spin_wait_count;
/* Spin waiting for the lock_word to become free */ os_rmb; while (i < srv_n_spin_wait_rounds && lock->lock_word <= X_LOCK_HALF_DECR) {
if (srv_spin_wait_delay) { ut_delay(ut_rnd_interval( 0, srv_spin_wait_delay)); // 加锁失败,调用ut_delay }
i++; }
spin_count += i;
if (i >= srv_n_spin_wait_rounds) {
os_thread_yield();
} else {
goto lock_loop; }...ulong srv_n_spin_wait_rounds = 30;ulong srv_spin_wait_delay = 6;
复制代码


上述源码可知,MySQL 锁等待是通过调用 ut_delay 做空循环实现的。


InnoDB 层有三种锁:S(共享锁)、X(排他锁)和 SX(共享排他锁)。SX 与 SX、X 是互斥锁。加 SX 不会影响读,只会阻塞写。所以在大量写入操作时,会造成大量的锁等待,即大量的 PAUSE 指令。


分析到这里,我们总结一下影响吞吐量的两个因素:


  • 自旋的时长,在 MySQL5.7 以及之前版本的源码定位为:spin_wait_delay * 50。

  • Intel CPU PAUSE 的指令周期。


接下来,我们就从这两方面入手,评估优化空间以及效果。

4. 针对 PAUSE 指令和 spin 参数优化与探索

4.1 MySQL spin 参数优化

4.1.1 MySQL 5.7 spin 参数优化

我们可以基于现有 MySQL 版本、硬件等方面,来寻找优化点。


MySQL 针对 spin 控制这块有个参数可以调整,根据参数特点进行相关优化。


innodb_spin_wait_delay


innodb_spin_wait_delay 的单位,是 100MHZ 的奔腾处理器处理 1 毫秒的时间,默认 innodb_spin_wait_delay 配置成 6,表示最多在 100MHZ 的奔腾处理器上自旋 6 毫秒。


innodb_sync_spin_loops


当 innodb 线程获取 mutex 资源而得不到满足时,会最多进行 innodb_sync_spin_loops 次尝试获取 mutex 资源。


其中 innodb_spin_wait_delay 参数对 PAUSE 运行时长是有影响的。针对此参数,我们进行调优测试。



同样,针对上述参数优化,我们通过基准测试来对比性能和效果:



可以总结为:


  • innodb_spin_wait_delay 的调整对 TPS、QPS 一定影响,其值趋于小,则 MySQL 性能有提升。反之,下降。

  • innodb_spin_wait_delay 参数调整性能优化效果有限,性能提升的幅度还是无法满足线上业务需求。

4.2 MySQL 8.0 spin 新特性移植

4.2.1 spin_wait_pause_multiplier 移植

针对 Skylake CPU,PAUSE 造成的吞吐量下降,我们对 MySQL 5.7 spin 控制参数 innodb_spin_wait_delay 的调优并未取得明显效果。


于是,我们将目光投向了 MySQL 8.0 的新特性:MySQL 8.0 针对 PAUSE,源码中新增了 spin_wait_pause_multiplier 参数,来替换之前写死的循环次数。

4.2.2 spin_wait_pause_multiplier 实现

MySQL 8.0 源码中,之前循环 50 次的逻辑修改成了可以调整循环次数的参数:spin_wait_pause_multiplier。


ulint ut_delay(ulint delay) {  ulint i, j;  /* We don't expect overflow here, as ut::spin_wait_pause_multiplier is limited  to 100, and values of delay are not larger than @@innodb_spin_wait_delay  which is limited by 1 000. Anyway, in case an overflow happened, the program  would still work (as iterations is unsigned). */  const ulint iterations = delay * ut::spin_wait_pause_multiplier;  UT_LOW_PRIORITY_CPU();
j = 0;
for (i = 0; i < iterations; i++) { j += i; UT_RELAX_CPU(); }
UT_RESUME_PRIORITY_CPU();
return (j);}...namespace ut {ulong spin_wait_pause_multiplier = 50;}
复制代码

4.2.3 移植 spin_wait_pause_multiplier patch 优化

既然 MySQL 8.0 参数 spin_wait_pause_multiplier 可以控制 PAUSE 执行的时长,那么就可以减少该值,从而降低整体 PAUSE 影响。


了解 MySQL 8.0 相关代码后,我们将该 patch 移植到线上的稳定版本:


MySQ >select version();+------------------+| version()        |+------------------+| 5.7.26-29-mt-log |+------------------+1 row in set (0.00 sec)
MySQL>show global variables like '%spin%'; +-----------------------------------+-------+| Variable_name | Value |+-----------------------------------+-------+| innodb_spin_wait_delay | 6 || innodb_spin_wait_pause_multiplier | 5 || innodb_sync_spin_loops | 30 |+-----------------------------------+-------+3 rows in set (0.00 sec)
复制代码


由上述可知,Silver 4110 的 PAUSE cycles 是 E5-2620 v4 的 14 倍左右。基于此,将 innodb_spin_wait_pause_multiplier 值调整为默认值的 1/14,取稍大值:5。即将该参数由原默认的 50 调整为 5。


最后,还是通过二维折线图来对比该 patch 调优后的基准测试数据:



  • Silver 4110 移植 spin_wait_pause_multiplier patch,并调整优化后,4110(patch)性能有了较大的提升。

  • Silver 4110(patch) 相对调优 innodb_spin_wait_delay 性能上更优。

  • Silver 4110(patch)并发线程大于 64 的只写场景,性能略低于 E5-2620 V4 ,其他均优。

  • 按照真实的线上读写比例,4110(patch)可以将吞吐量恢复到原先的性能水平。

4.3 PAUSE 指令周期优化

上述章节中,我们测出 Cascadelake CPU PAUSE 周期下降了。在跟 Intel 技术专家确认后得知:从 Purley 的第二代产品 Cascadelake 开始,Intel 将 PAUSE 的指令周期降低到了 44。(估计 Intel 也发现了第一代增加 PAUSE 周期后的性能瓶颈问题。)


我们针对第二代 CPU 产品继续做基准测试,来看一下性能表现:



接着用 perf diff 来对比一下 4110 和 4210 在 ut_delay 上的开销:



可以看到 4210 比 4110 占比下降了 8%。


  • 由于 PAUSE 指令周期还是数倍于 E5 系列 CPU,4210 在高负载下,PAUSE 的开销对 MySQL 吞吐量还是有较大的影响。而在 128 并发线程以下,性能相比 4110 有了较大的提升。按理,可以满足线上业务需求(该测试结果跟移植 spin_wait_pause_multiplier patch 性能测试数据曲线一致)。

5. 总结

最后针对本篇内容,我们可以做个简单的总结:


Intel 在新平台 CPU 产品调大了 PAUSE 指令周期,在高并发 spinlock 竞争激烈场景下,可能会造成程序性能较大损耗(特别是执行固定 PAUSE 次数的程序)。


  1. 针对 Skylake 架构 CPU(比如:4110 等)PAUSE 指令周期较长引起性能问题的优化方法如下:


a. 将 MySQL 8.0 innodb_spin_wait_pause_multiplier patch 移植到线上稳定版本(或升级到 MySQL 8.0),通过降低 PAUSE 执行时长,来提升吞吐量。


n. 如果是 OS 为 CentOS 6,可以升级到 CentOS 7,CentOS 7 本身 spinlock 优化,对 MySQL 性能也有一定提升。


c. 最简单、直接的方法可以替换为 Cascadelake 架构 CPU。


  1. 针对 Cascadelake 架构 CPU,由于 Intel 本身在 PAUSE 周期已经优化,性能上已经做了修复。当然也可以采用上述优化方案,让性能提升一个台阶。


作者介绍


春林,2017 年加入美团,主要负责 MySQL 运维开发和优化工作。


本文转载自公众号美团技术团队(ID:meituantech)。


原文链接


https://mp.weixin.qq.com/s/dlKC13i9Z8wjDDiU2tig6Q


2020-04-23 10:001771

评论

发布
暂无评论
发现更多内容

前端线下面授培训机构的选择

小谷哥

上海前端培训学习的就业前景

小谷哥

启科量子解决方案实践:使用QuTrunk+AWS Deep Learning AMI(TensorFlow2)构建量子神经网络

启科量子开发者官方号

人工智能 量子计算

利用混沌工程提高微服务的弹性

NGINX开源社区

nginx 微服务架构 性能 企业号 2 月 PK 榜

干货分享 | 3个Zbrush实用减面工具分享

3DCAT实时渲染

3D渲染 3D模型

单体应用、SOA、微服务,优劣势都有哪些?

FinFish

微服务 微服务架构 前端开发 移动开发 小程序化

BIGO 如何做到夜间同时运行 2.4K 个工作流实例?

Apache DolphinScheduler

spark 工作流调度 Apache DolphinScheduler 离线计算

NFT铸造系统模式开发定制

开发微hkkf5566

前端技术培训学习哪个机构好?

小谷哥

前端报表如何实现无预览打印解决方案或静默打印

葡萄城技术团队

《流浪地球2》“数字生命”最后一秒拯救人类,现实中AI也正在“长出”灵魂

硬科技星球

新书上市 | 以过去预测未来,有趣的时间序列

图灵社区

机器学习 统计学 时间序列 时间序列预测

真正的低代码平台

陈飞

PaaS SaaS 低代码平台

Apache RocketMQ 入选 SegmentFault 年度中国技术品牌影响力企业榜单!

阿里巴巴云原生

阿里云 Apache RocketMQ

下一朵云,会是谁

ToB行业头条

UE干货| UE虚幻引擎调试神器—控件反射器

3DCAT实时渲染

游戏开发 虚幻引擎 ue 游戏开发引擎

新书上市 | 以过去预测未来,有趣的时间序列

图灵教育

机器学习 统计学 时间序列 时间序列预测

RocketMQ 监控告警:生产环境如何快速通过监控预警发现堆积、收发失败等问题?

阿里巴巴云原生

阿里云 RocketMQ 云原生

怎么正确使用 NPS ?用对了才事半功倍

鼎道智联

运营 用户体验 用户推荐

速剖架构(一)-- 流量的自然走向

Dinfan

架构设计

基于流量双发平台的高效回归方案

网易云信

反垃圾 业务集群

程序员必备的数据库知识 2:Join 算法

NineData

数据库 程序员 join SQL sever NineData

设计模式-工厂方法模式和抽象工厂模式

C++后台开发

数据结构 设计模式 后端开发 Linux服务器开发 C++开发

大数据培训学习怎么入门

小谷哥

干货分享 | UE游戏鼠标双击判定

3DCAT实时渲染

游戏开发 虚幻引擎 ue 游戏开发引擎

化繁为简|中信建投基于StarRocks构建统一查询服务平台

StarRocks

数据库 大数据 开源

Go1.20新版本正式发布,新特性值得一看

王中阳Go

Go golang 高效工作 学习方法

尚硅谷发布九章云台项目视频

小谷哥

浅谈 2022 前端工作流中全流程多层次的四款测试工具

Liam

前端 测试 前端开发 测试工具 测试开发

点对点传输现状,镭速高速点对点传输解决方案

镭速

巧用Maya轴心操作小技巧,工作事半功倍!

3DCAT实时渲染

Maya,渲染 Autodesk Maya

Intel PAUSE指令变化影响到MySQL的性能,该如何解决?_数据库_春林_InfoQ精选文章