Delphi 一套成熟的ERP软件编译的时候出现Out of memory，怎么解决呢

Posted 2023-04-05

这个鬼知道啊！
如果长时间运行出了这问题 可能是资源没释放好
如果一开始编译就出现问题，
那就说明是代码问题。
有次我用的控件版本和原来用的版本不一致也出现了这问题。
如果不是控件问题，那可以考虑是代码问题。
是否可以最小化代码试试（在程序里注释掉代码，再运行，如果没问题，就逐步取消部分注释的代码。） 参考技术A 可能是数据过多造成的 导致软件崩溃。
如果找技术支持人员的话，减少不必要数据的检索，做软件的优化。或者开销允许的话直接做软件的升级。 参考技术B 工程可能太大了，换台好点电脑试试。

SaaS规模效应及其成熟度模型

　　SaaS软件相对传统软件而言，具有强大的规模效应。就传统软件而言，每部署一套应用都需要配置相应的服务器，网络设备，运维人员及进行一定程度的定制化开发，成本随部署应用的增多以恒定的速率上升。但SaaS模式只部署一套软件实例，所需投入的开发、服务器、运维人员是明确的。随着客户规模的上升，分摊到单个客户所需要承担的成本将进一步下降。如图所示：

　　在软件初期，SaaS模式需要投入的软件综合使用成本会比传统模式高，但随着客户数的增加，SaaS模式的”规模效应”的逐渐形成，其综合使用成本上升幅度不大，并逐步趋于平稳。反观传统模式，随着客户数的增加，所需投入的软件综合使用成本一直以恒定的增幅上升。

　　SaaS应用具有可预期的规模效应，这种规模效应不仅仅是商业上的问题，更是一个应用架构的问题，只有更稳定优良的应用架构，才能更好的支撑SaaS。根据是否具有可配置性、高性能、可伸缩可将SaaS成熟度分为四级，每一级都比前一级增加三种特性中的一种。

Level1:定制开发

　　为用户提供专用的数据库实例及应用服务器实例，依据用户实际需求进行定制化开发，其实最初的SaaS应用成熟度模型，在技术架构上和传统项目型软件开发或软件外包没什么区别。有一个客户项目，就按照客户的需求来定制一个版本，每个客户都有一份独立的代码，各版本间可通用的只有少量可重用软件，库及开发人员经验。

　　虽然最初级的SaaS模型，在应用架构上和传统软件模式并没有什么区别，但，在商业模式上，最初级的SaaS模型和传统软件模式，还是存在本质上的区别–即软硬件及相应的维护职责都由SaaS服务商提供，用户按需缴纳费用即可使用。

Level2:可配置

　　还是为用户部署单独的运行实例，但有效的减低了第二次开发的成本，通过可配置的形式，满足用户的基本需求。

　　最初级的成熟度模型，显然并不是良好的SaaS成熟度模型，每次新增用户都需要进行定制化的开发，单独部署。这种模式势必会导致随着客户数的增加，需要投入的定制化开发成本，软硬件已经运营成本，都将随着客户的增加而按照比较增加。

　　但这种模式达到一定规模后，想要进一步扩大规模，基本上就只能依赖于人肉战术了。

　　所以，首先需要解决的问题就是降低定制化开发成本。SaaS第二级依赖的解决方案，就是通过可配置化实现有效降低开发，进而达到缩减成本的目的。希望通过可配置化来满足不同客户的需求，而不需要为客户进行特定的开发。

　　但是，其实通过描述可发现，在第二级模型中，软件的部署架构并没有发生多大的变化，依旧是为每个客户部署一个运行实例，只是每个运行实例都是运行着同一份代码，通过配置的不同来满足不同客户的需求。

Level3:高性能多租户架构

　　从应用架构的角度而言，第一级和第二级成熟度模型和传统软件并没有太大的区别，只是在商业模式上比较符合SaaS的定义。由于其应用架构的设计是为每一个新的租户都单独部署一份软件实例，在一对一的架构，势必会导致需要维护软硬件成本，随着新租户的增加而直线上升，无法有效的发挥SaaS模式的规模效应。

　　所以，多租户单实例的SaaS架构才是通常上真正意义的SaaS模式，多个租户对应一个软件实例可有效的降低软硬件成本，充分发挥SaaS模式的规模效应。

　　实现多租户模型的关键是通一定的策略来确保用户数据的独立性，用户共享统一的应用实例，势必会对数据独立性提出一定的要求，在用户需求差别不大，客户数量不多时，讲一个第一级/第二级成熟度模型改造成多租户并不会太复杂，通常可以通过独立数据库，共享数据库独立数据结构，共享数据结果实现。

Level4:可伸缩性多租户架构

　　该级别的初始目的为了实现在用户数大量增加的情况下，无须更改应用架构，只需要简答的增加硬件部署的数量，就可支撑应用规模的增长。在架构设计中的Tenant Load Balaner层将会保存用户，租户与对应软件实例的映射，用户登录后，即刻映射到对应的软件实例。

往期 精彩回顾