#云

我们一开始并没有大的人工智能战略。

我们有一个传统的 InterSystems Caché 2018 应用程序、大量老旧的业务逻辑和一个实际需求：构建一个新的用户界面并改进已运行多年的代码。起初，我认为人工智能编码代理只能帮助完成一小部分工作。也许是一些模板、系统周围的一些 REST 工作，以及帮助阅读旧的 ObjectScript。

但实际上，它的作用远不止这些。

当我们开始认真使用它时，我们意识到它可以跨越庞大的代码库，理解模式，提出重构建议，并帮助我们以比我预期快得多的速度实现 Caché 的现代化。但这只是在开始时经历了一段令人沮丧的时期之后才发生的。

真正的挑战不是获得代码建议。而是教会代理我们的 Caché 环境如何实际运行。

我们为什么能使用它

在进行任何技术工作之前，我们必须回答一个安全问题。

我们不能将企业资源规划代码和内部业务逻辑直接发送给公共人工智能服务，并寄希望于最好的结果。这样做永远无法通过严格的安全审查。

亚马逊 Bedrock 改变了我们的想法。我们的服务器、数据和开发环境已经在 AWS 中，因此 Bedrock 可以很自然地融入我们已经信任和管理的云环境。我们可以使用该模型，同时将流量、访问控制和周边安全控制保持在我们已经在使用的 AWS 框架内。

有时，客户需要一个小型 IRIS 实例在云中执行某些操作，然后将其关闭，或者他们需要数百个容器（即每个最终用户或每个界面一个容器）来处理小型工作负载。 这个练习的目的是了解 IRIS 实例可以做到多小。在这次练习中，我们重点研究了IRIS 实例可配置的最小内存量。 您知道影响 IRIS 内存分配的所有参数吗？

内存设置

这些是影响 IRIS 内存分配的不同桶及其相应参数：

• 全局缓冲区（Global Buffers）（32 MB） => 8k 数据库的最小值似乎为 32 MB
• 常规缓冲区（Routine Buffers）（26 MB） => 文档中的理论最小值为 430 个缓冲区 x 每个缓冲区 64k ~ 26 MB，实际为 26 MB
• 日志缓冲区（Journal Buffers）（16 MB） => 理论上和实际上，Unicode 系统的最小值为 16 MB（8 位为 8 MB）
• 缓冲区描述符（Buffer descriptors）（3 MB） => 似乎是 3 MB，无法调整
• gmheap(16 MB) => 最小值为 256 页 x 每页 64k = 16 MB（CPF 中的配置字节数 = 16384）
• ECP(1 MB) => CPF 中有几个参数控制这个参数。MaxServerConn 和 MaxServers。