Open 0x46616c6b opened 2 years ago
There are two issues here that I'd like to address separately:
- Etherpad shouldn't crash if a DB query throws. This should be easy to fix.
Sigh, I jinxed myself by saying that. It's not easy to fix. IIUC, what's happening is the MySQL server is so busy trying to enumerate all pads that unrelated queries over other pool connections are timing out.
Thanks a lot for your constant work of improvement and support to help for our issues we have.
Will #5347 apply in the next release? We would like to test it and give a feedback.
Yes, it will be in the next release (1.9.0). Unfortunately, I think there's a low probability that PR will fix the issue for you. (It might, so it's still worth trying.)
Okay, we keep trying and still hope 🤞
Okay, we keep trying and still hope 🤞
hey i would like to know one thing....if we contribute here is etherpad going to pay us ...and if it then whats the criteria how many pull req
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
We tried another time to get deeper in this problem. As we are using MariaDB/MySQL for Storage with MyISAM engine we looked what ueberDB
would trigger in the database and did this:
MariaDB [etherpad]> SELECT COUNT(`key`) FROM store WHERE `key` LIKE 'pad:%' AND `key` NOT LIKE 'pad:%:%';
+--------------+
| COUNT(`key`) |
+--------------+
| 18924 |
+--------------+
1 row in set (51.514 sec)
After some improvements for our MariaDB instance we reduced the query time from ~90 seconds to ~53 seconds. But we were still not satisfied. So we noticed that we have ~18k Pads but 100.000.000 rows in MariaDB. So we stumble upon an old problem, that the sessionstorage still rapidly growths:
MariaDB [etherpad]> SELECT COUNT(*) FROM store WHERE `key` LIKE 'sessionstorage%';
+----------+
| COUNT(*) |
+----------+
| 38923592 |
+----------+
1 row in set (5 min 44.863 sec)
We cleaned around one year ago all entries starting with sessionstorage
from the database and after that year 40% of the database is used by this entries.
We will again clean the database from this entries and waiting for 1.9.0 release which hopefully fix the session creation. After we cleaned up the database I will bring new timings of our queries to compare.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Not stale.
Describe the bug
This bug report relates to #5005.
If we try to fetch the
getStats
API after Etherpad starts, the whole process get killed (see the additional context). In #5005 we sawError: Query inactivity timeout
. Now it isError: Request aborted
. Nevertheless the process should not be terminated when this happens.Our Etherpad instance runs around 20k pads with a MySQL storage backend.
To Reproduce Steps to reproduce the behavior:
Expected behavior
Etherpad should not crash if the HTTP Client closes the connection to the API Endpoint.
Server (please complete the following information):
node --version
): v14.18.2npm --version
): 6.14.15Additional context