Something Wrong? no reason iristemp grow to ful disk

Question

Question

Hansel Rudy Sta... · Sep 14, 2020

#System Administration #InterSystems IRIS

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

Discussion (7)1

Log in or sign up to continue

Danny Wijnschenk · Sep 14, 2020

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...

0 0

score 0 · Answer 1 · 2020-09-14T10:19:10-04:00

Danny Wijnschenk · Sep 14, 2020

Could be a xDBC query that is using too much temp space

0 0

score 0 · Answer 2 · 2020-09-14T13:02:34-04:00

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 ?

score 1 · Answer 3 · 2020-09-15T03:45:57-04:00

Danny Wijnschenk · Sep 15, 2020

by the way great album : The Police - Ghost in the Machine

1 0

score 0 · Answer 4 · 2020-09-17T07:09:46-04:00

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

Erik

score 1 · Answer 5 · 2020-09-14T14:43:30-04:00

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.

score 0 · Answer 6 · 2020-09-23T08:45:25-04:00

IRISTEMP is a bit different than other databases. For example, it holds the PPGs. If you're seeing growth in IRISTEMP specifically, then in addition to the other debugging suggestions I would also run:

d ^GETPPGINFO

to get the counts of PPG blocks. You need to run this before the process which is causing the problem goes away and its blocks are automatically released to get any useful information.