golang源码阅读:VictoriaMetrics中协程优先级的处理方式

这篇博客主要分析了VictoriaMetrics如何处理协程优先级,特别是在数据写入(insert)和查询(select)操作中。它指出写入操作的优先级高于查询,并通过设置不同数量的计算协程来实现这一策略。计算协程数等于CPU核心数,用于insert操作,而查询协程数是核心数的两倍。当insert操作受阻时,会通过原子计数和条件变量通知select协程让出CPU资源,确保写入操作的顺利进行。
摘要由CSDN通过智能技术生成

Python微信订餐小程序课程视频

https://edu.csdn.net/course/detail/36074

Python实战量化交易理财系统

https://edu.csdn.net/course/detail/35475
在阅读VictoriaMetrics的源码的时候,读到了那么平平无奇的一段:

// AddRows adds the given mrs to s.
func (s *Storage) AddRows(mrs []MetricRow, precisionBits uint8) error {
	if len(mrs) == 0 {
		return nil
	}

	// Limit the number of concurrent goroutines that may add rows to the storage.
	// This should prevent from out of memory errors and CPU trashing when too many
	// goroutines call AddRows.
	select {
	case addRowsConcurrencyCh <- struct{}{}:
	default:
		// Sleep for a while until giving up
		atomic.AddUint64(&s.addRowsConcurrencyLimitReached, 1)
		t := timerpool.Get(addRowsTimeout)

		// Prioritize data ingestion over concurrent searches.
		storagepacelimiter.Search.Inc()

		select {
		case addRowsConcurrencyCh <- struct{}{}:
			timerpool.Put(t)
			storagepacelimiter.Search.Dec()
		case <-t.C:
			timerpool.Put(t)
			storagepacelimiter.Search.Dec()
			atomic.AddUint64(&s.addRowsConcurrencyLimitTimeout, 1)
			atomic.AddUint64(&s.addRowsConcurrencyDroppedRows, uint64(len(mrs)))
			return fmt.Errorf("cannot add %d rows to storage in %s, since it is overloaded with %d concurrent writers; add more CPUs or reduce load",
				len(mrs), addRowsTimeout, cap(addRowsConcurrencyCh))
		}
	}

仔细看了以后,真是不得了。这感觉就像——

1.背景

在vm-storage这个组件中,作为存储节点,它一边要负责数据的写入,一边要负责数据的查询。很明显,数据写入的工作很重要,而查询的优先级相比写入就要低一些。

遇到这种问题,我的第一反应就是:把写入的协程数设置得比查询的协程数多不就行了吗?想要多高的优先级就设置为多大的比例。

太天真了!

  1. 物理核是性能真正的限制。无论你有多少协程,理
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值