Something Wrong? no reason iristemp grow to ful disk
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
Could be a xDBC query that is using too much temp space
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...
by the way great album : The Police - Ghost in the Machine
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.
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.
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.