-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ETS ** Too many db tables ** error #5
Comments
Hello! Thanks for the feedback. There are two main reasons that may cause the problem:
So there are several questions I would like to ask to get the situation more clear:
|
Closing due to no reply. |
@savonarola Hi, we just ran into the same issue. My max_connections is at 600 (while the ETS table limit should be around 1400 by default) and I had a health checker try and open (and close) a socket every 10 seconds.
After a few hours, of this though, any time the health checker opens a socket, we encounter this issue:
So it seems that the ETS table is not getting cleaned up properly when a Ranch socket is closed. |
Do note that we have no active connections to the instance, except for the health-check opening and closing the socket (so this is not a case of it being over-saturated with traffic). |
Hello! Trying to reproduce the issue. |
Reproduction tips: Repeatedly open and close a raw socket to the server,
(maybe leave a bit of delay for the garbage collector to kick in)
Decrease the limit of ETS tables too maybe, the default is 1400 so it will
take a while.. Set it to 100 or so
…On Thu, 6 Apr 2017 at 17:03, Аверьянов Илья ***@***.***> wrote:
Hello!
Trying to reproduce the issue.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<https://github.com/savonarola/smppex/issues/5#issuecomment-292099477>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABTy9o2o3vyWvRyCSh1rVhwwrczvbAOvks5rtJxigaJpZM4Kq2Hn>
.
|
With the probe we had, it took a few hours to reach the failure point, (1
socket every 10s, ~4h)
…On Thu, 6 Apr 2017 at 17:05, Blaž Hrastnik ***@***.***> wrote:
Reproduction tips: Repeatedly open and close a raw socket to the server,
(maybe leave a bit of delay for the garbage collector to kick in)
Decrease the limit of ETS tables too maybe, the default is 1400 so it will
take a while.. Set it to 100 or so
On Thu, 6 Apr 2017 at 17:03, Аверьянов Илья ***@***.***>
wrote:
Hello!
Trying to reproduce the issue.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<https://github.com/savonarola/smppex/issues/5#issuecomment-292099477>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABTy9o2o3vyWvRyCSh1rVhwwrczvbAOvks5rtJxigaJpZM4Kq2Hn>
.
|
Hello! I have reproduced the issue; the reason was that peer closing socket is not considered to be an abnormal case, so MC session stopped with I have added the necessary cleanup. |
@savonarola as always, thank you for the swift fix! 🍻 |
Hi man, I've recently run into this problem on my production environment:
It seems like something to do with the pdu_storage, is there any potential misconfiguration in the the SMPPEX code?
Thanks,
Long
The text was updated successfully, but these errors were encountered: