Insufficient packet capture capability

[Narcissus666]

I recorded 10G of data on the physical interface, but only about 5G were actually captured.

[fs714]

I haven't test 10G physical interface yet since I don't have such env now. Can you do some analysis by pprof to find where is the bottleneck?

[Narcissus666]

go tool pprof http://localhost:6060/debug/pprof/profile?seconds=60

Fetching profile over HTTP from http://localhost:6060/debug/pprof/profile?seconds=60 Saved profile in /root/pprof/pprof.goiftop.samples.cpu.024.pb.gz File: goiftop Build ID: 2a4918cfc8da65e0a956499106165975be3452fc Type: cpu Time: Feb 29, 2024 at 3:31pm (CST) Duration: 60.10s, Total samples = 70.30s (116.97%) Entering interactive mode (type "help" for commands, "o" for options) (pprof) top50 Showing nodes accounting for 61.25s, 87.13% of 70.30s total Dropped 251 nodes (cum <= 0.35s) Showing top 50 nodes out of 83 flat flat% sum% cum cum% 18.16s 25.83% 25.83% 21.31s 30.31% runtime.cgocall 6.13s 8.72% 34.55% 12.19s 17.34% runtime.mallocgc 2.69s 3.83% 38.38% 3.39s 4.82% runtime.scanblock 2.21s 3.14% 41.52% 2.21s 3.14% runtime.nextFreeFast (inline) 2.14s 3.04% 44.57% 2.14s 3.04% aeshashbody 1.87s 2.66% 47.23% 37.96s 54.00% github.com/fs714/goiftop/engine.(Capture).DecodeAndAccount 1.79s 2.55% 49.77% 6.60s 9.39% runtime.mapaccess2 1.48s 2.11% 51.88% 1.48s 2.11% net.ubtoa (inline) 1.25s 1.78% 53.66% 1.49s 2.12% runtime.mapaccess2_fast64 1.14s 1.62% 55.28% 4.59s 6.53% fmt.(pp).doPrintf 1.13s 1.61% 56.88% 1.13s 1.61% runtime.memmove 0.99s 1.41% 58.29% 1.01s 1.44% github.com/google/gopacket/layers.(Ethernet).DecodeFromBytes 0.94s 1.34% 59.63% 1.98s 2.82% runtime.scanobject 0.93s 1.32% 60.95% 2.91s 4.14% fmt.(pp).printArg 0.90s 1.28% 62.23% 0.90s 1.28% sync.(Mutex).Unlock (inline) 0.87s 1.24% 63.47% 0.95s 1.35% github.com/google/gopacket/layers.(IPv4).DecodeFromBytes 0.86s 1.22% 64.69% 25.59s 36.40% github.com/google/gopacket/pcap.(Handle).ZeroCopyReadPacketData 0.83s 1.18% 65.87% 5.18s 7.37% github.com/fs714/goiftop/decoder.(LayerDecoder).Decoder 0.80s 1.14% 67.01% 0.83s 1.18% runtime.casgstatus 0.78s 1.11% 68.12% 1.11s 1.58% runtime.findObject 0.76s 1.08% 69.20% 1.45s 2.06% runtime.exitsyscallfast 0.75s 1.07% 70.27% 1.39s 1.98% fmt.(buffer).writeString (inline) 0.74s 1.05% 71.32% 0.74s 1.05% memeqbody 0.73s 1.04% 72.36% 6.65s 9.46% runtime.slicebytetostring 0.66s 0.94% 73.30% 1.01s 1.44% runtime.heapBitsSetType 0.65s 0.92% 74.22% 4.37s 6.22% github.com/fs714/goiftop/accounting.(FlowCollection).UpdateL3Inbound 0.59s 0.84% 75.06% 6.66s 9.47% net.IP.String 0.52s 0.74% 75.80% 2.76s 3.93% runtime.exitsyscall 0.52s 0.74% 76.54% 0.53s 0.75% runtime.wirep 0.47s 0.67% 77.21% 3.62s 5.15% sync.(Map).Load 0.46s 0.65% 77.87% 0.91s 1.29% sync.(Pool).Get 0.45s 0.64% 78.51% 1.59s 2.26% fmt.(fmt).fmtS 0.45s 0.64% 79.15% 0.45s 0.64% runtime.releasem (inline) 0.41s 0.58% 79.73% 9.32s 13.26% fmt.Sprintf 0.40s 0.57% 80.30% 0.40s 0.57% runtime.acquirem (inline) 0.38s 0.54% 80.84% 24.18s 34.40% github.com/google/gopacket/pcap.(Handle).getNextBufPtrLocked 0.38s 0.54% 81.38% 0.38s 0.54% runtime.add (inline) 0.37s 0.53% 81.91% 1.86s 2.65% github.com/fs714/goiftop/decoder.(LayerDecoder).GetDecodingLayerByType (inline) 0.35s 0.5% 82.40% 0.42s 0.6% runtime.cgoCheckPointer 0.35s 0.5% 82.90% 5.82s 8.28% runtime.convTstring 0.35s 0.5% 83.40% 0.69s 0.98% sync.(Pool).pin 0.34s 0.48% 83.88% 1.93s 2.75% fmt.(pp).fmtString 0.33s 0.47% 84.35% 0.63s 0.9% sync.(Pool).Put 0.31s 0.44% 84.79% 0.96s 1.37% fmt.(pp).free 0.30s 0.43% 85.22% 0.36s 0.51% runtime.heapBitsForAddr (inline) 0.29s 0.41% 85.63% 1.27s 1.81% fmt.newPrinter 0.29s 0.41% 86.05% 0.77s 1.10% type..eq.github.com/fs714/goiftop/accounting.FlowFingerprint 0.27s 0.38% 86.43% 1.13s 1.61% fmt.(fmt).padString 0.25s 0.36% 86.79% 15.39s 21.89% github.com/fs714/goiftop/engine.BuildTrafficTypeDirKey (inline) 0.24s 0.34% 87.13% 19.26s 27.40% github.com/google/gopacket/pcap.(*Handle).pcapNextPacketEx.func1 (pprof)

I think there are certain performance bottlenecks in DecodeAndAccount.

[Narcissus666]

Thank you for your reply. I have conducted the above analysis. @fs714