Sorry, 【write queue is full】this problem is really bothering me.

[liusuyi2021]

Which version are you using?

v1.0.3

Which operating system are you using?

• Linux amd64 standard
• Linux amd64 Docker
• Linux arm64 standard
• Linux arm64 Docker
• Linux arm7 standard
• Linux arm7 Docker
• Linux arm6 standard
• Linux arm6 Docker
• Windows amd64 standard
• Windows amd64 Docker (WSL backend)
• macOS amd64 standard
• macOS amd64 Docker
• Other (please describe)

Describe the issue

Description

Describe how to replicate the issue

When I pull 81 channels of video, I can only pull 66 channels. When [write queue is full] appears, 15 channels are automatically closed, and the rest 66 channels are also too laggy. However, the CPU memory usage is not high, and the uplink bandwidth cannot exceed 100Mbps. What is the reason why [write queue is full] appears, and the single core performance? Not multithreaded?

Did you attach the server logs?

no

Did you attach a network dump?

no

[aler9]

Hello, the problems you are encountering depends on the fact that you've reached the capability of your network card, which is 100 Mbps. You have to switch to a gigabit-capable network card (and LAN) or decrease bitrate or number of streams.

[liusuyi2021]

I initially suspected that the bandwidth of the network card was insufficient, but after checking, the network card was fine. The bandwidth of the 1GB network card was increased. In order to increase the bandwidth, I conducted network card aggregation in the Windows 2016 system, and now it is 2GB bandwidth.

I tested using two separate computers, and of course, I could play more at a 2Mbps bit rate, but they also didn't occupy more than 300Mbps of bandwidth

I ensure that my bandwidth can reach 900M, I really don't understand why your program cannot break through the uplink bandwidth

In order to eliminate network issues, I directly pull streams on the server where MediaMTX is located, but this issue still occurs

[aler9]

If you see the message "write queue is full" it means that a reader can't consume messages with enough speed. It's surely a network bottleneck.

Regarding the switch from UDP to TCP, it worked because TCP has a couple of features to mitigate network congestions, including packet acknowledge and packet retransmission. This also means that your network is congested.

[liusuyi2021]

In fact, as you can see, my CPU and memory usage are very low. I have remade the Windows Server 2016 system separately for this purpose, and the system does not run any other programs. I am also worried that other programs are taking up the network, but only mediamtx is running on this server

[aler9]

If CPU and RAM are low, it means that any bottleneck is in the network and not in the application indeed.

Other than increasing writeQueueSize in the application in order to better consume the available throughout, you can analyze what's going on by using a network analyzer like Wireshark and by reviewing all network components between the server and the clients.

[liusuyi2021]

If there are network issues, what is your opinion on using two servers to transfer large files with a bandwidth of up to 1Gbps?

[liusuyi2021]

Thank you very much. After rebuilding the local area network environment, it was indeed discovered that there was a problem with the network, with insufficient performance of the WiFi router. Although the interfaces between the server and the client showed gigabit networks, the actual network was blocked. Thank you again.