火鸟架构
如何判断现有 Firebird RDBMS 服务器(即经典服务器或超级服务器)安装/配置/运行哪个架构?
如何-
如何在两种模式之间切换?
-
Firebird 的哪些版本(1.5、2.0、2.1)和架构(CS 或 SS)可以在多处理器服务器上使用?以及如何为多处理器服务器和多线程应用程序正确配置它们?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
1 -- 要了解哪个架构正在运行,请打开任务管理器并查看正在运行的进程。 fb_inet_server.exe代表经典架构,fbserver.exe——超级服务器。
2 -- 关闭所有客户端连接。到达 Firebird\Bin 目录。执行指定的命令序列:
然后:
或
之后:
3 -- Super Server 始终在单处理器或核心上运行,并且无法扩展。在SMP环境中使用经典架构。在后一种情况下,请勿指定超过 800-1000 的页面缓冲区。
请注意,经典服务器的性能取决于磁盘子系统的性能。
对于大型数据库,请使用具有内部高速缓存、电池和启用“写回”模式的 RAID 控制器。
1 -- To tell which architecture is running open Task Manager and look at running processes. fb_inet_server.exe stands for classic architecture, and fbserver.exe -- super server.
2 -- Close all client connections. Got to Firebird\Bin directory. Execute specified sequence of commands:
then either:
or
after that:
3 -- Super Server always runs on single processor or core and can not scale. Use Classic architecture in SMP environment. In latter case dont specify page buffers more than 800-1000.
Be aware that performance of Classic Server depends on performance of disk subsystem.
For big databases use RAID controllers with internal cache memory, battery and "write back" mode enabled.
几乎在所有情况下您都应该使用超级服务器。尽管超级服务器“仅”在一个 CPU 核心上运行,但它的速度基本上更快。其原因是数据库服务器负载。 它不渲染视频或计算小麦信息。它具有极高的 IO 负载。这意味着它从内存和驱动器读取和写入数据。经典和超经典服务器为每个连接创建缓存。这意味着 10 个不同的连接(例如 10 个客户端计算机)将拥有自己的缓存。假设他们正在使用相同的数据(客户、订单......)。问题是每个连接的缓存中都没有相关信息。因此每个连接都会从硬盘加载这些记录。这种行为会导致极高的驱动负载并减慢一切速度。超级服务器(版本将所有部分放在一起,超级服务器速度更快。而且我期待安装 firebird 3.0 版本,因为 firebird 3.0 超级服务器使用多个 CPU 并具有一个“共享”服务器缓存。
You should use the superserver in nearly every case. Although the superserver runs on "only" one CPU core, it's mostly faster. The reason for this is the DB server load. It's not rendering videos or calculating wheater information. It has an extreme high IO load. That means it reads and writes data from the memory and drives. The classic and superclassic server creates cache for every connection. That means that 10 different connections (for instance 10 client computers) will have their own cache. Let's say they are working with the same data (customers, oders...). The problem is that each connection does not have the relevant information in the cache. So every connection will load these records from the hard drive. This behavior causes an extrem high drive load and slows down everything. The superserver (version < FB 3.0) is just using one CPU core, but has one cache. So user 2,3..10 doesn't have to load the data from the drive because user 1 already loaded it into the server cache. Taking all pieces together the superserver is faster. And I'm looking forward to installing the firebird 3.0 release because the firebird 3.0 superserver uses multiple CPUs and has one "shared" server cache.
isql
from https://ib-aid.com/en/articles/how-to-determine-firebird-architecture-with-sql-query/ :