我们的商店已经为十几个客户端安装开发了一些WEB/SMS/DB解决方案。这些应用程序有一些实时性能要求,并且足以正常运行。问题在于,客户端(生产服务器的所有者)使用相同的服务器/数据库进行自定义,这会导致我们创建和部署的应用程序的性能出现问题。

一些客户定制的例子:

  • 为查询中转换为其他数据类型的列添加具有许多文本数据类型的大型表
  • 无主键、索引或 FK 约束
  • 使用外部脚本 count(*) from table where id = x, ,在脚本的循环中,确定稍后如何在同一脚本中构造更多查询。(规划者无法优化批量操作,或者只需一次完成所有操作)
  • 服务器上的所有新代码文件均由 root 创建/拥有,具有 0777 权限

客户不能很好地接受建议/批评。如果我们继续尝试自己移植/更改脚本,旧代码可能会回来,破坏我们所做的任何更改!或者,由于对他们的用例了解有限,我们在尝试优化他们的更改时破坏了功能。

我的问题是这样的:除了我们创建和部署的资源之外,我们如何限制查询/应用程序的资源?在这样的情况下有什么实用的选择吗?我们为拥有 OSS 解决方案而感到自豪,但它似乎已成为一种负担。

我们使用在 Linux Distos 上运行的 PG 8.3。客户更喜欢 php,但 shell 脚本、perl、python 和 plpgsql 都以一种或另一种形式在系统上使用。

有帮助吗?

解决方案

这个问题在第一个客户端获得对第一台计算机的完全访问权限后大约两分钟开始出现,此后一直没有消失。任何时候,如果一个人的首要任务是快速完成面向业务的工作,他们就会马虎行事,把每个人的事情都搞砸。这就是事情的运作方式,因为正确的设计和实施比廉价的黑客更难。你不会解决这个问题,你所能做的就是弄清楚如何让客户更容易与你合作而不是反对你。如果你做得对,它会看起来像是优质的服务而不是唠叨。

首先,数据库方面。现在有方法可以控制 PostgreSQL 中的查询资源。主要困难在于像“nice”这样的工具可以控制 CPU 使用情况,但如果数据库无法容纳在 RAM 中,那么很可能是 I/O 使用情况让您丧命。看到这个 开发者留言 总结一下这里的问题。

现在,如果实际上客户端正在消耗 CPU,您可以使用两种技术来改善这种情况:

  • 安装一个更改进程优先级的 C 函数(示例1, 示例2)并确保每当他们运行某些东西时它都会首先被调用(也许将其放入他们的 psql 配置文件中,还有其他方法)。
  • 编写一个脚本,查找由其用户 ID 生成的 postmaster 进程并重新启动它们,使其经常在 cron 中运行或作为守护进程运行。

听起来您的问题不是他们正在运行的特定查询进程,而是他们对更大的结构进行的其他修改。只有一种方法可以解决这个问题:你必须像对待入侵者一样对待客户,并使用计算机安全领域的该部分的方法来检测他们何时搞砸了。严重地!在服务器上安装像 Tripwire 这样的入侵检测系统(还有更好的工具,这只是典型的例子),并让它在它们触摸任何东西时向您发出警报。新文件是0777?应该直接跳出正确的 IDS 报告。

在数据库方面,您无法直接检测到正在被有用修改的数据库。您应该每天将架构的 pg_dump 到文件中(pg_dumpall -gpg_dump -s, ,然后将其与您交付的最后一个进行比较,并在更改时再次提醒您。如果您对此进行了很好的处理,那么与客户的联系会变成“我们注意到您在服务器上更改了……您想完成的工作是什么?”这使您看起来好像您真的在关注他们。这可以变成一个销售机会,他们可能会停止摆弄事情,因为他们知道你会立即抓住它。

您应该立即开始做的另一件事是在每个客户端机器上安装尽可能多的版本控制软件。您应该能够登录到每个系统,运行适当的状态/差异工具进行安装,并查看发生了什么变化。也定期将其邮寄给您。同样,如果与将模式转储为它所管理的组件的某些东西结合使用,效果最好。没有足够多的人对数据库中的代码使用严格的版本控制方法。

这是这里有用的主要技术方法。剩下的就是一个经典的咨询客户管理问题,它更多的是人的问题,而不是计算机的问题。振作起来,情况可能会更糟 - 如果您为他们提供 ODBC 访问权限,并且他们发现可以在 Access 中编写自己的查询或类似的简单内容,那么 FSM 会帮助您。

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top