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

True SMP support for SuperServer [CORE775] #1157

Closed
firebird-automations opened this issue Sep 17, 2003 · 14 comments
Closed

True SMP support for SuperServer [CORE775] #1157

firebird-automations opened this issue Sep 17, 2003 · 14 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: @pcisar

Is duplicated by CORE3044

Votes: 46

SFID: 807899#⁠
Submitted By: pcisar

Old news -- FB SS doesn't support SMP very well.

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Fix Version: 3.0 [ 10048 ]

assignee: Dmitry Yemanov [ dimitr ]

SF_ID: 807899 =>

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

assignee: Dmitry Yemanov [ dimitr ] =>

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

assignee: Dmitry Yemanov [ dimitr ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

Workflow: jira [ 10799 ] => Firebird [ 15222 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: Lewis Mettler (lmettler)

I have been using FB 1.5.5 on three quad core machines (4gb RAM each) for some time. There are a total of 6 FB data bases with at least one of them on each system. I assume multiple cores are not being used by the SS FB server but I have had only one problem in operation. Sometimes with the dbs of some size the server goes into a cpu loop trying to add additional connections. During this loop work on the db remains pending. This may or may not be related to the multiple cores. Empty dbs seem to never present this problem. And strangely enough, if I initiate a data base backup (via IBConsole) before requesting the connection from the application it almost always succeeds. This application runs about 48 hours on all three systems. It may make a good test application once there is code to be tested for SMP work. The application generates some 60-70 million records during the run on those 6 dbs coming from roughly 9 instances of the application. Please contact me at mailto:lmettler_business@lamlaw.com if this kind of application would be useful for testing purposes.

@firebird-automations
Copy link
Collaborator Author

Commented by: Fidel Viegas (araujofh)

Hi Lewis,

If you have a quad core machine, why not use FB Classic?

@firebird-automations
Copy link
Collaborator Author

Commented by: Lewis Mettler (lmettler)

Good question.

I did have some trouble trying to install FB Classic on my systems running Xandros. I believe Classic requires some services that are not installed by default or perhaps not enabled. So rather than work that problem I just went with the SS. I was more familiar with installing SS coming from single core systems.

The point being that even in its current form the SS servers do work on SMP machines. I mentioned above the processing loop that sometimes occurs during the establishment of additional connections. But, I have worked around that problem. Doing a db backup and restore always seems to solve that problem. So it is possible that the the SS server on SMP puts the db in same strange configuration overtime. I am fairly certain that no data is lost however. And sometimes the loop just clears. The application duplicates all calculations up to three times using different client systems and then does an extensive comparison to verify the calculated/stored/retreived results.

Even the SS server does use multiple cores during backup and restore operations. Perhaps the server itself does not but a backup/restore is IO heavy and the cpu utilization pretty much doubles during even a single backup/restore operation. (enough for two full cores) Multiple backups can almost use all four cores to their capacity.

But, I suppose the real reason I have not used the Classic is because these are production machines. And if it is not completely broken I tend not to fix it. Besides this application will make an excellent test application once SS 3.0 comes out.

I do believe the bottleneck in the application occurs within the FB server however. I have plenty of hardware and connect them via a dedicated 1GB lan. It is not IO bound. And not cpu bound. And each machine has 4gb memory. It is possible that the lan is the bottleneck but I do not think so. And users are not involved.

The interesting aspect of this application is that it appears to be a db bottleneck and it is possible that the Classic server might be a better choice. But, currently ongoing R&D on the application itself is taking precendence over work on installing the Classic version and comparing performance of those two. Plus the SS server with SMB consideration is the anticipated direction of work on Firebird. And this application may make an excellent test application as that development completes.

If getting higher performance was the only objective I could even use MySQL for some of the tables. That would eliminate any restrictions that might otherwise exist within any one server.

Of course if you have a big fat application you want to see the IO, cpu and lan all top out at the same time. But the reality is that something bottles it up before you get there. And it is possible that the Classic server might use more cpu time but not necessarily increase throughput.

Anyone who has good comparison data on the throughput between SS and Classic is more than welcome to chime in. Interactive response is not the issue. However, throughput is.

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Fix Version: 3.0 Alpha 1 [ 10331 ]

Fix Version: 3.0.0 [ 10048 ] =>

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Link: This issue is duplicated by CORE3044 [ CORE3044 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: Simon (daytripper)

Hi all,

Does FB 3.0 snapshot build contains any new SMP enabled code for SuperServer (like in Vulcan port) ?.

Regards

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

Nope, it will be available later, once they're tagged as Alpha 1.

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

assignee: Dmitry Yemanov [ dimitr ] => Vlad Khorsun [ hvlad ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

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

resolution: Fixed [ 1 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

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

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

No branches or pull requests

2 participants