Hallo,
I keep get this error log on /var/log/mysql/error.log
[Warning] Aborted connection 30500 to db: ‘db’ user: ‘dbuser’ host: ‘hostname’ (Got an error reading communication packets)
This Is happening on my production server
This causes ERPnext to be very slow or even inaccessible.
This is my /etc/mysql/mariadb.conf.d/50-server.cnf
If the max_allowed_packet was increased to deal with the error, and has not helped, then increasing wait_timeout could be tried.
Did the error start showing up after a change to the configuration or is this happening to a new installation? It may help to show the operating environment.
Review the installation instructions that were followed, that they are current, all steps were completed and the system requirements were met. Does the operating platform have adequate resources available?
Hi @Gembira_IT_Tech
Try reinstalling MySQL maybe solve the problem
sudo apt install mariadb-server mariadb-client
sudo mysql_secure_installation
"""
Enter current password for root: (Enter your SSH root user password)
Switch to unix_socket authentication [Y/n]: Y
Change the root password? [Y/n]: Y
It will ask you to set new MySQL root password at this step. This can be different from the SSH root user password.
Remove anonymous users? [Y/n] Y
Disallow root login remotely? [Y/n]: N
This is set as N because we might want to access the database from a remote server for using business analytics software like Metabase / PowerBI / Tableau, etc.
Remove test database and access to it? [Y/n]: Y
Reload privilege tables now? [Y/n]: Y
"""
As far as I remember, I once tried running the show processlist command when ERPnext was very slow.
there are lots of queries like this:
select *, timestamp(posting_date, posting_time) as “timestamp”
from tabStock Ledger Entry
where item_code = ‘0102010010009’
and warehouse = ‘Open End Blow Room Floor - IHL’
and is_cancelled = 0
and (
posting_date < ‘2023-12-31’ or
(
posting_date = ‘2023-12-31’ and
time_format(posting_time, ‘%H:%i:%s’) < time_format(‘20:41:23.753190’, ‘%H:%i:%s’)
)
)
order by timestamp(posting_date, posting_time) desc, creation desc
limit 1
ps: this is not the actual query data, but the model is exactly the same as what happens on my server
The number of background workers set is proportional to the number of cpu cores you have active from what i understand. However, this can negatively impact multiple background workers are working simultaneously but not enough RAM to handle the load… this is where i believe mariaDB suffers. So you have two options here:
1: Reduce the number of workers to maybe 4 or 5 to limit the number of concurrent tasks being run.
2: Increase your RAM to compensate for the workload mariaDB is forced to handle synchroneously.
These are suggested actions so they may not ultimately solve the problem. But reducing the workload by reducing the amount of active workers might help, although in a high volume production environment, this also has some negative impact so you may want to opt for increasing RAM, or both.
