High Recv-Q in netstat

Hi,

What could be the reason for non-zero value for Recv-Q in netstat?
It rises to thousands for over 500 vehicles which caused the traccar processed few messages at the same time.

Thank you.

Maybe you don't have enough resources to process all the data in time. Or database is too slow. Can be something else.

The current setup is as follows,

Traccar Server VM:

• Azure VM Standard B4ms (4 vcpus, 16 GiB memory)
• Linux

Traccar DB:

• Azure Database for MySQL General Purpose (2 vCore(s), 667 GB, 2000 IOPS)

I have noticed very high (thousands) Recv-Q in netstat when running 500 devices.

Firstly, I thought it is the DB, then I try to increase IOPS, but Recv-Q does not decrease.
CPU and memory usage of VM are also fine.

To run 5000 devices, sending 5000 messages per second in total. Is this setup applicable?

Thank you.

That's a very large volume of data. Are you not using a local database?

Thought having a dedicated server for database is faster. Thus, dedicated server is used.

Is having local database, sharing resources with traccar will be better in terms of performance?

When you need to make 10000 database updates per second, adding a network delay does not make it faster.

Tried to use a local database and also did this

https://www.traccar.org/mysql-optimization/

Recv-Q decreased, but hit thousands again for 1000 devices.

Is there a limit for innodb_log_file_size?

Thank you.

Have you tried increasing database connection pool?

Is there a limit for innodb_log_file_size?

Not sure about this.

Are you referring to database.maxPoolSize in traccar.xml?

Yes.

Will calling Traccar API such as

1. trips - /api/reports/trips
2. events - /api/reports/events
   slow down Traccar server while hundreds of devices are sending messages to it?

I have noticed the Traccar logs are stalled, when multiple trips API are called.

Thank you.

Why would you call multiple trips at the same time? Sounds like you're misusing APIs.

Cause we are calling it for each device that are running to verify if the trips are processed.

If this API is throttling the normal process, would you suggest to directly query the database?

There are no trips in the database.