Issue Details (XML | Word | Printable)

Key: CORE-775
Type: New Feature New Feature
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Vlad Khorsun
Reporter: Pavel Cisar
Votes: 46
Watchers: 23

If you were logged in you would be able to see more operations.
Firebird Core

True SMP support for SuperServer

Created: 17/Sep/03 12:00 AM   Updated: 27/Mar/14 12:00 PM
Component/s: Engine
Affects Version/s: None
Fix Version/s: 3.0 Alpha 1

Issue Links:

SF_ID: 807899

 Description  « Hide
SFID: 807899#
Submitted By: pcisar

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

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Lewis Mettler added a comment - 31/Dec/08 04:08 PM
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 if this kind of application would be useful for testing purposes.

Fidel Viegas added a comment - 06/Mar/09 06:05 PM
Hi Lewis,

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

Lewis Mettler added a comment - 07/Mar/09 12:30 PM
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.

Simon added a comment - 03/Dec/10 08:13 PM
Hi all,

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


Dmitry Yemanov added a comment - 04/Dec/10 09:07 AM
Nope, it will be available later, once they're tagged as Alpha 1.