一个实例中可创建的最大命名空间数量为2048个。这个上限不可修改。

一个实例中可创建的最大数据库数量（包括远程数据库）为15998个。这个上限也不可修改。

一个实例中可创建数据库的总数量还有其他因素制约：

1. 数据库路径信息总量最大为256KB，也就是所有数据库的路径字符加起来不能多于256KB。设置的路径越长，可创建的数据库数量越少。
计算公式：最大数据库数量=258048/(平均数据库路径长度+3)

2. 镜像的数据库一个按两个算。也就是创建一个镜像的数据库，相当于创建了2个非镜像数据库。

更多细节请参考在线文档：
https://docs.intersystems.com/irislatest/csp/docbook/Doc.View.cls?KEY=GS...

虽然 Caché 和 InterSystems IRIS 数据库的完整性完全不会受到系统故障的影响，但物理存储设备故障确实会损坏其存储的数据。 因此，许多站点选择运行定期数据库完整性检查，尤其要与备份配合，以验证在发生灾难时是否可以依赖给定的备份。 系统管理员在应对涉及存储损坏的灾难时，也可能强烈需要完整性检查。 完整性检查必须读取所检查的 global 的每个块（如果尚未在缓冲区中），并且按照 global 结构指示的顺序读取。 这会花费大量时间，但完整性检查能够以存储子系统可以承受的最快速度进行读取。 在某些情况下，需要以这种方式运行以尽快获得结果。 在其他情况下，完整性检查需要更加保守，以避免消耗过多的存储子系统带宽。

行动计划

以下概述适合大多数情况。 本文其余部分中的详细讨论提供了采取其中任一行动或得出其他行动方案所需的信息。

在我发了前一个帖子后，有人催促我说重点 - 好吧，于是我找到了我的“明星”日志 global，也就是那些最占空间的 global - 但如何避免这种情况呢？ 如何最大程度地减小日志？

[免责声明：有些人在看到本帖后可能仍然会失望 ，那就等下个帖子吧... ]

InterSystems的产品包括Caché/Ensemble/Health Connect/IRIS/IRIS for Health，均基于进程，当它们及在它们之上开发的应用运行时，您能在操作系统上看到大量cache/irisdb进程。下面以InterSystems IRIS为例，来说明下InterSystems产品的内存使用。

InterSystems IRIS进程的内存使用主要有以下两大类，

第一类，进程私有内存。

私有内存只由该进程使用，且会为每个进程单独分配。进程初始时会被分配128KB的内存空间，随着进程运行根据需要，这个内存空间会自动扩展。
InterSystems IRIS对于进程内存使用的限制是Maximum Per-Process Memory, 该参数的设置位置在系统管理门户SMP，System > Configuration > Memory and Startup，允许的取值范围是256KB到2147483647KB（2TB）。如果系统遇到<STORE>错误，那么可以尝试增加该数值，来解决进程运行时无法申请到更多内存的问题。从InterSystems IRIS开始，我们推荐将该值设置为-1, 也就是取上限2TB。

在最近的大规模基准测试活动中，我们看到过多的%sys CPU时间，对应用程序的扩展产生了负面影响。

问题

我们发现，由于TZ环境变量没有被设置，很多时间都花在了localtime()系统调用上。 我们创建了一个简单的测试程序来证实这一观察结果，设置了TZ与未设置TZ的时间差和所需的CPU资源都是惊人的。 我们发现，当TZ没有设置时，从localtime()继承使用stat()系统调用到/etc/local_time是成本很高。

本帖的目的是回答一个问题。 在本系列的第二篇帖子中，我包括了从 pButtons 提取的性能数据的图表。 有人在线下问我，有没有比剪切/粘贴更快的方法从 pButtons .html文件中提取 mgstat 等指标，以便在 Excel 中绘图。

参见：- 第 2 部分 - 研究收集的指标

pButtons 将其收集的数据编译成一个 html 文件，以便发送给 WRC 和查看整理的数据。 不过，尤其是对于长时间（如 24 小时）进行收集的 pButtons 来说，一些基于时间的数据（如 mgstat、vmstat 等）以图形方式查看更容易查找趋势或模式。

当您首次使用InterSystems IRIS时，通常只需安装最低安全级别的系统。您输入密码的次数会比较少，这样有利于快速了解和操作开发服务和Web应用程序。而且，最低的安全性有时更便于部署开发项目或解决方案。

然而，有时需要将项目移出开发环境，迁移到一个可能很不友好的互联网环境中。在部署到生产环境之前，需要使用最大的安全设置（即，完全锁定）对其进行测试。这就是我们在本文中将要讨论的内容。

如果想更全面地了解InterSystems Caché、Ensemble和IRIS中的DBMS安全性问题，请阅读我的另一篇文章《在生产环境中安装InterSystems Caché DBMS的相关建议》。

InterSystems IRIS中安全系统的设计概念是针对不同的类别（用户、角色、服务、资源、特权和应用程序）应用不同的安全设置。

可以为用户分配角色。用户和角色可以对资源（数据库、服务和应用程序）拥有不同的读、写和使用权限。用户和角色还可以对数据库中的SQL表拥有SQL权限。

系统实用类：SYS.Database中的查询FreeSpace可以用来在任何时候检查磁盘上的自由空间。

下面是在IRIS终端中的尝试方法（进入%SYS命名空间，然后运行它）。

zn "%SYS"
set stmt=##class(%SQL.Statement).%New()
set st=stmt.%PrepareClassQuery("SYS.Database","FreeSpace")
set rset=stmt.%Execute()
// 一次性显示所有
do rset.%Display()

输出结果示例如下。

*在命令执行的例子中，所有的数据库都放在同一个磁盘上，所以所有的磁盘空闲空间（DiskFreeSpace）返回相同的值。

我本人和其他技术架构师经常需要向客户和供应商说明 Caché IO 要求以及 Caché 应用程序使用存储系统的方式。 在向客户和供应商说明典型的 Caché IO 配置文件和事务性数据库应用程序的要求时，下面的表格很有用。 原始表格由 Mark Bolinsky 创建。

在以后的帖子中，我将讨论更多关于存储 IO 的内容，所以现在贴上这些表格也作为将来文章的参考。

我们不必等待SAM发布才开始规划和试用该API来监控IRIS实例。在以后的文章中，我将更深入地探讨可用的指标及其意义，并提供一些交互式仪表板的示例。首先，我将介绍一下相关背景和一些问题及答案。

IRIS（和Caché）一直在收集自身及其运行平台的数十个指标。收集这些指标来监控Caché和IRIS的方法向来有很多。我发现，很少有安装软件使用IRIS和Caché的内置解决方案。譬如，History Monitor作为性能和系统使用指标的历史数据库，已经推出很长时间了，但它没有简便方法可实时显示这些指标和仪表系统。

IRIS平台解决方案（以及整个业界）正在从仅在一些本地实例上运行的单体式应用程序过渡到“随处”部署的分布式解决方案。在许多用例中，原有的IRIS监控方案并不适用于这些新的模式。InterSystems没有做重复工作，而是将目光投向当前流行的、经过验证的监控和告警开源解决方案。

在一次重大的版本升级中，建议重新编译你所有命名空间的类和例程。 (主要版本的安装后任务).

do $system.OBJ.CompileAllNamespaces("u")

do ##Class(%Routine).CompileAllNamespaces()

为了自动完成这项管理任务并记录任何错误，下面是一个导入并编译到USER命名空间的类的例子，你可以在每次升级后使用它 : admin.utils.cls