Skip to content
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

Classic server periodically raise "Global mapping memory overflow" and need to be restarted to accept new connections [CORE5517] #5786

Closed
firebird-automations opened this issue Apr 10, 2017 · 15 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: @kattunga

Attachments:
5517.patch

I have a server in production.

Firebird Classical server
Ubuntu 16.04 64 bits
4 cores
32gb ram

It is serving 30 databases with 2~5 connections each one.
Every 4 to 5 days new client connections raise the error "Global mapping memory overflow" and the server needs to be completely rebooted to continue working.

The problem started when we switch from SupersServer to Classical Server.

The only place where I found the text error in source code is in /src/jrd/mapping.cpp

if (process >= sMem->processes)
{
sMem->processes++;
if (((U_IPTR) &sMem->process[sMem->processes]) - ((U_IPTR) sMem) > DEFAULT_SIZE)
{
sMem->processes--;
(Arg::Gds(isc_random) << "Global mapping memory overflow").raise();
}
}

Which could be the problem?

Does any firebird.conf parameter affect this issue?

Regards
Christian

Commits: 92d37c8 cc16459

====== Test Details ======

Need any suggestion about possible test implementation for this ticket.

@firebird-automations
Copy link
Collaborator Author

Modified by: @AlexPeshkoff

assignee: Alexander Peshkov [ alexpeshkoff ]

@firebird-automations
Copy link
Collaborator Author

Commented by: Sean Leyne (seanleyne)

This is really a support question, please post this to the Firebird Support mailing list.

@firebird-automations
Copy link
Collaborator Author

Commented by: @kattunga

Hi Sean,

I understand that my last question sound as a support question but I only asked it to do more tests and provide more information about this issue.
We use classical server since first Firebird version and we never saw this issue.

Checking the code I also not found parameters directly related with the conditional that raise the exception.
DEFAULT_SIZE is a hard-coded constant, so at first look it sound as a kind of leak.
it seems that sMem->processes is constantly incremented and never decremented.

@firebird-automations
Copy link
Collaborator Author

Commented by: @AlexPeshkoff

Christian, can you try with a 5517.patch attached?

@firebird-automations
Copy link
Collaborator Author

Modified by: @AlexPeshkoff

Attachment: 5517.patch [ 13090 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @kattunga

Yes, I do it right now.

The server is under heavy load, so I need to replace Firebird very fast.
It's safe to only replace the binaries (/firebird/bin) with the compiled ones, instead of uninstall and install?
if yes, which binaries should I replace all "/bin" or only "/bin/firebird" executable?

@firebird-automations
Copy link
Collaborator Author

Commented by: @AlexPeshkoff

It's enough to replace plugins/libEngine12.so (provided you use same gcc version).
If gcc version is changed (or you use currently firebird compiled at some other place) - better replace all binaries.
You need not stop all firebird processes to do it - just stop xinetd, replace file and start xinetd again.
It does not mean that such trick can be done in any case - only for _this_ change it's OK.

@firebird-automations
Copy link
Collaborator Author

Commented by: @kattunga

Thank you.
I putted it on production, I need to test it at least one week to see if the patch works.

@firebird-automations
Copy link
Collaborator Author

Commented by: @kattunga

It's running since 11/Apr with no issues.
if no issue apears next week I think we can considered it fixed.

@firebird-automations
Copy link
Collaborator Author

Commented by: @kattunga

Hi Alexandre,

This seems to be fixed, are you going to include patch in next release?

@firebird-automations
Copy link
Collaborator Author

Modified by: @AlexPeshkoff

summary: Classical server periodically raise "Global mapping memory overflow" and need to be restarted to accept new connections => Classic server periodically raise "Global mapping memory overflow" and need to be restarted to accept new connections

@firebird-automations
Copy link
Collaborator Author

Modified by: @AlexPeshkoff

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

Fix Version: 4.0 Alpha 1 [ 10731 ]

Fix Version: 3.0.3 [ 10810 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @AlexPeshkoff

Version: 3.0.1 [ 10730 ]

Version: 3.0.0 [ 10740 ]

Version: 4.0 Initial [ 10621 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

status: Resolved [ 5 ] => Resolved [ 5 ]

QA Status: No test => Deferred

Test Details: Need any suggestion about possible test implementation for this ticket.

Test Specifics: [Architecture (SS/CS) specific, Platform (Windows/Linux) specific]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

status: Resolved [ 5 ] => Resolved [ 5 ]

QA Status: Deferred => Not enough information

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment