内存方面可能需要优化

[xczh]

我使用这里的geosite.dat和geoip.dat作为域名和IP过滤文件，上游转发器使用forward。开启pprof后运行三天，发现内存方面可能存在这些问题：

• 内存占用过多
• 内存频繁申请释放

具体现象如下：

1. 堆内存占用

Showing nodes accounting for 16921.37kB, 100% of 16921.37kB total
Showing top 10 nodes out of 45
      flat  flat%   sum%        cum   cum%
15182.50kB 89.72% 89.72% 15182.50kB 89.72%  github.com/IrineSistiana/mosdns/dispatcher/pkg/matcher/domain.(*DomainMatcher).add
  669.43kB  3.96% 93.68%   669.43kB  3.96%  github.com/IrineSistiana/mosdns/dispatcher/pkg/matcher/netlist.(*List).Grow
  557.26kB  3.29% 96.97%   557.26kB  3.29%  crypto/elliptic.initTable
  512.19kB  3.03%   100%   512.19kB  3.03%  runtime.malg
         0     0%   100%   557.26kB  3.29%  crypto/ecdsa.Verify
         0     0%   100%   557.26kB  3.29%  crypto/ecdsa.VerifyASN1
         0     0%   100%   557.26kB  3.29%  crypto/ecdsa.verify (inline)
         0     0%   100%   557.26kB  3.29%  crypto/ecdsa.verifyGeneric
         0     0%   100%   557.26kB  3.29%  crypto/elliptic.(*p256Point).p256BaseMult
         0     0%   100%   557.26kB  3.29%  crypto/elliptic.p256Curve.CombinedMult
(pprof) list add
Total: 16.52MB
ROUTINE ======================== github.com/IrineSistiana/mosdns/dispatcher/pkg/matcher/domain.(*DomainMatcher).add in github.com\IrineSistiana\mosdns\dispatcher\pkg\matcher\domain\matcher.go
   14.83MB    14.83MB (flat, cum) 89.72% of Total
         .          .     63:type KeywordMatcher struct {
         .          .     64:   kws map[string]interface{}
         .          .     65:}
         .          .     66:
         .          .     67:func NewKeywordMatcher() *KeywordMatcher {
   10.59MB    10.59MB     68:   return &KeywordMatcher{
         .          .     69:           kws: make(map[string]interface{}),
         .          .     70:   }
         .          .     71:}
         .          .     72:
         .          .     73:func (m *KeywordMatcher) Add(keyword string, v interface{}) error {
         .          .     74:   m.add(keyword, v)
    4.24MB     4.24MB     75:   return nil
         .          .     76:}
         .          .     77:
         .          .     78:func (m *KeywordMatcher) add(keyword string, v interface{}) {
         .          .     79:   o := m.kws[keyword]
         .          .     80:   if appendable, ok := o.(Appendable); ok {

目前我还没有时间细看实现，猜测是否将dat文件中所有的item都add进了KeywordMatcher？

2. 频繁内存分配释放

Showing nodes accounting for 628.64MB, 93.90% of 669.46MB total
Dropped 154 nodes (cum <= 3.35MB)
Showing top 10 nodes out of 107
      flat  flat%   sum%        cum   cum%
  425.56MB 63.57% 63.57%   425.56MB 63.57%  math/big.nat.make (inline)
   67.01MB 10.01% 73.58%    67.01MB 10.01%  reflect.New
   40.96MB  6.12% 79.69%    40.96MB  6.12%  github.com/miekg/dns.(*Conn).ReadMsgHeader
   26.66MB  3.98% 83.68%    26.66MB  3.98%  github.com/IrineSistiana/mosdns/dispatcher/pkg/matcher/domain.(*DomainMatcher).add
   24.77MB  3.70% 87.38%    24.77MB  3.70%  google.golang.org/protobuf/internal/impl.pointer.AppendPointerSlice
   13.37MB  2.00% 89.37%    13.37MB  2.00%  os.ReadFile
    8.81MB  1.32% 90.69%    14.27MB  2.13%  compress/flate.NewWriter
    8.50MB  1.27% 91.96%   255.54MB 38.17%  crypto/elliptic.(*CurveParams).doubleJacobian
    6.50MB  0.97% 92.93%     6.50MB  0.97%  google.golang.org/protobuf/encoding/protowire.ConsumeString
    6.50MB  0.97% 93.90%     6.50MB  0.97%  google.golang.org/protobuf/internal/impl.consumeBytesNoZero

猜测是forward与上游dot通信时，没有对TLS会话复用导致的频繁握手开销，还需要进一步确认原因。

gctrace这边的情况显示还行，由于goal是当前占用量的两倍，一般不会达到这个值，基本维持在2分钟触发一次的默认状态。

[xczh]

补充，目前加载的matcher情况：

query_matcher/query_matcher.go:94       domain matcher loaded   {"length": 22435}
query_matcher/query_matcher.go:94       domain matcher loaded   {"length": 25460}
query_matcher/query_matcher.go:94       domain matcher loaded   {"length": 71467}
query_matcher/query_matcher.go:94       domain matcher loaded   {"length": 13}
query_matcher/query_matcher.go:94       domain matcher loaded   {"length": 49218}
response_matcher/response_matcher.go:92 ip matcher loaded       {"length": 8991}
coremain/run.go:42      all plugins are successfully loaded

[IrineSistiana]

猜测是否将dat文件中所有的item都add进了KeywordMatcher

应该不是。我猜是因为你本地的mosdns源码跟pprof采样的mosdns版本不一样。导致显示岔行了。

内存占用方面，目前匹配器是用了大量的 map。其他算法本人能力有限目前还搞不出来。欢迎 PR。

TLS会话复用导致的频繁握手开销。

我看了一下我的 pprof。

确实你这比例有点高了。有可能是上游支不支持连接复用或者时间很短？

[xczh]

应该不是。我猜是因为你本地的mosdns源码跟pprof采样的mosdns版本不一样。导致显示岔行了。

经确认，确实是这个问题，跑的是release版，本地源码是最新的master，感谢！

内存占用方面，目前匹配器是用了大量的 map。其他算法本人能力有限目前还搞不出来。欢迎 PR。

如果现在的实现没有将所有的domain 都加载到map里去的话，个人认为目前也不太需要改进。 runtime的map实现对于通用环境已经非常高效，之后看看有没有其他（主要是嵌入式）用户的反馈吧，如果针对10w+大量域名的情况确实需要改进，可以考虑使用前缀树等结构优化，需要评估投入-产出比。

确实你这比例有点高了。有可能是上游支不支持连接复用或者时间很短？

上游部分的配置文件：

  - tag: forward_non_domestic
    type: forward
    args:
      upstream:
        - addr: 'tls://8.8.4.4'
          trusted: true
        - addr: 'tls://1.0.0.1'
          trusted: true
        - addr: 'tls://8.8.8.8'
          trusted: true
        - addr: 'tls://1.1.1.1'
          trusted: true
      timeout: 10
      deduplicate: true

这几个都应该支持TLS连接复用的。查看了一下dnsproxy连接复用的代码
没有看到设置TLSPool中连接的有效期，即连接空闲多长时间会自动关闭。可能需要一个办法来调试dnsproxy包里的变量和日志。

不管怎么样，感谢作者@IrineSistiana 贡献了这么优秀的软件给大家使用 :)

[IrineSistiana]

没有看到设置TLSPool中连接的有效期，即连接空闲多长时间会自动关闭。可能需要一个办法来调试dnsproxy包里的变量和日志。

建议试试 fast_forward 插件。dnsproxy 的连接池实现，连接的利用率不高。

[xczh]

感谢，已更改为fast_forward，再测试几天看看情况，dnsproxy那边的实现确实太臃肿了，直觉上TLSPool应该有BUG