Something Wrong? no reason iristemp grow to ful disk

Primary tabs

No reason apparently,

to many times executed :

[Database.SparseDBExpansion] Expanding capacity of sparse database /usr/irissys/mgr/iristemp/ by 1000 MB.

no details on audits, no traffic for that, no process to justify this, some ideas ?

IRIS for UNIX (Red Hat Enterprise Linux for x86-64) 2020.1 (Build 215U) Mon Mar 30 2020 20:23:13 EDT

Replies

Sorry, not enough data on my question,
this machine work as "ensemble",
more bigger database have no more 40Gb (production active),
iristemp growth from aprox 10Gb  to 106Gb,
after init Iris Again i move this database to another disk, and use truncate button, the screen show 24 Gb size, not file total size, after run process file and portal show lower 100Mg file
this machine use outbound queries ODBC, not inbound queries exists, this outbound queries get a lower number of rows,
some process clean tables used as temporal data extracted from Non Iris database to transfer this data to another Iris Server
This machine work on Failover Cluster, the other machine have no news after shutdown
Only one special condition, this cluster work without arbiter
After start iris again i read Audit and logs, not a clue in Iris or Linux logs

ghost in the machine ?

Hi Hansel,

Temp should only grow because of use of temporary globals. (^IRIS.temp, ^mtemp, or any other global explicitly mapped to IRISTEMP)
In my experience, sudden growth of temp is mostly due to an SQL query that is doing a join or order of non-indexed columns.
When you restart Iris, you could delete the iristemp (it will recreate it), you can also set a param to truncate it automatically at startup:
https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls...
 

Hansel, you may want to reach out to the InterSystems WRC for help if you have not found the cause on your own. 

Erik

I would suggest a few points, how to catch what's going on wrong with the unexpected growth of databases, it's not actually really matter iristemp/cachetemp or some other.

  • zn "%SYS" Do ^GLOBUFF - will show you the biggest globals in the Global Buffer, useful tool to inspect slowness as well. If you see that some global from iristemp uses too much of global buffer, you can use it to investigate further
  • Integrity check for growing database, if the size not too big, it's the simplest way to understand the sizes of globals in the database.

When you found exact global name, you now have a point where to start an investigation.

If you stopped IRIS, you can just delete IRISTEMP, it will be recreated as a new in any way, after the start.