This presentation was made at Firebird Conference 2008 in Bergamo, Italy, by Dmitry Yemanov. Presentation is devoted to the new architecture type introduced in Firebird 2.5 - SuperClassic. Firebird SuperClassic introduces the major step to more effective and scalable SMP support in Firebird.
2. DEVEL-A35 Dmitry Yemanov
Firebird 2.5
Rationale
First step in the Classic/SuperServer unification
Codebase modernization
Common threadable architecture
and more efficient multi-threading support
A number of new features
Intermediate release between v2.1 and v3.0
2
3. DEVEL-A35 Dmitry Yemanov
Threadability as a Primary Goal
Major MT cleanup
Only threadable platforms are supported
Old synchronization logic is updated
Generic thread safety everywhere,
starting from the API (both client and embedded)
Better scalability
No cooperative scheduling anymore
Say “goodbye” to the global mutex
Synchronization goes to the lower levels
3
4. DEVEL-A35 Dmitry Yemanov
Threadability as a Primary Goal
Server layer / remote subsystem
Worker thread pooling
Asynchronous connection cleanup
Unified listener code for SS and CS
Lock management
Non-blocking notifications
No need in the static semaphores setup
Per database lock tables
4
5. DEVEL-A35 Dmitry Yemanov
Effects for the Supported Architectures
Classic Server
Lock manager doesn't need explicit semaphores
and signals setup anymore
fb_lock_mgr binary is deprecated on POSIX
Services and automatic sweep are executed
as threads (less processes spawned)
Server layer may determine broken network links
immediately and terminate the worker process
libfbembed.so is thread-safe
5
6. DEVEL-A35 Dmitry Yemanov
Effects for the Supported Architectures
SuperServer
Better overall scalability and respond timings due
to a lower-level synchronization inside the engine
SMP/multi-core hardware can be utilized efficiently
when multiple databases are accessed
simultaneously
fbclient.so/.dll is thread-safe
6
7. DEVEL-A35 Dmitry Yemanov
Effects for the Supported Architectures
Embedded Server
Now based on the Classic architecture,
including all the benefits of the SuperClassic
Multiple processes can safely access the database
Official utilities (gbak, gfix, isql, etc)
can be used as well
fbembed.dll is thread-safe
7
8. DEVEL-A35 Dmitry Yemanov
What is Super Classic?
Architecture
Single process, multiple worker threads (pooled)
Per connection page cache and metadata cache
A number of in-process optimizations
Database access can be safely shared among
Classic, SuperClassic and Embedded processes
8
9. DEVEL-A35 Dmitry Yemanov
What is Super Classic?
Classic Embedded
SuperClassic Classic Embedded
Classic Embedded
Database
9
10. DEVEL-A35 Dmitry Yemanov
What is Super Classic?
Benefits as compared to Classic
Less kernel resources (but not memory) used
Scalability limits are shifted
Better performance due to local calls inside the lock
manager and other in-process optimizations
(25% performance boost in TPC-C)
Server can be safely shutdown as a whole
Possibility to enumerate attached databases/users
Security database connection is cached
10
11. DEVEL-A35 Dmitry Yemanov
What is Super Classic?
Benefits as compared to SuperServer
Better scalability
(number of connections is not explicitly limited)
Better concurrency on SMP/multi-core hardware
More responsive under high load
11
12. DEVEL-A35 Dmitry Yemanov
What is Super Classic?
Drawbacks
Still ineffective memory usage
High lock table contention (page locks),
requires careful tuning of the LM configuration
Server crash affects all user attachments
Doesn't make much sense on 32-bit systems
12
13. DEVEL-A35 Dmitry Yemanov
What is Super Classic?
How to use on Windows
The same binary as for the regular Classic
Application: fb_inet_server.exe -a -m
Service: instsvc install -m
How to use on POSIX
New fb_smp_server binary
No need in [x]inetd
13
14. DEVEL-A35 Dmitry Yemanov
Combined Efforts
Firebird team
Synchronization inside the core engine
SuperClassic and Embedded modes
Updated lock manager
Remote subsystem rework
SAS Institute
Concurrency testing, SuperClassic/Embedded
RedSoft Corporation
Concurrency testing and bugfixing
14
15. DEVEL-A35 Dmitry Yemanov
Evolution in Firebird 3.0
Architecture
Single server, different working modes:
- shared – multiple server processes (CS like)
- dedicated – standalone server process (SS like)
Per database configuration
Multi-threading abilities
Full cross-attachment concurrency
Prepared statements cache
15