2014-03-06 19 views
1

进程版本11.0 srt *(srt)排序/临时文件在RHEL Linux 6.0中增长很大。与Webspeed用于Web应用程序的特定数据库隔离。使用-T开关参数来定义文件的位置。不使用-t,因此文件断开连接并且不在文件系统上显示。大型srt *文件正在进行中4gl

在shell执行lsof显示文件增长到GB大小并增加。第三列是大小在轮空:

_mprosrv 29968 3862790144的/ usr /温度/ srtJrjsxX(删除)

_mprosrv 31588 15290187776的/ usr /温度/ srtVEi9Lp(删除)

_mprosrv 32644 1533157376的/ usr /温度/ srtTozP1W(删除)

_mprosrv 32667 3890683904在/ usr /温度/ srte5qI1U(删除)

有没有办法来限制这些临时文件的大小或增长如此之大的阻止他们?

回答

1

如果您使用11.0,请考虑升级到11.2或更高版本。

显然有一个错误(称为缺陷OE00227173,在11.2中修复),其中一些大型查询会导致_mprosrv进程不断增长其.srt文件,而不是按照它们应该重用的文件空间。

从发行说明:

发行编号:OE00227173 临时排序文件成长的每一个查询被执行

时间运行在一个字索引的通配符搜索时,该搜索 将在数据库服务器上创建一个srt文件。如果查询返回大量的行数(大于100,000),则排序文件中的空间不是 完全重新使用,并且.srt可能会变得非常大。

暂时缓解可以通过从所讨论的服务器的PID断开用户会话,然后终止所述服务器进程(最好用PROMONř& d,4,7,7-)中找到。

def var v-pid as int format ">>>>>>>>>9" label "Server PID" no-undo. 

do while true: 
    update v-pid with frame f1 side-labels. 

    find _server where _server._server-pid eq v-pid 
     no-lock no-error. 
    disp _server with frame f2. 

    for each _connect where 
     _connect._Connect-Server eq _server._server-num /** NOT _server-id **/ 
     no-lock: 

     find _userio where _connect._connect-id eq _userio._userio-id 
     no-lock no-error. 

     disp _connect._Connect-Usr /** NOT _Connect-Id **/ 
      _connect._Connect-Name 
      _connect._Connect-Device 
      _connect._Connect-Time 
      _connect._Connect-Pid 
      _userio._userio-dbaccess 
      _userio._userio-dbread 
      _userio._userio-dbwrite. 

    end. 
end. 
+0

这样的声音解决了我们遇到的确切问题。当在字词索引中进行具有通配符的搜索时,我们可以看到文件增长。谢谢 – MikeM

+0

也意识到,作为临时措施,您可以使用特别大的srt文件停止服务器进程以释放该磁盘空间。 (无论是直接杀死还是提示R&D,4,7,7 ...)当然,连接到该服务器的任何用户都可能会断开连接,直接杀死服务器进程可能会导致数据库崩溃。最好首先断开用户与服务器PID的关系[可能在系统安静的时候,如果存在]。 – user3466351

+0

添加代码以获取每个服务器的用户PID ... – user3466351

1

不,没有参数来限制它们。了解你在做什么来促进增长是关键。通常它们是缺少适当索引的查询的结果,因此必须有客户选择和排序的记录。

我想:

  • 在客户端上启用-t这样就可以实时监控SRT文件增长。
  • 启用客户端语句缓存,以便您可以确定在增长发生时哪个源代码模块负责哪一行代码中的哪个查询。
  • 编译XREF和调试,使您可以查看表扫描代码(XREF“整个索引”引用)和http://dbappraise.com/protop.html发现语句缓存中的信息
  • 下载PROTOP 3(调试)源代码行,这样就可以实时监控
  • 查询活动的-noautoresultlist参数添加到您的客户端启动(这是不是万能的,但它可能在某些情况下帮助)
  • 如果你碰巧赶上“的行为,”客户端不声明缓存启用发送“kill -USR1”,然后查找并检查protrace中的4gl堆栈跟踪。 (可能在客户端的启动目录中)
+0

审议了以下进展文章http://knowledgebase.progress.com/articles/Article/P95930?popup=true任何帮助查明其代码/查询:

代码由服务器PID获取用户实际上是在增长? – MikeM

+0

我会启用客户端语句缓存,PROMON,R&D,1,18 –

+0

一旦它们变得太大以致只能杀死与SRT文件相关联的PID的任何副作用,因此它们的空间可以被回收?看起来像是一旦杀死了应用程序中的查询被执行时重新创建的文件。 – MikeM