在我发了前一个帖子后，有人催促我说重点 - 好吧，于是我找到了我的“明星”日志 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是成本很高。

建议

InterSystems强烈建议在任何Linux安装中，无论是x86还是Linux on Power，都要确认TZ环境变量的设置是否适当，以获得最佳性能。 更多详情请见。"man tzset"。

目前的Caché 2016.1现场测试包含了对日期和时间功能的优化，初步测试表明有很大的改进。 下面是测试新的内部函数调用的样本输出，在这两种情况下，在Power上的Linux都没有设置TZ。

在Caché 2016.1 FT之前:

本帖的目的是回答一个问题。 在本系列的第二篇帖子中，我包括了从 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 的内容，所以现在贴上这些表格也作为将来文章的参考。

本系列其他帖子的列表

拥有设置良好的存储（如存储阵列）以提供可预测的磁盘 IO 性能，支持高可用性功能并为应用程序提供存储冗余、可伸缩性和可靠性，这几点至关重要。

Caché 存储 IO 配置文件

根据所选的存储阵列技术，物理层的磁盘存储可分为池或磁盘组。 如果可能，出于可用性和性能考虑，应根据预期的 IO 配置文件对存储进行分区。 例如，数据和日志（事务日志）应该在不同的物理磁盘组上，因为它们有不同的 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