when there are two many pendding transactions,the mined block package transactions become very slow

[liuzhijun23]

I build my private blockchain with PoA，there are two nodes,one miner and one normal nodes.I set the paramete --txpool.globalslots 40860. I use a script to send transactions in a loop.The block can package 700~800 transactions at the beginning,but after some minutes，the blockchain became blocking,I use txpool.status in the console,the result is:

txpool.status
{
pending: 43753,
queued: 0
}
eth.getBlock(eth.blockNumber).transactions.length
8
why the block package so less transactions when the pedding is overflow?who can help me to explain this?

[liuzhijun23]

I place a log in the MainLoop located in the work.go as follow：

func (w *worker) mainLoop() {
.........
case ev := <-w.txsCh:
			log.Info("lzj-log get one tx")
			// Apply transactions to the pending state if we're not mining.
			//
			// Note all transactions received may not be continuous with transactions
			// already included in the current mining block. These transactions will
			// be automatically eliminated.
			if !w.isRunning() && w.current != nil {
				w.mu.RLock()
				coinbase := w.coinbase
				w.mu.RUnlock()

				txs := make(map[common.Address]types.Transactions)
				for _, tx := range ev.Txs {
					acc, _ := types.Sender(w.current.signer, tx)
					txs[acc] = append(txs[acc], tx)
				}
				txset := types.NewTransactionsByPriceAndNonce(w.current.signer, txs)
				w.commitTransactions(txset, coinbase, nil)
				w.updateSnapshot()
			} else {
				// If we're mining, but nothing is being processed, wake on new transactions
				if w.config.Clique != nil && w.config.Clique.Period == 0 {
					w.commitNewWork(nil, false, time.Now().Unix())
				}
			}
			atomic.AddInt32(&w.newTxs, int32(len(ev.Txs)))

		// System stopped
		case <-w.exitCh:
			return
}

when the pendding is blocked, I find the console print log for a deadloop as follows:

INFO [10-29|18:22:28.252] lzj-log get one tx 
INFO [10-29|18:22:28.288] lzj-log get one tx 
INFO [10-29|18:22:28.322] lzj-log get one tx 
INFO [10-29|18:22:28.357] lzj-log get one tx 
INFO [10-29|18:22:28.393] lzj-log get one tx 
INFO [10-29|18:22:28.428] lzj-log get one tx 
INFO [10-29|18:22:28.462] lzj-log get one tx 
INFO [10-29|18:22:28.496] lzj-log get one tx 
INFO [10-29|18:22:28.530] lzj-log get one tx 
INFO [10-29|18:22:28.564] lzj-log get one tx 
INFO [10-29|18:22:28.598] lzj-log get one tx 
INFO [10-29|18:22:28.632] lzj-log get one tx 
INFO [10-29|18:22:28.667] lzj-log get one tx 
INFO [10-29|18:22:28.702] lzj-log get one tx 
INFO [10-29|18:22:28.737] lzj-log get one tx 
INFO [10-29|18:22:28.771] lzj-log get one tx 
INFO [10-29|18:22:28.806] lzj-log get one tx 
INFO [10-29|18:22:28.840] lzj-log get one tx 
INFO [10-29|18:22:28.875] lzj-log get one tx 
INFO [10-29|18:22:28.910] lzj-log get one tx 
INFO [10-29|18:22:28.944] lzj-log get one tx 
INFO [10-29|18:22:28.978] lzj-log get one tx 
INFO [10-29|18:22:29.012] lzj-log get one tx 
INFO [10-29|18:22:29.297] lzj-log get one tx 
INFO [10-29|18:22:29.350] lzj-log get one tx 
INFO [10-29|18:22:29.386] lzj-log get one tx 
INFO [10-29|18:22:29.421] lzj-log get one tx 
INFO [10-29|18:22:29.456] lzj-log get one tx 
INFO [10-29|18:22:29.491] lzj-log get one tx 
INFO [10-29|18:22:29.526] lzj-log get one tx 
INFO [10-29|18:22:29.562] lzj-log get one tx 
INFO [10-29|18:22:29.597] lzj-log get one tx 
INFO [10-29|18:22:29.631] lzj-log get one tx 
INFO [10-29|18:22:29.666] lzj-log get one tx 
INFO [10-29|18:22:29.700] lzj-log get one tx 
INFO [10-29|18:22:29.738] lzj-log get one tx 
INFO [10-29|18:22:29.773] lzj-log get one tx 
INFO [10-29|18:22:29.809] lzj-log get one tx 
INFO [10-29|18:22:29.843] lzj-log get one tx 
INFO [10-29|18:22:29.878] lzj-log get one tx 
INFO [10-29|18:22:29.932] lzj-log get one tx 
INFO [10-29|18:22:29.995] lzj-log get one tx 
INFO [10-29|18:22:30.057] lzj-log get one tx 
INFO [10-29|18:22:30.122] lzj-log get one tx 
INFO [10-29|18:22:30.182] lzj-log get one tx 
INFO [10-29|18:22:30.242] lzj-log get one tx 
INFO [10-29|18:22:30.286] lzj-log get one tx 
INFO [10-29|18:22:30.322] lzj-log get one tx 
INFO [10-29|18:22:30.437] lzj-log get one tx 
INFO [10-29|18:22:30.639] lzj-log get one tx 
INFO [10-29|18:22:30.686] lzj-log get one tx 
INFO [10-29|18:22:30.721] lzj-log get one tx 
INFO [10-29|18:22:30.757] lzj-log get one tx 
INFO [10-29|18:22:30.792] lzj-log get one tx 
INFO [10-29|18:22:30.827] lzj-log get one tx 
INFO [10-29|18:22:30.862] lzj-log get one tx 
INFO [10-29|18:22:30.897] lzj-log get one tx 
INFO [10-29|18:22:30.932] lzj-log get one tx 
INFO [10-29|18:22:30.966] lzj-log get one tx 
INFO [10-29|18:22:31.004] lzj-log get one tx 
INFO [10-29|18:22:31.041] lzj-log get one tx 
INFO [10-29|18:22:31.078] lzj-log get one tx 

It seems that something wrong has happend. Why the geth enter the dead loop in the chan select ：
case ev := <-w.txsCh:
It is very strange.

[holiman]

This should be fixed by #19734 , and also the upcoming txpool rewrite : #19705